Friday 30 November 2012

Network Installation Manager (NIM) -- Part 1 Introduction & Concepts


Introduction

       NIM (Network Installation Manager) is a IBM AIX  Service used for remote unattended installation similar to the Sun/Oracle Jumpstart and RedHat Kickstart or PXE without DVD/CD used to install AIX in many servers at a time in an Infra. Now, the installation of VIO and Linux can also be performed using NIM. Apart from installation, upgradation and maintainig AIX softwares/filesets the management activities like backup and restore of mksysb can be performed via NIM. By using NIM Master to store mksysb can reduce usage of tape device and time duration.

Activities performed by NIM
        1) New Installation (Pull method)
        2) TL/SP upgradation
        3) OS Migration/Upgradation
        4) mksysb backup/restore
        5) Provide boot CD image for maintenance activities
        6) Centralized repository for Filesets
        7) Used to restore missed files in the mksysb backup

Components of NIM
     The following are the important components involved in NIM installation, confiugration and managment.
   1. Master (NIM Master)
   As named NIM Master server is the repository of all the softwares, OS images, mksysb backup which serves the same to its clients for the corresponding operations.
   2. Client (NIM Client)
    Systems which are managed by NIM Master server for the operations like installation, backup and restoration 
   3. Resources (NIM Resources)
    This can be a single file or up to a whole filesystem that is used to provide some sort of information to, or perform an operation on a NIM client. Resources are allocated to NIM clients using NFS and can be allocated to multiple clients at the same time. The NIM resources are lpp_source,SPOT,mksysb,bosinst_data and image_data
   4. Resource Server 
     Server where resources are available. NIM client can also act as Resource Server. But in most cases NIM Master server will be the resource server. Briefly discuss types of  resources in consecutive sections.
   5. NIMSH Daemon (NIM Service Handler)
     For environments where the standard "rsh" protocol are not enough secure, at the time "nimsh". Using the port nos 3901 and 3902
   6. Allocate/Allocation :
      This process is what allows your NIM client to access resources in NIM. The master uses NFS to perform the allocation process. Resources can be allocated to one or more NIM clients at the same time

NIM RESOURCES

a) lpp_source
           It is just a directory which acts as source of installation which contains the following
                     *  OS image cd/dvd
                     *  filesets/packages
                     *  TL/SP updates
            These type of resources can be used for all NIM clients.
b) SPOT (Shared Processor Object Tree)
           It is similar to boot cd, we can boot the nimclient using the SPOT. It contains the "/usr" part i.e., kernel, filesets, device drivers and BOS install programs.
           There are 2 types of SPOT i) lppspot and ii) mksysbspot and these types of SPOT are specific to particular NIM client or can be used  for all NIM clients.
c) mksysb
         In general, rootvg backup is the mksysb backup which may be specific to particular NIM client.
         Important advantages are quick restoration of crashed OS and can create customized (hardened) mksysb backup of particular which could be installed/resotred in other servers to avoid fresh installation and performing hardening.
d) bosinst_data
       Customized Installation Procedure (bosinst.data) which is used in non-interactive installation, mainly POST installation changes.
e) image_data
        image.data (rootvg architecture) layout of LV,VG,PP information and its architecture.


Daemons Required
  a) bootp protocol (BOOTPD)
   This is the initial communication made between NIM master and client during network boot. 
  b) Trivial File Transfer Protocol (TFTPD)
  It is used to transfer lppsource,SPOT and other resources from NIM server to NIM client during the NIM client booting.
Check the services are running, 
#lssrc -ls inetd
bootps    /usr/sbin/bootpd   bootpd /etc/bootptab     active
tftp         /usr/sbin/tftpd        tftpd -n                    active
#grep bootps /etc/services
bootps                  67/tcp          # Bootstrap Protocol Server
bootps                  67/udp        # Bootstrap Protocol Server
#grep tftp /etc/services
tftp                    69/udp          # Trivial File Transfer
tftp                    69/tcp          # Trivial File Transfer
If the above services are not enabled, start the same.
#chubserver -v bootp -p udp -a 
#chubserver -v tftpd  -p udp -a
#refresh -s inetd
   Also, ensure NFS group related services are  also enabled.
#startsrc -g nfs

Important Directories and Files
   a) /tftpboot
     When we create SPOT, kernel is copied into /tftpboot directory . All kernles of NIM clients are in the direcotry
root@aixnim1: /etc # ls -l /tftpboot
lrwxrwxrwx    1 root     system           34 Dec 19 18:36 aix21.domain.com -> /tftpboot/spot_5200-08.chrp.mp.ent
-rw-r--r--    1 root     system         1276 Dec 19 18:36 aix21.domain.com.info
-rw-r--r--    1 root     system      9379964 Dec  8 15:31 spot_5200-08.chrp.64.ent
-rw-r--r--    1 root     system      9260943 Dec  8 15:31 spot_5200-08.chrp.mp.ent
   b) /etc/bootptab
      File which authenticate nim client for remote boot up for nim operations like bos installation, restoration & maintenance boot. Based on the NIM operation, nim client info update and once the NIM operation completed, entry also removed automatically from this file.
      In simple words, authenticates NIM client for remote boot up.
#tail /etc/bootptab
aix21.domain.com:bf=/tftpboot/aix21.domain.com:ip=10.200.50.56:ht=ethernet:sa=50.20.100.48:gw=10.200.50.1:sm=255.255.255.0:
The fields are separated with colon (:) and attributes are separated with equal sign (=):
    first field  - NIM client name
           bf       - boot file name
           ip       - NIM client IP address
           ht       - hardware type
          sa       - TFTP server address for the boot file
          gw      - gateway used by client to reach the server
          sm      - subnet mask for the nim client
  c) /etc/niminfo
       The file always exists on the NIM master and client. contains information about who is master and client, port no, protocol informations.
        This is automatically generated when master was created and client was registered to master. This file was not manually edited. If any corrupted, want to be removed and recreated.
 1)Rebuild on Master
        #nimconfig -r
 2)Rebuild on Client
        #nimint -a master=<MASTER_HOSTNAME> -a name=<CLIENT_NIM_NAME>

Filesets Required
   bos.sysmgt.nim.master
   bos.sysmgt.nim.spot

Useful NIM Basics Link
http://www.youtube.com/watch?v=UBbhoSUnCwE



Thursday 29 November 2012

HMC Commands

In general, HMC operations in CLI  are categorized under the following commands,
  • chsystate
  • lssyscfg
  • lssysconn 
1) To display MS connected with HMC
    $lssyscfg -r sys -F name state
    

2) To display LPARs in managed system
  $lssyscfg -r lpar -m appserver -F name state

3) To lists attributes of Managed systems
   $lssysconn  -r sys

4) To power ON managed system
    $chsystate -r sys -m Msserver -o on

5) To power OFF managed system
    $chystate -r sys -m Msserver -o off

6) To start the LPAR in sms
    $chystate -r lpar -m Msserver -n lpar_name -o on -f normal -b sms

7) To shutdown the LPAR
    $chystate -r lpar -m Msserver -n lpar_name -o shutdown –immed

8) To find the hmc version
    $lshmc -V

9. Show processor information of the LPAR
    #lshwres -m  <Msname>  -r  proc –level lpar

10.Show the processor information of the Managed server
    #lshwres -m  <Msname>  -r proc –level sys

11.Show the memory information of the Managed server
    #lshwres -m <Msname> -r  mem –level sys

12. Show the memory information of the LPARs
   #lshwres -m  <MS.name> -r mem –level lpar

13.Shows the io slot information
   #lshwres -m <MS.name> -r io –rsubtype slot

14.Show the SCSI devices by the LPAR.
   #lshwres -m <MS.name> -r virtualio -rsubtype scsi –level lpar

15.Shows the virtual ether devices by LPAR
   #lshwres  --m <MS.name> -r virtualio -rsubtype eth –level lpar 



SSH login slowness troubleshooting

           In newly installed servers, while trying to login using  "ssh" we may feel some slowness to get the password prompt . Most of us think that this is due to network level DNS issue, but actually the assumption is wrong there is a  parameters in the SSH configuration file which makes delay in getting this password prompt.

          Let us see the solution for the above issue in Sun SSH and Open SSH.

In SunSSH, 

Add the mentioned parameter in the file /etc/ssh/sshd_config
LookupClientHostnames no

In OpenSSH,

Edit the mentioned parameter in the file /etc/ssh/sshd_config
UseDNS no
              After that restart the ssh service and check the response of quick password prompt while login to the servers through ssh

Wednesday 28 November 2012

Lesson-4 Object Data Manager (ODM)

What is ODM ?
  • ODM – Object Data Manager  is the database for storing system information.
  • Physical and logical devices  information are stored and  maintained as objects in ODM.
  • It is in binary format hence can't view or edit.
  • Whenever we add, delete and configure the devices in OS, the entries will be added in ODM
System Data Managed by  ODM

1) Device Configuration information (Predefined and Customized Devices )
2) Software Vital Product Data (SVPD)
3) System Resource Controller
4) TCP/IP configuration information
5) SMIT menus and commands
6) NIM  information
7) Error Log and dump information.


  

Data Not Managed by ODM

            The Filesystem information, User/Security information and  Queues & its devices are not manged by ODM.


How ODM is compared with Rational Database?

            ODM  is more or less similar  to  Relational Database.
1. Object Class is equivalent  to the database file.
2. Objects are  equivalent are to the row of the database.
3. Object descriptors are equivalent to the column of the database
                   OC   --  datafiles
                     O   --  records
                    OD  --  fields 


Where the ODMDIR environment variable declared?
            ODMDIR environment variable is declared  in /etc/environment. The default ODMDIR variable is /etc/objrepos. 

Types of ODM Components & Commands associated with them
            ODM have 3 components, they are Object Classes, Objects and Descriptors

 
 Object Classes: (odmcreate, odmdrop)
            The ODM contains many database files.  Each file is called  Object Class.
            Commands Used
            #odmcreate desc_file.cre  (Create ODM class file)
            #odmdrop -o desc_file.cre (Delete entire ODM class)

Objects:  (odmadd,odmdelete,odmget,odmchange)
            Each  object class contains of  objects. Each object is one record in an object class

            Commands Used
            #odmget -q name=hdisk0  CuDv
                        The above command is used to display the object  hdisk0 in the CuDV
          #odmdelete –o CuDv –q name=hdisk0
                        The above command is used to delete the specified object hdisk0 in ODMe
           
Descriptors: (odmshow)
            It describes layout of the object. They determine the name and datatype of the fields that are part of the object classes.

            #odmshow  object_class_name
            #odmshow PdDv
            #odmshow CuDv

Device Configuration Summary

What are Device Database aka Object Class files?
            There are 2 important  device database or Object class files are there in ODM, they are Predefined device and Customized  device
 
  1. Predefined device information describes all supported devices.  (PdDv,PdAt,PdCn). If  the device to be configured, it must be the part of  PdDv class, it is not possible to configure a device without defined in the corresponding Pd classes.
  1. Customized device information describes all  the devices that are attached to the system. (CuDv, CuAt, CuDep, CuDvDr, CuVPD, Config_Rules). If the device is in defined state, it should have entry in CuDv.


 
What are the states of  devices in the  ODM?

            There are 2 important states of devices in the ODM, they are  Defined and Available

    Defined State  (device status will be 0 )
  •  If a device is in the defined state there is an entry in ODM class CuDv.
  • A device can be either defined by cfgmgr or mkdev command . Both methods use “define method” (cfgmgr) to generate instance in the class CuDv. 
  •  Suppose that installed device is removed from server or hdd has failed. This case that device is moved to defined state. i.e. that device configuration is available in server but currently device is not accessible.
           
    Available State (device status will be 1)
  •  When the device is in available, the device driver has been loaded and special device file is configured under  /dev  directory and the device is ready for accessible. 
  •   The "configure method" is used to load the device driver and add an entry in the /dev directory
 In addition to the above the following state also availble                     

     Undefined

    The device is supported device but not configured. Devices reside in the Predefined Database  not customized database.


Note
        The difference between Defined and Available state is that no device driver loaded into the kernel.




What are the commands used to get device informations?
  • lsdev command  to get information about PdDv and CuDv. 
  • lsattr command  to get information about PdAt and CuAt.  

 SWVPD (Software Vital Product Data)

  • VPD is the Vital Product data which is the subset of ODM. 
  • Using  lscfg  can find the VPD data of the hardware devices.
   The following are objects of VPD
  
1)      LPP  (Contains information about the product)
2)      Inventory ( contains files associated with s/w product)
3)      Product ( information of the prdt)
4)      History (Historical info about software)

Object Class Repositories
 
     There are 3 repositories, in which ODM  data are stored.

i) /etc/objrepos
  • This is the main repository file. Data that is specified to the system is stored. 
  • /(root) part of the s/w contains the part of the product that cannot be shared through networks. 
  • Customized Devices object classess (CuDv,CuAt)
ii) /usr/lib/objrepos
  • Predefined device object classess  (PdDv.PdAt) 
  • Platform specific data that can be shared across the network.
  • SMIT menu objectclasses and /usr part of the SWVPD. 
  • The four object classes used by SWVPD for the /usr part of installable s/w prdt sofw installed in /usr part can be  shared among the h/w arch
iii) /usr/share/lib/objrepos
  • /usr/share part of the SWVPD (history, inventory,lpp,product). 
  • Platform independent data can be shared across the systems.