A large number of resources (files and directories) are needed to support NIM software installation and maintenance operations. The following is a list of resources:
From the NIM master, to obtain detailed information about any resource, enter:
lsnim -Pa ResourceType
The following sections describe detailed information about each NIM resource. The Web-based System Manager and SMIT interfaces are designed to hide much of the detail required for the command line interface. Therefore, this section only documents the resource task procedures for the command line. The following information applies to the other interfaces as well, but discussion of those interfaces is deferred to the online contextual help available for those applications.
The boot resource is an internally-managed NIM resource used to indicate that a boot image has been allocated to a client. The boot resource is automatically allocated to clients to support NIM operations requiring a network boot. The boot resource will be automatically deallocated when the operation completes.
The nim_script resource is an internally managed NIM resource used to indicate that a script should be run by NIM as part of a NIM operation. The nim_script resource is automatically allocated to support some NIM operations, and it is automatically deallocated when the operations complete.
The Shared Product Object Tree (SPOT) is a fundamental resource in the NIM environment. It is required to install or initialize all machine configuration types. A SPOT provides a /usr file system for diskless and dataless clients, as well as the network boot support for all clients.
Everything that a machine requires in a /usr file system, such as the AIX kernel, executable commands, libraries, and applications are included in the SPOT. Machine-unique information or user data is usually stored in the other file systems. A SPOT can be located on any standalone machine within the NIM environment, including the master. The SPOT is created, controlled, and maintained from the master, even though the SPOT can be located on another system.
There are two ways to create a SPOT. You can convert the /usr file system (/usr SPOT), or you can locate the SPOT elsewhere within the file system (non-/usr SPOT) on the server.
The /usr SPOT inherits all the optional software that is already installed on the server. All the clients using the /usr SPOT have access to the optional software installed on the server. The non-/usr SPOT can be used to manage a different group of optional software than those that are installed and licensed for the server.
Creating a SPOT by converting the /usr file system has the advantage of being fast and using much less disk space. However, this method does not give you the flexibility to choose which software packages will be included in the SPOT, because all the packages and filesets installed in the /usr file system of the machine serving the SPOT will be included in the SPOT. The second method, creating a non-/usr SPOT, uses a lot more disk space, but it is more flexible. Initially, only the minimum set of software packages required to support NIM clients is installed in the SPOT, but additional packages and filesets can be installed. Also, it is possible to have multiple SPOTs, all with different additional packages and filesets installed, serving different clients.
Note that you should not create a non-/usr SPOT in a subdirectory of /usr.
A SPOT varies in size from 100MB up to, and sometimes in excess of, 300MB depending on the software that is installed. Since all device support is installed in the SPOT and the number of device filesets typically increases, the size is not easily predictable from release-to-release.
SPOTs are used to support all NIM operations that require a machine to boot over the network. These operations are as follows:
When a SPOT is created, network boot images are constructed in the /tftpboot directory of the SPOT server, using code from the newly created SPOT. When a client performs a network boot, it uses tftp to obtain a boot image from the server. After the boot image is loaded into memory at the client, the SPOT is mounted in the client's RAM file system to provide all additional software support required to complete the operation.
Each boot image created is up to 4MB in size. Before creating a SPOT, ensure there is sufficient space in the root (/) file system, or create a separate file system for /tftpboot to manage the space required for the network boot images.
The Micro Channel-based systems support booting from the network using Token-Ring, Ethernet, or FDDI. The PowerPC PCI bus-based systems support booting from the network using Token-Ring or Ethernet. The uniprocessor MCA and PCI bus-based systems can be used in a diskless or dataless configuration.
A single network boot image can be accessed by multiple clients; therefore, the network boot image cannot contain any client-specific configuration information. The platform type is specified when the machine object is defined, while the network type is determined from the primary interface definition. Two files are created in the /tftpboot directory on the SPOT server for each client to be network-booted: ClientHostName and ClientHostName.info. The ClientHostName file is a link to the correct network boot image, while the ClientHostName.info file contains the client configuration information.
When the SPOT is defined (and created), the following occurs:
To list the software installed in a SPOT, enter the following command:
nim -o lslpp SPOTName
If you want to change your /usr SPOT back to a normal /usr file system, you must remove the SPOT from the NIM database.
For information about software installation and maintenance tasks you can perform on a SPOT, see the following sections:
Each network boot image supports a single network type and a single platform type. The network boot image files are named SPOTname.Platform.Network. The network types are Token-Ring, Ethernet, and FDDI. Network boot capability is not provided over NIM's generic network type. The platform types are:
A total of seven network boot images are created for different combinations of platforms and network interfaces. The network boot images located in /tftpboot for a SPOT named 41spot , look similar to the following:
41spot.rs6k.ent 41spot.rs6k.fddi 41spot.rs6k.tok 41spot.rs6ksmp.ent 41spot.rs6ksmp.tok 41spot.rspc.ent 41spot.rspc.tok
Each network boot image supports a single network, platform, and kernel type. The network boot image files are named SPOTName.Platform.Kernel.Network. The network types are Token-Ring, Ethernet, and FDDI. The platform types are:
The rs6ksmp platform for 4.2 (and later) SPOTs is represented by the boot image with a platform type of rs6k and a kernel type of mp.
| up | Used for single processor machines. |
| mp | Used for multiple processor machines. |
Both up and mp boot images are created for each platform and network type. The network boot images located in /tftpboot for a SPOT named 42spot look similar to the following:
42spot.rs6k.mp.ent 42spot.rs6k.mp.fddi 42spot.rs6k.mp.tok 42spot.rs6k.up.ent 42spot.rs6k.up.fddi 42spot.rs6k.up.tok 42spot.rspc.mp.ent 42spot.rspc.mp.tok 42spot.rspc.up.ent 42spot.rspc.up.tok
The amount of space used in the /tftpboot directory for boot images may become very large. An AIX 4.2.1 (or later) SPOT that supports network boot for all possible combinations of platforms, kernel types, and network adapters may require as much as 60MB in /tftpboot. If the same server serves multiple SPOTs, the space required in /tftpboot will be even more since each SPOT creates its own set of boot images.
In AIX 4.3, NIM creates by default only the boot images required to support the machines and network types that are defined in the environment. This should significantly reduce the amount of disk space used and the time required to create boot images from SPOT resources. See "Creating Network Boot Images to Support Only the Defined Clients and Networks" for further information.
The command line syntax for defining a SPOT resource is:
nim -o define -t spot -a Attribute=Value ... SPOTName
where the following attributes are required:
and the following attributes are optional:
Note: The creation of a SPOT, by default, produces a large amount of output. Be sure to scan through the output to look for nonfatal errors and warnings that may not be evident from a successful return code.
An lpp_source resource represents a directory in which software installation images are stored. If the lpp_source contains the minimum set of support images required to install a machine, it is given the simages attribute and can be used for BOS installation (bos_inst) operations. If an lpp_source does not contain enough software to be an simages lpp_source, then it can only be used in NIM cust operations to install software on running machines and SPOTs.
NIM uses an lpp_source for an installation operation by first mounting the lpp_source on the client machine. The installp commands are then started on the client using the mounted lpp_source as the source for installation images. When the installation operation has completed, NIM automatically unmounts the resource.
In addition to providing images to install machines, lpp_source resources can also be used to create and update SPOT resources.
The minimum set of images required for an lpp_source to have the simages attribute in AIX 4.2 and later are:
You can define an lpp_source in several ways:
The size of an lpp_source may vary greatly with the amount of software it includes. A minimum lpp_source with just enough software to qualify for the simages attribute may be under 100MB, but a default lpp_source created from a CD-ROM may be over 350MB. It is recommended that a separate file system be created to contain an lpp_source so the space can be more easily managed. By default, NIM automatically expands a file system as needed when creating an lpp_source and copying images from a source device.
The command line syntax for defining an lpp_source resource is:
nim -o define -t lpp_source -a Attribute=Value ... lpp_sourceName
where the following attributes are required:
| -a location=Value | Specifies the directory that will contain the installation images. |
| -a server=Value | Specifies the name of the machine where the lpp_source is to be created. |
and the following attributes are optional:
If a migration installation will be performed on NIM client machines, the lpp_source used in the operation must contain all the required software to migrate the machine.
If the directory specified in the location attribute does not exist, NIM will create the directory. NIM will also remove the directory and its contents if the lpp_source is later removed.
A mksysb resource represents a file that is a system backup image created using the mksysb command. This type of resource can be used as the source for the installation of a client. The mksysb image must reside on the hard disk of a machine in the NIM environment in order to be defined as a resource. It cannot be located on a tape or other external media.
A mksysb resource can be defined from an image that already exists on the hard disk of the NIM master or any NIM client. If such an image does not exist, it can be created when the resource is defined. To create the image when the resource is defined, specify the name of the NIM client that will be the source for the backup, and set the mk_image attribute to yes in the command to define the mksysb resource. Use an exclude_files resource to list any files and directories that should not be included in the backup image.
The command line syntax for defining a mksysb resource is:
nim -o define -t mksysb -a Attribute=Value ... mksysbName
where the following attributes are required:
| -a location=Value | Specifies the full path name of the mksysb image. |
| -a server=Value | Specifies the name of the machine where the mksysb image resides or is to be created. |
and the following attributes are optional:
An exclude_files resource represents a file that contains a list of files and directories that should be excluded when creating a system backup image. This resource may be used when a mksysb resource is being created from a running NIM client.
The command line syntax for defining an exclude_files resource is:
nim -o define -t exclude_files -a Attribute=Value ... \ exclude_filesName
where the following attributes are required:
and the following attributes are optional:
A script resource represents a file that is a user-defined shell script. Once defined, this type of resource can be used to perform processing on a client as part of a NIM cust or bos_inst operation.
script resources are always run by NIM after software installation is performed in cust or bos_inst operations. This allows the scripts to perform configuration processing on the client after all the software is installed. Multiple script resources can be allocated for client use, but the order that the scripts will be run is not predictable.
Note: script resources must not point to files that reside in the /export/nim/scripts directory. This directory is used for the nim_script resource that is managed by NIM. NFS restrictions prevent defining multiple resources in the same location.
The command line syntax for defining a script resource is:
nim -o define -t script -a Attribute=Value ... ScriptName
where the following attributes are required:
| -a location=Value | Specifies the full path name of the script resource file. |
| -a server=Value | Specifies the name of the machine where the script resource file resides. |
and the following attributes are optional:
A bosinst_data resource represents a file that contains information for the BOS install program. Normally, the BOS installation program looks for this information in the /bosinst.data file in the BOS install image. If this file does not exist or if it does not contain all the information that the BOS installation program requires, the program prompts for information by using a console that is local to the target. Information must then be specified manually for the BOS installation to proceed. With a bosinst_data resource, the data can be specified in a NIM resource prior to the installation to prevent the need for prompting at the console.
A sample bosinst.data file (SPOT_Offset/usr/lpp/bosinst/bosinst.template) is located on the SPOT resource server. Also, see "Sample Files" for a sample bosinst_data file.
For instructions on how to create and use a bosinst_data file, see "Performing a Non-Prompted BOS Installation".
The command line syntax for defining a bosinst_data resource is:
nim -o define -t bosinst_data -a Attribute=Value ... \ bosinst_dataName
where the following attributes are required:
| -a location=Value | Specifies the full path name of the bosinst_data resource file. |
| -a server=Value | Specifies the name of the machine where the bosinst_data resource file resides. |
and the following attributes are optional:
An image_data resource represents a file that contains information for the BOS install program. This information describes how physical disks and file systems should be configured in the root volume group during installation. Normally, the BOS install program determines default values that should be used, or uses an image.data file from a mksysb being restored. Only in special cases would you use a customized image_data resource.
A sample image.data file (SPOT_Offset/usr/lpp/bosinst/image.template) is located on the SPOT resource server. For more information about image.data files, see the AIX Version 4.3 Files Reference and the AIX Installation Guide.
The command line syntax for defining an image_data resource is:
nim -o define -t image_data -a Attribute=Value ... image_dataName
where the following attributes are required:
| -a location=Value | Specifies the full path name of the image_data resource file. |
| -a server=Value | Specifies the name of the machine where the image_data resource file resides. |
and the following attributes are optional:
An installp_bundle resource represents a file that contains the names of filesets that should be managed by NIM. During an installation or maintenance operation, NIM mounts the installp_bundle file on the client machine so it can be used by the local installp command. NIM automatically unmounts the resource from the client when the operation has completed.
The command line syntax for defining an installp_bundle resource is:
nim -o define -t installp_bundle -a Attribute=Value ... \ installp_bundleName
where the following attributes are required:
and the following attributes are optional:
A fix_bundle resource represents a file containing fix keywords to be used by the instfix command which is called by the NIM cust and fix_query operations. NIM mounts the fix_bundle resource on the client so it can be used by the local instfix command. NIM automatically unmounts the resource when the operation has completed.
A fix can include either a single fileset update or multiple fileset updates that are related in some way; fixes are identified by unique keywords. When a fix is identified with an Authorized Program Analysis Report (APAR) number, it includes all the fileset updates that are necessary to fix the reported software problem identified by that number.
The command line syntax for defining a fix_bundle resource is:
nim -o define -t fix_bundle -a Attribute=Value ... \ fix_bundleName
where the following attributes are required:
| -a location=Value | Specifies the full path name of the file containing the list of fixes to manage. |
| -a server=Value | Specifies the name of the machine where the fix_bundle resource file resides. |
and the following attributes are optional:
A resolv_conf resource represents a file containing valid /etc/resolv.conf entries which define Domain Name Protocol name-server information for local resolver routines. A resolv_conf resource can be allocated to a standalone machine as part of a bos_inst operation or to a diskless or dataless machine as part of a dkls_init or dtls_init operation. Upon successful installation and reboot, the machine will be configured to use the domain name services defined by the resource.
The following are sample entries in a resolv_conf resource file:
nameserver 129.35.143.253 domain test.ibm.com
The command line syntax for defining a resolv_conf resource is:
nim -o define -t resolv_conf -a Attribute=Value ... \ resolv_confName
where the following attributes are required:
and the following attributes are optional:
A root resource represents a directory in which client root directories are maintained. When this type of resource is allocated to a diskless or a dataless client, NIM creates a subdirectory for the client's exclusive use. This allocated subdirectory is subsequently initialized when you perform the dkls_init or dtls_init operation.
After initialization, anytime the client performs a network boot, the client NFS mounts this subdirectory over "/" to gain access to the root directory that has been set up for its use. This subdirectory remains mounted over "/" on the client as long as the client is running.
Note: Whenever this resource is deallocated, NIM removes the subdirectory that was created for the client's use. Therefore, any files you want to save in the client's subdirectory should be backed up before you deallocate a resource of this type.
The command line syntax for defining a root resource is:
nim -o define -t root -a Attribute=Value ... RootName
where the following attributes are required:
and the following attributes are optional:
A paging resource represents a directory where client paging files are maintained. When this type of resource is allocated to a client, NIM creates a subdirectory for the client's exclusive use. This allocated subdirectory is initialized by the dkls_init or dtls_init operation, which creates a file in this subdirectory that the client configures as a paging device when it performs a network boot. By default, 32MB are reserved for this file. A different value can be specified using the size flag when the dkls_init or dtls_init operation is performed.
After this resource has been initialized for a client, it is configured as a paging device by the client each time the client performs a network boot.
Note: If you subsequently deallocate this resource, NIM removes the paging file and the subdirectory it created for the client's use.
The command line syntax for defining a paging resource is:
nim -o define -t paging -a Attribute=Value ... PagingName
where the following attributes are required:
and the following attributes are optional:
A dump resource represents a directory in which client dump directories are maintained. When this type of resource is allocated to a client, NIM creates a subdirectory for the client's exclusive use. This allocated subdirectory is initialized by the dkls_init or dtls_init operation, which creates an empty file in this subdirectory. After initialization, the client uses this file to store any dump images it creates.
Note: If you subsequently deallocate this resource, NIM removes the dump file and the subdirectory NIM created for the client's use.
The command line syntax for defining a dump resource is:
nim -o define -t dump -a Attribute=Value ... DumpName
where the following attributes are required:
and the following attributes are optional:
A home resource represents a directory in which client /home directories are maintained. When this type of resource is allocated to a client, NIM creates a subdirectory for the client's exclusive use. This allocated subdirectory is subsequently initialized when you perform the dkls_init or dtls_init operation. After initialization, anytime the client performs a network boot, the client NFS mounts this subdirectory over /home to gain access to the home directory that has been set up for its use. This subdirectory remains mounted over /home on the client as long as the client is running.
Note: Whenever this resource is deallocated, NIM removes the subdirectory that was created for the client's use. Therefore, back up any files you want to save in the client's subdirectory before you deallocate a resource of this type.
The command line syntax for defining a home resource is:
nim -o define -t home -a Attribute=Value ... HomeName
where the following attributes are required:
and the following attributes are optional:
A shared_home resource represents a directory that can be used as a common /home directory by one or more clients. When this type of resource is allocated to a client, and when the dkls_init or dtls_init operation is performed, NIM configures the client's configuration to use this common directory. After initialization, anytime the client performs a network boot, the client NFS mounts this common directory over its /home directory. This common directory remains mounted as long as the client is running.
Note: Whenever this resource is deallocated, NIM only changes the client's configuration so that this directory is no longer used by the client. NIM does not remove the common directory.
The command line syntax for defining a shared_home resource is:
nim -o define -t shared_home -a Attribute=Value ... shared_homeName
where the following attributes are required:
and the following attributes are optional:
A tmp resource represents a directory where client /tmp files are maintained. When this type of resource is allocated to a client, NIM creates a subdirectory for the client's exclusive use. This allocated subdirectory is subsequently initialized when you perform the dkls_init or dtls_init operation. After initialization, anytime the client performs a network boot, the client NFS mounts this subdirectory over /tmp to gain access to the /tmp directory that has been set up for its use. This subdirectory remains mounted over /tmp on the client as long as the client is running.
Note: Whenever this resource is deallocated, NIM removes the subdirectory that was created for the client's use. Therefore, back up any files you want to save in the client's subdirectory before you deallocate a resource of this type.
The command line syntax for defining a tmp resource is:
nim -o define -t tmp -a Attribute=Value ... TmpName
where the following attributes are required:
and the following attributes are optional:
Usually, a NIM administrator will use the NIM master as the server for all resources. This strategy keeps all resources together on one machine. However, there are several reasons to distribute resources onto client machines:
Distributing resources on different machines in the NIM environment is simply a matter of specifying the correct server information when the resource is defined. After the resources are created, they are used no differently than resources defined on the master.