8224003 AIX Network Install Manager NIM

8/3/2019 8224003 AIX Network Install Manager NIM

1/6

AIX Network Install Manager

When we replaced our old hardware platform with IBM AIX RS/6000 systems, a mainconcern was controlling how our new systems would be installed. With the old

platform, we ran into several instances where the software (moving from ourdevelopment group to QA and into production) was not the same, which caused

numerous build breaks. We chose the AIX Network Installation Management (NIM)

setup, because we needed to ensure consistent, standard OS installations betweensystems within our four separate data centers. Our company also has a security rule

that doesn't allow any one machine access to all networks within our organization.Our four separate data centers have four separate networks with no connection

between them, and each network is segmented into either inside or outside the

firewall.

NIM Resources

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 directoriescontaining data that NIM will use to install, customize, and maintain NIM clients. ANIM client is any machine configured and defined in the NIM database. Some key

NIM resources used in our setup are:

Licensed Program Product Source Directory (lpp_source): This directory

contains backup file format (BFF) images, which AIX installp uses to loadsoftware. 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) alongwith a base core set of software (called simages) that are on the BASE

installation CDs. We created a base 433 lpp_source, multiple lpp_sources

containing different maintenance levels, and separate lpp_sources for our32-bit and 64-bit third-party application software.

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). We created several different SPOTs forthe different data centers and maintenance levels we use to support our

systems.

bosinst_data: 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, wecreated separate bosinst_data resources for each machine type (S80, H70,

B50, M80, P680, and 43P). Then, by specifying two disks to target in ourbosinst_data resource and specifying copies in the image_data resource, we

could set up mirroring during the initial load.

image_data: 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 created


2/6

separate image_data resources for each machine type (S80, H70, B50, M80,

P680 and 43P).

Script: This is a customization file the systems administrator can create,

which executes near the end of the BOS installation. You can execute multiple

NIM script resources during a BOS installation. If you need to control theorder of execution, I recommend putting it all in one large script. We created

one NIM script to set up the OS environment and hardware parameters,configure certain system files, set up security, install third-party software,

create and set up dump devices, customize paging space to correspond to thesystem RAM, and help create a complete inventory by machine type and

serial number. I've included a copy of this script at the end of this article(Listing 1). All listings for this article are available from the Sys Admin Web

site: http://www.sysadminmag.com/code/

Installp_bundles: This data file contains a customized list of additional

software to install after the base AIX software is loaded. If you have differentconfigurations that you need to duplicate on a repeatable basis, this resource

is very useful. In our environment, we have different OS software

requirements for development, QA, and production above the minimal AIXsoftware needed to support different hardware systems. The easiest way to

facilitate and maintain these different requirements, which need to beconsistent, is to use installp_bundles.

mksysb: This is a backup archive file that contains a system image ofrootvg.

Because of our network security restrictions (no one machine could beconnected to all the networks within our organization), we used mksysb and

savevg tapes to replicate the NIM master to the other data centers. If we had

one machine connected to the different data centers, we could have used 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.

mac_group: This is a logical grouping of machine types (standalone, diskless,

or dataless) that enables the systems administrator to target one or more

machines with a single command or NIM operation. We did not use thisfeature, but we could have taken advantage of this by grouping all like

systems and like configurations to install to more than one machine at a time.

Working with NIM

We used the 43P systems as our NIM masters for each data center because they

could complete remote installations of machines or be moved and directly connectedto a server for OS installations. These NIM masters were also designated as the

resource servers in our environment. To ensure consistency and standardization ofeach NIM master (for the different data centers), we created a standard NIM master

machine, which we cloned. We made 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 we ran on the standard NIM master to create thisstacked 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
http://www.samag.com/documents/s=1150/sam0106sd/0106d_f1.htmftp://ftp.mfi.com/pub/sysadmin/2001/jun_sup2001.tar.Zhttp://www.samag.com/documents/s=1150/sam0106sd/0106d_f1.htmftp://ftp.mfi.com/pub/sysadmin/2001/jun_sup2001.tar.Z


3/6

To restore the tape to the other NIM masters, we did 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 were placed throughout our environment and are used by

multiple operators with different training levels. Thus, we developed a strict directorytree for storage of resources on the NIM server, but this was our own restriction, not

a restriction created by NIM. I recommend creating either one large separatefilesystem 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 anddirectory structure. The following is a breakdown of our directory structure and a

description of what is contained in the directory:

Master directory of bundle lists:

/export/installp_bundles

Master directory of all NIM resources:

/export/nim

lpp sources for use by the NIM server during SPOT generation and system

installation:

Installations/export/nim/aix433

32-bit and 64-bit compiled third-party applications:

/export/nim/aix433/32bit-lpp and /export/nim/aix433/64bit-lpp

Master bosinst.data files for each server type:

/export/nim/bosinst

Master image.data files for each server type:

/export/nim/imagedata

In-house customization scripts:

/export/nim/scripts

Master OS system files:

/export/nim/system


4/6

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:

/export/nim/packages

Any mksysb file images of servers:

/export/nim/mksysb

Master installable SPOT images:

/export/nim/spot

NIM custom scripts:

/export/nim/custom

Manual backups of the NIM configurations:

/export/nim/nim-backup

We used SPOT copies (customized to contain only the minimal OS software) tocomplete the initial loads of our NIM client systems to support our six different

hardware platforms. To build a SPOT, we first loaded all AIX 4.3.3.0 filesets into adirectory called raw-lpp_source. This directory essentially contained all volumes of

the BASE install CDs, bonus pack CDs, and base and extended documentation CDsfor 4.3.3. We also had an equivalent raw-lpp_source for each maintenance level we

needed to support. We made sure that every fix for that maintenance level was

present. Once completed, we generated a listing oflpp's into a bundle format (an

installp_bundle resource that contained our customized minimal OS software) to

create the AIX433-base lpp_source. We then created an MLXX lpp_source

containing only the maintenance level we approved for our standard. This wascustomized similar to the AIX433-base lpp_source except it contained only the ML

fixes. After our customized SPOTs were created, we were ready to install a systemfrom this base lpp_source with any ML level.

During the installation process, we used the bosinst.data and image.data files to

control the layout of the rootvg onto the hard disks of the server. Using NIM hasbeen facilitated by establishing strict hardware configuration standards for each each

IBM server type at our site. This provides the ability to move machines aroundwithout conducting a hardware upgrade. It also makes installation easy, because we

always know what kind of hardware we are using.

Customizing


5/6

After the installation of the OS was complete, we had the NIM server automaticallyrun a customization script to enforce more unique standards within our computing

environment. This customization script (Listing 1) was written, in-house, to facilitateturning on and off selected functions. It uses these functions to control the flow of

each operational section. Each command used was echoed to the NIM console logalong with a description to aid in diagnostics in case something went wrong during

the NIM installation. By defining this script as a NIM resource, NIM is able to performthe administrative tasks discussed below. Note that this script is designed to meetthe objective of a system being 95% pre-configured for our operating environment

after NIM has completed its operations. The other 5% is what our operations staff

performs on the server to turn it into a Web server, ftp server, gateway, or even adatabase server. Also note that this script is good for teaching new AIX systems

administrators about essential system commands in AIX. Each command executed isechoed to the screen with a description of what it's doing, it's command syntax, and

it's output.

Set Up OS Environment Parameters

During this phase of the script, we adjust AIX to meet our standards for items suchas:

Timezone

Remote boot facility

Network Options

Starting certain demons on restart

Setup Hardware Parameters

AIX will set the 10/100 NIC cards to "autonegotiate". We found this caused anetwork bottleneck in our infrastructure. We utilize these commands to force the

adapter to 100/full duplex on startup of the server.

Configure System Files

We have created 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. This is also the first time in the scriptthat you see special programming for a particular platform. Note at the end of this

function that we do not want the "httplite docsearch" utility running on anything

other than a 43P workstation.

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 systemdown 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 hangif you run these commands before NIM has completed.
http://www.samag.com/documents/s=1150/sam0106sd/0106d_f1.htmhttp://www.samag.com/documents/s=1150/sam0106sd/0106d_f1.htm


6/6

Install Third-Party Applications

Here we have created our own "BFF"-formatted install packages for 32-bit and 64-bitcompiled 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 installthe correct versions.

Create and Set Dump Devices

Depending on the configuration of an AIX server, the initial dump space defined maynot 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 thefunction 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 thisfunction to calculate the size of RAM and then adjust the swap space to the valuesnoted 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 (Listing 2). We use this to verify a server install or for disasterrecovery 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 (Listing 3)that will only give the amount of information about each NIM-installed server for ourinventory-tracking database.

Conclusion

In summary, we needed to ensure consistent standard OS installations between fourseparate data centers. By using AIX 43P systems and NIM system software, we

succeeded in our efforts. NIM allowed for remote installation and management of ournetworked systems. Specifically, the NIM script resource handled tedious and time-

consuming tasks that cause systems administrators to dread post-installconfiguration. From setting up hardware parameters to creating inventory lists, NIM

allowed complete customization while leaving us free to handle other vexingtasks...like resetting passwords.
http://www.samag.com/documents/s=1150/sam0106sd/0106d_f2.htmhttp://www.samag.com/documents/s=1150/sam0106sd/0106d_f3.htmhttp://www.samag.com/documents/s=1150/sam0106sd/0106d_f2.htmhttp://www.samag.com/documents/s=1150/sam0106sd/0106d_f3.htm

Documents

8224003 AIX Network Install Manager NIM