AIX Network Install Manager NIM

July 11, 2016 by S4

Filed under AIX

Last modified July 15, 2016

AIX Network Install Manager NIM

AIX Network Installation Management (NIM) setup ensures consistent, standard OS installations between systems that can be in separate data centers. Sometimes company also has a security rule that doesn’t allow any one machine access to all networks within organization. Separate data centers may have separate networks with no connection between them, and each network is segmented into either inside or outside the firewall.
NIM allows you to customize installations and maintain clients on the network from a centralized location (the NIM master) or the NIM client itself.
The master contains the NIM database and can serve resources. Resources in NIM are files or directories containing data that NIM will use to install, customize, and maintain NIM clients.
A NIM client is any machine configured and defined in the NIM database.
NIM Resources
Some key NIM resources used in are as follows:
Licensed Program Product Source Directory (lpp_source):
This directory contains backup file format (BFF) images, which AIX installp uses to load software. One way to understand the role of the lpp_source directory in a BOS installation is to compare it to all the installation images needed to support any configuration (specifically different device configurations) along with a base core set of software (called simages) that are on the BASE installation CDs.

Shared Product Object Tree (SPOT):
This directory is created from an lpp_source and is equivalent in content to a /usr file-system on AIX. The purpose of a SPOT in a NIM installation is similar to the boot images and BOS installation scripts (bi_main, rc.boot, and rc.bosinst) on volume 1 of the BASE install CD. The SPOT must contain support for all boot environments (platform, network type, kernel type).
This data file contains information that drives the BOS install (e.g., prompt vs. no-prompt, which disk to install the OS on, and the type of installation (Overwrite, Preservation, or Migration) to name a few). First, we need separate bosinst_data resources for each machine type. Then, by specifying two disks to target in bosinst_data resource and specifying copies in the image_data resource, we could set up mirroring during the initial load.

This data file contains information about the characteristics of the OS being installed. For example, it includes the size of file systems, whether or not to mirror, and whether or not to disk stripe. We need to create separate image_data resources for each machine type.
This data file contains a customized list of additional software to install after the base AIX software is loaded. If you have different configurations that you need to duplicate on a repeatable basis, this resource is very useful. The easiest way to facilitate and maintain these different requirements, which need to be consistent, is to use installp_bundles.
This is a backup archive file that contains a system image of rootvg. Because of network security restrictions (no one machine canbe connected to all the networks within organization), we can use mksysb and savevg tapes to replicate the NIM master to the other data centers. If we have machine connected to the different data centers, we can use NIM to replicate and update the NIM masters in the different data centers by BOS-installing a NIM mksysb resource and using a NIM script to restore the other volume group data.
This is a logical grouping of machine types (standalone, diskless, or dateless) that enables the systems administrator to target one or more machines with a single command or NIM operation. This feature is more advantageous by grouping all like systems and like configurations to install to more than one machine at a time.
Working with NIM
NIM masters are also designated as the resource servers in the environment. To ensure consistency and standardization of each NIM master (for the different data centers), we need to create a standard NIM master machine, which is cloned. Also we need to make a stacked tape containing a mksysb image and a savevg image of the standard NIM master to sync up and update the other NIM masters. Here are the commands that needs to be run on the standard NIM master to create this stacked single tape:
1. mksysb -i /dev/rmt0
2. tctl -f/dev/rmt0.1 fsf4
3. savevg -i -m {volume_group_name} -f/dev/rmt0.1
4. mt -f/dev/rmt0 rewind
To restore the tape to the other NIM masters, do the following:
1. Booted and restored the mksysb image from the stacked tape
2. tctl -f/dev/rmt0.1 fsf4
3. restvg volume_group_name
These NIM servers are placed throughout the environment and are used by multiple operators with different training levels. Thus it will be helpful , if we create a strict directory tree for storage of resources on the NIM server. It is recommended to create either one large separate filesystem or a few file systems that will contain your NIM resource files. Also, use naming conventions that make sense to you in terms of the resource name and directory structure.
The following is a breakdown of directory structure and a description of what is contained in the directory:
• Master directory of bundle lists:
• Master directory of all NIM resources:
• lpp sources for use by the NIM server during SPOT generation and system installation:
• 32-bit and 64-bit compiled third-party applications:
/export/nim/aix433/32bit-lpp and /export/nim/aix433/64bit-lpp
• Master files for each server type:
• Master files for each server type:
• In-house customization scripts:
• Master OS system files:
• Flat file inventories by serial number of each system installed by the NIM server:
/export/nim/system/{system type}/{serial number}
• Master directories of additional special filesets:
• Any mksysb file images of servers:
• Master installable SPOT images:
• NIM custom scripts:
• Manual backups of the NIM configurations:
One can use SPOT copies (customized to contain only the minimal OS software) to complete the initial loads of NIM client systems to support different hardware platforms. To build a SPOT, first we need to load all AIX filesets into a directory called raw-lpp_source. This directory essentially contains all volumes of the BASE install CDs, bonus pack CDs, and base and extended documentation CDs for 5.3.0. Also one can have an equivalent raw-lpp_source for each maintenance level that needs to support. Make sure that every fix for that maintenance level is present. Once it is completed, one need to generate a listing of lpp’s into a bundle format (an installp_bundle resource that contains customized minimal OS software) to create the AIX530-base lpp_source. Then create an MLXX lpp_source containing only the maintenance level that approved for the standard. This is customized similar to the AIX530-base lpp_source except it contains only the ML fixes. After customized SPOTs are created, we are ready to install a system from this base lpp_source with any ML level.
During the installation process, we will use the and files to control the layout of the rootvg onto the hard disks of the server.
After the installation of the OS is complete, we have the NIM server automatically run a customization script to enforce more unique standards within our computing environment. This customization script is written to facilitate turning on and off selected functions. It uses these functions to control the flow of each operational section. Each command used is echoed to the NIM console log along with a description to aid in diagnostics in case something goes wrong during the NIM installation. By defining this script as a NIM resource, NIM is able to perform the administrative tasks discussed below.
Set Up OS Environment Parameters
During this phase of the script, we adjust AIX to meet our standards for items such as:
• Time zone
• Remote boot facility
• Network Options
• Starting certain demons on restart
Setup Hardware Parameters
AIX will set the 10/100 NIC cards to “autonegotiate”. This can cause a network bottleneck in infrastructure, so utilize these commands to force the adapter to 100/full duplex on startup of the server.
Configure System Files
Create a master directory of certain system files that are copied onto each system when a NIM installation takes place. Utilizing this repository allows control of what the initial system files will conform to.
Setup Security
Here we utilize the NIM server to create another script that will only run once on bootup and then remove itself, the /etc/firstboot. By placing commands in the /etc/firstboot script, the NIM-installed client will execute these commands and then remove the script after it gets an OS installed. This allows us to lock a system down to our security standards immediately. We do this after NIM is finished with the server, because you will lose connectivity to the NIM server and your install will hang if you run these commands before NIM has completed.
Install Third-Party Applications
Here we have created our own “BFF”-formatted install packages for 32-bit and 64-bit compiled software. We keep these in separate directories and use this script to determine whether we are installing a 32-bit or 64-bit machine, and then to install the correct versions.
Create and Set Dump Devices
Depending on the configuration of an AIX server, the initial dump space defined may not be big enough. The two main parts of this function are to calculate whether the dump space is big enough and to determine whether a mirror drive exists. If the function determines the dump space is too small, it will increase it automatically and set up a secondary dump file on the mirror drive if available.
Adjust Paging Space to Complement RAM
Because AIX has changed its swap algorithms, it is no longer necessary to have swap space equal to size of RAM. (This really helps on a 64-Gig RAM system.) We use this function to calculate the size of RAM and then adjust the swap space to the values noted in the script.
Create a Hardware Inventory — By Machine Type or by Serial Number
This function calls another script that will create an exhaustive inventory of a NIM installed server . We use this to verify a server install or for disaster recovery of a down server. We could literally rebuild a like server from this listing.
Create a Complete Inventory — By Machine Type or by Serial Number
The purpose of this function is to call a smaller system inventory script that will only give the amount of information about each NIM-installed server for our inventory-tracking database.

Leave a Comment