NIM installation Filesets
You will need Volume 1 of your Base AIX Installation media CD. If you have a directory where you’ve used the bffcreate utility to copy down the contents of the media to disk, that is fine as well. What we’re looking for basically is the base level versions of the NIM filesets.
There are 3 filesets we will need to deliver the NIM software to our future NIM master.
There are 3 filesets we will need to deliver the NIM software to our future NIM master.
1. bos.sysmgt.nim.master
2. bos.sysmgt.nim.client
3. bos.sysmgt.nim.spot
Put Volume 1 of your media in the drive and from and command line you can run the following command :
# installp -acgXd /dev/cd0 bos.sysmgt.nim.master bos.sysmgt.nim.client bos.sysmgt.nim.spot
Using smitty :
# smitty install_all
* INPUT device / directory for software /dev/cd0
* SOFTWARE to install
PREVIEW only? (install operation will NOT occur) no
COMMIT software updates? yes
SAVE replaced files? no
AUTOMATICALLY install requisite software? yes
EXTEND file systems if space needed? yes
OVERWRITE same or newer versions? no
VERIFY install and check file sizes? no
DETAILED output? no
Process multiple volumes? yes
ACCEPT new license agreements? no
Preview new LICENSE agreements? no
NIM Key Components
If you are unfamiliar with NIM I highly recommend reading through this section and also use it as a reference while reading through this guide. If you’re figuring, “eh he’ll explain all this later so I’ll just skip this part,” you’re going to be flipping back to this part all mad later thinking, “ok fine so I should have read through this before....”.
So this is sort of like a “reverse-glossary”. I have it before any of the “How to” portions of the guide because it is important to know what it is we are talking about. I’ll give the best and easiest to understand description of these terms so that you’ll hopefully have a much easier time understanding any new concepts you’re unfamiliar with. In all cases - actually using the files/keywords are handled in greater detail in their corresponding “How To...” sections.
Important Files and Directories:
- /etc/bootptab :
This file will exist on the NIM master. In a quiet NIM environment with no operations that require a client to boot, this file will be empty (except for the pre-existing commented section). This file gets updated automatically by the NIM master when a NIM operation is executed that requires the client machine to boot from a NIM SPOT. If this file contains incorrect information about either the master or the client, the boot operation will fail. While this file “can” be edited manually to fix a bootp issue - it should not be, as you are only applying a “band-aid” fix to an existing issue in your NIM environment....but, sometimes it’s 5pm on a Friday and you’re ready to go home, right ?
(Also note related entry ‘bootp’)
- /etc/exports :
This is not a “NIM specific” file, it is a NIM critical file. Any sort of installation, boot, mksysb, savevg....etc operation requires the use of NFS. This file will be updated with which locations are NFS exported from the master to the client and the permissions associated with those exports. If these entries are incorrect or incomplete you will run into boot failures, permission problems, and other errors commonly associated with NFS. This is a text file and also “can” be edited manually to sometimes “band-aid” a problem, but should only be done so with care in knowing exactly what you’re doing. The good thing is, if we mess up this file we can remove it and recycle NFS. The file can be recreated.
- /etc/hosts :
While not a “NIM specific” file, it is also a NIM critical file. This file is sort of like a phone book. It gives a relationship between a system’s hostname and an ip address. Much like a telephone, if you dial the wrong number you get the wrong person. In NIM, if your ip address does not match up to the correct hostname, your install fails. This is a text file and can be edited manually. There should also only be 1 entry per ip/hostname. I personally prefer to make sure my NIM master has all entries in the /etc/hosts file and are of the following format :
If the client machine is up and running, it should also have a good entry in there for the NIM master as well.
- /etc/niminfo:
This file should always exist on the NIM master and sometimes will exist on a NIM client.
On the Master : This file is built when you first initialize the NIM environment. This is simply a text file so feel free to ‘cat’ or ‘more’ the file and look at the entries included in there. You do not want to manually edit this file if there is a mistake in the definition of the master. In this case you will want to redefine the master, or use the feature in NIM to change the master’s attributes (hostname, gateway....etc).
On the Client : This file is “optional” depending on what sort of operations you are performing on the client. If the NIM client is up and running, and you intend to perform operations on the client (like take backups, or install maintenance) you will want to make sure this file exists. This file contains not only hostname information for the client, but tells the client who its master is.
This also should not be edited manually. If there is incorrect information in the file, it should be removed and recreated.
- /tftpboot :
This directory should always exist on the NIM master. The main purpose of this directory is to hold the boot images that are created by NIM when a boot or installation is initiated. This directory also holds informational files about the clients that are having a boot or installation operation performed. The file names that are generated in both cases are very descriptive file names For example :
The boot image created might be named : 53_spot.chrp.mp.ent.
The format of the file name is
The client info files are aptly named :
The NIM master will create the
NIM key words
Base Operating System Installation :
Also commonly called (and referred to from here on out) as a bos_inst operation. This simply refers to the fact that you are initiating a boot and installation to a client machine. There are other installation types that do NOT require a boot. A bos_inst operation always means a boot of the client machine is involved.
Bootp :
This is the initial communication made between the NIM master and client during a boot or bosinst operation. In order for this to be successful several factors must be met :
1. - bootpd must be running on the NIM master
2. - the NIM client and master must have correct ip information about each other
3. - the /etc/bootptab must be populated correctly
4. - If the master and client systems are on separate networks, the router must be set to forward bootp packets.
There are other causes of failure, but checking/verifying those 4 will solve most bootp issues.
Tftp (Trivial File Transfer Protocol):
When the NIM client has been rebooted for a boot or bos_inst operation you don’t have access to normal TCP communication. Once bootp connection has successfully been achieved, the NIM master uses tftp to transfer over the.info file and the boot image to the client.
if1= : Or interface 1
This is known as the ‘nim network’. Every machine, even the master, is placed on a defined NIM network. A machine who has multiple adapters defined to NIM will have “if2=” and “if3=”....etc attributes. Not all adapters on a client need to be defined in NIM, only the ones that you wish to use with NIM. When your NIM master is generated, you will create a network name for the master and every client on the same subnet as the master. If you name this network “master_net” for example, then all clients on the same subnet as the master will have their “if1=” line set to “master_net”. If you add additional clients that are on separate subnets, then you will need to create new network names. You can see the “if1=” information from an :
# lsnim -l master |more
-or-
# lsnim -l
You can get further information about the network name by running an ‘lsnim -l’.
Having incorrect networking information is probably the leading cause of NIM installation failures. This attribute and the information used when creating networks is extremely important to make sure you have correct.
Client (nim client) :
Any standalone machine or lpar in a NIM environment other than the NIM master. Clients use resources that reside on the NIM master to perform various software maintenance, backup, or other utility functions.
*Note that NIM resources do not always have to reside on the NIM master, but for our purposes they all will.
Groups (machine groups) :
In the spirit of convenience you can create a machine group which consists of a number of NIM clients. All NIM operations initiated from the master to that machine group subsequently are performed to all machines that are part of that group. For example, you can define a machine group and call it “Group1”. Group1 has ClientA, ClientB, ClientC, and ClientD in it. You can initiate a bos_inst operation to each individual client, or if all clients are being installed with the same image, you can initiate the bosinst operation to Group1. All client systems will be installed at the same time. The downside to this however, is that you sacrifice performance for convenience. It is best if you decide to use machine groups to test out what sort of load your network and NIM master can hold before seeing diminishing returns.
Master (nim master) :
The one and only one machine in a NIM environment that has permission to run commands remotely on NIM clients. A client can only have one master, and a master can not be a client of any other master. The NIM master must also be at an equal or higher OS/TL/SP level than any client in the NIM environment. The NIM master also can not create SPOT resources at a higher level than it is currently installed at. Finally, the NIM master can not install any clients with an OS/TL/SP higher than his own. Long story short, for all intents and purposes, for any NIM operation, make sure you master is at an equal or higher level.
The NIM master also will hold all of our NIM resources. Due to this we’ll want to make sure the NIM master has plenty of space available to it. Ideally, having a separate volume group (nimvg) is beneficial, so the rootvg does not get out of control in size.
Resource (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. Various resource types will be explained below. I’ve decided to order them in a logical order of description rather than alphabetical order. It should make more sense to read through them in this manner.
Resource (nim resources) lpp_source:
When running an installation of a system outside of NIM, you use an installation CD. NIM uses resources. Two of the most important resources are made using the installation CD. First of all let’s understand what exactly is on an installation CD that allows us to install a system. There are 4 parts :
- The filesets that get installed.
- The .toc file so the system knows what filesets are on the media.
- The boot images so the CD can boot the system initially
- A /usr filesystem to run the commands needed to install the system.
The lpp_source is created from an AIX installation CD and is responsible for holding :
- The filesets that get installed.
- The .toc file so NIM knows what is available in the lpp_source to be installed to the client.
In short, the lpp_source is simply a depot. It’s just a directory that holds all of the filesets and the .toc file.
Resource (nim resources) SPOT:
The SPOT resource (stands for Shared Product Object Tree in case you were wondering) is responsible for the following :
- Creating a boot image to send to the client machine over the network.
- Running the commands needed to install the NIM client.
Essentially the SPOT is a /usr filesystem just like the one on your NIM master. You can think of it as having multiple “mini-systems” on your NIM master, because each SPOT is its own /usr filesystem. You can upgrade it, add fixes to it, use it to boot a client system....etc. Just like your NIM master’s /usr filesystem, going in there manually and messing around with files can easily corrupt it. The good thing about a SPOT however, is that it is easily rebuilt.
You can also create a SPOT from a NIM mksysb resource. This SPOT however is not as versatile as one created from an lpp_source and can not be upgraded with any fixes and can only be used with the mksysb resource it was created from.
Resource (nim resources) mksysb:
This is simply a mksysb image of a machine. The mksysb image can be of the NIM master, a NIM client, or a machine outside of the NIM environment. This resource can be defined in one of two ways.
- From an existing mksysb taken to file that resides on the NIM master.
- Creating a new mksysb image of a currently existing NIM client.
At this time there is no supported way to use a mksysb tape or mksysb on CD/DVD, as an input device to define a mksysb resource in NIM.
Resource (nim resources) bosinst_data:
When booting from installation media to install or upgrade a system you boot to what are known as the “BOS Menus” or Base Operating System Installation Menus. Here you select your console, what language to use, what disks to install to.....and many other options. In NIM we can create a “bosinst_data” resource that will answer these questions for us. By doing this we can perform a “non-prompted” installation. So if you have a NIM client in another building, down the road, or half way across the country, you can create this type of NIM resource which will provide the answers to those questions, so once you kick off the install from the NIM master no further interaction is required. The system should (ideally) install and reboot itself afterward.
A mksysb (as discussed above) has a “built in” bosinst.data file. If the option in that file
(PROMPT =) is set to yes, this file really does nothing as the choices you make in the BOS menus will override the options in the file. However, if the mksysb was created to have that option set to no, then we can create a new bosinst_data resource which will trump the one that is part of the mksysb.
Resource (nim resources) image_data:
Outside of NIM this file is responsible for knowing how your rootvg is built. It contains information like the partition size of rootvg, the disks belonging to rootvg, all of the filesystems (and their sizes) that belong to rootvg, whether the rootvg is mirrored, and other information. As with the bosinst_data file, a mksysb also has one of these “built in”. If this built in file needs to be altered in any way, we can accomplish this by creating and allocating an image_data resource.
Tftp (Trivial File Transfer Protocol):
When the NIM client has been rebooted for a boot or bos_inst operation you don’t have access to normal TCP communication. Once bootp connection has successfully been achieved, the NIM master uses tftp to transfer over the
if1= : Or interface 1
This is known as the ‘nim network’. Every machine, even the master, is placed on a defined NIM network. A machine who has multiple adapters defined to NIM will have “if2=” and “if3=”....etc attributes. Not all adapters on a client need to be defined in NIM, only the ones that you wish to use with NIM. When your NIM master is generated, you will create a network name for the master and every client on the same subnet as the master. If you name this network “master_net” for example, then all clients on the same subnet as the master will have their “if1=” line set to “master_net”. If you add additional clients that are on separate subnets, then you will need to create new network names. You can see the “if1=” information from an :
# lsnim -l master |more
-or-
# lsnim -l
You can get further information about the network name by running an ‘lsnim -l
Having incorrect networking information is probably the leading cause of NIM installation failures. This attribute and the information used when creating networks is extremely important to make sure you have correct.
Client (nim client) :
Any standalone machine or lpar in a NIM environment other than the NIM master. Clients use resources that reside on the NIM master to perform various software maintenance, backup, or other utility functions.
*Note that NIM resources do not always have to reside on the NIM master, but for our purposes they all will.
Groups (machine groups) :
In the spirit of convenience you can create a machine group which consists of a number of NIM clients. All NIM operations initiated from the master to that machine group subsequently are performed to all machines that are part of that group. For example, you can define a machine group and call it “Group1”. Group1 has ClientA, ClientB, ClientC, and ClientD in it. You can initiate a bos_inst operation to each individual client, or if all clients are being installed with the same image, you can initiate the bosinst operation to Group1. All client systems will be installed at the same time. The downside to this however, is that you sacrifice performance for convenience. It is best if you decide to use machine groups to test out what sort of load your network and NIM master can hold before seeing diminishing returns.
Master (nim master) :
The one and only one machine in a NIM environment that has permission to run commands remotely on NIM clients. A client can only have one master, and a master can not be a client of any other master. The NIM master must also be at an equal or higher OS/TL/SP level than any client in the NIM environment. The NIM master also can not create SPOT resources at a higher level than it is currently installed at. Finally, the NIM master can not install any clients with an OS/TL/SP higher than his own. Long story short, for all intents and purposes, for any NIM operation, make sure you master is at an equal or higher level.
The NIM master also will hold all of our NIM resources. Due to this we’ll want to make sure the NIM master has plenty of space available to it. Ideally, having a separate volume group (nimvg) is beneficial, so the rootvg does not get out of control in size.
Resource (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. Various resource types will be explained below. I’ve decided to order them in a logical order of description rather than alphabetical order. It should make more sense to read through them in this manner.
Resource (nim resources) lpp_source:
When running an installation of a system outside of NIM, you use an installation CD. NIM uses resources. Two of the most important resources are made using the installation CD. First of all let’s understand what exactly is on an installation CD that allows us to install a system. There are 4 parts :
- The filesets that get installed.
- The .toc file so the system knows what filesets are on the media.
- The boot images so the CD can boot the system initially
- A /usr filesystem to run the commands needed to install the system.
The lpp_source is created from an AIX installation CD and is responsible for holding :
- The filesets that get installed.
- The .toc file so NIM knows what is available in the lpp_source to be installed to the client.
In short, the lpp_source is simply a depot. It’s just a directory that holds all of the filesets and the .toc file.
Resource (nim resources) SPOT:
The SPOT resource (stands for Shared Product Object Tree in case you were wondering) is responsible for the following :
- Creating a boot image to send to the client machine over the network.
- Running the commands needed to install the NIM client.
Essentially the SPOT is a /usr filesystem just like the one on your NIM master. You can think of it as having multiple “mini-systems” on your NIM master, because each SPOT is its own /usr filesystem. You can upgrade it, add fixes to it, use it to boot a client system....etc. Just like your NIM master’s /usr filesystem, going in there manually and messing around with files can easily corrupt it. The good thing about a SPOT however, is that it is easily rebuilt.
You can also create a SPOT from a NIM mksysb resource. This SPOT however is not as versatile as one created from an lpp_source and can not be upgraded with any fixes and can only be used with the mksysb resource it was created from.
Resource (nim resources) mksysb:
This is simply a mksysb image of a machine. The mksysb image can be of the NIM master, a NIM client, or a machine outside of the NIM environment. This resource can be defined in one of two ways.
- From an existing mksysb taken to file that resides on the NIM master.
- Creating a new mksysb image of a currently existing NIM client.
At this time there is no supported way to use a mksysb tape or mksysb on CD/DVD, as an input device to define a mksysb resource in NIM.
Resource (nim resources) bosinst_data:
When booting from installation media to install or upgrade a system you boot to what are known as the “BOS Menus” or Base Operating System Installation Menus. Here you select your console, what language to use, what disks to install to.....and many other options. In NIM we can create a “bosinst_data” resource that will answer these questions for us. By doing this we can perform a “non-prompted” installation. So if you have a NIM client in another building, down the road, or half way across the country, you can create this type of NIM resource which will provide the answers to those questions, so once you kick off the install from the NIM master no further interaction is required. The system should (ideally) install and reboot itself afterward.
A mksysb (as discussed above) has a “built in” bosinst.data file. If the option in that file
(PROMPT =) is set to yes, this file really does nothing as the choices you make in the BOS menus will override the options in the file. However, if the mksysb was created to have that option set to no, then we can create a new bosinst_data resource which will trump the one that is part of the mksysb.
Resource (nim resources) image_data:
Outside of NIM this file is responsible for knowing how your rootvg is built. It contains information like the partition size of rootvg, the disks belonging to rootvg, all of the filesystems (and their sizes) that belong to rootvg, whether the rootvg is mirrored, and other information. As with the bosinst_data file, a mksysb also has one of these “built in”. If this built in file needs to be altered in any way, we can accomplish this by creating and allocating an image_data resource.
NIM Master Installation
Procedure to install and configure the nim master
Command line :
# nimconfig -a pif_name=en0 -a master_port=1058 -a netname=master_net -a cable_type=bnc
pif_name = This is your primary interface for your NIM master
netname = Name your master’s network. With NIM you want to give objects names that are easy and descriptive. If I see “master_net” I know for that is my NIM master’s network. Using a name like “NetworkA” doesn’t really tell you anything just by the name itself.
The rest of the options are default options.
smit :
# smitty nimconfig
-or-
# smitty nim
=> Configure the NIM environment => Advanced configuration => Initialize the NIM master only
* Network Name [master_net]
* Primary Network Install Interface [en0]
Allow Machines to Register Themselves as Clients? [yes]
Alternate Port Numbers for Network Communications
(reserved values will be used if left blank)
Client Registration []
Client Communications []
Once this is complete you have a functioning NIM master.
Take a look at the following output and you’ll see information about your master :
# lsnim -l master
Look at this next output and you’ll see that by defining the NIM master you have some resources that have been pre-generated for you.
# lsnim -l |more
The “boot” resource created a /tftpboot directory to hold all of your boot images.
There’s also a “nim_scripts” resource. That belongs to the master. Do not go into the /export/nim/scripts and mess with any files that get generated during an install.
Finally, there’s a “master_net” which represents the NIM network we created earlier. All NIM clients that are on the same subnet as this master will be assigned to the “master_net” network.
If you add any NIM clients that are on a different network, then you will need to generate a new network name for that network. More on that a little later. Now we’ll go into defining your lpp_source and SPOT resources.
Setting up your first lpp_source resource :
Before we get your lpp_source and SPOT defined we’ll need to decide on a place to put them. One of the best things you can do in NIM is be neat. An organized NIM environment is a happy NIM environment. I recommend having separate filesystems for separate resource types. In other words I’ll have a filesystem to hold my lpp_sources, one to hold my SPOT resources, one for my mksysb images......etc. The “norm” is to use “/export/nim” filesystems.
For my lpp_sources I’ll create a filesystem called /export/nim/lpp_source. A good rule on space is a little more than a ½ gig per volume you want to copy down to your lpp_source. I will be using all 8 volumes of my 5300-05 base AIX media.
# crfs -v jfs2 -g nimvg -m /export/nim/lpp_source -a size=5G
This will create a jfs2 filesystem in nimvg with a size of 5gig and have a mountpoint of /export/nim/lpp_source. Again, this is just an example. Feel free to use rootvg or another volume group. If this command does not fit your environment you can go into :
# smitty crfs
...and create your own filesystem using whatever parameters you need.
We then mount up the filesystem :
# mount /export/nim/lpp_source
The lpp_source is now ready to be created. We’ll need Volume 1 of your base media in the drive. The minimum you’ll use is V1 of the media. You can put 1, 2, 3, or all volumes in the lpp_source. You’re looking at a trade off of space and convenience. I recommend at least having volumes 1-3 if you’re concerned about space. Ideally, and in this example environment, you want to create the lpp_source using all volumes of media.
From command line :
# nim -o define -t lpp_source -a location=/export/nim/lpp_source/53_05 -a server=master -a comments='5300-05 lpp_source' -a multi_volume=yes -a source=/dev/cd0 -a packages=all 5305_lpp
Yes, that would be 1 command. That is one of the reasons many NIM operations are done from SMIT. It’s really easy to mistype something, especially if communicating over the phone with someone in a noisy server room. Now, to break down the command :
The only 2 required fields are the “location” (where we want it to be created) and “server” (which machine will hold this resource). You can hold resources on other NIM clients but for our purposes we will always hold resources on the NIM master. The rest of the “-a” flags are optional. You may think - ‘wait a minute....the source has to be required, otherwise, where do you get the filesets from ?’ You can “pre-generate” the lpp_source. If you’ve already copied the filesets down into a directory and want to use that as your lpp_source, then you have no “source”, you just have a “location”. At the end of the command, I named the resource “5305_lpp”. This is what NIM uses to reference this resource. Next we’ll use smit to do the same thing.
From SMIT :
# smitty nim_mkres
-or-
# smitty nim
=> Perform NIM Administration Tasks => Manage Resources => Define a Resource
Next you select “lpp_source” as the resource type.
* Resource Name [5305_lpp]
* Resource Type lpp_source
* Server of Resource [master]
* Location of Resource [/export/nim/lpp_source/5305]
Architecture of Resource []
Source of Install Images [/dev/cd0]
Names of Option Packages [all]
Show Progress [yes]
Comments [5300-05 lpp_source]
Notice there isn’t an option for multiple volumes. For the most part smit and command line are the same, but occasionally there are differences. Doing it this way will only create the lpp_source from V1 of the media. If you wish to add other volumes you can do one of the following :
A) bffcreate the volumes into the lpp_source
B) use NIM to add the volumes
# smitty nim_res_op
-or-
# smitty nim
=> Perform NIM Administration Tasks => Manage Resources => Perform Operations on Resources
Select your lpp_source
Select “update”
TARGET lpp_source 5305_lpp
SOURCE of Software to Add /dev/cd0
SOFTWARE Packages to Add [all]
-OR-
INSTALLP BUNDLE containing packages to add []
gencopy Flags
DIRECTORY for temporary storage during copying [/tmp]
EXTEND filesystems if space needed? Yes
Process multiple volumes? Yes
Either way, you will get the same result.
How to we take a look at the lpp_source ? We use the ‘lsnim’ command.
# lsnim -l 5305_lpp
5305_lpp:
class = resources
type = lpp_source
comments = 5300-05 lpp_source
arch = power
Rstate = ready for use
prev_state = unavailable for use
location = /export/nim/lpp_source/53_05
simages = yes
alloc_count = 0
server = master
Important lines :
Rstate = if this is not set to “ready for use” then you can not use this resource. Sometimes running a check on the lpp_source will allow you to clear this up.
# nim -o check
simages = This means that this lpp_source has the proper system images in order to properly build a SPOT resource. If any required system image filesets are missing from the lpp_source they will typically be listed at the bottom of the output.
Why wouldn’t you want all lppsources have the “simages” attribute to be “yes” ?
A lpp_source can have pretty much anything you want in it. It doesn’t have to be built from base installation media, nor does it have to be used to only build a SPOT. Let’s say you have your 5300-05 lpp_source, build a SPOT from it, and build some systems.
You then order some service pack updates (5300-05-01) for example. You can update your current lpp_source, but if you do that all of your future installs using this will be at 5300-05-01. If you do not want this to be the case, you can create another lpp_source that only holds these updates. It is more of a preference issue than anything else.
Next, we move on to creating a SPOT resource.
# nimconfig -a pif_name=en0 -a master_port=1058 -a netname=master_net -a cable_type=bnc
pif_name = This is your primary interface for your NIM master
netname = Name your master’s network. With NIM you want to give objects names that are easy and descriptive. If I see “master_net” I know for that is my NIM master’s network. Using a name like “NetworkA” doesn’t really tell you anything just by the name itself.
The rest of the options are default options.
smit :
# smitty nimconfig
-or-
# smitty nim
=> Configure the NIM environment => Advanced configuration => Initialize the NIM master only
* Network Name [master_net]
* Primary Network Install Interface [en0]
Allow Machines to Register Themselves as Clients? [yes]
Alternate Port Numbers for Network Communications
(reserved values will be used if left blank)
Client Registration []
Client Communications []
Once this is complete you have a functioning NIM master.
Take a look at the following output and you’ll see information about your master :
# lsnim -l master
Look at this next output and you’ll see that by defining the NIM master you have some resources that have been pre-generated for you.
# lsnim -l |more
The “boot” resource created a /tftpboot directory to hold all of your boot images.
There’s also a “nim_scripts” resource. That belongs to the master. Do not go into the /export/nim/scripts and mess with any files that get generated during an install.
Finally, there’s a “master_net” which represents the NIM network we created earlier. All NIM clients that are on the same subnet as this master will be assigned to the “master_net” network.
If you add any NIM clients that are on a different network, then you will need to generate a new network name for that network. More on that a little later. Now we’ll go into defining your lpp_source and SPOT resources.
Setting up your first lpp_source resource :
Before we get your lpp_source and SPOT defined we’ll need to decide on a place to put them. One of the best things you can do in NIM is be neat. An organized NIM environment is a happy NIM environment. I recommend having separate filesystems for separate resource types. In other words I’ll have a filesystem to hold my lpp_sources, one to hold my SPOT resources, one for my mksysb images......etc. The “norm” is to use “/export/nim” filesystems.
For my lpp_sources I’ll create a filesystem called /export/nim/lpp_source. A good rule on space is a little more than a ½ gig per volume you want to copy down to your lpp_source. I will be using all 8 volumes of my 5300-05 base AIX media.
# crfs -v jfs2 -g nimvg -m /export/nim/lpp_source -a size=5G
This will create a jfs2 filesystem in nimvg with a size of 5gig and have a mountpoint of /export/nim/lpp_source. Again, this is just an example. Feel free to use rootvg or another volume group. If this command does not fit your environment you can go into :
# smitty crfs
...and create your own filesystem using whatever parameters you need.
We then mount up the filesystem :
# mount /export/nim/lpp_source
The lpp_source is now ready to be created. We’ll need Volume 1 of your base media in the drive. The minimum you’ll use is V1 of the media. You can put 1, 2, 3, or all volumes in the lpp_source. You’re looking at a trade off of space and convenience. I recommend at least having volumes 1-3 if you’re concerned about space. Ideally, and in this example environment, you want to create the lpp_source using all volumes of media.
From command line :
# nim -o define -t lpp_source -a location=/export/nim/lpp_source/53_05 -a server=master -a comments='5300-05 lpp_source' -a multi_volume=yes -a source=/dev/cd0 -a packages=all 5305_lpp
Yes, that would be 1 command. That is one of the reasons many NIM operations are done from SMIT. It’s really easy to mistype something, especially if communicating over the phone with someone in a noisy server room. Now, to break down the command :
The only 2 required fields are the “location” (where we want it to be created) and “server” (which machine will hold this resource). You can hold resources on other NIM clients but for our purposes we will always hold resources on the NIM master. The rest of the “-a” flags are optional. You may think - ‘wait a minute....the source has to be required, otherwise, where do you get the filesets from ?’ You can “pre-generate” the lpp_source. If you’ve already copied the filesets down into a directory and want to use that as your lpp_source, then you have no “source”, you just have a “location”. At the end of the command, I named the resource “5305_lpp”. This is what NIM uses to reference this resource. Next we’ll use smit to do the same thing.
From SMIT :
# smitty nim_mkres
-or-
# smitty nim
=> Perform NIM Administration Tasks => Manage Resources => Define a Resource
Next you select “lpp_source” as the resource type.
* Resource Name [5305_lpp]
* Resource Type lpp_source
* Server of Resource [master]
* Location of Resource [/export/nim/lpp_source/5305]
Architecture of Resource []
Source of Install Images [/dev/cd0]
Names of Option Packages [all]
Show Progress [yes]
Comments [5300-05 lpp_source]
Notice there isn’t an option for multiple volumes. For the most part smit and command line are the same, but occasionally there are differences. Doing it this way will only create the lpp_source from V1 of the media. If you wish to add other volumes you can do one of the following :
A) bffcreate the volumes into the lpp_source
B) use NIM to add the volumes
# smitty nim_res_op
-or-
# smitty nim
=> Perform NIM Administration Tasks => Manage Resources => Perform Operations on Resources
Select your lpp_source
Select “update”
TARGET lpp_source 5305_lpp
SOURCE of Software to Add /dev/cd0
SOFTWARE Packages to Add [all]
-OR-
INSTALLP BUNDLE containing packages to add []
gencopy Flags
DIRECTORY for temporary storage during copying [/tmp]
EXTEND filesystems if space needed? Yes
Process multiple volumes? Yes
Either way, you will get the same result.
How to we take a look at the lpp_source ? We use the ‘lsnim’ command.
# lsnim -l 5305_lpp
5305_lpp:
class = resources
type = lpp_source
comments = 5300-05 lpp_source
arch = power
Rstate = ready for use
prev_state = unavailable for use
location = /export/nim/lpp_source/53_05
simages = yes
alloc_count = 0
server = master
Important lines :
Rstate = if this is not set to “ready for use” then you can not use this resource. Sometimes running a check on the lpp_source will allow you to clear this up.
# nim -o check
simages = This means that this lpp_source has the proper system images in order to properly build a SPOT resource. If any required system image filesets are missing from the lpp_source they will typically be listed at the bottom of the output.
Why wouldn’t you want all lppsources have the “simages” attribute to be “yes” ?
A lpp_source can have pretty much anything you want in it. It doesn’t have to be built from base installation media, nor does it have to be used to only build a SPOT. Let’s say you have your 5300-05 lpp_source, build a SPOT from it, and build some systems.
You then order some service pack updates (5300-05-01) for example. You can update your current lpp_source, but if you do that all of your future installs using this will be at 5300-05-01. If you do not want this to be the case, you can create another lpp_source that only holds these updates. It is more of a preference issue than anything else.
Next, we move on to creating a SPOT resource.
Setting up your first SPOT resource :
Now we will create a filesystem for our SPOT. This does not have nearly the space requirement that an lpp_source does. 500meg should be plenty of space for your initial SPOT. If you recall, the SPOT is just like a /usr filesystem. When you install your system from CD-ROM not every single fileset gets installed to the system right - only what is necessary to run the system. The same applies for the SPOT.
# crfs -v jfs2 -g nimvg -m /export/nim/spot -a size=1G
We then mount up the filesystem :
# mount /export/nim/spot
From command line :
# nim -o define -t spot -a server=master -a source=5305_lpp -a location=/export/nim/spot -a auto_expand=yes -a comments='5300-05 spot' 5305_spot
Here you minimally have 3 required fields. You need to let the NIM master know who will be holding the resource (again, you can use a NIM client as a resource server, but that is rare, and for our purposes, it will always be the NIM master), you need to give it an lpp_source that contains the “simages=yes” attribute, and you need to give it a location to build the resource.
The “auto_expand=yes” is recommended because this allows the system to automatically expand the size of the filesystem if necessary (instead of failing the operation).
From SMIT:
# smitty nim_mkres-or-
# smitty nim
=> Perform NIM Administration Tasks => Manage Resources => Define a Resource
Next you select “SPOT” as the resource type.
* Resource Name [5305_spot]
* Resource Type spot
* Server of Resource [master]
* Source of Install Images [5305_lpp]
* Location of Resource [/export/nim/spot]
Expand file systems if space needed? Yes
Comments [5300-05 spot]
This will take a while to create as it is typically installs 300+ filesets into the SPOT resource. Once this completes you can check the output of the lsnim command to see information about the SPOT.
# lsnim -l 5305_spot
5305_spot:
class = resources
type = spot
comments = 5300-05 spot
plat_defined = chrp
arch = power
bos_license = yes
Rstate = ready for use
prev_state = verification is being performed
location = /export/nim/spot/5305_spot/usr
version = 5
release = 3
mod = 0
oslevel_r = 5300-05
alloc_count = 0
server = master
Rstate_result = success
mk_netboot = yes
Important lines :
Rstate = if this is not set to “ready for use” then you can not use this resource. The first thing you’ll want to do is run a force check against the SPOT. This forces the rebuild of the boot images and should return the “unavailable for use” back to “ready for use”.
# nim -Fo check
oslevel_r = this works just like the ‘oslevel -r’ if you ran that from an AIX command line. Knowing the level of the SPOT resource is extremely important in NIM operations we will go into later.
Your NIM master has officially been initialized and setup. The next 2 sections go into alternate (theoretically “easier”, but we’ll call it “less interactive”) ways of setting up the NIM master.
Feel free to review those and/or move on to defining NIM clients.
Number of Hits :
excellent its very useful
ReplyDelete