NIMadm

Nimadm requirements

1) nim master must have bos.alt_disk_install.rte fileset installed and in the spot . Both must be at the same level 2) nim master should be at the same or higher level than the level you are migrating on the client 3) apart from spare disk , client should have 500MB free space. This space varies according to the configuration 4) rsh connection must be available between client and nim master . Reliable network connection is required as nim uses rsh and NFS connections for migration NIM NFS vs local disk caching

this option allows nim server to use local disk caching instead of NFS to write to the client if there is a NFS bottleneck .

Decreaed cpu usage at the client and client filesystems are not exported , are the key advantages of the local disk caching nimadm log file : //var/adm/ras/alt_mig/<>

alt disk caching : log file used when syncing data between cache ancd client filesystems /alt_mig/alt_disk_mig_rfail

common operating system image management

diskless clients are machines without disks and uses a network server to boot . Dataless clients have disks but dont have required data to operate indepedently . These servers uses a bootimage along with NIM SPOT exported by a nim server to boot .

Thin server is a machine that lacks the physical hardware or software to allow it to operate independently

thin server relies on remote resources such as CoSI

thin server includs Disk less as well as data less clients

diskless clients relies on a remote SPOT , root , dump and paging resource dataless client except paging resource it requires all other resources to be served by a remote server

thin server resources root root : this is the directory NFS mounted by thin client when it is initialized . When client is initialized this directory is populated with system configuration files . These files are copied from SPOT or COSI image. Paging : this is the directory NFS mounted by client and used as a paging device . Dump : directory used for use as dump space for clients home tmp shared home are the other directories COSI : is a respository which contains all the required software to bring thin client to functional state nim client back up if you are using NIM to create a client back up , you have to execute the same from NIM master it self

nim -o define -t mksysb -a server=master -a source=lpar_name -a mk_images=yes -a location= <resource name>

replicating a nim lpp_resource from an existing resource

nim o define t lpp_source a server=master a source=<existing lpp_s> -a

location=/export/lpp_source <resource name>

replicating lpp_source from a directory which holds bff filesets of an existing lpp_source

nim o define t lpp_source a server=master a location=<> -a source=/export/lpp_source/<>/installp/ppc <resource name> updating a lpp resource from TL / SP downloaded

nim o update a show_progress=all a packages=all a source=<directory where tl is kept> <lpp_resource_name>

removing duplicate filesets from a lpp_source

nim o lppmgr <lpp_source>

Strategies for yearly update maintenance model of TL Before updating to second half release its better to update to fisrt half like TL6 etc which is stable as it is being used for six or 7 months and also it contains Latest update maintenance model This model is for new hardware model or upgraded hardware that require a new TL, or that want to use new hardware and software features introduced in a new TL Removing duplicate level filestes using lppmgr nim operation and standalone command

/usr/lib/instl/lppmgr -d /export/lpp_source/LPP_71TL0SP4 -ubr nim -o lppmgr -a lppmgr_flags=ubr LPP_71TL0SP4 Determining the OS levels

lslpp -qLc bos.rte |cut -f2-3 -d: oslevel -r <------------- recommended level oslevel -s <----------------- service pack oslevel -g <level> <--------------- shows filesets on level higher than mentioned level

uname -s -v -r To find filesets that are on a lover level

instfix -i |grep -i ml Not all filesets for <> found instfix -icqk <> |grep :-:

niminv The niminv command can gather, conglomerate, compare, and download fixes based on the installation inventory of NIM objects. Niminv -o invget -a target=master -a location= invget operation will collect and o/p file in the location and will be in lslpp -L format comparing levels between different systems niminv -o invcon -a target=master,nim_client -a base=higest -a location to display filesets that can be downloaded based on the lovest intallations in the conglomerate of the master and the nim client group

niminv -o fixget -a target=master,nim_client downloading fixes to a new lpp resource niminv -o fixget -a target=master -a download=yes -a location=<> -a newlppname= niminv will create both location and newlppname if they do not exit to download fixes to lpp when filtering from same lpp source

nim -o fixget -a target=master -a download=yes -a lpp_source=LPP_71TL1SP3 compare_report compare_report command compares filesets installed on a machine to filesets in a repository it also generates report with detailed information of which filesets in system have to be on latest level compare_report -s -r <downloded report from IBM site which contains information of latest update / fix packs available > -l -h

Free IBM tools Retrieving ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/ NFS export during file creation

creating bundles bff and rpm packages

if we are using geninstall for installing a package then use prefixes to indiacate the package format to the geninstall command I bff format R rpm format J ISMP format E interim fix format mkinstallp allows to create package in the native format or so called back up file format mkfile uses files that will be packaged in to directory such that location of the files relative to the root build directory is the same as the destination of the file after installation package creation after mkinstallp locates packages in given directory it prompts for informations to create package template , informations like package names ,description of the files to be packed etc . Steps involved 1) create a build structure 2) populate the build structure with programs and files 3) create packaging template file for use by mkinstallp 4) create the package using installp program mkinstallp -d <build directory> -T <template> how to verify bff packages restore -qTvf <package file> to list the directory toc file installp -qld <directory where packages are kept> installp bundle installp_bundle nim resource represent a file which contains the names of filesets that should be

managed by nim

during installation nim server mounts the installp_bundle file on client machine and make it available for local installp command and unmounts when software installation is finished system bundles are contained in a directory
/usr/sys/inst.data/sys_bundles

defining installp bundle 1 ) packages will be contained in lpp resource

2) we define a installp_bundle file

file format file should contain package type prefix and fileset . Eg I:VRTSvxvm.bff R:VRTSvxvm.rpm to create a nim bundle resource nim -o define -t installp_bundle -a server=master -a location=<> <bundle_name>

nim best practices

updating the nim environment ( lpp_source and spot ) nim master should be updated before updating nim client followed by lpp and spot resource then nim client nim master should always be on latest level

nimcheck operation rebuilds the .toc files in the lpp source directory and checks whether all necessary filesets are in the directory to qualify lpp_source for the simages

secondary adapter
using secondary adapter defenitions you can have additional network adapters and interfaces configured during a bos installation or customized installation nimadapters command is used to sparce secondary adapter stanza file to build files required to add secondary adapter defenitions as a part of adapter_def resource
Flag Purpose

-a Assigns the following attribute=value pairs: client=nim_client_name

Specifies the NIM client that will have a secondary adapter definition added or removed. This option allows you to define one secondary adapter for a client. To define multiple secondary adapters, use a stanza file. info=AttributeList When previewing or defining a secondary adapter, the info attribute must be used when the client attribute is specified. AttributeList is a list of attributes separated by commas. -d Defines secondary adapters. A Client.adapter file is created in the adapter_def location for each valid secondary adapter definition. If the nimadapters command encounters existing secondary adapter definitions for a NIM client, the existing definitions are replaced. -f SecondaryAdapterFileName. Specifies the name of the secondary adapter file. -p Displays a preview operation to identify any errors. This flag processes the secondary adapter file or info attribute, but does not add adapter definitions to the NIM environment. -r Removes the secondary adapter definitions of a specific client or all the clients listed in a secondary adapter stanza file. If the client attribute or secondary adapter stanza file is not specified, then all the secondary adapter definitions in the adapter_def resource will be removed.

Nimsh rsdh and openssh considerations from aix 5.3 onwards nimsh is available for remote command exectution from a nim master nimsh uses reserved ports 3901 and 3902 for communication only comments registered in nimsh is executed as root , anything else is denied execution nimsh allows to query network hosts by hostname , nimsh processes the query and returns parameters required to define a client in nim environment using nimsh you can define a nim client without knowing system specific or network specific information .

Two ports are involved in nimsh communication . Primary port 3901 and secondary port 3902 . primary port listens for service requests . When a request is accepted primary port is used for stdin and stdout , stderr is redirected to secondary port nimsh authentication process packets from nim master are builds packets with following data for authentication 1) hostname of client 2) cpuid of client 3) cpuid of nim master 4) return port for secondary connection 5) query flag if the query flag is 1 then it is treated as query for client information if the option flag is not set then a request for nim operation is pushed by nim master 1) verify that hostname of nim master is the recognized master hostname to the client 2) check the client CPUID passed in the data . It should macth the client CPUID 3) check the master CPUID in the data . It should macth with the CPUID saved in the memory . It is read from /etc/niminfo and mktcpip -S primary_nim _interface 4) verify that operation passed in the method is a method residing in the /usr/lpp/bos.sysmgt/nim/method 5) check for cryptographic authentication settings

to configure nimsh

1) nimsh must be configured only on nim client 2) smitty nim_config_services or nimclient -C command run from client configures nimsh once nimsh is configured on client then entry in rhosts is no longer required as nim master uses nimsh for communication with client to enable crtyptographic authentication openssl needs to be installed . Then nimsh uses encrtypted ssl encrypted certiciates for authenticating connecting master

for configuring openssl in nimclient script has been already provided and is kept in /usr/samples/nim/ssl directory . We can use it without any modification . To configure ssl communication on nim master

install openssl on nim server then smitty nim_ssl or nimconfig -c important points to enable cryptographic authenticatoin nim master must already be configured for ssl authentication operation initiated from client do not use encrypted authentication . Whereas nim push operation use it . During authentication encrypted handshake communication takes place in case of ssl nimsh cofigured to use ssl . But data packets are not encrypted disabling push operations by nimsh to enable client push operations nimclient -p to disable nimclient -P

master initiated installation when a push operation is initiated from master it creates files required for installation . It nfs exports the files which later on mounted by client to install OS and execute rsh command on the client to set boot device to boot the client from network

how nim based os installation works

performs installation based on a client server model uses bootp/tftp to recieve bootimage after receiving boot image client requests for a niminfo file using tftp protocol . This file contains information like server which provides installation image and other resources after completion of installation nim client sends state information to master via nimclient call to nimesis daemon . Master then deallocate all resources allocated to the server which completed the installation

protocols involved in nim installatoin

rsh requires clients to connect using source ports obtained from range 1023-513 client call rcmd () which inturn calls rreservport() . Rresevport () try to bind a tcp socket connection with a reserved port . The port is determined by initializing the starting port and binding it . If it fails then port number is decremented . This process is continued until port is bound or port 513 is reached . Upon successful binding of source port rcmd () allows option of binding a secondary port for any stderr connection . When set rreservport is called and this time port number selected depends on the source port number set in the initial procedure bootpc 68 bootps 67 tftp uses TIDs ( transfer IDs ) using nfso to change the portcheck operation of nim when portcheck option is enabled , nfs server checks whether nfs requests are coming from privileged ports restoring clients using mksysb checking the spot level nim -o fix_query SPOT | grep ML

Doing lppheck on client after a client is upgraded to new level nim -o lppckh -a lppchk_flags=-c -m3 <lpar_name> doing a update _all operation on client nim -o cust -a lpp_source= -a installp_flags= -a fixes=update_all <client> listing all available resources for the client nimclient -l <client name> allocating a lpp source to the client nimclient -o allocate -a lpp_source= nimclient -o deallocate -a lpp_source= show the allocated resources to a client nimclient -l -c resources <client> Performing installation time customization

there are various methods to provide installation time customization during a BOS or mksysb installation 1) nim script resources 2) nim bosinst_data resource 3) using SPOT modified /usr filesystems using installation 4) using installable filesets and scripts any time after the first boot 5) using manually or remotely run commands from scrips 6) using fb_script resource after first boot the script resource that we define must not be saved in /export/nim/scripts directory as this contains script resources managed by nim . To check the customized bos_inst data
/usr/lpp/bosinst/bicheck

SOE

standard operating environment helps when there are many AIX systems with standard and consistent AIX versions installed in them . Recovering NIM master using NIM methods nim_master_recover is used to recover nim master

/usr/lpp/bos.sysmgt/nim/methods/nim_master_recover -i en1 -S if the new IP address is in the same subnet as the old one then the netwrk object is updated . If its in a new subnet then object is updated