The following tasks can be performed on the NIM master:
Once the NIM master fileset has been installed, the master activated, and the master object defined in the NIM database, this object, and hence the master fileset itself, cannot be removed. The master must be deactivated before the NIM master fileset can be removed.
To deactivate the master using Web-based System Manager, see "Unconfiguring the NIM Master".
To use the command line to deactivate the master and remove the NIM master fileset, enter:
nim -o unconfig master installp -u bos.sysmgt.nim.master
By default, when NIM exports a file or directory via NFS during resource allocation, it creates an entry in the /etc/exports file granting the target host both client mount access and root access for root users. As a result, when exporting to numerous clients, the limit on the length of a line in the exports file (32767 characters) may be exceeded, resulting in failure.
NIM provides an option to decrease the line length of an allocation entry in an NFS exports file by roughly half, effectively permitting files to be allocated to a greater number of hosts. This has the side effect of increasing the number of machines permitted in a NIM machine group. NIM achieves this by only granting root access to allocation target hosts. The client mount access list is not created which allows any machine to mount the resource, but still restricts root access to NIM clients only. NFS permits no more than 256 host names in a root exports file entry.
To enable this mode of operation, set the restrict_nfs_exports attribute to no on the master's NIM object. Use the change operation as follows:
nim -o change -a restrict_nfs_exports=no master
To restore client mount access restrictions, set restrict_nfs_exports to yes with the change operation.
For information about how to export NIM resources globally, see "Exporting NIM Resources Globally".
Certain NIM operations are asynchronous, whereby the nim command executed on the master initiates the operation on the client, but does not wait for the operation to finish. This is because the NIM operation on the client is typically time-consuming. An example of an asynchronous operation is the bos_inst operation. Examples of synchronous operations are the cust, maint, and lppchk operations on a single machine target. However, these operations when applied to members of a machine group, are asynchronous. The nim command initiates these operations on each member of the group without waiting for the operation to finish.
If desired, the asynchronous behavior of cust, maint, and lppchk can be controlled by setting the async attribute on the command line. For example, to ensure that the execution of a customization script identified by the NIM resource script1 is executed completely on a given member of the group MacGrp1 before initiating execution of the script on the next member of the group, enter the following:
nim -o cust -a script=script1 -a async=no MacGrp1
To force the master to not wait for the customization operation to finish when running the script on machine Standalone1 that is not part of a machine group, enter:
nim -o cust -a script=script1 -a async=yes Standalone1
By default, progress messages are displayed by the nim command operating on machine groups to inform the user of how much processing remains. Similarly, the output from the installation and customization programs invoked by the cust and maint operations on SPOTs and machines is also displayed. This output can be suppressed by setting the show_progress attribute to no on the command line. For example, to tell NIM not to display output from the installp command when updating the machine Standalone1 with software from the lpp_source named images1 , enter the following command:
nim -o cust -a show_progress=no -a lpp_source=images1 \ -a fixes=update_all Standalone1
It is not unusual for resources such as the SPOT and lpp_source to take several hundred megabytes of storage space on a NIM server. By creating /usr SPOTs and defining CD-ROM file system directories as lpp_sources, space consumption can be reduced significantly on resource servers.
A /usr SPOT can be created from the /usr file system of the NIM master or any NIM client. The AIX system files for the Base Operating System are already installed, so only software for additional device support will be added to the system. The resulting system ultimately has more software installed on it than it needs to run, but far less disk space is used than otherwise would have been, had a non-/usr SPOT been created on the same system. For more information on creating /usr SPOT resources, see the "Shared Product Object Tree (SPOT) Resource" and "Defining /usr versus non-/usr SPOTs".
A directory on the AIX product CD can be mounted and defined as an lpp_source, eliminating the need to copy installation images to the hard disk of a resource server. The defined lpp_source contains all the images available on the CD, but the CD must remain mounted at the server for the lpp_source to be usable in NIM operations. See "Defining an lpp_source on CD-ROM versus Disk" for more information about using a CD-ROM file system as an lpp_source.