Installation and Migration: AIX Version 6.1
Installation and Migration: AIX Version 6.1
Installation and Migration: AIX Version 6.1
Note Before using this information and the product it supports, read the information in Notices on page 397.
This edition applies to AIX Version 6.1 and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation 2002, 2011. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
About this document . . . . . . . . . v
Highlighting . . . . Case-sensitivity in AIX . ISO 9000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v . v . v Troubleshooting a full /usr file system . . . . 92 Viewing BOS installation logs . . . . . . . 92 Interpreting installation-related system and error messages . . . . . . . . . . . . . . 92 Network Installation Management . . . . . . 103 NIM concepts . . . . . . . . . . . . 104 Configuring NIM . . . . . . . . . . . 117 Installing with NIM . . . . . . . . . . 157 Setting up NIM networks . . . . . . . . 175 Booting with NIM . . . . . . . . . . . 181 Administering NIM . . . . . . . . . . 185 Managing NIM . . . . . . . . . . . . 205 Using NIM resources . . . . . . . . . . 217 Using NIM operations . . . . . . . . . 246 Using EZNIM . . . . . . . . . . . . 268 Using network installation files . . . . . . 271 Troubleshooting NIM. . . . . . . . . . 274 Creating and installing system backups. . . . . 303 Creating system backups . . . . . . . . 304 Installing system backups . . . . . . . . 315 Optional products and service updates . . . . . 321 Optionally installed software . . . . . . . 322 Identifying software products . . . . . . . 322 Software licensing . . . . . . . . . . . 323 Managing AIX Editions . . . . . . . . . 323 Preparing to install optional software products and service updates . . . . . . . . . . 324 Checking fileset build dates . . . . . . . 324 Installing optional software products or service updates . . . . . . . . . . . . . . 325 Maintaining optional software products and service updates . . . . . . . . . . . . 329 Cleaning up optional software products and service updates . . . . . . . . . . . . 332 Using the Software Service Management menu (including SUMA) . . . . . . . . . . . 333 Using InstallShield MultiPlatform . . . . . 337 Interim fix management solution . . . . . . 341 Related information . . . . . . . . . . 361 Software product packaging . . . . . . . . 361 Installing variously formatted software packages 361 Fileset installation packages . . . . . . . 362 Creating software packages. . . . . . . . 363 Packaging software bundles . . . . . . . 364 Migrating AIX . . . . . . . . . . . . . 366 Ensuring binary compatibility between AIX 6.1 and earlier versions . . . . . . . . . . 367 BOS pre- and post-migration checks . . . . . 368 Migrating to AIX 6.1 . . . . . . . . . . 369 mksysb migration . . . . . . . . . . . 372 Related information . . . . . . . . . . 377 Partitioning . . . . . . . . . . . . . . 377 Partitioning concepts . . . . . . . . . . 377 Implementations of logical partitions . . . . 380 Network adapter communication between partitions and the HMC . . . . . . . . . 381
iii
Installing AIX in a partitioned environment . Creating and changing a dedicate dump device Verifying your dump device . . . . . . Shutting down a partition . . . . . . . Changing your operating system host name .
Notices . . . . . . . . . . . . . . 397
Trademarks . . . . . . . . . . . . . . 399
Index . . . . . . . . . . . . . . . 401
iv
Highlighting
The following highlighting conventions are used in this document:
Bold Identifies commands, subroutines, keywords, files, structures, directories, and other items whose names are predefined by the system. Also identifies graphical objects such as buttons, labels, and icons that the user selects. Identifies parameters whose actual names or values are to be supplied by the user. Identifies examples of specific data values, examples of text similar to what you might see displayed, examples of portions of program code similar to what you might write as a programmer, messages from the system, or information you should actually type.
Italics Monospace
Case-sensitivity in AIX
Everything in the AIX operating system is case-sensitive, which means that it distinguishes between uppercase and lowercase letters. For example, you can use the ls command to list files. If you type LS, the system responds that the command is not found. Likewise, FILEA, FiLea, and filea are three distinct file names, even if they reside in the same directory. To avoid causing undesirable actions to be performed, always ensure that you use the correct case.
ISO 9000
ISO 9000 registered quality systems were used in the development and manufacturing of this product.
vi
October 2011
The following information is a summary of the updates made to this topic collection: v Documented the NIM support for VIOS and IVM machines. Added information on NIM operations, rules and restriction for the VIOS and IVM NIM objects.
In this scenario, you will do the following: v Boot from the AIX product media v Set BOS Installation Settings Perform a new and complete overwrite installation of AIX onto hdisk0 Use English as the primary language Use the default options in the More Options menu v Start the BOS Installation and Configure the System
Copyright IBM Corp. 2002, 2011
If you are overwriting an existing system, gather the TCP/IP information from the system before you begin this scenario. Attention: This procedure requires shutting down and reinstalling the base operating system. Whenever you reinstall any operating system, schedule your downtime when it least impacts your workload to protect yourself from a possible loss of data or functionality. Before you perform a new and complete overwrite installation, ensure you have reliable backups of your data and any customized applications or volume groups. For instructions on how to create a system backup, refer to Creating system backups. The following steps show you how to use the system's built-in media device to perform a new and complete overwrite base operating system installation. At this point, the BOS Installation is complete, and the initial configuration of the system is complete.
Welcome to Base Operating System Installation and Maintenance Type the number of your choice and press Enter. >>> 1 Start Install Now with Default Settings 2 Change/Show Installation Settings and Install 3 Start Maintenance Mode for System Recovery 4 Configure Network Disks (iSCSI) Choice is indicated by >>>.
3. Type 1 for New and Complete Overwrite in the Choice field and press Enter. The Change Disk(s) Where You Want to Install screen now displays.
Change Disk(s) Where You Want to Install Type one or more numbers for the disk(s) to be used for installation and press Enter. To cancel a choice, type the corresponding number and Press Enter. At least one bootable disk must be selected. The current choice is indicated by >>>. Name 1 2 3 >>> 0 66 77 88 99 hdisk0 hdisk1 hdisk2 Location Code 04-B0-00-2,0 04-B0-00-5,0 04-B0-00-6,0 Size(MB) 4296 4296 12288 VG Status Bootable Yes Yes Yes
Continue with choices indicated above Disks not known to Base Operating System Installation Display More Disk Information Help ? Previous Menu
a. Select hdisk0 by typing a 1 in the Choice field and press Enter. The disk will now be selected as indicated by >>>. To unselect the destination disk, type the number again and press Enter. b. To finish selecting disks, type a 0 in the Choice field and press Enter. The Installation and Settings screen displays with the selected disks listed under System Settings. 5. Change the Primary Language Environment Settings to English (United States). Use the following steps to change the Cultural Convention, Language, and Keyboard to English. a. Type 2 in the Choice field on the Installation and Settings screen to select the Primary Language Environment Settings option. b. Type the number corresponding to English (United States) as the Cultural Convention in the Choice field and press Enter. c. Select the appropriate keyboard and language options. You do not need to select the More Options selection, because you are using the default options in this scenario. For more information about the installation options available in AIX, see BOS installation options. 6. Verify that the selections are correct in the Overwrite Installation Summary screen, as follows:
Overwrite Installation Summary Disks: hdisk0 Cultural Convention: en_US Language: en_US Keyboard: en_US JFS2 File Systems Created: Yes Graphics Software: Yes Desktop: CDE System Management Client Software: Yes Enable System Backups to install any system: Optional Software being installed: >>> 1 88 99 Continue with Install Help ? Previous Menu
Yes
The default options change based on machine, security, and console type. 7. Press Enter to begin the BOS installation. The system automatically reboots after installation is complete.
Things to consider
The information in this how-to scenario was tested using specific versions of AIX. The results you obtain might vary significantly depending on your version and level of AIX.
In this scenario, you will do the following: v Perform a migration installation of AIX 5.1 to AIX Version 6.1 v Use English as the primary language v Use the default options in the Advanced Options menu Attention: This procedure requires shutting down and reinstalling the base operating system. Whenever you reinstall any operating system, schedule your downtime when it least impacts your workload to protect yourself from a possible loss of data or functionality. Before you perform a migration installation, ensure you have reliable backups of your data and any customized applications or volume groups. For instructions on how to create a system backup, refer to Creating system backups in Installation and migration.
v Before you begin the installation, other users who have access to your system must be logged off. v Verify that your applications will run on AIX Version 6.1. Also, check if your applications are binary-compatible with AIX Version 6.1. If your system is an application server, verify that there are no licensing issues. Refer to your application documentation or provider to verify on which levels of AIX your applications are supported and licensed. You can also check the Supported Products List at the following Web address: http://www-03.ibm.com/services/sl/products/ v Check that your hardware microcode is up-to-date. v All requisite hardware, including any external devices (such as tape drives or CD/DVD-ROM drives), must be physically connected and powered on. If you need further information, refer to the hardware documentation that accompanied your system. v Use the errpt command to generate an error report from entries in the system error log. To display a complete detailed report, type the following:
# errpt -a
v There must be adequate disk space and memory available. AIX requires 256512 MB of memory and 2.2 GB of physical disk space. For additional release information, see the AIX 6.1 Release Notes. v Run the pre_migration script located in the mount_point/usr/lpp/bos directory on your media. To mount the media run the following command:
# mount -v cdrfs -o ro /dev/cdN /mnt
where "N" is your media drive number. Note: Do not remove the data created by the pre_migration script, because it is used by the post_migration script. v Make a backup copy of your system software and data. For instructions on how to create a system backup, refer to Creating system backups. v Always refer to the release notes for the latest migration information.
Installation and migration
4. When the system beeps twice, press F5 on the keyboard (or 5 on an ASCII terminal). If you have a graphics display, you will see the keyboard icon on the screen when the beeps occur. If you have an ASCII terminal (also called a tty terminal), you will see the word keyboard when the beeps occur. Note: If your system does not boot using the F5 key (or the 5 key on an ASCII terminal), refer to your hardware documentation for information about how to boot your system from an AIX product media. 5. Select the system console by pressing F1 (or 1 on an ASCII terminal) and press Enter. 6. Select the English language for the BOS Installation menus by typing a 5 at the Choice field and press Enter. The Welcome to Base Operating System Installation and Maintenance menu opens. 7. Type 2 to select 2 Change/Show Installation Settings and Install in the Choice field and press Enter.
Welcome to Base Operating System Installation and Maintenance Type the number of your choice and press Enter. 1 Start Install Now with Default Settings 2 Change/Show Installation Settings and Install 3 Start Maintenance Mode for System Recovery 4 Configure Network Disks (iSCSI) Choice is indicated by >>>.
2. Select Primary Language Environment Settings (AFTER Install). 3. Type 3 and press Enter to select More Options. To use the Help menu to learn more about the options available during a migration installation, type 88 and press Enter in the Installation Options menu. For more information about the installation options available in AIX Version 6.1, see BOS installation options. 4. Verify the selections in the Migration Installation Summary screen and press Enter. 5. When the Migration Confirmation menu opens, follow the menu instructions to list system information or continue with the migration by typing 0 and pressing Enter.
Migration Confirmation Either type 0 and press Enter to continue the installation, or type the number of your choice and press Enter. 1 List the saved Base System configuration files which will not be merged into the system. These files are saved in /tmp/bos. 2 List the filesets which will be removed and not replaced. 3 List directories which will have all current contents removed. 4 Reboot without migrating. Acceptance of license agreements is required before using system. You will be prompted to accept after the system reboots. >>> 0 Continue with the migration. 88 Help ? +--------------------------------------------------------------------------WARNING: Selected files, directories, and filesets (installable options) from the Base System will be removed. Choose 2 or 3 for more information.
>>> Choice[0]:
A user-defined software bundle is a text file ending in .bnd that is located in the /usr/sys/inst.data/ user_bundles path. By creating the software bundle file in the /usr/sys/inst.data/user_bundles path, SMIT (System Management Interface Tool) can locate the file and display it in the bundle selection screen. In this scenario, you will do the following:
v Create a user-defined software bundle that contains the Web-based System Manager Security application, which is located on the Expansion Pack v Install the software bundle v Verify the installation of the software bundle was successful
2. Add the software products, packages, or filesets to the bundle file with one entry per line. Add a format-type prefix to each entry. For this example, we are dealing with AIX installp packages, so the format-type prefix is I:. Type the following in the MyBundle.bnd file: I:sysmgt.websm.security. For more information on installation format types, see Software product packaging. 3. Save the software bundle file and exit the text editor.
4. Change the values provided in the Install Software Bundle screen as appropriate to your situation. You can change the PREVIEW only? option to yes to preview the installation of your software bundle before you install it. You might also need to accept new license agreements if the software in your bundle has an electronic license.
Install Software Bundle Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] /cdrom MyBundle [all] no/yes yes no yes yes no yes no yes no/yes no F4=List F8=Image
* INPUT device / directory for software * BUNDLE * SOFTWARE to install PREVIEW only? (install operation will NOT occur) COMMIT software updates? SAVE replaced files? AUTOMATICALLY install requisite software? EXTEND file systems if space needed? VERIFY install and check file sizes? Include corresponding LANGUAGE filesets? DETAILED output? Process multiple volumes? ACCEPT new license agreements? Preview new LICENSE agreements? F1=Help Esc+5=Reset F9=Shell F2=Refresh F6=Command F10=Exit F3=Cancel F7=Edit Enter=Do
+ + + + + + + + + + + + +
5. Press Enter to continue. 6. Press Enter a second time to confirm your decision and begin the installation of your software bundle.
v You can also verify the installation at a later time by completing one of the following: Run the following command:
lslpp -Lb MyBundle
The output indicates whether the installation of your user-defined software bundle was successful. You might see output similar to the following:
Fileset Level State Type Description ------------------------------------------------------------------------------------------sysmgt.websm.security 6.1.0.0 C F WebSM Security Components State A -B -C -E -O -? -codes: Applied. Broken. Committed. EFIX Locked. Obsolete. (partially migrated to newer version) Inconsistent State...Run lppchk -v.
Type codes: F P C T R E ------Installp Fileset Product Component Feature RPM Package Interim Fix
Complete the following steps in SMIT: 1. Type the following at a command line: smitty list_installed 2. Select List Installed Software by Bundle. 3. With your cursor at the BUNDLE name field, press F4 and select your bundle from the list. 4. Press Enter. Output is shown similar to that in the preceding option.
The AIX Toolbox for Linux Applications media that is shipped with your base operating system software contains the most commonly used open source applications that you can use with the AIX operating system. Your options for installing from this media include: v Using the SMIT install_software fast path to install RPM packages from the AIX Toolbox for Linux Applications media. v Using the geninstall command to install RPM packages from the AIX Toolbox for Linux Applications media. v Installing a bundle. Bundles group the applications you need for a basic Linux operating environment, basic desktop use, GNOME or KDE desktop use, or application development. v Installing from a directory of packages classified by function. These directory groupings cover a broad range of applications, shell environments, network applications, development tools, application libraries, and so on. v Installing a single package for a particular application. The following procedures provide examples of installing RPM packages from AIX Toolbox for Linux Applications media. v To install the cdrecord and mtools RPM packages using SMIT, do the following: 1. Run the SMIT install_software fast path. 2. Enter the device name for the AIX Toolbox for Linux Applications media (for example, /dev/cd0), and press Enter. 3. Use the F4 key to list the contents of the device.
10
4. Select the cdrecord and mtools packages, and press Enter. 5. Accept the default values for the rest of the Install Software menu fields, and press Enter. 6. Confirm that you do want to install the software, and press Enter. The software installation process begins at this point. v To install the cdrecord and mtools RPM packages from the command line, type the following:
# geninstall -d/dev/cd0 R:cdrecord R:mtools
The software installation process begins at this point. v Use the rpm command, which is automatically installed with the base operating system for AIX, to install the bundles required for the GNOME desktop and the bc application package. Complete instructions are available on the readme file for the AIX Toolbox for Linux Applications. 1. With your system powered on and AIX running, insert the AIX Toolbox for Linux Applications media into the media drive of your system. 2. With root authority, mount the media drive using the following command:
mount -vcdrfs -oro /dev/cd0 /mnt
The -v flag specifies the virtual file system type of cdrfs. The -o flag specifies the ro option, which means the mounted file is read-only. The device name is /dev/cd0. The directory in which you want to mount the media drive is /mnt. 3. Change to the /mnt directory by using the following command:
cd /mnt
4. Use the ls command to list the contents of the media. The listing contains the following, which you can view or print: The readme file contains complete instructions for installing from this media. The CONTENTS file lists all packages available on this media and provides a short description of the purpose for each package. 5. In your Web browser, open the /mnt/LICENSES/index.html file to view software licensing information. 6. In your terminal window, change to the ezinstall/ppc directory by using the following command:
cd /mnt/ezinstall/ppc
In the next step, you use the rpm program to install GNOME by installing four bundles (Base, Desktop Base, GNOME Base, and GNOME Apps). Alternatively, you can install all necessary packages using the smit install_bundle fast path and selecting the GNOME bundle. 7. Install GNOME by using the following sequence of commands:
rpm rpm rpm rpm -Uhv -Uhv -Uhv -Uhv ezinstall/ppc/base/* ezinstall/ppc/desktop.base/* ezinstall/ppc/gnome.base/* ezinstall/ppc/gnome.apps/*
The -U flag updates any earlier versions of each package that you might have on your system. The -h flag prints hash marks (#) at timed intervals to indicate that the installation is progressing. The -v flag displays relevant informational or error messages that occur during the installation. Your result will look similar to the following:
rpm -Uhv ezinstall/ppc/desktop.base/* gdbm ################################################## libjpeg ################################################## libpng ################################################## libtiff ################################################## libungif ################################################## readline ################################################## zlib ##################################################
If your rpm command returns an error, it is probably caused by one of the following:
Installation and migration
11
Not enough space in your current file system. Resize the file system or change your mount point. Package is already installed. The rpm program discovered an existing package of the same name and version level, so it did not replace the package. A script on the media installs only those packages from a directory that are not already installed on your system, as shown in the following example:
/mnt/contrib/installmissing.sh ezinstall/ppc/desktop.base/*
Failed dependencies. The packages listed in the error message must be installed before you can install this package or bundle. 8. Install the bc application package by using the following command:
rpm -Uhv RPMS/ppc/bc-*.rpm
Because the alternate disk installation process involves cloning an existing rootvg to a target alternate disk, the target alternate disk must not be already assigned to a volume group. In this scenario you will do the following: v v v v Prepare for the alternate disk installation Perform the alternate disk installation and customization Boot off the alternate disk Verify the operation
For information about alternate disk installation, see Installing to an alternate disk. Also, refer to the alt_disk_copy man page.
We can use hdisk1 as our alternate disk because no volume group is assigned to this physical disk. 2. Check to see if the alt_disk_copy fileset has been installed by running the following:
# lslpp -L bos.alt_disk_copy.rte
Output similar to the following displays if the alt_disk_copy fileset is not installed:
lslpp: 0504-132 Fileset bos.alt_disk_copy.rte not installed.
3. Using volume 1 of the AIX installation media, install the alt_disk_copy fileset by running the following:
# geninstall -d/dev/cd0 bos.alt_disk_copy.rte
12
4. Create a user-defined bundle called /usr/sys/inst.data/user_bundles/MyBundle.bnd that contains the following filesets:
I:bos.content_list I:bos.games
For more information on how to create a user-defined software bundle, refer to Creating and installing a software bundle. 5. Create the /home/scripts directory:
mkdir /home/scripts
2. Select hdisk1 in the Target Disk to Install field. 3. Select the MyBundle bundle in the Bundle to Install field. 4. Insert volume one of the installation media. 5. 6. 7. 8. Type /dev/cd0 in the Directory or Device with images field. Type /home/scripts/AddUsers.sh in the Customization script field. Press Enter to start the alternate disk installation. Check that the alternate disk was created, by running the following:
# lspv
The system boots from the boot image on the alternate disk (hdisk1).
Installation and migration
13
2. Verify that the customization script ran correctly, by typing the following:
# find /home/johndoe -print
3. Verify that the contents of your software bundle was installed, by typing the following:
# lslpp -Lb MyBundle
The SMIT EZNIM option installs the bos.sysmgt.nim.master fileset and configures the NIM environment. The configuration involves creating the NIM database and populating it with several default entries. Several basic NIM resources will then be created and defined in the NIM database. 1. Type the following: # smitty eznim. 2. Select Configure as a NIM Master, and press Enter. 3. Select Setup the NIM Master Environment, and press Enter. 4. Verify that the default selections for software source, volume group, and file system are correct for your environment. Change the selections, if needed. 5. Press Enter to begin configuring the NIM environment. 6. To display the NIM resources that have been created, do the following: a. Use the SMIT eznim_master_panel fast path to open the EZNIM Master menu. b. Select Show the NIM environment, and press Enter.
14
The information in this how-to scenario was tested using specific versions of AIX. The results you obtain might vary significantly depending on your version and level of AIX.
It is assumed that you have already configured the NIM master, defined the basic NIM resources, and defined the NIM client you want to install. For a guide on configuring the NIM environment and defining resources, see NIM Task Roadmap. In this scenario, you will do the following: 1. Perform an BOS (rte) installation. 2. Use a bosinst_data resource to perform a nonprompted installation. For information on how to create a bosinst.data file for nonprompted installation, see Using the bosinst.data file. 3. Use a resolv_conf resource to configure the network nameserver and domain. It is recommended that you first perform a system backup on the client to ensure safe system recovery. For instructions on how to create a system backup, see Creating system backups. 1. Type the following: # smit nim_bosinst. 2. Select the lpp_source resource for the BOS installation. 3. Select the SPOT resource for the BOS installation. 4. Select the BOSINST_DATA to use during installation option, and select a bosinst_data resource that is capable of performing a nonprompted BOS installation. 5. Select the RESOLV_CONF to use for network configuration option, and select a resolv_conf resource. 6. Select the Accept New License Agreements option, and select Yes. Accept the default values for the remaining menu options. 7. Press Enter to confirm and begin the NIM client installation. 8. To check the status of the NIM client installation, type: # lsnim -l va09. Output similar to the following displays:
va09: class = machines type = standalone default_res = basic_res_grp platform = chrp netboot_kernel = 64 if1 = master_net va09 0 cable_type1 = bnc Cstate = Base Operating System installation is being performed prev_state = BOS installation has been enabled Mstate = in the process of booting info = BOS install 7% complete : 0% of operations completed. boot = boot bosinst_data = bid_tty_ow lpp_source = 520lpp_res nim_script = nim_script resolv_conf = master_net_conf spot = 520spot_res cpuid = 0009710F4C00 control = master Cstate_result = success
15
The information in this how-to scenario was tested using specific versions of AIX. The results you obtain might vary significantly depending on your version and level of AIX.
In this scenario, you will do the following: v Gather the required TCP/IP information for your JS20 blade. v Prepare your Network Installation Management (NIM) environment. v Configure a NIM master. v Create NIM installation resources. v Define your JS20 blade as a NIM client. v Prepare your JS20 blade for a network installation. v Boot the JS20 blade off the network using a directed bootp or broadcast bootp method. To perform a network install, you will need to configure a NIM master if you do not already have one configured. For instructions about how to create a NIM master, see Configuring NIM and other basic operations Note: This procedure requires shutting down and reinstalling the base operating system. When you reinstall any operating system, schedule your downtime when it least impacts your workload to protect yourself from a possible loss of data or functionality. Before you perform a new and complete overwrite installation, ensure you have reliable backups of your data and any customized applications or volume groups. For instructions about how to create a system backup, see Creating system backups.
16
2. Specify the MAC Address when you define the JS20 blade as a NIM client. If you are using the smitty nim_mkmac command, specify the MAC address on the Network Adapter Hardware Address SMIT screen. Do not include the colons (":") when you are specifying the MAC address. If the client is already defined, you can change the MAC address with the smitty nim_chmac command. 3. Set up your NIM master to install the JS20 blade, by completing the following steps: a. Run the smitty nim_bosinst command. b. Select the JS20 blade that is defined as your target . c. Select the type of install that you want to perform and select the installation resources that you want to use to install the JS20 blade. You can also prepare the JS20 blade to install using the bos_inst NIM operation on the command line. For more information on using the bos_inst operation, see Using the NIM bos_inst operation. 4. Power off the JS20 blade. If you do not want the JS20 blade to reboot automatically, set Initiate reboot and installation now? to no in the SMIT screen and press Enter. Step 2: Initiate the installation from the management module The bootp protocol allows you to install through a directed bootp or broadcast bootp request. 1. Ensure that the JS20 blade's boot list is set to install from the network in the MM Web interface by selecting Blade Tasks > Configuration and scroll down Boot Sequence. 2. Click the JS20 blade that you are installing and ensure the first device listed is Network BOOTP. When the JS20 blade boots, it will install from the first network adapter that receives a bootp response. Note: You should not have a serial over LAN connection open to the JS20 blade that you are attempting to install when you power on the JS20 blade. 3. Click save. 4. Power on the JS20 blade from the MM Web interface by selecting Blade Tasks > Power/Restart. 5. Select the JS20 blade that you are installing and click Power On Blade. If you do not have an serial over LAN connection to the JS20 blade, you can view the status of the installation by running the following command from your NIM master:
lsnim -l js20_nim_name
For example, if the JS20 blade was defined as JS20blade1, run the following command:
lsnim -l JS20blade1
Note: If you run the AIX bootlist command to set the IP parameters for a network adapter and reboot the system, the IP parameters will be stored in NVRAM. When you reboot the JS20 blade from the MM with the boot sequence set to Network-BOOTP, the JS20 blade attempts to use the IP parameters stored in NVRAM instead of performing a broadcast bootp. To perform a broadcast bootp, run the bootlist command specifying 0.0.0.0 for each IP parameter and reboot from AIX using the shutdown -Fr command. For example, to perform a broadcast bootp over ent1, run the following commands.
# bootlist -m normal ent1 client=0.0.0.0 bserver=0.0.0.0 gateway=0.0.0.0 hdisk0 # shutdown -Fr
If you are unable to log into the AIX system, then follow the instructions for performing a directed bootp via the Open Firmware prompt, but specify "0.0.0.0" for each IP address. Once the JS20 blade installs successfully, the boot IP parameters are reset to "0.0.0.0".
17
3. Define the JS20 blade as a NIM client on your NIM master by running the smitty nim_mkmac command on the NIM master. This command creates a client definition for your JS20 blade. You can also define the JS20 blade using the define NIM operation on the command line. 4. If you want to set the JS20 blade's name server and domain name after the installation, use a resolv_conf resource. For more information on creating a resolv_conf resource, see Using the nim_script resource. 5. Set up your NIM master to install the JS20 blade, by running the smitty nim_bosinst command. Select the JS20 blade that you defined earlier as your target. Then select the type of install that you want to perform and select the installation resources that you want to use to install the JS20 blade. You can also prepare the JS20 blade to install using the bos_inst NIM operation on the command line. Note: a. If the JS20 blade is powered off or has never been installed, set Initiate reboot and installation now? to no and press enter in the SMIT interface. b. If the JS20 blade is powered on and running AIX, set Initiate reboot and installation now? to yes in the SMIT interface. If you choose this option, a directed bootp is initiated by default and you can skip step 2. Before you run this command, ensure that the JS20 blade is a registered NIM client. To do this, run smitty niminit on the JS20 blade. Then specify the hostname of your NIM master and the interface you want to use for the installation. You can also initialize the JS20 blade using the niminit command on the command line. Step 2: Specify a directed bootp from the JS20 blade
18
1. Open a Web interface to the MM by navigating to the IP address or hostname of the MM using a Web browser. 2. Enable serial over LAN to the JS20 blade from the MM Web interface by selecting Blade Tasks > Serial Over LAN . 3. Select the JS20 blade that you are installing and click Enable Serial Over LAN. 4. Power on the JS20 blade from the MM Web interface by selecting Blade Tasks > Power/Restart. 5. Select the JS20 blade that you are installing and click Power On Blade. 6. Open a serial over LAN connection to the JS20 blade by telnetting into the MM and running the console command. For example, if the JS20 blade is in slot 3, you would run the following command:
console -T blade[3]
The serial over LAN connection shows a series of LED numbers. 7. Press 8 on the keyboard when you see E1F1 to go to the Open Firmware prompt. 8. Run boot net:bootp,server_ip,,client_ip,gateway_ip to boot from the network. v If you are using a net type boot, you would run a command similar to the following:
boot net:bootp,192.168.2.10,,192.168.1.11,192.168.1.1
v If you are using ent1, then you would run a command similar to the following:
boot /pci@8000000f8000000/pci@0/ethernet@1,1:bootp,192.168.2.10,,192.168.1.11,192.168.1.1
Note: You must specify the full device path name with this command. To determine the full path to your device, list the device tree by running the ls command at the Open Firmware prompt. This command displays output similar to the following:
0 > ls 000000c87f18: /ibm,serial 000000c88840: /chosen 000000c88a98: /packages ... 000000d31488: /vdevice 000000d327a8: /vty@0 000000d32f88: /IBM,sp@4000 000000d33f10: /rtc@4001 000000d34a18: /pci@8000000f8000000 000000d384d0: /pci@0 000000d4bbd0: /ethernet@1 000000d5af50: /ethernet@1,1 000000d3be00: /pci@3 000000d6a350: /usb@0 000000d845f8: /hub@1 000000d854b8: /usb@0,1 000000d9f760: /hub@1 000000d3f798: /pci@1f 000000d45ed8: /ide@4,1 000000d47b10: /disk@0
The highlighted items are the path to the second ethernet adapter. You would pass this information to the boot command to initiate a network boot from the second ethernet adapter 9. After you run the boot command, then network installation begins. Output similar to the following is displayed on the serial over LAN connection:
BOOTP: BOOTP: BOOTP: BOOTP: BOOTP: chosen-network-type = ethernet,auto,none,auto server IP = 192.168.2.10 requested filename = client IP = 192.168.1.11 client HW addr = 0 d 60 1e c cb
Installation and migration
19
BOOTP: gateway IP = 192.168.1.1 BOOTP: device /pci@8000000f8000000/pci@0/ethernet@1,1 BOOTP: loc-code U8842.P1Z.23A0984-P1-T7 BOOTP R = 1 FILE: /tftpboot/js20blade1.austin.ibm.com Load Addr=0x0000000000004000, Max Size=0x0000000000bfc000 FINAL Packet Count = 21131 FINAL File Size = 10818623 bytes. load-base=0x4000 real-base=0xc00000 Elapsed time since release of system processors: 2 mins 28 secs ...
v All hardware must already be installed, including external devices, such as tape and media drives.
20
v The bos.sysmgt.sysbr fileset must be installed. The bos.sysmgt.sysbr fileset is automatically installed in AIX. To determine if the bos.sysmgt.sysbr fileset is installed on your system, type:
# lslpp -l bos.sysmgt.sysbr
If the lslpp command does not list the bos.sysmgt.sysbr fileset, install it before continuing with the backup procedure. Type the following:
# installp -agqXd /dev/cd0 bos.sysmgt.sysbr
4. 5. 6. 7. 8. 9. 10. 11.
12. Record any backed-up root and user passwords. Remember that these passwords become active if you use the backup to either restore this system or install another system. You have successfully created the backup of your rootvg. Because the system backup contains a boot image, you can use this tape to start your system if for some reason you cannot boot from hard disks.
The target systems might not contain the same hardware devices or adapters or be the same hardware platform as the source system. All devices are installed by default during the base operating system (BOS) installation process. If the Enable System Backups to install any system selection in the Install Software menu was set to yes, you can create a mksysb image that boots and installs supported systems. Verify that your system is installed with all devices by typing the following:
# grep ALL_DEVICES_KERNELS /var/adm/ras/bosinst.data
21
ALL_DEVICES_KERNELS = yes
Use this scenario if your system was not installed with all devices during BOS installation. Be sure to boot from the appropriate product media for your system and at the same maintenance or technology level of BOS as the installed source system on which the mksysb was made. For example, use BOS AIX media with a mksysb from a BOS AIX system. Use this how-to while installing a system backup tape to a different system. In this scenario, perform the following steps: 1. Boot the system with the AIX Volume 1 media in the media drive and the system backup tape in the tape device. Note: You can boot from a CD and use a tape for the installation. However, during a tape boot, you cannot use the CD and DVD drives to supply customized information. 2. Select Start Maintenance Mode for System Recovery. 3. Select Install from a System Backup. 4. Select the drive containing the backup tape, and press Enter. The system reads the media and begins the installation. You are then prompted for the BOS installation language, and the Welcome screen displays. Continue with the Prompted Installation, because cloning is not supported in nonprompted installations. If you are cloning from the product media to restore a backup tape, do not remove the media from the media drive. After the mksysb installation completes, the installation program automatically installs additional devices on your system, using the original product media you booted from. Information is saved in BOS installation log files. To view BOS installation log files, type cd /var/adm/ras and view the devinst.log file in this directory. If the source system does not have the correct passwords and network information, you can make modifications on the target system now. Also, some products (such as graPHIGS) ship device-specific files. If your graphics adapter is different on the target system, verify that the device-specific filesets for graphics-related LPPs are installed.
The cleanup procedure attempts to delete items that were partially installed or left in an incomplete state. This scenario applies only to the update or installation of optional software products. If your AIX BOS installation was unsuccessful, see Troubleshooting after a BOS installation. Note: It is recommended that you first perform a system backup before installing software updates to ensure safe system recovery. For instructions on how to create a system backup, refer to Creating system backups.
22
The cleanup procedure attempts to revert the update to its previous state. For example, when cleaning up an update that was interrupted in the COMMITTING state, the cleanup procedure attempts to return the update to its APPLIED state. If an update installation is interrupted, run the lslpp -l command to see the current state of the update. For example, if you run lslpp -l on an interrupted update installation, it might report the update status as APPLYING rather than APPLIED. If the interruption occurs during the initial state of an installation, then the cleanup procedure attempts to delete the installation entirely and restore the previous version of the product (if there is one). When the previous version is restored, it becomes the active version. When the previous version cannot be restored, the software is listed by the lslpp -l command as BROKEN. When the product is deleted or BROKEN, you can attempt to reinstall the software. Any product in the BROKEN state cannot be cleaned up; it can only be reinstalled or removed. To initiate a cleanup procedure using SMIT: 1. Type smit maintain_software on the command line. 2. Select Clean Up After Failed or Interrupted Installation and press Enter. To initiate a cleanup procedure from the command line: Type installp -C on the command line and press Enter. If prompted to reboot (restart) the system after running the cleanup procedure, then do so now. If you get a message indicating that no products were found that could be cleaned up, you may have executed the cleanup procedure when it was not needed. Try your installation again.
Installing AIX using the media device to install a partition with an HMC
In this procedure, you will perform a new and complete base operating system installation on a logical partition using the partition's media device. This procedure assumes that there is an HMC attached to the managed system.
Prerequisites
Things to consider
The information in this how-to scenario was tested using specific versions of AIX. The results you obtain might vary significantly depending on your version and level of AIX.
Note: For the installation method that you choose, ensure that you follow the sequence of steps as shown. Within each procedure, you must use AIX to complete some installation steps, while other steps are completed using the HMC interface. Before you begin this procedure, you should have already used the HMC to create a partition and partition profile for the client. Assign the SCSI bus controller attached to the media device, a network adapter, and enough disk space for the AIX operating system to the partition. Set the boot mode for this partition to be SMS mode. After you have successfully created the partition and partition profile, leave the partition in the Ready state. For instructions about how to create a logical partition and partition profile, refer to the Creating logical partitions and partition profiles article in the IBM eServer Hardware Information Center.
Step 1. Activate and install the partition (perform these steps in the HMC interface)
1. Activate the partition, as follows: a. Insert the AIX 6L Volume 1 media into the media device of the managed system.
Installation and migration
23
b. In the navigation panel, open Systems Management > Servers, and click the system on which the logical partition is located. c. From the Tasks menu, select partition, click Operations > Activate > Profile. d. Select Open a terminal window or console session at the bottom of the menu to open a virtual terminal (vterm) window. e. Select Advanced to open the Advanced options menu. f. For the Boot mode, select SMS. g. Select OK to close the Advanced options menu. h. Select OK. A vterm window opens for the partition. 2. In the SMS menu on the vterm, do the following: a. Press the 5 key and press Enter to select 5. Select Boot Options.
PowerPC Firmware Version SF220_001 SMS 1.5 (c) Copyright IBM Corp. 2000, 2003 All rights reserved. ------------------------------------------------------------------------------Main Menu 1. 2. 3. 4. 5. Select Language Setup Remote IPL (Initial Program Load) Change SCSI Settings Select Console Select Boot Options
------------------------------------------------------------------------------Navigation Keys: X = eXit System Management Services ------------------------------------------------------------------------------Type the number of the menu item and press Enter or select Navigation Key: 5
b. Press the 2 key and press Enter to select 2. Select Boot Devices. c. Press the 1 key and press Enter to select 1. Select 1st Boot Device. d. Press the 3 key and press Enter to select 3. CD/DVD. e. Select the media type that corresponds to the media device and press Enter. f. Select the device number that corresponds to the media device and press Enter. The media device is now the first device in the Current Boot Sequence list. g. Press the ESC key until you return to the Configure Boot Device Order menu. h. Select the device number that corresponds to the hard disk and press Enter. i. Press the x key to exit the SMS menu. Confirm that you want to exit SMS. 3. Boot from the AIX Volume 1, as follows: a. Select console and press Enter. b. Select language for BOS Installation menus, and press Enter to open the Welcome to Base Operating System Installation and Maintenance menu. c. Type 2 to select Change/Show Installation Settings and Install in the Choice field and press Enter.
24
Welcome to Base Operating System Installation and Maintenance Type the number of your choice and press Enter. 1 Start Install Now with Default Settings 2 Change/Show Installation Settings and Install 3 Start Maintenance Mode for System Recovery 4 Configure Network Disks (iSCSI) 88 Help ? 99 Previous Menu >>> Choice [1]: 2 Choice is indicated by >>>.
4. Verify or Change BOS Installation Settings, as follows: a. Type 1 in the Choice field to select the System Settings option. b. Type 1 for New and Complete Overwrite in the Choice field and press Enter. Note: The installation methods available depend on whether your disk has a previous version of AIX installed. c. When the Change Disk(s) screen opens, you can change the destination disk for the installation. If the default shown is correct, type 0 in the Choice field and press Enter. To change the destination disk, do the following: 1) Type the number for each disk you choose in the Choice field and press Enter. Do not press Enter a final time until you have finished selecting all disks. If you must deselect a disk, type its number a second time and press Enter. 2) When you have finished selecting the disks, type 0 in the Choice field and press Enter. The Installation and Settings screen opens with the selected disks listed under System Settings. d. If needed, change the primary language environment. Use the following steps to change the primary language used by this installation to select the language and cultural convention you want to use. Note: Changes to the primary language environment do not take effect until after the Base Operating System Installation has completed and your system is rebooted. 1) Type 2 in the Choice field on the Installation and Settings screen to select the Primary Language Environment Settings option. 2) Select the appropriate set of cultural convention, language, and keyboard options. Most of the options are a predefined combination, however, you can define your own combination of options. v To choose a predefined Primary Language Environment, type that number in the Choice field and press Enter. v To configure your own primary language environment, do the following: a) Select MORE CHOICES. b) Select Create Your Own Combination. c) When the Set Primary Cultural Convention screen opens, type the number in the Choice field that corresponds to the cultural convention of your choice and press Enter. d) When the Set Primary Language screen opens, type the number in the Choice field that corresponds to your choice for the primary language and press Enter. e) When the Set Keyboard screen opens, type the number in the Choice field that corresponds to the keyboard attached to the system and press Enter.
25
e. After you have made all of your selections, verify that the selections are correct. Press Enter to confirm your selections and to begin the BOS Installation. The system automatically reboots after installation is complete. 5. Switch the partition to Normal Mode, as follows: a. Right-click on the partition profile to open the menu. Be sure the correct partition profile is highlighted. b. c. d. e. f. g. Select Properties. Select the Settings tab. For the Boot Mode, select Normal. Select OK to close the Properties menu. Right-click on the partition to open the menu. Select Restart Partition.
h. Select Immediate for the Restart Options. i. Confirm that you want to restart the partition. j. When the partition has restarted, right-click on the partition to open the menu. k. Select Open terminal window to open a virtual terminal (vterm) window. 6. Complete the BOS Installation, as follows: a. Type vt100 as the terminal type.
Set Terminal Type The terminal is not properly initialized. Please enter a terminal type and press Enter. Some terminal types are not supported in non-English languages. ibm3101 ibm3151 ibm3161 ibm3162 ibm3163 ibm3164 ibmpc lft tvi912 tvi920 tvi925 tvi950 vs100 vt100 vt320 sun vt330 vt340 wyse30 wyse50 wyse60 wyse100 wyse350
88 99
Help ? Exit
+-----------------------Messages-----------------------| If the next screen is unreadable, press Break (Ctrl-c) | to return to this screen. | |
b. In the License Agreement menu, select Accept License Agreements. c. Select yes to ACCEPT Installed License Agreements. d. Press F10 (or Esc+0) to exit the License Agreement menu. e. In the Installation Assistant main menu, select Set Date and Time.
Installation Assistant Move cursor to desired item and press Enter. Set Date and Time Set root Password Configure Network Communications Install Software Applications Using SMIT (information only)
F1=Help F9=Shell
F2=Refresh F10=Exit
F3=Cancel Enter=Do
F8=Image
26
f. Set the correct date, time, and time zone. Press the F3 (or Esc+3) key to return to the Installation Assistant main menu. g. Select Set root Password. Set a root password for the partition. h. Select Configure Network Communications. Select TCP/IP Startup. Select from the Available Network Interfaces and press Enter. Enter the appropriate network information in the Minimum Configuration and Startup menu and press Enter. Use the F3 (or Esc+3) key to return to the Installation Assistant main menu. i. Exit the Installation Assistant by pressing F10 (or Esc+0). j. The vterm window displays a login prompt.
Step 2. Manage your partition (perform this step in the AIX environment)
When the installation has completed and the system has rebooted, the vterm window displays a login prompt. At this point, you may want to perform several common system-administration procedures. The following table lists where to find information about performing these procedures.
Table 3. Common System Administration Procedures
Procedure Backing up and recovering system backups Managing users and groups Installing software Installing fixes/updates Tuning the system for performance Configuring printers Location "Creating and installing system backups" in Installation and migration "Users, Roles, and Passwords" in Security "Optional Software Products and Service Updates" in Installation and migration "Optional Software Products and Service Updates" in Installation and migration "Performance tuning" in Performance management Printers and printing
Installing AIX using the media device to install a partition without an HMC
In this procedure, you will use the system's built-in media device to perform a new and complete Base Operating System Installation on the standalone system. Things to consider
The information in this how-to scenario was tested using specific versions of AIX. The results you obtain might vary significantly depending on your version and level of AIX.
This information contains procedures to install the AIX operating system. For more information on concepts and considerations involved when performing a base operating system installation of AIX, or concepts and requirements involved when using the Network Installation Manager (NIM) to install and maintain AIX, refer to Installation and migration. At this point, the BOS Installation is complete, and the initial configuration of the system is complete.
27
28
2. To change the System Settings, which includes the method of installation and disk where you want to install, type 1 in the Choice field and press Enter.
Installation and Settings Either type 0 and press Enter to install with current settings, or type the number of the setting you want to change and press Enter. 1 System Settings: Method of Installation.............New and Complete Overwrite Disk Where You Want to Install.....hdisk0
3. Type 1 for New and Complete Overwrite in the Choice field and press Enter. The Change Disk(s) Where You Want to Install screen now displays.
Change Disk(s) Where You Want to Install Type one or more numbers for the disk(s) to be used for installation and press Enter. To cancel a choice, type the corresponding number and Press Enter. At least one bootable disk must be selected. The current choice is indicated by >>>. Name 1 2 3 >>> 0 66 77 88 99 hdisk0 hdisk1 hdisk2 Location Code 04-B0-00-2,0 04-B0-00-5,0 04-B0-00-6,0 Size(MB) 4296 4296 12288 VG Status Bootable Yes Yes Yes
Continue with choices indicated above Disks not known to Base Operating System Installation Display More Disk Information Help ? Previous Menu
4. In the Change Disk(s) Where You Want to Install screen: a. Select hdisk0 by typing a 1 in the Choice field and press Enter. The disk will now be selected as indicated by >>>. To unselect the destination disk, type the number again and press Enter. b. To finish selecting disks, type a 0 in the Choice field and press Enter. The Installation and Settings screen displays with the selected disks listed under System Settings. 5. Change the Primary Language Environment Settings to English (United States). Use the following steps to change the Cultural Convention, Language, and Keyboard to English. a. Type 2 in the Choice field on the Installation and Settings screen to select the Primary Language Environment Settings option. b. Type the number corresponding to English (United States) as the Cultural Convention in the Choice field and press Enter. c. Select the appropriate keyboard and language options. 6. Verify that the selections are correct in the Overwrite Installation Summary screen, as follows:
29
Overwrite Installation Summary Disks: hdisk0 Cultural Convention: en_US Language: en_US Keyboard: en_US Desktop: CDE Enable System Backups to install any system: Optional Software being installed: >>> 1 88 99 Continue with Install Help ? Previous Menu
Yes
7. Press Enter to begin the BOS installation. The system automatically reboots after installation is complete.
30
The information in this how-to scenario was tested using specific versions of AIX. The results you obtain might vary significantly depending on your version and level of AIX.
v On systems with a graphics display, after a new and complete overwrite installation, the Configuration Assistant opens. 1. Select the Accept Licenses option to accept the electronic licenses for the operating system. 2. Set the date and time, set the password for the administrator (root user), and configure network communications (TCP/IP). Use any other options at this time. You can return to the Configuration Assistant at any time by typing configassist at the command line. 3. Select Exit the Configuration Assistant and select Next. 4. If you are in the Configuration Assistant, select Finish now, and do not start Configuration Assistant when restarting AIX and select Finish. At this point, the BOS Installation is complete, and the initial configuration of the system is complete. v On systems with an ASCII display, after a new and complete overwrite installation, the Installation Assistant opens. 1. If the Set Terminal Type menu appears, type vt100 as the terminal type.
Set Terminal Type The terminal is not properly initialized. Please enter a terminal type and press Enter. Some terminal types are not supported in non-English languages. ibm3101 ibm3151 ibm3161 ibm3162 ibm3163 ibm3164 ibmpc lft tvi912 tvi920 tvi925 tvi950 vs100 vt100 vt320 sun vt330 vt340 wyse30 wyse50 wyse60 wyse100 wyse350
88 99
Help ? Exit
+-----------------------Messages-----------------------| If the next screen is unreadable, press Break (Ctrl-c) | to return to this screen. | |
2. 3. 4. 5.
In the License Agreement menu, select Accept License Agreements. Select yes to ACCEPT Installed License Agreements. Press F10 (or Esc+0) to exit the License Agreement menu. In the Installation Assistant main menu, select Set Date and Time.
Installation Assistant Move cursor to desired item and press Enter. Set Date and Time Set root Password Configure Network Communications Install Software Applications Using SMIT (information only)
F1=Help F9=Shell
F2=Refresh F10=Exit
F3=Cancel Enter=Do
F8=Image
6. Set the correct date, time, and time zone. Press the F3 (or Esc+3) key to return to the Installation Assistant main menu. 7. Select Set root Password. Set a root password for the partition.
Installation and migration
31
8. Select Configure Network Communications. Select TCP/IP Startup. Select from the Available Network Interfaces and press Enter. Enter the appropriate network information in the Minimum Configuration and Startup menu and press Enter. Use the F3 (or Esc+3) key to return to the Installation Assistant main menu. 9. Exit the Installation Assistant by pressing F10 (or Esc+0). 10. The vterm window displays a login prompt. At this point, the BOS Installation is complete, and the initial configuration of the system is complete.
Activation Engine
Activation Engine is an enablement framework used for boot-time customization of virtual images. You can find information related to customizing a running system by performing configuration steps such as, bringing up the network interface(s), creating non-default user accounts along with their permissions, and creating new file systems.
32
1. Enable and configure Activation Engine on the target system. You must enable Activation Engine on the AIX system by running the enable command. This process adds an Activation Engine entry to the /etc/inittab file, that is executed when the system boots. 2. Capture a virtual image of the virtual desktop infrastructure of the target system. This is the image you use to deploy to other systems. The target system must have the Activation Engine enabled so you can customize specific parameters when the system boots. The image is captured using the VM Control tool. 3. Create virtual image templates for the systems you want to deploy the Activation Engine. 4. Place the virtual image templates and scripts on optical drives at the appropriate location of the systems that you are deploying the Activation Engine. 5. Boot the target systems using virtual desktop infrastructure. To configure and use the Activation Engine that is performed using the Activation Engine binary, at the /usr/sbin/ae file, use the following usage message:
/usr/sbin/ae a {enable|disable|status|check|run}
enable<template> - Enables the Activation Engine disable- Disables the Activation Engine status- Prints current status of Activation Engine check<template> - Validates a user created template against the Activation Engine schema run<template> - Executes the activation engine against a particular template file
Current Limitations
Activation Engine is executed from the /etc/inittab file, which is executed after the initial system boot. This means that any configuration performed at the initial boot such as the NIM customization scripts is overridden by the rules set in Activation Engine templates. The customization performed using Activation Engine script on a system is limited to changing only the configuration settings of the system because the script is run during system boot. For example, you must not use the Activation Engine script and templates to install new file sets. Activation Engine is used for changing system configuration, and must not be used to modify the user space. The Activation Engine does not perform any input validation when parsing template files. To validate, the Activation Engine requires root access, and it is the responsibility of the user to create and store the XML template files. During the process of enabling and disabling the Activation Engine, the /etc/inittab file is modified. To ensure that data integrity Activation Engine creates a backup copy of the file at /etc/inittab.old. This backup file is NOT deleted during the cleanup process.
Required Inputs
Input to the Activation Engine is the default image template file. Activation Engine script has a default location that it uses to search for virtual image template files in the optical media. The script attempts to mount and search the available optical media until it finds the initial template file, called ae_template.xml. Activation Engine uses the first template image it finds, in any of the optical discs it mounts. The default template file must be located in the root directory of the disc. If it does not find the template on any optical media it exits with an error message.
33
Schema
This following is an XML schema that is used to validate the Activation Engine template files:
<?xml version="1.0" encoding="ISO-8859-1"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="template"> <xs:complexType> <xs:sequence> <xs:element name="settings"> <xs:complexType> <xs:sequence> <xs:element name="logDirectory" type="xs:string" minOccurs="0"/> <xs:element name="scriptsDirectory" type="xs:string"/> <xs:element name="extensions" minOccurs="0"> <xs:complexType> <xs:sequence> <xs:element name="extendedTemplate" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="rules"> <xs:complexType> <xs:sequence> <xs:element name="section" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="ruleSet" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:any minOccurs="0" processContents="lax" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="script" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:schema>
The schema can be used to validate the custom made virtual image template files. To validate, type:
/usr/sbin/ae
34
Example
An example for ae_template.xml file is as follows:
<?xml version="1.0" encoding="UTF-8"?> <template name="Default Activation Engine template"> <settings> <!-- created automatically if it doesnt exist --> <logDirectory>/var/adm/ras/nim/ae/</logDirectory> <!-- / is assumed to be / of optical media --> <scriptsDirectory>/ae/scripts/</scriptsDirectory> <extensions> <extendedTemplate>/ae/user_template1.xml</extendedTemplate> <extendedTemplate>/ae/user_template2.xml</extendedTemplate> </extensions> </settings> <rules> <section name="network" script="ae_network.sh"> <ruleSet> <address>9.3.148.163</address> <mask>255.255.254.0</mask> <gateway>9.3.148.0</gateway> <routes>default:0:9.3.149.1</routes> </ruleSet> </section> <section name="accounts" script="ae_accounts.sh"> <ruleSet> <username>scott</username> <groups>admin,sys,system</groups> <admin>true</admin> <home>/home/bear</home> </ruleSet> <ruleSet> <username>eric</username> <groups>cron,security</groups> <rlogin>true</rlogin> <home>/home/misty</home> </ruleSet> </section> <section name="filesystems" script="ae_filesystems.sh"> <ruleSet> <mountpoint>/usr/blah</mountpoint> <type>jfs2</type> <size>3834383</size> <efs>yes</efs> <vix>no</vix>
Installation and migration
35
</ruleSet> <ruleSet> <mountpoint>/usr/bleh</mountpoint> <type>jfs</type> <size>9595999</size> <efs>no</efs> <volume_id>Bleh</volume_id> </ruleSet> </section> </rules> </template>
Template Settings
The template settings are rules-specific to a particular template file that includes the following: v logDirectory: Is a directory with the script logs. Each script has a separate log file. For example, if a script was called ae_network_extension.sh then its log file is ae_network_extension.log and is placed in the directory specified by logDirectory rule. If the logDirectory does not exist when Activation Engine starts execution, run the mkdir command to create the directory. v scriptsDirectory: Is a directory that defines the location of the scripts. The script contains information about how each rule in the template must be linked to a particular script, and the script must be run to apply the rule. The default scripts provided are ae_network.sh, ae_accounts.sh and ae_filesystems.sh. These scripts contains basic functionality and must be extended for more advanced uses. The root of the path specified in scriptsDirectory element is assumed to be the root of the mounted optical media containing the template. v extensions: Is a list of all user created virtual image templates that must be processed by the Activation Engine. Specify the templates that must be processed in order and with full file path. This list is not required if there are no user extensions to the process. Note: The parameters of the template settings are not customizable because it is interpreted by the Activation Engine.
Creating AE Scripts
You can find information related to the AE script.
Scripts
You can create custom templates and their scripts. It is implied that if you create your templates, the template has custom scripts to execute the new rules that you have created in your templates. The scriptsDirectory in template settings is the place to define the location of your scripts. If you want to link a particular section to a script that must be executed by AE in your section, then you must place the script in location defined by scriptsDirectory.
36
It is expected that all the created scripts to be executed by the Activation Engine, must follow a certain set of criteria. The important requirement is that the created scripts must accept the set of arguments passed to them by the Activation Engine, as defined in the RuleSet section of the template files linking to these scripts. For example, the network section of the template file contains:
<section name="network" script="ae_network.sh"> <ruleset> <address>9.3.148.163</address> <mask>255.255.254.0</mask> <gateway>9.3.148.0</gateway> <routes>default:0:9.3.149.1</routes> </ruleset> </section>
The script ae_network.sh is expected to accept all three arguments as defined in the included RuleSet: address, mask, and gateway. The script also has to provide a proper return code to the Activation Engine. It must return 0 for SUCCESS and 1 for FAILURE. Return code of 2 is reserved for SUCCESS_WITH_WARNINGS, which informs AE the script was successful with minor warnings and AE must log it in the execution logs. The scripts are also not expected to pipe their output to any external file. Any verbose/error messages must be sent to STDOUT, or STDERR where they are piped by AE to the appropriate destination log files, as defined in the template settings section. See, Template settings, for more details. The scripts have certain expectations from the templates created by you. Firstly, any custom template file must follow the defined structure as defined in Schema. See Schema for more information. The template must contain a Settings section and a Rules section. The Settings section might or might not be filled out. If any or all of the rules in Settings section is not filled out by the template then its parents' rules are used. (The parent template is the ae_template.xml template file). Note that if the scriptsDirectory settings are not present in the custom template file, then the AE cannot call any scripts that are not defined in the parent template. The rules section of the XML file must be filled out and it must follow the rigid structure of rules:
<rules> <section name="SECTION_NAME" script="SCRIPT"> <ruleset> <argument1>value1</argument1> <argument2>value2</argument2> </ruleset> </section> </rules>
In the above example, SCRIPT is a placeholder for a custom string that names the subscript. SCRIPT can be a filename of any system executable script, as long as its location is defined in the scriptsDirectory element. The above script will be run as follows:
PATH/SCRIPT argument1=value1 argument2=value2
All argument and value pairs are processed and passed to the script in the way described above. PATH represents the scriptsDirectory path defined in the settings section. See Template settings for more details.
Template Extensions
The process of linking to template extensions is similar to linking new scripts. You must define extensions list that includes your custom made templates that need to be processed by AE. Activation Engine, initially processes its default template file, ae_template.xml and then searches for the extension settings.
Installation and migration
37
If the AE find the settings, it uses that list to process template files created by you. Templates created by you must match the predefined structure of AE template files described in the section, Schema. If the newly created template file does not match the exact structure required by AE, the template is not processed by the engine. Just as with script extensions there are certain expectations from the templates created by you. Firstly, any custom template file must follow the defined structure as defined in Schema. See Schema for more information. The template must contain a Settings section and a Rules section. The Settings section might or might not be filled out. If any or all of the rules in Settings section is not filled out by the template then its parents' rules are used. (The parent template is the ae_template.xml template file). Note that if the scriptsDirectory settings are not present in the custom template file, then the AE cannot call any scripts that are not defined in the parent template.
38
Migration This method upgrades from earlier versions of the AIX BOS to AIX 6.1 (see the release notes for restrictions). The migration installation method is used to upgrade from an existing version or release of AIX to a later version or release of AIX. A migration installation preserves most file systems, including the root volume group, logical volumes, and system configuration files. It overwrites the /tmp file system. For instructions on migrating an existing version or release of AIX to a later version or release of AIX, refer to Migrating AIX on page 366. The following table shows the differences in the installation steps among the installation methods.
Table 7. AIX BOS Installation Methods
Installation Steps Create rootvg Create file system /, /usr, /var Create file system /var/adm/ras/livedump. If this file system does not exist, it is created during any method of installation. Create file system /home Save Configuration Restore BOS Install Additional Filesets Restore Configuration New and Complete Overwrite Yes Yes Yes Preservation No Yes Yes, if not present* Migration No No Yes, if not present*
No No Yes Yes No
* The livedump file system is only created during preservation or migration installations if it does not exist. You can modify the file system by using a customized bosinst.data file with a livedump stanza.
Note: To turn on the debug mode for the BOS installation process, type 911 in the Choice field and press Enter. The Welcome to Base Operating System Installation and Maintenance window refreshes and the
39
BOS installation process runs in debug mode when the installation occurs. Continue the procedure for selecting options and specifying data until the installation begins. Debug output is sent to the client's display as the installation proceeds. If you select Start Install Now with Default Settings, the BOS command determines the default installation method to use based on your system's configuration. A summary window displays, similar to the following, where you can confirm the installation method and installation options:
Overwrite Installation Summary Disks: hdisk0 Cultural Convention: en_US Language: en_US Keyboard: en_US JFS2 File Systems Created: Yes Graphics Software: Yes System Management Client Software: Yes Enable System Backups to install any system: Selected Edition: express Optional Software being installed:
Yes
>>> 1
Continue with Install +----------------------------------------------------88 Help ? | WARNING: Base Operating System Installation will 99 Previous Menu | destroy or impair recovery of ALL data on the | destination disk hdisk0. >>> Choice [1]:
If the selections are correct, press Enter to begin the BOS installation. However, if you would like to change the installation method or options, go back to the Welcome to Base Operating System Installation and Maintenance menu.
Welcome to Base Operating System Installation and Maintenance Type the number of your choice and press Enter. >>> 1 Start Install Now with Default Settings 2 Change/Show Installation Settings and Install 3 Start Maintenance Mode for System Recovery 4 Configure Network Disks (iSCSI) 5 Select Storage Adapters 88 99 Help ? Previous Menu Choice is indicated by >>>.
If you want to reduce the number of disks available for selection, select option 5 Select Storage Adapters. Next from the menu listing every storage adapter on the system, select one, many, or all. If you do a preservation or migration install, and the current rootvg is on multiple disks attached to multiple adapters, select all the adapters on which the rootvg disks resides.
40
| | | | | | | | | | | | | | | | | | |
Welcome to Base Operating System Installation and Maintenance Type the number of your choice and press Enter. 1 Start Install Now with Default Settings >>> 2 Change/Show Installation Settings and Install 3 Start Maintenance Mode for System Recovery 4 Configure Network Disks (iSCSI) 5 Select Storage Adapters 88 99 Help ? Previous Menu Choice is indicated by >>>.
To continue and make more install time selections, select choice 2, Change/Show Installation Settings and Install. The Installation and Settings menu displays, as follows:
Installation and Settings Either type 0 and press Enter to install with current settings, or type the number of the setting you want to change and press Enter. 1 System Settings: Method of Installation.............New and Complete Overwrite Disk Where You Want to Install.....hdisk0
Primary Language Environment Settings (AFTER Install): Cultural Convention................English (United States) Language ..........................English (United States) Keyboard ..........................English (United States) Keyboard Type......................Default 3 Security Model.......................Default 4 More Options (Software install options) 5 Select Edition.......................express >>> 0 Install with the current settings listed above. +----------------------------------------------------| WARNING: Base Operating System Installation will | destroy or impair recovery of ALL data on the | destination disk hdisk0.
88 99
For more information on the BOS menu options, refer to the Help at any time by typing 88 in the Choice field.
41
automatically with the BOS. Some software, such as the GNOME or KDE desktops, can be optionally installed during BOS installation; the appropriate licensing information for such software is displayed separately. If a customized bosinst.data file is used (usually for unattended installations, or nonprompted installations), the ACCEPT_LICENSES field in the control_flow stanza can be used to accept the license agreements so users are not prompted at reboot time. When performing a "push" installation using the Network Installation Management (NIM) environment, the licenses must be accepted, either from the choices made when initializing the installation or in a customized bosinst.data file, before the installation can continue. For more information about the bosinst.data file, refer to The bosinst.data file on page 45. For additional software package installations, the installation cannot occur unless the appropriate license agreements are accepted. This option, as well as options to preview licenses, is offered in both the System Management Interface Tool (SMIT) and the Web-based System Manager installation interfaces. When using the installp command, use the -Y flag to accept licenses and the -E flag to view license agreement files on the media. For more information about license manipulation, refer to the inulag command description in the AIX Version 6.1 Commands Reference, Volume 3.
42
Trusted Computing Base install The Trusted Computing Base (TCB) is the part of the system that is responsible for enforcing the information security policies of the system. All of the computer's hardware is included in the TCB, but a person administering the system should be concerned primarily with the software components of the TCB. If you install the Trusted Computing Base option, you enable the trusted path, trusted shell, and system-integrity checking (tcbck command). These features can be enabled only during BOS installation. The choices are yes and no. To enable the Trusted Computing Base, type 2 and press Enter. The default is no. CAPP and EAL4+ Configuration install Applies only to a new and complete overwrite installation. If you enable Controlled Access Protection Profile (CAPP) and Evaluation Assurance Level 4+ (EAL4+), there are restrictions on installation choices, such as: v v v v Desktop = CDE or NONE JFS2 = yes Enable system backups to install any system (installs all devices and kernels) = no Install more software options = no
For information about CAPP and EAL4+, see Controlled Access Protection Profile and Evaluation Assurance Level 4+ in Security. Desktop The default is CDE for new and complete overwrite installations. If you select NONE, a minimal configuration is installed including X11, Java, perl, SMIT, and the Web-based System Manager (if Graphics Software is selected). If you select GNOME or KDE, the BOS installation process prompts you for the AIX Toolbox for Linux Applications media. If this media is not available, you can type q to continue the installation without the AIX Toolbox for Linux Applications media. You can select additional desktops from the Install More Software menu. Import User Volume Groups Applies only to migration installation and preservation installation. You have the option to have user volume groups imported after the installation completes. These volume groups can be manually imported at a later time. Create JFS2 File Systems Applies only to new and complete overwrite installation, as well as preservation installation. Create enhanced journaled file systems during BOS installation. Graphics Software Applies only to new and complete overwrite installation, as well as preservation installation. Install graphics software support. System Management Client Software Installs web-based system management software, Java, service agent software, and System p Console runtime software. Remove Java 1.1.8 Software Applies only to migration installation. You have the option to have all Java version 1.1.8 software removed. Enable System Backups If you select Enable System Backups to install any system, all devices are installed, so that a system backup can be installed on a different system. For more information about installing a system backup to a different system, see Cloning a system backup.
43
Install More Software Applies to new and complete overwrite installation method, as well as the preservation installation method. Select Install More Software to choose additional software to install after the BOS installation process finishes. A software bundle file corresponds to each selection that contains the required packages and filesets. The following software bundles are available:
Install More Software 1. 2. 3. 4. 5. Firefox (Firefox CD).............................................. Kerberos_5 (Expansion Pack)....................................... Server (Volume 2)................................................ GNOME Desktop (Toolbox for Linux Applications).................... KDE Desktop (Toolbox for Linux Applications)...................... No No No No No
>>> 0 88 99
Install with the current settings listed above. Help ? Previous Menu
The new and complete overwrite installation options (with no security models) are similar to the following:
Install Options Create JFS2 File Systems......................................... System Management Client Software................................ Graphics Software................................................ Desktop.......................................................... Enable System Backups to install any system...................... (Installs all devices) >>> 6. Install More Software 0 88 99 Install with the current settings listed above. Help ? Previous Menu 1. 2. 3. 4. 5. Yes Yes Yes NONE, CDE, GNOME, KDE Yes
Select Edition Type the number of this menu item to toggle through the choices of express, standard, or enterprise. The edition selection defines the signature file copied to the /usr/lpp/bos directory. The signature file is used by the IBM License Metric Tool (ILMT), to facilitate licensing compliance.
44
INSTALL_METHOD
45
INSTALL_EDITION
PROMPT
Specifies the edition selection, which defines the license manager signature file to be copied to the /usr/lpp/bos directory on the system. The choices are express, standard, or enterprise, and the default option is express. The signature file is used by the IBM License Metric Tool (ILMT), to facilitate licensing compliance. Specifies whether the installation program uses menus from which you make choices. The possible values are yes (default) and no. Note: You must fill in values for all variables in the locale stanza to uniquely identify the disk, if you set the PROMPT variable to no. Similarly, if PROMPT equals no, you must supply values for variables in the control_flow stanza, with two exceptions: the ERROR_EXIT and CUSTOMIZATION_FILE variables, which are optional. Attention: Fill in values for enough variables in the target_disk_data stanza if you set the PROMPT variable to no. The BOS installation program assigns target disks for blank variables. You can lose data if the installation program assigns a disk where you store data. Confirms that the installation program can overwrite existing volume groups. This variable is applicable only for a non-prompted overwrite installation. The possible values are no (default), yes, and any. no yes (Default) Only disks that are not part of a volume group can be used for the installation. Disks that contain the root volume group is used first, and if additional disks are needed for the installation, then disks that contain no volume groups are used. Any disks can be used for the installation.
EXISTING_SYSTEM_OVERWRITE
any
When the installation is non-prompted and the target_disk_data stanza is empty, the installation process uses the value of the EXISTING_SYSTEM_OVERWRITE field to determine the disks to install on. When you do a prompted installation, this value is changed to yes, and is saved with other changes in the /var/adm/ras/bosinst.data file. Network Install Manager (NIM) creates a default bosinst.data file (NIM bosinst_data resource) with this value set to yes, and system backups use the bosinst.data file that is copied from the /var/adm/ras directory, so in most cases this value is already be set to yes. If this field is set to no, as seen in the /usr/lpp/bosinst/bosinst.template file, an error message informs you that there are not enough disks matching the criteria needed to complete the installation during a non-prompted install. The BOS installation is then changed to a prompted BOS installation, and the value of the EXISTING_SYSTEM_OVERWRITE field is set to yes. Specifies whether a desktop should be installed or not. The possible values are yes, all, and no. The default value for this field is yes, meaning that if the system has a graphical console, and a DESKTOP is specified, the desktop is installed. If set to all and a DESKTOP is specified, the desktop is installed, whether the system has a graphical console or not. If set to no and a DESKTOP is specified, the desktop is not installed. Starts the Configuration Assistant on first boot after the BOS installation completes, if the system has a graphical interface. Starts Installation Assistant if the machine has an ASCII interface. The possible values are yes (default) and no. The no value is valid only when the ACCEPT_LICENSES field is set to yes. Removes all files and directories in the /usr/lpp/*/inst_roots directories. The possible values are no (default) and yes. The /usr/lpp/bos/inst_roots directories must remain if the machine is used as a network server or to create workload partitions. To save disk space, set this value to yes if the machine is not a workload partition or network server. Starts an executable program if an error occurs in the installation program. The default value is blank, which signals BOS installation to use a command that is shipped on the installation media. The command starts an error message routine when the installation program halts because of an error. As an alternative to the default, you can enter the path name of your own script or command for a customized error routine.
INSTALL_X_IF_ADAPTER
RUN_STARTUP
RM_INST_ROOTS
ERROR_EXIT
46
CUSTOMIZATION_FILE
TCB
INSTALL_TYPE
BUNDLES
Specifies the path name of a customization file you create. The default value is blank. The customization file is a script that starts immediately after the installation program concludes. Specifies whether you want to install the Trusted Computing Base (TCB). When you install the TCB, the trusted path, the trusted shell, and system integrity checking are installed. The TCB must be installed and initialized when the operating system is installed. The TCB cannot be installed later. By not installing the TCB, installation time is reduced. The possible values are no (default) and yes. If set to CC_EVAL, then CAPP and EAL4+ technology will be enabled. This is only allowed when INSTALL_METHOD is overwrite. If this is set, the CULTURAL_CONVENTION and MESSAGES fields of the locale stanza can only be en_US or C. Set CREATE_JFS2_FS to yes, ALL_DEVICES_KERNELS to no, and TCB to yes. DESKTOP can only be NONE or CDE. Set the additional software bundles to no (FIREFOX, HTTP_SERVER_BUNDLE, KERBEROS_5_BUNDLE, SERVER_BUNDLE and ALT_DISK_INSTALL_BUNDLE). Specifies what software bundles to install. Type the full path name of each bundle file. Be sure there is sufficient disk space and paging space on the target machine for the software you specify in the BUNDLES variable. This list of bundle file names is limited to 139 bytes. If your list of bundle file names is longer than 139 bytes, use the cat command to combine the bundle files into a single custom bundle file and enter the name of your custom bundle file in this field. If you are installing from tape, to specify system-defined bundles on the product media, use the full path name of each bundle file as follows: /usr/sys/inst.data/sys_bundles/BundleFileName If you are using a bosinst.data diskette to define your own bundle files, specify the full path name of each bundle file as follows: /../DirectoryName/ BundleFileName. For example, if you put a bundle file named mybundle in the root directory, the full path name would be /../mybundle. If you are using preservation installation, create bundle files before you start the installation. Create the files in /home and specify the full path name of each bundle file as follows: /home/BundleFileName
RECOVER_DEVICES Specifies whether to re-configure the devices. The default value is Default. For mksysb installations, the ODM configuration database is saved in the image. The device names and attributes are automatically extracted from the database, and the BOS installation program attempts to recreate the devices the same way they were on the machine the mksysb was created on. This is normal procedure for regular mksysb restores on the same system. However, for cloning (installing the mksysb image on another system), you may not want these devices configured this way, especially for network configuration. When the mksysb image is created, the CPU ID is saved. If you are reinstalling the same system, then the device information is recovered. If the mksysb image is used to install another system, device information is not recovered from the mksysb image. The Default value can be overwritten. For example, if your system had the planar replaced, or you upgraded to another system, you might want to recover devices. In these cases, you can select yes in the Backup Restore menu to recover devices. Specifies whether to show debug output during BOS installation. The value yes sends set -x debug output to the screen during BOS installation. The possible values are no (default) and yes.
BOSINST_DEBUG
47
ACCEPT_LICENSES
Specifies whether to accept software license agreements during the BOS installation. The default is no. To automatically accept them, set this value to yes. When the software licenses agreements are not accepted during BOS installation, Configuration Assistant or Installation Assistant prompts you to view and accept them. During a BOS installation, if this value is blank, the default of no is assumed. For mksysb installations, when the ACCEPT_LICENSES field is no, the user is forced to accept the licenses again before continuing to use the system. When the ACCEPT_LICENSES field is set to yes, the licenses are automatically accepted for the user. If blank, the state of the licenses is the same as when the mksysb was created. Specifies whether to install Web-based System Management software, Java, service agent software, and System p Console software. The choices are yes and no. Specifies the MLS version of the operating system to be installed. This is valid only with overwrite and preservation installations, and restricts other variables. The choices are yes and no. The DESKTOP value must be NONE, GRAPHICS_BUNDLE must be no, and CREATE_JFS2_FS must be yes. All other software bundles must be no, except for SYSTEM_MGMT_CLIENT_BUNDLE. You can only turn off these options by installing a new operating system. For more information about Trusted AIX, see Trusted AIX. Specifies the MLS version of the operating system to be installed, in LSPP/EAL4+ configured mode. This is a more restrictive mode of Trusted AIX. The choices are yes and no. For more information about Trusted AIX, see Trusted AIX. Specifies a minimal software installation and removes all clear password access such as telnet and rlogin. SECURE_BY_DEFAULT also applies the AIX Security Expert high security settings. This is only valid on an overwrite install. You must set DESKTOP to NONE, GRAPHICS_BUNDLE to yes, ALL_DEVICES_KERNELS to no, and SYSTEM_MGMT_CLIENT_BUNDLE to no. The choices are yes and no. For more information about AIX Security Expert, see AIX Security Expert. Specifies the desktop to be installed. The choice of available desktops are CDE (the default), NONE, GNOME, and KDE. If you choose GNOME or KDE, you will be prompted for the AIX Toolbox for Linux Applications CD. When installing a mksysb image to a system with a different hardware configuration, boot from product media to get any missing device drivers installed. In addition, if the product media is a later level of AIX than the mksysb, software in the mksysb image will be updated. To prevent either of these additional installations from occurring, set this field to no. The default is yes. Specifies whether you want any user volume groups to be automatically imported after the system has been installed. The choices are yes and no. Specifies whether you want to create enhanced journaled file systems. The choices are yes and no. Specifies whether to install all device filesets. The choices are yes and no. If you select no, your system will be installed with the devices and kernel specific to your system configuration. If you select yes, when you create a system backup of your system, you can use that system backup to install any system. Specifies whether to install the graphics software bundle during the BOS installation. This software bundle contains the graphics support for the Web-based System Manager and Linux desktops. The choices are yes and no. Specifies whether to install the Firefox software bundle during the BOS installation. This software bundle contains the Firefox Web browser software. The choices are yes and no. Specifies whether to install the Kerberos 5 client software bundle during the BOS installation. This software bundle installs the Kerberos 5 client software. The choices are yes and no. Specifies whether to install the AIX server software bundle during the BOS installation. This software bundle installs additional networking software, performance tools, and accounting services software. The choices are yes and no. Specifies whether to install the alternate disk installation software during the BOS installation. The choices are yes and no.
SYSTEM_MGMT_CLIENT_BUNDLE
TRUSTED_AIX
TRUSTED_AIX_LSPP
SECURE_BY_DEFAULT
DESKTOP
INSTALL_DEVICES_AND_UPDATES
GRAPHICS_BUNDLE
FIREFOX_BUNDLE
KERBEROS_5_BUNDLE
SERVER_BUNDLE
ALT_DISK_INSTALL_BUNDLE
48
REMOVE_JAVA_118 HARDWARE_DUMP
ERASE_ITERATIONS
ERASE_PATTERNS
ADD_CDE
ADD_KDE
ADD_GNOME
MKSYSB_MIGRATION_DEVICE
ADAPTER_SEARCH_LIST
Specifies whether to remove the Java 1.1.8 software from the current system when performing a migration installation. The choices are yes and no. Creates a dump logical volume to contain firmware and hardware dump data. Dump logical volumes are only create on hardware that supports creation of firmware and hardware dump data. The choices are yes and no. Specifies the number of times to erase the chosen hard drives before the installation occurs. This field is only valid when the INSTALL_METHOD field is set to overwrite or erase_only. The choices for this field is a number from 0 to 8. If the field is set to 0 then no erasure of the hard drives will occur. The default is 0. Specifies the patterns to write to the choosen hard drives. The value for this field is a comma separated list of the patterns to use for each erasure of the drives. A valid pattern is a hexadecimal value from 0 to ffffffff. The number of patterns specified must be equal or greater to the number of iterations specified in ERASE_ITERATIONS. If ERASE_ITERATIONS is 0 then this field is ignored. ex: If ERASE_ITERATIONS = 3 then a valid entry for this field could be ERASE_PATTERNS = 00,ff,0a0a0a0a . Adds CDE as an additional desktop. If the DESKTOP field is not CDE and ADD_CDE is set to yes, the CDE desktop is installed in addition to the desktop specified by the DESKTOP field. The default value is no. If DESKTOP is set to none, this attribute is ignored. Adds KDE as an additional desktop. If the DESKTOP field is not KDE and ADD_KDE is set to yes, the KDE desktop is installed in addition to the desktop specified by the DESKTOP field. The default value is no. If DESKTOP is set to none, this attribute is ignored. Adds GNOME as an additional desktop. If the DESKTOP field is not GNOME and ADD_GNOME is set to yes, the GNOME desktop is installed in addition to the desktop specified by the DESKTOP field. The default value is no. If DESKTOP is set to none, this attribute is ignored. When set, specifies the device to be used to restore the mksysb image for migration. Default is blank. Valid values are /dev/cddevice number for a mksysb image on a CD-DVD, and /dev/rmtdevice number for a mksysb image on tape. For a network installation, the valid value is the word network. Specifies the adapter search list for disks. The value for this variable can be used to reduce the number of disks on which to install AIX. The field consists of a space separated list of adapters and * can be used for a group of adapters, or to specify all. Acceptable values could be: v scsi0 scsi1 v fr0 scsi* v fr* scsi25 v * ADAPTER_SEARCH_LIST = scsi0 scsi1 ADAPTER_SEARCH_LIST = fr0 scsi* If an adapter specified is not defined or not available, an error occurs. If a disk in the target_disk_data stanza is not a child of the adapter(s) that is selected, an error occurs. If the rootvg spans multiple disks and adapters, and only one of the adapter is selected, the volume group information shows blank, as not all the disks in the volume group are being selected. If you want to install to the same rootvg disks specify each adapter associated with a disk in a rootvg.
bosinst.data target_disk_data stanza: The target_disk_data stanza contains variables for disks in the machine where the program is to install BOS. The default bosinst.data file has one target_disk_data stanza, but you can add new stanzas to install BOS on multiple disks, one stanza for each disk.
49
Multiple target_disk_data stanzas can exist. They define the disks that are to contain the root volume group. Only one field (PVID, PHYSICAL_LOCATION, SAN_DISKID, CONNECTION, LOCATION, SIZE_MB, HDISKNAME) must be non-null for BOS installation to choose a disk. The order of precedence is PVID (Physical Volume ID), PHYSICAL_LOCATION, SAN_DISKID, then CONNECTION (parent attribute//connwhere attribute), then LOCATION, then SIZE_MB, and then HDISKNAME. The BOS installation process uses the following logic to determine how to use the target_disk_data stanza information: v If PVID is set, BOS installation checks to see if a disk matches the value. If so, other attributes are ignored. v If PVID is empty and PHYSICAL_LOCATION is set, then BOS installation checks to see if the parent and connwhere attributes (separated by "//") match a disk. If they do, other attributes are ignored. v If either PVID or PHYSICAL_LOCATION is set, and neither value matches a disk on the target system, and no other attributes are set, an error message is generated, and a disk must be explicitly selected. v If PVID and PHYSICAL_LOCATION are empty, and SAN_DISKID is set, then, for fibre channel-attached disks, BOS installation interprets the SAN_DISKID as a World Wide Port Name and a Logical Unit ID (separated by "//"). The World Wide Port Name (ww_name) and Logical Unit ID (lun_id) can be obtained on a running system from the lsattr command. The SAN_DISKID field is checked before the CONNECTION field. v If the ww_name and lun_id match a disk, other attributes are ignored. v If either PVID or SAN_DISKID is set, and neither value matches a disk on the target system, and no other attributes are set, an error message is generated and a disk must be explicitly selected. v If PVID and SAN_DISKID are empty and CONNECTION is set, BOS installation verifies if the parent and connwhere attributes (separated by "//") match a disk. If this is true, other attributes are ignored. v If CONNECTION is set, the value does not match a disk on the target system, and no other attributes are set, an error message is generated and a disk must be explicitly selected. v If other attributes are specified, processing occurs as described below: If LOCATION is set, BOS installation ignores SIZE_MB and HDISKNAME. If LOCATION is not set and SIZE_MB is, BOS installation selects disks based on SIZE_MB and ignores HDISKNAME. If LOCATION and SIZE_MB are both empty, BOS installation chooses the disk specified in HDISKNAME. If all fields are empty, BOS installation chooses a disk for you. For the PVID, PHYSICAL_LOCATION, SAN_DISKID, and CONNECTION fields, the BOS installation process uses the following logic to determine how to use the target_disk_data stanza information: v Does the information in one or more of the PVID, PHYSICAL_LOCATION, SAN_DISKID, and CONNECTION fields match the disk information? v If the disk information matches the information in one of these four fields, use that information. v If the disk information does not match the information in one of these four fields, and if the LOCATION, SIZE_MB, and HDISKNAME fields are not set, display an error message and prompt the user for the correct disk information. The PHYSICAL_LOCATION information can be retrieved using the lsdev command. For example:
# lsdev -Cc disk -l hdisk0 -F "name physloc"
returns the hdisk0 diskname and the P2/Z1-A8 physical location. Attention: If prompt=no, do not leave the target_disk_data stanzas empty, unless it is unimportant which disk BOS installation overwrites. This is because the algorithm that determines the default disk for the installation is not always predictable.
50
The SIZE_MB field can contain either a size or the word largest. If a size is listed, BOS installation does a "best-fit" on the disks. If the word largest is in that field, BOS installation selects the largest disk. If there is more than one target_disk_data stanza, BOS installation selects the two "largest" disks, and so on.
PVID PHYSICAL_LOCATION Specifies the 16-digit physical volume identifier for the disk. The physical location code provides a way to identify fibre channel disks during BOS Install. For fibre channel disks the PHYSICAL_LOCATION field includes the World Wide Port Name and Lun ID that are included in the SAN_DISKID field. The information in the PHYSICAL_LOCATION field supercedes the information in the SAN_DISKID field. Specifies the World Wide Port Name and a Logical Unit ID for fibre channel-attached disks. The ww_name and lun_id are separated by two slashes (//). This information can be obtained on a running system from the lsattr command. Specifies the combination of the parent attribute and the connwhere attribute associated with a disk. The parent and connwhere values are separated by two slashes (//). If the parent value is scsi0 and the connwhere value is 0,1, then the CONNECTION value is scsi0//0,1. An example of the CONNECTION value for a SSA disk would be ssar//000629CCC07300D. In the example, the parent attribute is represented by ssar and the ConnectionLocation (15-character unique identity) of the disk drive 000629CCC07300D is used for the connwhere attribute. Specifies the formatted size of the disk, in megabytes, where the program is to install BOS. The default value is blank. You can specify the size of your target disk by typing the number of megabytes available on the formatted disk. Also, you can type largest if you want to use the largest disk (that has not already been selected) found by the installation program. Specifies a location code for the disk where the program is to install BOS. The default value is blank. If you do not specify a value, the installation program assigns a value based on the next two variables. For more information about physical location codes, refer to the Diagnostic Information for Multiple Bus Systems guide. Specifies the path name of the target disk. The default value is blank. To name a target disk, use the hdiskname format, where hdiskname is the device name of your disk (for example, hdisk0).
SAN_DISKID
CONNECTION
SIZE_MB
LOCATION
HDISKNAME
bosinst.data target_iscsi_data stanza: The optional target_iscsi_data stanza contains variables for the parent iSCSI adapter of the disks in the system where the program resides to install the Base Operating System. The bosinst.data file contains a target_iscsi_data stanza only if the root volume group includes an iSCSI disk. Only one target_iscsi_data stanza can exist. It defines the iSCSI target for the disks that are to contain the root volume group. The target_iscsi_data stanza must be located after all the target_disk_data stanzas to ensure correct processing.
Variable ADAPTER_NAME Description Specifies the name of the iSCSI TOE adapter (for example, ics0) or the iSCSI software solution protocol device (for example, ics0) to which this iSCSI target will be configured. This is a required field. This field should be set to the static value. Specifies the iSCSI target name of the iSCSI target. The mkiscsi command will not do normalizing on the TARGET_NAME. Specifies the iSCSI initiator name of the iSCSI Initiator. Specifies the TCP port number of the iSCSI target. Specifies the IP address of the iSCSI target. Specifies whether the adapter is an iSCSI software solution protocol device. If the adapter is an iSCSI software protocol device, the network interface that was configured by NIM is used to connect to the iSCSI target. Set the value of odm. Specifies the IP address of the iSCSI TOE adapter when SW_INITIATOR is set to no. Specifies the IP address of the gateway that is used by the iSCSI TOE adapter when SW_INITIATOR is set to no. Specifies the subnet mask that is used by the iSCSI TOE adapter when SW_INITIATOR is set to no.
51
The following example shows a target_iscsi_data stanza for a configuration where the adapter is a software initiator adapter:
target_iscsi_data: ADAPTER_NAME = iscsi0 ISCSI_GROUP = static TARGET_NAME = iqn.sn1234.iscsi_hw1 INITIATOR_NAME= iqn.2000-01.ibm.boot PORT_NUMBER = 3260 IP_ADDRESS = 10.1.1.130 SW_INITIATOR = yes DISC_POLICY = odm
The following example shows a target_iscsi_data stanza using an iSCSI TOE adapter:
target_iscsi_data: ADAPTER_NAME = ics0 ISCSI_GROUP = static TARGET_NAME = iqn.sn1234.iscsi_hw1 INITIATOR_NAME= iqn.2000-01.ibm.boot PORT_NUMBER = 3260 IP_ADDRESS = 10.1.1.130 SW_INITIATOR = no DISC_POLICY = odm ADAPTER_IP = 10.1.2.115 ADAPTER_GW = 10.1.2.1 ADAPTER_SNM = 255.255.255.0
bosinst.data file locale stanza: The locale stanza contains variables for the primary language that the installed machine is to use. Refer to Understanding Locale Categories in AIX Version 6.1 National Language Support Guide and Reference, which provides information about locales and the format to use when editing variables.
BOSINST_LANG CULTURAL_CONVENTION MESSAGES KEYBOARD Specifies the language that the installation program uses for prompts, menus, and error messages. The default value is blank. Specifies the primary locale to install. The default value is blank. Specifies the locale for message catalogs to install. The default value is blank. Specifies the keyboard map to install. The default value is blank.
bosinst.data large_dumplv stanza: The optional large_dumplv stanza specifies characteristics used if a dedicated dump device is to be created on the systems. A dedicated dump device is only created for systems with 4 GB or more of memory. The following characteristics are available for a dedicated large dump device:
DUMPDEVICE SIZEGB Specifies the name of the dedicated dump device. Specifies the size of the dedicated dump device in gigabytes.
If the stanza is not present, the dedicated dump device is created when required. A dedicated dump device is created in machines with at least 4 Gigabytes of real memory during an overwrite install. By default, the name of the dedicated dump device is lg_dumplv and its size is determined by the following formula:
4>= RAM < 12 12>= RAM < 24 24>= RAM < 48 RAM >= 48 size size size size of of of of dump dump dump dump device= device= device= device= 1 2 3 4 GB GB GB GB
52
bosinst.data dump stanza: The dump stanza specifies system dump characteristics.
PRIMARY SECONDARY COPYDIR FORCECOPY ALWAYS_ALLOW Specifies the primary dump device to be set by sysdumpdev -P -p device. Specifies the secondary dump device to be set by sysdumpdev -P -s device. Specifies the directory to which the dump is copied at system boot. Specifies whether the system boots into menus that allow copy of the dump to external media if the copy fails. Specifies whether the key mode switch can be ignored when a dump is requested.
If the stanza is not present in the bosinst.data file, no additional dump-device handling occurs beyond what is already in place. Checking on the values of the fields is limited; if the device specified for a dump device is not valid, any error processing comes from the sysdumpdev command and is sent to the console and stored in the BOS installation log. v If FORCECOPY is specified and no COPYDIR is specified, the value field of the autocopydump attribute from /etc/objrepos/SWservAt is retrieved and used for the sysdumpdev -[d|D] copydir operation. v If only the COPYDIR is specified without FORCECOPY being specified, forcecopy defaults to yes. The sysdumpdev -d (FORCECOPY = no) or sysdumpdev -D (FORCECOPY = yes) is used to set the copy directory. v If ALWAYS_ALLOW=yes, run sysdumpdev -K. Otherwise, run sysdumpdev -k. v If any values other than yes and no are specified for FORCECOPY or ALWAYS_ALLOW, the default actions occur, and processing continues. v If no value is specified for a particular dump field, no analogous sysdumpdev operation is performed. This leaves the system values in the appropriate state, even for a migration or system backup image installation. If a COPYDIR is specified but FORCECOPY is not specified, the value of the forcecopydump attribute is retrieved from the /etc/objrepos/SWservAt file to determine the correct form of sysdumpdev to invoke. bosinst.data livedump stanza: The optional livedump stanza allows you to customize the attributes of the livedump filesystem that is created during a BOS installation. During a BOS installation, a livedump filesystem is created. To modify the attributes used to create this filesystem, use a customized bosinst.data file with a livedump stanza. The following attributes can be specified: LD_DIR The directory where the livedump filesystem will be mounted. If the LD_DIR attribute is not specified, the default directory is /var/adm/ras/livedump. LD_SIZEMB The livedump filesystem size in MB. If the LD_SIZEMB attribute is not specified, the default is 256. LD_DEVICE The logical-volume name for the filesystem. If the LD_DEVICE attribute is not specified, the default is livedump. If the livedump stanza does not exist, or is not modified, the livedump filesystem is created with the default values. Depending on the type of installation, the filesystem is created as follows: v Overwrite installations always create a livedump filesystem.
Installation and migration
53
v Preservation and migration installations create the file system as follows: If you specify attribute values in the livedump stanza, the filesystem is created with those values unless it already exists. If you do not specify attribute values in the livedump stanza, the filesystem is created with default values, if it does not already exist. For more information about livedump, see Live Dump Facility in in AIX Version 6.1 Kernel Extensions and Device Support Programming Concepts
bosinst.data file nonprompted network installation: An example of a modified bosinst.data file is shown that might be used in a nonprompted network installation.
control_flow: CONSOLE = Default INSTALL_METHOD = overwrite PROMPT = no EXISTING_SYSTEM_OVERWRITE = yes INSTALL_X_IF_ADAPTER = yes RUN_STARTUP = yes RM_INST_ROOTS = no ERROR_EXIT = CUSTOMIZATION_FILE = TCB = no INSTALL_TYPE = BUNDLES = RECOVER_DEVICES = no BOSINST_DEBUG = no ACCEPT_LICENSES = yes DESKTOP = NONE INSTALL_DEVICES_AND_UPDATES = yes IMPORT_USER_VGS = CREATE_JFS2_FS = Default ALL_DEVICES_KERNELS = yes GRAPHICS_BUNDLE = yes MOZILLA_BUNDLE = no KERBEROS_5_BUNDLE = no SERVER_BUNDLE = no REMOVE_JAVA_118 = no HARDWARE_DUMP = yes ADD_CDE = no ADD_GNOME = no ADD_KDE = no ERASE_ITERATIONS = 0 ERASE_PATTERNS = target_disk_data: LOCATION = SIZE_MB =
54
mksysb_migration_device
The device type or name where the mksysb image can be located when describing how to perform a mksysb or migration operation. For a network installation, the mksysb image device must be a network resource and the value of "network" needs to be specified with this variable. For an installation from media, the mksysb image device needs to be specified using the device logical name as known to AIX (such as /dev/cd0, /dev/rmt0).
55
Note: Preservation install is only supported when moving to a newer level of the AIX Base Operating system. To re-install a prior level of AIX, you must either do a new and complete overwrite install, or re-install from a prior level system backup. 1. Insert the AIX Volume 1 media into the media device. 2. Shut down your system. If your machine is currently running, power it off by following these steps: a. Log in as the root user. b. Type the following command:
shutdown -F
c. If your system does not automatically power off, place the power switch in the Off (0) position. Attention: You must not turn on the system unit until instructed to do so in Step 4. Booting from your installation media on page 57. 3. Turn on all attached external devices. These include the following: v Terminals v CD-ROM or DVD-ROM drives v Tape drives v Monitors v External disk drives Turning on the external devices first is necessary so the system unit can identify each peripheral device during the startup (boot) process.
56
Keyboard and Display Options Option Screen Row and Column Scroll Auto LF (line feed) Line Wrap Forcing Insert Tab Operating Mode Turnaround Character Enter Return New Line Send Insert Character Setting normal 24x80 jump off on line (or both) field echo CR return new line CR page space
57
a. Type 1 in the Choice field to select the System Settings option. b. When the Change Method of Installation window displays, type the number corresponding to desired installation (either 1 for New and Complete Overwrite or 2 for Preservation) in the Choice field and press Enter. Note: Available installation methods depend on whether your system has a previous version of AIX installed. If you only want to install the next recommended maintenance or technology level of AIX, see Preparing to install optional software products and service updates on page 324. You can also use the SMIT update_all fast path or the install_all_updates command to update existing filesets to the next recommended maintenance or technology level. c. When the Change Disk(s) window displays, you can change the destination disk for the installation. If you selected the preservation installation, the window lists only disks containing a rootvg. The disk name, the location, the size of the disk, and the root volume group status is displayed for each available disk. The Bootable column indicates whether the disk is bootable. Type 77 to select Display More Disk Information to view additional disk attributes such as physical volume identifier, device adapter connection location, or World Wide Port Name//Lun ID. If the default shown is correct, type 0 in the Choice field and press Enter. To change the destination disk, use the following procedure: 1) Type the number for each disk you choose in the Choice field and press Enter. Do not press Enter a final time until you have finished selecting all disks. If you need to deselect a disk, type its number a second time and press Enter. v You can specify a supplemental disk by typing 66 and pressing the Enter key for the Disks not known to Base Operating System Installation option. This option opens a new menu that prompts for a device support media for the supplemental disk. The device-support media is only needed when the device cannot configure with the generic SCSI or bus-attached device drivers. BOS installation configures the system for the disk and then returns to the Change Disk window. v If this is an overwrite installation, you can specify to erase the disks chosen to be installed before the installation occurs by typing 55 and pressing the Enter key for the More Disk Options option. This option opens a new menu that prompts for the number of patterns to write, which is the number of times the drive will be overwritten. If you choose 0 for the number of patterns to write, the disks will not be erased prior to installation. This menu also prompts for the patterns to be used for each disk erasure. The patterns are a choice of the hexadecimal values 00,a5,5a, or ff. For example, a pattern of 00 will write all zeros to the drive. Erasing a drive is a time consuming process and only drive types that are supported by the diag command can take advantage of this option (for example, erasure of IDE drives are not supported). 2) When you have finished selecting the disks, type 0 in the Choice field and press Enter. The Installation and Settings window displays with the selected disks listed under System Settings. 2. Change the primary language environment, if needed. Use the following steps to change the primary language used by this installation. Note: Changes to the primary language environment do not take effect until after BOS is installed and your system is rebooted. a. Type 2 in the Choice field on the Installation and Settings window to select the Primary Language Environment Settings option. b. Select the appropriate set of cultural convention, language, and keyboard options. Most of the options are a predefined combination, however, you can define your own combination of options.
58
v To select a predefined Primary Language Environment, type that number in the Choice field and press Enter. v To configure your own primary language environment: 1) Select MORE CHOICES. 2) Page through the choices and select the Create Your Own Combination option. 3) When the Set Primary Cultural Convention window displays, type the number in the Choice field that corresponds to the cultural convention of your choice and press Enter. 4) When the Set Primary Language window displays, type the number in the Choice field that corresponds to your choice for the primary language and press Enter. 5) When the Set Keyboard window displays, type the number in the Choice field that corresponds to the keyboard attached to the system and press Enter. 3. Change the installation options by typing 3 to change the Security Model or 4 to select More Options and press Enter. These options will vary based on install type (overwrite, preservation, or migration) and security choices. For more information on the installation options, see BOS installation options on page 42. 4. Change the install edition by typing 5 to toggle through the choices, express, standard, or enterprise. For more information on the installation options, see BOS installation options on page 42. 5. Verify your selections in the installation summary window and press Enter to begin the BOS installation process. Your system automatically reboots after installation is complete. Go to Step 6. Finishing the BOS installation.
Related information
Links to information related to BOS installation are listed. v For additional release information, see the AIX Release Notes that correspond to your level of AIX. v For late-breaking information, which might include information about the configuration process and installed software, refer to the readme files. v For information about installing optional software, refer to Preparing to install optional software products and service updates on page 324.
59
installed within a Workload Partition because default System WPAR configurations do not include a writeable /usr or /opt file system. Application installations might need to be retargeted to locations other than the traditional /usr or /opt placement. In addition to being able to install filesets in the default installation location, the system administrator can install relocatable packages into alternate root install locations. This enables the system administrator to: v Install and maintain multiple installations of the same installp package in a single instance of the AIX operating system. v Install and maintain multiple versions of the same installp package in a single instance of the AIX operating system. v Use native installp tracking tools (such as lppchk, lslpp, instfix, and inulag) to verify and report installation data on all relocated installation instances. v Attach and detach preinstalled software locations on a given system (such as application hosting).
Lists existing USIL instance(s). lsusil [-R *!ENTITY!*RelocatePath> | "ALL"] Flags: -R Path to an existing USIL location
60
Description Removes an existing USIL instance. rmusil -R <RelocatePath> Flags: -R Path to an existing USIL location Note: The rmusil command only removes the USIL reference in the SWVPD. The USIL installation path does not use any remote files.
/usr/sbin/chusil
Changes an attribute of an existing USIL instance. chusil -R <RelocatePath> -c <NewComments> [X] Flags: -c -R -X New comments to include in the USIL definition (visible with the lsusil command) Path to an existing USIL location Automatically expands to space needed
Attach/Detach operations
You can use the attach operation to integrate an existing detached USIL path into the SWVPD. For example, the administrator creates a "master" USIL instance with various relocatable applications installed for the purposes of application hosting. The administrator then copies or NFS mounts this USIL instance to various systems and uses the attach feature to integrate the USIL instance into the SWVPD. The detach operation removes reference to the USIL instance.
installp licensing
A new USIL instance starts out with an empty LAG (installp license agreement ODM object class). Any installation of filesets or LPPs that require a license will require the license acceptance with the usual installp conventions. The license acceptance does not span USIL instances.
61
v v v v
Note: Each utility takes the -R <RelocatePath> flag. You must use these utilities when working with relocatable installp packages on AIX.
Relocatable requisites
A new packaging semantic indicates relocatable requisite location. A packager can specify that a given requisite should be found in the default install path or in the relocated install path. The following are the new requisite semantics that apply: prereq_ r prereq in relocated install path o ifreq_r ifreq in relocated install path coreq_r coreq in relocated install path instreq_r instreq in relocated install path The currently defined requisites types (prereq, ifreq, coreq, and instreq) are all default requisites (requisites that apply to the default install location).
62
IY99999 1 APAR text here. % RELOCATABLE <-- attribute tag to denote relocatable package % *prereq bos.rte 1.1.1.1 <-- default requisite in relocated requisite section *coreq_r bos.games 1.1.1.1 <-- relocated requisite in relocated requisite section ] }
v If the relocatable requisite section is present during a relocated installation, it is used as the requisite section for the installation. v If the relocatable requisite section is not present during a relocated installation, the default requisite section is used. This means all requisites will be default requisites. v A default installation (non-relocated) does not use the relocatable requisite section.
Note: The current SWVPD object classes include the following: product, lpp, inventory, history, fix, vendor, and lag.
63
IP Address of Gateway IP address of the gateway that is used by the adapter specified by Adapter Name. Subnet Mask Subnet mask that is assigned to the adapter specified by Adapter Name. iSCSI Target Name Name that is configured for the iSCSI Target. iSCSI Initiator Name Initiator name that is configured for the iSCSI Target. Port Number Port Number that is configured for the iSCSI Target. IP Address of Target IP Address that is configured for the iSCSI Target. Notes: 1. Consult your iSCSI vendor's documentation for more information. 2. IPv6 support for iSCSI disk installation is not supported. For prompted installs of AIX, these parameters can be submitted using the iSCSI configuration menus. For non-prompted installs of AIX, these parameters can be supplied using the bosinst.data file stanza descriptions. Only one iSCSI target can be configured for the root volume group used to install the Base Operating System. The root volume group cannot be created by combining iSCSI disks with non-iSCSI disks.
64
Note: If you supplied all of the iSCSI parameters through a bosinst.data file using NIM, this step might not be required. When the correct disk has been configured, exit the iSCSI configuration menus. 2. At the Maintenance menu, save the iSCSI configuration parameters for the disk configured in the previous step to the root volume group on the disk. Select option 1, Access a Root Volume Group. The Warning screen is displayed. 3. Read the information displayed on the Warning screen. When you are ready to continue, type 0 and press Enter. The Access a Root Volume Group menu is displayed. 4. Select the root volume group on the disk that was configured in Step 2. After entering your selection, the Volume Group Information menu is displayed. Note: Reviewing the disk and location code information on the Volume Group Information menu enables you to determine whether the volume group you selected was the root volume group. You can return to the Access a Root Volume Group screen if the choice you made was not the root volume group. If you have not chosen a root volume group, you cannot continue beyond the Volume Group Information menu. 5. Select Choice 1 from the Volume Group Information menu and press Enter. A shell and system prompt is displayed. 6. At the system prompt, run the update_iscsi command to save the iSCSI configuration to the root volume group. The system can now be restarted using the updated iSCSI parameters. | | | | | | | | 7. Run the bootlist command, specifying the hdisk option being used for booting the system, as configured in step 2. For example, run bootlist -m normal hdisk3 if hdisk3 is the new iSCSI boot disk. Note: The update_iscsi command may change the state of some network interfaces to down and help avoid possible conflicts with the changes made to the network interface used to access the iSCSI boot disk. After the system starts, examine the network interfaces. Delete any network interfaces that are no longer valid and bring up any network interfaces that are still valid but were marked down by the update_iscsi command. For more information, see Using the iSCSI configuration menus.
65
The mksysb image is created on a system that either was the same hardware configuration as the target system, or had all the device and kernel support installed for a different machine type or platform, or different devices. The installed device and kernel support would be as follows: v devices.* v bos.mp64 Note: In AIX, all device and kernel support is automatically installed during a base operating system installation. When the alt_disk_mksysb command is run, the image.data file from the mksysb image is used by default (unless a customized image.data is given) to create the logical volumes and file systems. The prefix alt_ is added to the logical volume names, and the file systems are created with a prefix of /alt_inst. For example, hd2 would be created as alt_hd2, and its file system, 1, would be created as /alt_inst/usr. These names are changed back to their original names at the end of the alternate disk installation process. The mksysb image is then restored into the alternate file system. A prepopulated boot image is then copied to the boot logical volume of the altinst_rootvg, and the boot record of the boot disk is modified to allow booting from the disk. At this point, a script can be run to allow for any customization before the system is rebooted. The alternate file systems are still mounted as /alt_inst/real_file_system (for example: /alt_inst/usr, /alt_inst/home). Files can be accessed at this point, but nothing can be installed into the alternate file system because the kernels and libraries of the mksysb image may not match those of the running system. After the optional script is run, the file systems are unmounted, and the logical volume and file system names are changed to match the image.data file's names (for example, alt_inst_hd6 is changed to hd6 in the volume group descriptor area). The logical volumes are exported from the Object Data Manager (ODM), but the altinst_rootvg is only varied off. It is left in the ODM as a placeholder so the disk is not accidentally overwritten. The default action of the alt_disk_mksysb command is to set the bootlist so that the next time the system boots, it boots from this newly installed volume group. This default action can be turned off. If specified, the system reboots at this point, and the system reboots from the new rootvg. The boot process proceeds to a certain point, with the new rootvg's file systems mounted, and the bosboot command is called to rebuild a "normal" boot logical volume. The system then reboots. After rebooting from the new alternate disk, the former rootvg volume group is contained in an lspv listing as old_rootvg, and includes all disk(s) in the original rootvg. This former rootvg volume group is set to not varyon at reboot and should only be removed with the -X flag. For example:
alt_rootvg_op -X old_rootvg
If a return to the original rootvg is necessary, the bootlist command is used to change the bootlist to reboot from the original rootvg. If it is unclear which disk is the boot disk for a specific volume group, use the -q flag to determine the boot disk. This flag can be useful when a volume group comprises multiple disks and a change in the bootlist is necessary.
1. /usr
66
Another benefit of rootvg cloning occurs when applying new maintenance or technology level updates. A copy of the rootvg is made to an alternate disk, then updates are applied to that copy. The system runs uninterrupted during this time. When it is rebooted, the system boots from the newly updated rootvg for testing. If updates cause problems, the old_rootvg can be retrieved by resetting the bootlist and then rebooting. By default, calling the alt_disk_install command does the following: 1. Creates an /image.data file based on the current rootvg's configuration. A customized image.data file can be used. 2. Creates an alternate rootvg (altinst_rootvg). 3. Creates logical volumes and file systems with the alt_inst prefix. 4. Generates a backup file list from the rootvg, and if an exclude.list file is given, those files are excluded from the list. 5. Copies the final list to the altinst_rootvg's file systems. 6. If specified, the installp command installs updates, fixes, or new filesets into the alternate file system. 7. The bosboot command creates a boot logical volume on the alternate boot disk. 8. If a customization script is specified, it runs at this point. 9. The file systems are then unmounted, and the logical volumes and file systems are renamed. 10. The logical volume definitions are exported from the system to avoid confusion with identical ODM names, but the altinst_rootvg definition is left as an ODM placeholder. 11. By default, the bootlist is set to the new cloned rootvg for the next reboot. Performing an alternate disk phased installation: For AIX 5.1 and later, alternate disk installation can be performed in stages. The installation is broken down into three phases. The default is to perform all three phases in the same invocation. The phases are as follows:
Phase 1 Phase 2 Creates the altinst_rootvg volume group, the alt_ logical volumes, and the /alt_inst file systems. Also restores the mksysb or rootvg data. Runs any specified customization script. For cloning only, installs updates, new filesets, fixes, or bundles. Also copies a resolv.conf file (if specified) and necessary files to remain a NIM client (if specified). Unmounts the /alt_inst file systems, renames the file systems and logical volumes, removes the alt_ logical volume names from ODM, and varies off the altinst_rootvg. It also sets the bootlist and reboots (if specified).
Phase 3
As an alternative to running all three phases, the phases can be completed by one of the following methods: v Each phase separately v Phases 1 and 2 together v Phases 2 and 3 together (Phase 2 can be run multiple times before Phase 3 is run.) You must run Phase 3 to obtain a usable rootvg. Running Phases 1 and 2 leave the /alt_inst file systems mounted. Any time during the phase process and before rebooting, the altinst_rootvg can be removed, and disk cleanup occurs using the following command:
alt_rootvg_op -X
67
Using alternate disk migration installation compared to a conventional migration provides the following advantages: v Reduced downtime; the migration is performed while the system is up normally, and there is no need to boot from any media. v Quick recovery in case of migration failure. v High degree of flexibility and customization. Reduced downtime. The migration is performed while the system is up and functioning. There is no requirement to boot from install media, and the majority of processing occurs on the NIM master. Quick recovery in the event of migration failure. Because you are creating a copy of rootvg, all changes are performed to the copy (altinst_rootvg). In the event of serious migration installation failure, the failed migration is cleaned up, and there is no need for the administrator to take further action. In the event of a problem with the new (migrated) level of AIX, the system can be quickly returned to the premigration operating system by booting from the original disk. High degree of flexibility and customization in the migration process. This is done with the use of optional NIM customization resources including image_data, bosinst_data, exclude_files, premigration script, installp_bundle, and post-migration script. Network Install Manager Alternate Disk Migration (nimadm) is a utility that allows you to do the following: v Create a copy of rootvg to a free disk, or disks, and simultaneously migrate it to a new version or release level of AIX. v Using a copy of rootvg, create a new nim mksysb resource that has been migrated to a new version or release level of AIX. v Using a nim mksysb resource, create a new nim mksysb resource that has been migrated to a new version or release level of AIX. v Using a nim mksysb resource, restore to a free disk, or disks, simultaneously migrating it to a new version or release level of AIX. nimadm uses NIM resources to perform these functions. For more information about the nimadm command, refer to the AIX Version 6.1 Commands Reference. Preparing for an alternate disk migration: These are the requirements for an alternate disk migration installation. v Configured NIM master running AIX. v The NIM master must have bos.alt_disk_install.rte installed in its rootvg and the SPOT which will be used. v The level of the fileset, which includes the bos.alt_disk_install.rte file and the bos.alt_disk_install.boot_images file, on the NIM master rootvg, lpp_source, and SPOT must be at the same level. v The client must have a disk (or disks) large enough to clone the rootvg and an additional 500 MB (approximately) of free space for the migration. The total amount of required space will depend on original system configuration and migration customization. v The client must be a registered NIM client to the master. v The nim master must be able to execute remote commands on the client using the rshd protocol. v The client must have a minimum of 256512 MBs of memory. v A reliable network, which can facilitate large amounts of NFS traffic, must exists between the NIM master and the client.
68
v The client's hardware should support the level it is migrating to and meet all other conventional migration requirements. Note: If you cannot meet the alternate disk migration installation requirements 1-10, perform a conventional migration. For information on the conventional migration installation method, see Migrating AIX on page 366. If you cannot meet requirement 11, no migration installation is possible. Before performing an alternate disk migration installation, you are required to agree to all software license agreements for software to be installed. You can do this by specifying the -Y flag as an argument to the alternate disk migration command or setting the ADM_ACCEPT_LICENSES environment variable to yes. Alternate disk migration limitations: These limitations apply to alternate disk migration installations. The limitations are: v If the client's rootvg has the Trusted Computing Base option enabled, either disable it (permanently), use the disk caching option (-j), or perform a conventional migration. The Trusted Computing Base option must access file metadata that is not visible over NFS. v All NIM resources used must be local to the NIM master. v During the migration, the client's active rootvg may experience a small performance decrease due to increased disk I/O, nfsd activity, and some CPU usage associated with alt_disk_install cloning. v NFS tuning may be required to optimize performance. Alternate disk migration installation usage: The syntax for the alternate disk migration installation command is described. The syntax is:
nimadm -l lpp_source -c NIMClient -s SPOT -d TargetDisks [ -a PreMigrationScript ] [ -b installp_bundle] [ -z PostMigrationScript] [ -e exclude_files] [ -i image_data ] [ -m NFSMountOptions ] [ -o bosinst_data] [-P Phase] [ -j VGname ] [-Y ] [ -F ] [ -D ] [ -E ] [ -V ] [ { -B | -r } ]
Use the nimadm command to target the aix1 NIM client, using the spot1 NIM SPOT resource, the lpp1 NIM lpp_source resource, and hdisk1 and hdisk2 target disks, by typing the following:
nimadm -c aix1 -s spot1 -l lpp1 -d "hdisk1 hdisk2" -Y
Use the -Y flag to agree to all required software license agreements for the software being installed Cleanup alternate disk migration on client: The syntax is:
nimadm -C -c NIMClient -s SPOT [ -F ] [ -D ] [ -E ]
69
Installing alternate disk migration: The nimadm command performs a migration in 12 phases. Each phase can be executed individually using the -P flag. Before performing a migration in phases, you should have a good understanding of the nimadm process. The nimadm phases are as follows: 1. The master issues the alt_disk_install command to the client, which makes a copy of the rootvg to the target disks (this is Phase 1 of the alt_disk_install process). In this phase, altinst_rootvg (alternate rootvg) is created. If a target mksysb has been specified, the mksysb is used to create a rootvg using local disk caching on the NIM master. 2. The master runs remote client commands to export all of the /alt_inst file systems to the master. The file systems are exported as read/write with root access to the master. If a target mksysb has been specified, the cache file systems are created based on the image.data from the mksysb. 3. The master NFS mounts the file systems exported in Phase 2. If a target mskysb has been specified, the mksysb archive is restored into the cache file systems created in Phase 2. 4. If a premigration script resource has been specified, it is executed at this time. 5. System configuration files are saved. Initial migration space is calculated and appropriate file system expansions are made. The bos image is restored and the device database is merged (similar to a conventional migration). All of the migration merge methods are executed and some miscellaneous processing takes place.
70
6. All system filesets are migrated using installp. Any required RPM images are also installed during this phase. 7. If a post-migration script resource has been specified, it is executed at this time. 8. The bosboot command is run to create a client boot image, which is written to the client's boot logical volume (hd5). 9. All mounts made on the master in phase 3 are removed. 10. All client exports created in phase 2 are removed. 11. The alt_disk_install command is called again (phase 3 of alt_disk_install) to make final adjustments and put altinst_rootvg to sleep. The bootlist is set to the target disk (unless the -B flag is used). If an output mksysb has been specified, the cache is archived into a mksysb file, and made a nim mksysb resource. 12. Cleanup is executed to end the migration. The client is rebooted, if the -r flag is specified. Note: The nimadm command supports migrating several clients at the same time.
Accessing data between the original rootvg and the new alternate disk
You can initiate data access between the original rootvg and the new alternate disk. A volume group "wake-up" can be accomplished, on the non-booted volume group. The "wake-up" puts the volume group in a post alt_disk_install Phase 1 state. For example, the /alt_inst file system is then mounted. The volume group that experiences the "wake-up" is renamed altinst_rootvg. When data access is no longer needed, the volume group can be "put to sleep." For more information on the command flags to "wake-up" and "put to sleep", see the alt_rootvg_op man page. Once the alternate disk or rootvg is mounted, file access is the same as for any mounted file system. Note: v The running operating system's version must be greater than or equal to the version of the volume group that undergoes the "wake-up." This might mean that it is necessary to boot from the altinst_rootvg and "wake-up" the old_rootvg. This limitation is caused by a journaled file system (JFS) log entry incompatibility. It is possible to "wake-up" a volume group that contains a more recent version, but the volume group cannot have ever been the system rootvg. If this was true, the volume group would have made JFS log entries that could not be interpreted by an older version rootvg, when the volume group was experiencing a "wake-up." The alt_disk_install command does not allow a "wake-up" to occur on a volume group with a more recent version, unless the FORCE environment variable is set to yes. v The volume group that experiences a "wake-up" must be "put to sleep" before it can be booted and used as the rootvg. Attention: If a FORCE "wake-up" is attempted on a volume group that contains a more recent version of the running operating system, and the "waking" volume group has been a system rootvg, errors occur.
71
1. Start the Web-based System Manager by typing wsm on the command line. 2. Select the Software container. 3. From the pulldown, select Alternate Disk Install > Install Mksysb on an Alternate Disk. To 1. 2. 3. clone the rootvg to an alternate disk, do the following: Start the Web-based System Manager by typing wsm on the command line. Select the Software container. From the pulldown, select Alternate Disk Install > Clone the Rootvg to an Alternate Disk.
-g
In SMIT, use the smit alt_clone fast path and select hdisk1 from the listing for Target Disk(s) to install, select the update_all bundle from the listings in the Bundle to Install field, and /dev/cd0 from the listing in the Directory or Device with images field. 2. To clone the rootvg running 5.3.2 to hdisk3, then update to the latest fixes that are mounted from another system on /533fixes, and run a customized script named /tmp/finish_alt_install, run the following command:
alt_disk_copy -b update_all -l /533fixes \ -s /tmp/finish_alt_copy -d hdisk3
72
In SMIT, use the smit alt_clone fast path and select hdisk3 from the listing for Target Disk(s) to install, select the update_all bundle from the listings in the Bundle to Install field, type /533fixes in the Directory or Device with images field, and type /tmp/finish_alt_copy in the Customization script field. 3. To install an AIX mksysb tape that was created from a machine with the same hardware configuration as the target, to hdisk1, run the following command:
alt_disk_mksysb -m /dev/rmt0 -d hdisk1
In SMIT, use the smit alt_mksysb fast path and select hdisk1 from the listing for Target Disk(s) to install field and select /dev/rmt0 from the listing for Device or image name field. 4. To install an AIX mksysb image that is NFS mounted on file system /mksysbs to the alternate disk hdisk2 using a customized image.data file and an exclude file containing ^./tmp/, type the following command:
alt_disk_mksysb -m /mksysbs/my_53_mksysb -i /mksysbs/my_53_image.data \ -e /mksysbs/my_exclude_file -d hdisk2
Using the ^./tmp/ pattern does not backup files in the /tmp directory, but does backup files in the /var/tmp directory. Note: All files are backed up relative to the current directory. This directory is represented by a . (dot character). If it is important that the search match the string at the beginning of the line when excluding a file or directory, it is necessary to use a ^. (caret followed by a dot character) as the first part of the search string, followed by the filename or directory to be excluded. The form is as follows:
^./filename
If the file name or directory being excluded is a substring of another file name or directory, use a ^. (caret followed by a dot character) for the search to start at the beginning of the line and the $ (dollar symbol) to have the search finish at the end of the line. In SMIT, use the smit alt_mksysb fast path and select hdisk2 in the Target Disk(s) to install field. Next, type /mksysbs/my_53_mksysb in the Device or image name field, /mksysbs/my_53_image.data in the image.data file field, and /mksysbs/my_exclude_file in the Exclude list field. 5. To "wake-up" an original rootvg, after booting from the new alternate disk, run the following command:
alt_rootvg_op -W -d hdisk0
The following example illustrates the output that might display when running the command discussed above:
# lspv hdisk0 hdisk1 000040445043d9f3 00076443210a72ea old_rootvg rootvg
At this point, the altinst_rootvg volume group is varied-on and the /alt_inst file systems are mounted. 6. To "put-to-sleep" a volume group that had experienced a "wake-up," type the following command:
alt_rootvg_op -S
The following example illustrates the output that might display when running the command previously discussed:
# lspv hdisk0 hdisk1 000040445043d9f3 00076443210a72ea altinst_rootvg rootvg
# alt_rootvg_op -S
73
000040445043d9f3 00076443210a72ea
altinst_rootvg rootvg
The altinst_rootvg is no longer varied on and the /alt_inst file systems are no longer mounted. If necessary for the altinst_rootvg volume group name to be changed back to old_rootvg, do this task with the -v flag.
74
3. The standby logical volumes are created based on image.data attributes. The active and standby logical volumes are marked with unique tags in the logical volume control block. The multibos utility uses these tags to identify copied logical volumes. If the active logical volume names are classic names, such as hd2, hd4, hd5, and so on, then the bos_ prefix is prepended to create a new standby name. If the active logical volume names have the bos_ prefix, the prefix is removed to create a new standby name. Note: The Logical Volume Manager (LVM) limits the maximum length of a logical volume name to 15 characters. This means that any logical volume classic name may not exceed 11 characters. You can rename logical volumes that have classic names that exceed 11 characters using the chlv command. If the active logical volume name already has the bos_ prefix, then the prefix is removed in the standby name. 4. The standby file systems are created based on image.data attributes. The active and standby file systems are marked with unique tags in the hosting logical volume control block and /etc/filesystems. The multibos utility uses these tags to identify copied logic volumes. The /bos_inst prefix is prepended to the original active file system name to create the standby file system name. The standby file system name may not exceed the systems PATH_MAX limit. The standby file systems appear as standard entries in the active BOS /etc/filesystems. 5. The standby file systems are mounted. 6. A list of files that will be copied from the active BOS is generated. This list is comprised of the current files in copied active BOS file systems, less any files that you excluded with the optional exclude list (see the -e flag). 7. The list of files generated in the previous step is copied to the standby BOS file systems using the backup and restore utilities. 8. Any optional customization is performed. This can include installation of fileset updates or other software. 9. The standby boot image is created and written to the standby BLV using the AIX bosboot command. You can block this step with the -N flag. Only use the -N flag if you are an experienced administrator and have a good understanding the AIX boot process. 10. The standby BLV is set as the first boot device, and the active BLV is set as the second boot device. You can skip this step using the -t flag.
75
Preview option
The preview option, using the -p flag, applies to the setup, remove, mount, unmount, and customization operations. If you specify the preview option, then the operation provides information about the action that will be taken, but does not perform actual changes.
Preview option
The preview option, using the -p flag, applies to the setup, remove, mount, unmount, and customization operations. If you specify the preview option, then the operation provides information about the action that will be taken, but does not perform actual changes.
76
Preview option
The preview option, using the -p flag, applies to the setup, remove, mount, unmount, and customization operations. If you specify the preview option, then the operation provides information about the action that will be taken, but does not perform actual changes.
Preview option
The preview option, using the -p flag, applies to the setup, remove, mount, unmount, and customization operations. If you specify the preview option, then the operation provides information about the action that will be taken, but does not perform actual changes.
77
persistent changes to the kernel, process table, or other operating system structures. Only use the BOS shell if you are experienced with the chroot environment. The multibos shell operation performs the following steps: 1. The standby BOS file systems are mounted, if they are not already. 2. The chroot utility is called to start an interactive standby BOS shell. The shell runs until an exit occurs. 3. If standby BOS file systems were mounted in step 1, they are unmounted. Here is an example of some operations that can be performed in the multibos shell:
MULTIBOS> lppchk v # check system fileset consistency MULTIBOS> installp -ug bos.games # removes bos.games MULTIBOS> oslevel r # reports recommended maintenance level for standby BOS
Preview option
The preview option, using the -p flag, applies to the setup, remove, mount, unmount, and customization operations. If you specify the preview option, then the operation provides information about the action that will be taken, but does not perform actual changes.
78
See the lsfs command for details about how to match file system mount points to logical volumes. Separate log devices (those not contained within the file systems) are not supported for copy and will not be copied even if listed in the AddFile file. Note: Only LVM-based objects (that is, objects associated with logical volumes) are supported for multibos copying.
79
The bosinst.data file directs the actions of the BOS installation program. The file resides in the /var/adm/ras directory on the installed machine only, and it is not accessible on the commercial tape or the media on which you received AIX. The bosinst.data file contains stanzas with variables set to default values. Each variable is on a new line, in the Variable=Value form. A blank line separates each stanza. These stanzas provide the installation program with information such as the method and type of installation, the disks in the machine, and the language used. By editing the file with an ASCII text editor, you can substitute new values for the default variables. Another installation file, image.data, can also be modified and used during BOS installation. The image.data file contains information describing the root volume group image created during the BOS installation process. This information includes the sizes, names, maps, and mount points of logical volumes and file systems in the root volume group. The installation program also takes input from the image.data file regarding defaults for the machine being installed. For a description of the image.data file, see AIX Version 6.1 Files Reference. The procedure for using the bosinst.data file to customize BOS installation can also be used for the image.data file. The modified files can be used together to override BOS installation defaults. You can also use the instructions in this chapter to create a supplemental diskette, a CD-R, or a DVD-RAM containing a modified preserve.list file, which is used during a preservation Installation. For more information about a preservation installation, see Installing the Base Operating System on page 38.
80
c. d. e. f. g.
Copy the /var/adm/ras/bosinst.data file to /tmp/mycd. Copy the /var/adm/ras/bosinst.data file to /tmp/mycd. Edit the bosinst.data file with an ASCII editor to customize it. Create a signature file: echo data > signature. Change the permissions on the file using the following command: # chmod 777 *.
2. Create the customized media by completing the following steps: a. Use the cd command to change your directory to the / directory. b. Create the customized media using the following command (where /dev/cd1 varies depending on your CD writer device): # mkcd -d /dev/cd1 -r /tmp/mycd 3. Use the customized media for installation by completing the following steps: v If you have only one media drive and you are installing from CD or DVD, complete the following: a. Insert the installation media in the media drive of the machine where you are installing AIX. b. Boot the machine from the installation media. c. Type 311 at the BOS welcome screen. You will be prompted to insert the customized media. d. Insert the customized media. The BOS installation program uses the bosinst.data file on the media, rather than the bosinst.data file on the boot media. For more information on the bosinst.data file, see The bosinst.data file on page 45. v If you are performing a network installation or tape mksysb installation, or if you have more than one media drive, complete the following: a. Insert the customized media in the media drive of the machine where you are installing AIX. b. Boot the machine from the network or a tape. Note: You can boot from a CD and use a tape for the installation. However, during a tape boot, you cannot use the CD and DVD drives to supply customized information. c. Type 311 at the BOS welcome screen. The installation continues for a non-prompted installation, or the menus display for a prompted installation. The BOS installation program uses the bosinst.data file on the media, rather than the bosinst.data file from the boot media. For more information on the bosinst.data file, refer to The bosinst.data file on page 45.
81
c. Boot the target machine from the installation media (tape, CD or DVD-ROM, or network) and install the operating system. The BOS installation program uses the diskette file, rather than the default bosinst.data file shipped with the installation media. For more information on the bosinst.data file, see The bosinst.data file on page 45.
3. If you are using a fibre-channel disk for the installation, you can use the following command in the bosinst.data file:
SAN_DISKID=worldwide_portname//lun_id
v Specify the installation disk in the 2 file through either an installation from CD or DVD, or through a network installation. 1. For a network installation, specify the installation disk in the bosinst.data file by typing the following command:
nim -o bos_inst -a bosinst_data=value ...
2. For an installation from CD or DVD, specify the installation disk in the bosinst.data file by following the procedures at Customizing and using the bosinst.data file on page 80. If you do not specify the characteristics of the disk in the bosinst.data file on the target system, the installation disk is chosen based on the flags in the control_flow stanza of the bosinst.data file. Unless you specify EXISTING_SYSTEM_OVERWRITE=no, the first suitable root volume group is chosen for the installation. For overwrite or preserve installations, any root volume group is acceptable. For migration, the volume group must be installed with a version of the operating system that can be migrated to the level being installed. If you specify EXISTING_SYSTEM_OVERWRITE=no in the control_flow stanza of the bosinst.data file, then the installation goes to the first unused disk.
Related information
Links to information related to customizing your BOS installation are shown. For more information about the bosinst.data file, refer to The bosinst.data file on page 45. For a description of the image.data file, see AIX Version 6.1 Files Reference.
2. bosinst.data
82
Note: These filesets are not translated into all languages. The fileset names for the AIX commands, files and libraries in man command format are titled as follows: v infocenter.man.XX_XX.commands v infocenter.man.XX_XX.files v infocenter.man.XX_XX.libs Where XX_XX is the language indicator for that fileset (for example, EN_US). While performing installs from either the AIX operating system CDs or DVD or the AIX Documentation CDs or DVD, select filesets such as those in the list above for the languages in which you wish to view man command documentation.
Configuring AIX
Complete all configuration tasks that apply to your newly installed system. Two configuration tools are available to assist you. Depending on which type of console you are using, one of the following usually begins automatically after installation: v Configuration Assistant for graphics consoles v Installation Assistant for ASCII consoles Note: v If your system was installed by a network installation server, the Configuration Assistant or Installation Assistant does not display when the BOS installation program completes. If your system was installed using a system backup image, or if your BOS installation was customized, or if you selected migration installation from AIX, the Configuration Assistant or Installation Assistant might not display when the BOS installation program completes. v The Configuration Assistant and the Installation Assistant do not contain the tasks needed to configure your machine as a server. If you need to configure your system for a specific resource, refer to the documentation pertaining to that resource. v If your terminal type is not set, the first menu displayed by the ASCII Installation Assistant requires you to enter your terminal type (TTY). If you enter a terminal type that is not valid, this menu redisplays until a valid type is entered. If you enter a valid terminal type that does not match your terminal, the next screen displayed might be unreadable. In this case, press the break key sequence to return to the Set Terminal Type screen. For most terminal types, the break key sequence is Ctrl-C.
83
v Configure the Web server for Web-based System Manager remote management. v Manage Software. v Exit the Configuration Assistant. The Manage Software option allows you to perform software management tasks immediately after a BOS installation. The following options are available: v List installed software v Install additional software v List software licenses with license text If you select List installed software, the following options are available: v List automatically installed Software Displays a list of all installed packages v List optionally installed software Displays a list of all optional software that was selected to be installed during BOS installation If you select Install additional software, the following options are available: v Install by bundles Allows you to select from a list of software bundles to install additional software, such as the Mozilla Software Bundle or a User-Defined Software Bundle v Selective install Allows you to select a specific package or set of packages to install The graphical interface for the Configuration Assistant provides step-by-step instructions for completing each configuration task. The tasks are presented to you in a logical sequence. Complete all configuration tasks before you use your system. When you exit the Configuration Assistant, the guide asks you whether you want to start Configuration Assistant again the next time you restart the operating system. After exiting the Configuration Assistant, users can begin logging in to and using AIX. To access the Configuration Assistant later, type configassist on the command line.
84
v Install and Update Software v Add License Passwords for Applications v Show Installed License Agreements If you select Install and Update Software, the following menu displays:
Install and Update Software Move cursor to desired item and press Enter. Install Software Update Installed Software to Latest Level (Update All) Install Software Bundle Update Software by Fix (APAR) Install and Update from ALL Available Software
You can also access this SMIT menu by using the install_update fast path.
Related information
The following are links to information related to Configuring AIX. If you are installing from CD or DVD-ROM, or would like more information about installing optional software, refer to Preparing to install optional software products and service updates on page 324.
85
Note: The Use Maps option is not supported in Maintenance Mode. For more information on the maps options in Maintenance Mode, refer to Installing a system backup on the source machine on page 317.
86
Note: Depending on the type of data or files in the file system, you might need additional blocks free. For example, if the file system has a lot of small files, an extra 4 KB is automatically allocated to allow for metadata expansion. v Check that you are using the correct tape type for the density setting that you selected. v Check that the tape is not write-protected. v Clean the tape drive at the recommended intervals and use only approved data-grade tapes (not video tapes for 8 mm). v Check that 7206 4-mm Digital Audio Tape (DAT) tape drives are using only DAT tapes marked with the Dataphone Digital Services (DDS) symbol. Any other DAT tapes (for example, voice grade) cannot be used. v Check the /smit.log file for any errors from SMIT. v Check that your mksysb backup image contains an image.data file. If you create the mksysb backup image through Web-based System Manager or SMIT, it is done automatically. If you run mksysb from the command line, you must either run the mkszfile command first, or use the -i flag with the mksysb command.
87
v If you cannot find extra space in your rootvg, you might have to do a preservation installation instead of a migration installation to AIX. A preservation installation saves all the "non-system" logical volumes and file systems (for example, /home), but removes and re-creates the following logical volumes: hd2, hd3, hd4, hd5 and hd9var. If you do a preservation installation, you must reinstall any applications that were installed in your rootvg after the preservation installation has completed. You must also reconfigure devices, as well as re-create users and groups. For more information about a preservation installation, see Installing the Base Operating System on page 38. After you have released enough space, reboot from your installation media, and try the migration installation again. You must have at least 8 MB of free disk space to complete the migration installation. If there is insufficient space to complete the migration installation during the BOS installation process, a message similar to the following is displayed at the end of the installation:
An error occurred while migrating packages. Some packages have not been installed. Please see /var/adm/ras/devinst.log for details or perform an overwrite or preservation install.
If space limitations prevent the migration of all software that is usually automatically migrated, the installation program attempts to install the software that is usually installed for a Preservation or Overwrite installation. If there is still not enough disk space available, the minimum set of software required to support the use of the system is installed. If there is not enough space to migrate all of the usually migrated software, a collection of software called a Migration Bundle will be available when you install additional software later. If the minimum set of software is installed, or if the installation is not performed from a graphics console, a Graphics_Startup Bundle is created. Before installing either of these bundles, create additional disk space on the machine you want to install. For more information about installing software bundles and migrating or installing optional software products, refer to Optional products and service updates on page 321. Maintaining optional software products and service updates on page 329 describes how to remove software from the system to release disk space.
88
corresponding entries from the /etc/filesystems file. This action removes the real file system stanzas from your running system and causes boot problems if you reboot with the missing stanzas. Use the alt_disk_install -X command to remove the altinst_rootvg name from the database. This removes only the ODM information from the CuDv database, so the lspv command shows the disk(s) as no longer belonging to altinst_rootvg. It also resets your bootlist to the boot disk on which the hd5 boot logical volume resides. You can still boot from the altinst_rootvg, because the volume group, logical volume, and file system information remain on the disk. However, you must set your bootlist to the altinst_rootvg boot disk.
Troubleshooting a system that does not boot from the hard disk
Follow this procedure to access a system that will not boot from the hard disk. If a mksysb backup tape fails to boot, read Troubleshooting an installation from a system backup on page 85 for instructions. This procedure enables you to get a system prompt so that you can attempt to recover data from the system or perform corrective action that will enable the system to boot from the hard disk. Note: 1. This procedure is intended only for experienced administrators who have knowledge of how to boot or recover data from a system that is unable to boot from the hard disk. Most administrators should not attempt this procedure but instead should follow local problem-reporting procedures. 2. This procedure is not intended for administrators who have just completed a New Installation, because the system will not contain data that needs to be recovered. If you are unable to boot from the hard disk after completing a New Installation, follow your local problem-reporting procedures. The following steps summarize the procedure for accessing a system that will not boot. 1. Boot the system from Volume 1 of the BOS media or a bootable tape. 2. Select Maintenance Options. 3. Recover data or perform corrective action using the system prompt.
89
Confirm the following: v Your system cannot be booted from the hard disk. v All hardware is installed. v AIX Base Operating System (BOS) is installed. v Your system unit is set to Off.
90
v v v v v v v v v v
Line Wrap = on Forcing Insert = line (or both) Tab = field Operating Mode = echo Turnaround Character = CR Enter = return Return = new line New Line = CR Send = page Insert Character = space Note: If your terminal is an IBM 3151, 3161, or 3164, press the Ctrl+Setup keys to display the Setup Menu and follow the onscreen instructions to set these options. If you are using some other ASCII terminal, refer to the appropriate documentation for information about how to set these options. Some terminals have different option names and settings than those listed here.
4. Turn the system unit power switch to the On position. The system begins booting from the installation media. If your system is booting from tape, it is normal for the tape to move back and forth. After several minutes, c31 is displayed in the LED. If you have more than one console, each terminal and directly attached display device (or console) might display a screen that directs you to press a key to identify your system console. A different key is specified for each terminal displaying this screen. If this screen is displayed, then press the specified key on the device to be used as the system console. The system console is the keyboard and display device used for installation and system administration. Press a key on only one console. 5. Type 3 to select Start Maintenance Mode for System Recovery from the Welcome to the Base Operating System Installation and Maintenance screen when it displays. Note: If you customized the bosinst.data file in your installation media to specify a nonprompted installation, the installation and maintenance screens are not displayed. The system instead reboots from the installation media using the settings already defined in the bosinst.data file. To access the installation and maintenance screens, override the nonprompted mode. You can do this when three zeros are displayed on the screen. When you observe the three zeros, type 000 (zeros) and press Enter at the terminal. You can select 88 to display help on this or any subsequent screen. After you have selected the Start Maintenance Mode for System Recovery option, the Maintenance screen displays. 6. Select option 1, Access a Root Volume Group, from the Maintenance screen. The Warning screen displays. 7. Read the information displayed on the Warning screen. When you are ready to continue, type 0 and press Enter. The Access a Root Volume Group screen displays. 8. Select the option for the root volume group whose logical volume information you want to display. The Access a Root Volume Group screen lists all of the volume groups (root and otherwise) on your system. After entering your selection, the Volume Group Information screen displays. Note: Reviewing the disk and location code information on the Volume Group Information screen enables you to determine whether the volume group you selected was the root volume group. You can return to the Access a Root Volume Group screen if the choice you made was not the root volume group. If you have not chosen a root volume group, you cannot continue beyond the Volume Group Information screen. 9. Select one of the options from the Volume Group Information screen and press Enter. Each option does the following:
Installation and migration
91
Choice 1 Choice 2
Choice 99
Access this volume group and start a shell. Selecting this choice imports and activates the volume group and mounts the file systems for this root volume group before providing you with a shell and a system prompt. Access this volume group and start a shell before mounting file systems. Selecting this choice imports and activates the volume group and provides you with a shell and system prompt before mounting the file systems for this root volume group. Typing 99 returns you to the Access a Root Volume Group screen.
After you select either choice1 or 2, a shell and system prompt display. 10. Take appropriate measures to recover data or take action (such as using the bosboot command) to enable the system to boot normally.
The resulting list contains all logs that are viewable with the alog command. Select from the list by pressing the F4 key.
92
The system message is displayed in bold type. Describes what is likely to have caused the system message to be displayed. Describes what the system does after the message is displayed. Suggests a possible resolution to the problem suggested by the system message.
Note: Multiple messages can have the same explanation, system action, and user action. 0516-404 allocp: Not enough resources available to fulfill allocation. Either not enough free partitions or not enough physical volumes to keep strictness. Try again with different allocation characteristics. 0516-788: extendlv: Unable to extend logical volume 0503-008 installp: There is not enough free disk space in file system /usr (506935 more 512 byte blocks are required.) An attempt to extend this file system was unsuccessful. Make more space available, then retry this operation.
Explanation System Action User Action There is not enough space to complete the installation. The installation cannot begin until the problem is resolved. You have several options: v Select fewer filesets than the number originally selected for installation. OR v Extend the root volume group to another disk. Type: extendvg rootvg hdisk Number, where Number is the number of the specified disk. OR v Remove user-defined file systems to release space in the rootvg file system. OR v Follow the instructions in Troubleshooting a full /usr file system on page 92.
BOS Install: After saving all the data from the previous system into /tmp, it was discovered that there will not be enough free space in /tmp to make the boot image. Please reboot in normal mode and increase the size of /tmp or reduce the number of files to save as listed in the /etc/preserve.list file.
Explanation System Action User Action During a preservation installation, files listed in the/etc/preserve.list file were copied to the /tmp file. After doing so, there was not enough room in /tmp to create the boot image. Installation cannot continue. Reboot in normal mode and increase the size of /tmp or reduce the number of files to be saved.
BOS Install: You chose to create logical volumes mapped exactly as they were on the previous disks, but there are no map files specified in the image.data file.
Explanation System Action User Action On system backup restore, EXACT_FIT = yes was specified in the image.data file, but no map files were specified in the image.data file. Nonprompted mode is terminated. The user is prompted. Run the mkszfile command with the -m option before creating the system backup tape. OR Do not specify EXACT_FIT = yes in the image.data file.
The boot logical volume (hd5) must be at least 12 MB. The system you are installing has a boot logical volume smaller than this, and the system does not have enough free contiguous physical partitions on diskname to increase the size of the boot logical volume. Please reboot in normal mode and correct
Installation and migration
93
this problem, or restart the installation and choose an overwrite install. Use the lspv -M diskname command to see the current allocation map of the disk. OR Error: No space available to create a larger boot logical volume. In order to proceed with this installation the size of the boot logical volume (hd5) must be increased to 12 MB. At this time there are not N contiguous physical partitions available on the boot disk (diskname) for recreating the larger boot logical volume. You must free up this space by removing or relocating one or more logical volumes or file systems from diskname. Use lspv -M diskname to see its current partition allocation map.
Explanation The boot logical volume (blv), logical volume hd5, must be greater than 12 megabytes. If your system had disks less than 4 gigabytes in size in the root volume group, your boot logical volume may only be 4 megabytes. You might experience this failure during preservation or migration installations. Overwrite installations create the boot logical volume with a minimum size of 12 megabytes. If free partitions contiguous to hd5 are available or if another location on the disk contains hd5 is identified, the installation process increases the size of hd5 and continues. Only the disk that currently contains the boot logical volume is checked for additional partitions in order to increase the size of the boot logical volume. Other disks in the rootvg are not checked. You will be prompted to reboot in normal mode from the existing rootvg and increase the boot logical volume, or restart the installation and choose an overwrite install. Only a system administrator with root authority should attempt to increase the boot logical volume. To increase the boot logical volume, follow the process described below: If you received this error, then your partition size is less than 8 megabytes, and you must increase the number of partitions in hd5 (boot logical volume). You can check your partition size as follows: 1. Type the following: # lsvg rootvg 2. Look for the field: PP SIZE: 3. Obtain the current number of partitions in hd5, as follows: # lslv hd5 4. Look for the field: LPs: 5. Your boot logical volume must contain enough partitions such that: v PP SIZE multiplied by LPs is greater than or equal to 8. v The partitions for the boot logical volume must be contiguous. If there were free partitions available next to hd5 or at some other location on the disk that contains hd5, the installation process would have increased the size of hd5, and continued. To view the current allocation map (free and used partitions) of a disk, use the command: # lspv -M diskname
94
If there are not enough contiguous free partitions, you must increase the size of the boot logical volume (hd5) using one of the options described below, and rerun the installation. The options for increasing the boot logical volume size are as follows: v If a user-created logical volume or file system follows hd5 on the disk (check the allocation map), and has free partitions, you can back up, remove, re-create, and restore the logical volume. v If there is another disk in the rootvg, that has enough contiguous free partitions, then you could move hd5 to the other disk with the following steps: 1. Verify that the disk you plan to move hd5 to is bootable by using the command: bootinfo -B diskname If 1 is returned, the disk is bootable. If 0 is returned, the disk is not bootable. 2. Find the free contiguous partitions you need on the other disk by viewing the allocation map with the command: lspv -M diskname 3. Create a map file to use when re-creating hd5. For example, if you want to re-create hd5 on hdisk2, on partitions 88 and 89, use the command: echo "hdisk2:88-89" > your_MAP_file 4. Remove the existing hd5: rmlv -f hd5 5. Create the new hd5: mklv -y hd5 -t boot -m your_MAP_file rootvg 2 The 2 represents the number of partitions and can vary as needed. Note: If the mklv command moves hd5 to a new location, you must run the following command: echo ":C:C:C" | /usr/lpp/bosinst/blvset -d /dev/hdiskN Where C is the message, locale, and keyboard (respectively) and hdiskN is the disk that contains hd5. 6. Run the mkboot command to clear the boot record from the disk that previously contained hd5 (boot logical volume). For example, if hd5 was previously on hdisk0, use the command: mkboot -d /dev/hdisk0 -c 7. Use the bosboot command to re-create the boot image and boot record on the new disk. For example, if hd5 was re-created on hdisk2, use the command: bosboot -a -d /dev/hdisk2
95
1. Change the bootlist of your system to boot from the new disk. To see the current bootlist, use the command: bootlist -m normal -o OR If your previous hd5 was on hdisk0, the output might be: hdisk0 To change the bootlist to use hdisk2, use the command: bootlist -m normal hdisk2 If there were additional items in your bootlist, add them after hdisk2, with spaces separating each item. 2. If there were no errors, reboot your system. 3. If you encountered this error when installing a mksysb on a system other than the system it was created on (cloning), then you might be able to use a customized image.data file to increase the size of hd5. The vg_data stanza contains the size of the physical partitions in the PPSIZE field. Use this information to determine how many partitions are needed for hd5. The lv_data stanza for hd5 contains the fields for the number of logical partitions (LPs), the number of physical partitions (PP), and the minimum number of logical partitions required for the logical volume (LV_MIN_LPS). These fields must be set to the number of partitions needed. See Creating and using a supplementary bosinst.data diskette on page 81 for information on putting an image.data file on diskette and a bosinst.data file. If the source machine had no free partitions, and the target machine has the same disk size, then you might need to install using the shrink option, as well as the customized image.data file.
The bosinst.data file specified doing a migration install, but there is no existing root volume group.
Explanation System Action User Action A BOS installation method of migration was specified in the bosinst.data file, but the existing volume group is at a lower level. This error only occurs during a nonprompted BOS installation. The installation menus are displayed. Respond to the menu prompts to complete the installation.
The bosinst.data file specified doing either a migration or a preservation install, but there is no existing root volume group.
96
A BOS installation method of migrate or preserve was specified in the bosinst.data file, but no root volume group was found. This error only occurs during a nonprompted BOS installation. The installation menus are displayed. Respond to the menu prompts to complete the installation.
The data file did not specify enough disk space to contain the operating system.
Explanation System Action User Action Nonprompted mode was specified, and there were not enough disks specified in the bosinst.data file to hold the operating system. Nonprompted mode is terminated. The user is prompted. When the system prompts, select disks to install on. OR Add more target_disk_data stanzas to bosinst.data file.
Duplicate lv_data stanzas specified in the image.data file. The installation cannot continue because data may be lost.
Explanation System Action User Action An lv_data stanza was duplicated in the image.data file. Installation cannot continue. Correct the problem and try the installation again.
Duplicate fs_data stanzas specified in the image.data file. The installation cannot continue because data may be lost.
Explanation System Action User Action An fs_data stanza was duplicated in the image.data file. Installation cannot continue. Correct the problem and try the installation again.
The following disks failed the preliminary diagnostic tests: <disk name> bosset: No hard disks can be accessed.
Explanation System Action User Action The listed disks failed pretest. The system initiated a diagnostic pretest on the specified disk. Run full diagnostics on the specified disks.
97
The menus subsystem encountered an unrecoverable error. The menu is restarted. None
The image.data file contains no vg_data stanza for rootvg. The installation cannot continue.
Explanation System Action User Action The image.data file is incomplete. Installation cannot continue. Use the default image.data file supplied with product media.
0516-366 putlvodm: Volume group rootvg is locked. Try again. 0516-788: extendlv: Unable to extend logical volume.
Explanation System Action User Action You interrupted the installation of your optional software. When an installation is interrupted, the system sometimes locks the root volume group. Unlock the root volume group. Then attempt the installation procedure again. To unlock a root volume group: 1. Log in with root authority. 2. Type chvg -u rootvg 3. Type smit_install and attempt to install your optional software products again.
installp: An error occurred during bosboot processing. Please correct the problem and rerun. 0301-52 bosboot: not enough file space to create: /tmp/disk.image. OR 0301-152 bosboot: not enough file space to create: /tmp/unix.
98
The bosboot command was unable to finish processing because of insufficient space in /tmp. The bosboot process is interrupted. The error message, the amount of disk space required, and the available disk space are displayed. The disk space displayed indicates the number of 1024 KB blocks required. Release space in the /tmp file system or extend the /tmp file system. Continue or restart the installation process. To resize the /tmp file system and complete the installation, do the following: 1. Note the error message preceding this one. Either the message bosboot verification starting or bosboot process starting will precede this message. 2. Change directories to /tmp. List the files and determine which files can be deleted. If there is sufficient space available, go to step 6. If you need to expand the /tmp file system, continue with this procedure. 3. Type smit chfs 4. Select the /tmp file system from the displayed list. 5. Add the additional block space required. The smit chfs command requires disk space to be defined in 512 KB blocks. Double the required disk space displayed in the system message. 6. If the message installp: An error occurred during bosboot processing was displayed after the message bosboot verification starting, rerun the installation procedure. OR If the message installp: An error occurred during bosboot processing was displayed after the message bosboot process starting, enter installp -C. 7. Continue the installation process.
User Action
installp: An error occurred during bosboot processing. Please correct the problem and rerun. 301-155 bosboot: Invalid or no boot device specified.
Explanation A device specified with the bosboot -d command is not valid. The bosboot command was unable to finish processing because it could not locate the required boot device. The installp command calls the bosboot command with /dev/ipldevice. If this error does occur, it is probably because /dev/ipldevice does not exist. /dev/ipldevice is a link to the boot disk. The bosboot process is interrupted. Determine if the link to the boot device is missing or incorrect, correct the error and complete the installation process. To identify the boot device and complete the installation: 1. To identify the boot disk, enter lslv -m hd5. The boot disk name displays. 2. Create a link between the boot device indicated and the /dev/ipldevice file. Enter: ln /dev/boot_device_name /dev/ipldevice (An example of boot_device_name is rhdisk0.) 3. If the message installp: An error occurred during bosboot processing was displayed after the message bosboot verification starting, rerun the installation procedure. OR If the message installp: An error occurred during bosboot processing was displayed after the message bosboot process starting, enter installp -C. Continue the installation process.
Missing image.data file. The tape does not contain a valid install image.
99
The system could not find an image.data file. Installation cannot continue. The most likely cause of this error is the tape is bad. Try a different tape.
0512-0016 mksysb: Attempt to create a bootable tape failed: bosboot -d /dev/device -a failed with return code xxx. OR 0512-0016 mksysb: Attempt to create a bootable tape failed: mkinsttape /dev/device failed with return code xxx.
Explanation The xxx return code indicates the error: 5 OR 1 Not enough space in one or more of three file systems: v / must have at least 500 1KB blocks. v /tmp must have at least 7400 1KB blocks. v /usr must have at least 4000 1KB blocks. 11 42 OR 45 Either the /usr/lib/boot/unix file is corrupted (may be 0 length) or the link to /unix is missing. 48 Cannot write to the tape drive or cannot read /dev/blv. This is probably caused by an incorrect density setting for the tape drive. It could also be caused by either a hardware problem with the tape drive or by dirty heads on the drive. Defective tape.
The mksysb command failed to make a bootable tape. The return code xxx indicates the action required: 5 OR 1 11 42 OR 45 Either restore the /usr/lib/boot/unix file from the original tape or create the missing link. 48 Check the tape drive settings and clean the heads. Check the /, /tmp, and /usr file systems and create more space as required. Replace the defective tape.
100
User Action
You have several options: v Select Maintenance (option 3) from the Welcome to Base Operating System Install Menu, and select the Limited Function Maintenance Shell. Verify that no disks were configured by entering the following command: lsdev -Cc disk To determine if there were configuration errors, enter the command: cfgmgr -v 2>1 | tee /tmp/cfgmgr.out You can use the cat command to view the /tmp/cfgmgr.out file, and look specifically for errors in configuration of disks. The file can be copied to diskette media using either the dd or pax commands, and moved to a running system for ease of viewing. OR v Turn off the system and check the following on systems with SCSI devices: Check all SCSI devices to ensure that all SCSI addresses are unique. Make sure the SCSI cards are properly terminated. If external SCSI devices are in use, make sure that the SCSI chain is terminated and that the devices are turned on. Check the SCSI cabling and connections. Reboot and attempt the installation again. OR v Turn off the system and check the following on systems with IDE devices: Check all IDE devices to ensure that all IDE master and slave settings are unique per controller. If only one IDE device is connected to a controller, it must be set to master. If an ATA device (disk) and an ATAPI device (CD-ROM or tape) are connected to the same controller, the ATA device must be set to the master device and the ATAPI device must be set as the slave device. Check the IDE cabling and connections. Reboot and attempt the installation again. OR v Boot from the diagnostics and check the hard disks. OR v Follow your local problem-reporting procedures.
You chose to install only onto disks in the existing root volume group and those not in any volume group. There are not enough of those disks to contain the mksysb image.
Explanation The EXISTING_SYSTEM_OVERWRITE field in bosinst.data was set to yes, and prompt was set to no, and there were not enough disks on the system that contained the root volume group or contained no volume group. Nonprompted mode is terminated. The user is prompted. Use target_disk_data stanzas to specify the disks to install on, set SHRINK to yes in the image.data file, or at the BOS Install prompt set the EXISTING_SYSTEM_OVERWRITE in the bosinst.data file to any. This allows any disks to be used for the installation. Attention: If EXISTING_SYSTEM_OVERWRITE is set to any, user volume groups might be overwritten. OR When the system prompts, select disks on which to install or select to shrink the file systems.
101
You chose to install only onto disks which are not contained in a volume group, but there are not enough of those disks to contain the mksysb image.
Explanation System Action User Action The EXISTING_SYSTEM_OVERWRITE field in bosinst.data was set to no, and prompt was set to no, and there were not enough disks on the system that contained a volume group. Nonprompted mode is terminated. The user is prompted. If you want the system to select the disk to install on, use the target_disk_data stanzas to specify the target disks and set the appropriate setting for EXISTING_SYSTEM_OVERWRITE, leave EXISTING_SYSTEM_OVERWRITE blank in the bosinst.data file, or set SHRINK to yes in the image.data file and retry the installation. OR When the system prompts, select disks on which to install.
102
This message is displayed when the installation program cannot determine the kernel type at the time of the installation. The installation will be paused for troubleshooting. Contact your service representative for troubleshooting.
The size of the Logical Volume (logical volume name) is larger than the size supported by the running kernel.
Explanation System Action User Action This message is displayed when the installation program detects that one of the Logical Volumes being created is larger than 1 TB (1048576 MB) and the running kernel is not the 64 bit kernel. The installation will be paused for troubleshooting. Restart the installation with AIX media (product or mksysb image) that supports booting the 64 bit kernel to prevent data loss or errors.
The size of one of the Logical Volumes in the rootvg disk or disks is larger than the size supported by the running kernel.
Explanation This message is displayed when the installation program detects that one of the Logical Volumes on the root volume group about to be imported is larger than 1 TB (1048576 MB) and the running kernel is not the 64 bit kernel. The installation will be paused for troubleshooting. Restart the installation with AIX media (product or mksysb image) that supports booting the 64 bit kernel to prevent data loss or errors.
103
NIM concepts
To use all the available features in NIM, you should understand various components of AIX installation.
NIM objects
The machines you want to manage in the NIM environment, their resources, and the networks through which the machines communicate are all represented as objects within a central database that resides on the master. Network objects and their attributes reflect the physical characteristics of the network environment. This information does not affect the running of a physical network but is used internally by NIM for configuration information. Each object in the NIM environment has a unique name that you specify when the object is defined. The NIM name is independent of any of the physical characteristics of the object it identifies and is only used for NIM operations. The benefit of unique names is that an operation can be performed using the NIM name without having to specify which physical attribute should be used. NIM determines which object attributes to use. For example, to easily identify NIM clients, the host name of the system can be used as the NIM object name, but these names are independent of each other. When an operation is performed on a machine, the NIM name is used, and all other data for the machine (including the host name) is retrieved from the NIM database.
NIM machines
The types of machines that can be managed in the NIM environment are standalone, diskless, and dataless clients. This section describes the differences between the machines, the attributes required to define the machines, and the operations that can be performed on them. The NIM environment is composed of two basic machine roles: master and client. The NIM master manages the installation of the rest of the machines in the NIM environment. The master is the only machine that can remotely run NIM commands on the clients. All other machines participating in the NIM environment are clients to the master, including machines that may also serve resources. Operating NIM on client machines: There are unique operations to initialize the different client configurations. NIM checks that the operation is a valid operation for a specific client configuration. The following table shows the operations that can be performed on the different client configuration types.
NIM Operation Standalone bos_inst dkls_init dtls_init diag cust fix_query lppchk maint maint_boot reset check showlog x x x x x x x x x x x x x x x x x x x x x x x x x x x Machine Configuration Diskless Dataless WPAR
104
NIM Operation Standalone reboot activate chwpar create deactivate destroy lswpar syncwpar x x x
Defining NIM clients: You can use the NIM define operation to define stand-alone, diskless, and dataless clients. The client system can be either managed or unmanaged. A managed client is associated with a managing system that controls the client. Managed clients use the network-boot and power-control capabilities of the dsm.core fileset when the file is installed. For example, You can request a maintenance boot of the client without accessing the managing system to request a network-boot. When the dsm.core fileset is installed the additional capabilities of the managed clients in comparison with the unmanaged clients, is as follows: v Performs a network-boot and boot in maintenance mode by using the following command:
nim -o maint_boot -a boot_client=yes
v Performs a network-boot and installs the client by using the following command:
nim -o bos_inst -a boot_client=yes
v Boots or reboots the client with the nim -o reboot parameter. v Opens a virtual console xterm, when using the -a open_console parameter on selected NIM operations. v Defines and uses virtual optical devices to allow the VIOS clients to mount an ISO image from a virtual CD. Managed clients require an mgmt_profile attribute. This attribute specifies the management object that controls the client. It also provides the client identifier (lpar_id or blade slot). To set the mgmt_profile attribute, use the mgmt_source and identity attributes. The mgmt_profile can be set directly, but it must not be merged with the mgmt_source and identity attributes of the define operation. Depending on the controlling system, the mgmt_source and identity attributes provide the following information: v If the client is managed by Hardware Management Console (HMC), the mgmt_source attribute must be a CEC or a VIOS object and the identity must be the lpar identifier of the client. v If the client is managed by an Integrated Virtual Machine (IVM), the mgmt_source attribute must be an IVM object and the identity must be the lpar identifier of the client. v If the client is managed by a Blade Center Management Module (BCMM), the mgmt_source attribute must be a BCMM object and the identity must be the blade slot of the client.
105
For managed clients, include the real network-adapter-hardware address in the if attribute to activate the network-boot capabilities. The definition of the CEC,HMC IVM, VIOS, and BCMM management object is described in To define a stand-alone, diskless, or dataless client, enter the command-line syntax as follows:
nim -o define -t MachineType -a Attribute=Value ... MachineName
Value 2 Value 3
Value 4
-a cable_type=Value
-a netboot_kernel=Value -a iplrom_emu=Value
106
-a net_definition=Value ...
Defines a NIM network to be associated with the client being defined. The value for this attribute consists of required values and optional values: Value 1 = NetworkType (required) Specifies the values tok, ent, fddi, and generic. Value 2 = SubnetMask (required) Specifies the dotted decimal mask for the network. Value 3 = ClientGateway (optional) Specifies the IP address or host name of the default gateway used by the machine being defined to communicate with the NIM master. Value 4 = MasterGateway (optional) Specifies the IP address or host name of the default gateway used by the NIM master to communicate with clients on other subnets. Value 5 = NetworkName (optional) Specifies a name to be given to the NIM definition created for the network. (Otherwise, a unique default value is assigned.) When specifying the net_definition attribute to create or change a machine definition, the find_net keyword must be specified as the first component of the if attribute for the machine. The net_definition attribute can also be specified when defining additional NIM interfaces (if attributes) for machine definitions. Specifies the CPU ID of the machine being defined. This attribute can be used for client verification during NIM operations. To display the CPU ID on a running machine, use the uname -m command. This field is optional and is automatically set the first time a client communicates with the NIM master. Specifies the port number used by the NIM master for socket communication with the clients. The default master port number is 1058. Specifies the port number used by clients to register themselves with the NIM master. The default registration port number is 1059. Specifies a machine group to which the client must be added. The group will be defined, if it does not exist. Provides comments about the client being defined. Displays information for debugging. Use verbose=5 to show maximum detail. Specifies the speed and duplex settings to use for the client's ethernet adapter during a network installation, and requires a sequence number when specified. When initiating an install and reboot of a client, NIM will set these parameters in the bootlist. Value1= auto, 10, 100, or 1000 The default is value is 100. Value2 = auto, half, or full The default value is full. For example:
-a cpuid=Value
nim -o change -a net_settings1="10 half" jellyfish Specifies the communicating service used by the NIM client for remote execution of NIM commands. Value options are shell (for RSH) and nimsh. The default setting is connect=shell. Stores managing system information for a NIM client that is managed by another NIM client, and requires a sequence number when specified. A mgmt_profile setting is required for operations on WPAR clients which must be performed by a managing system. Two values are required for this attribute. Value1 Value2 Specifies the name of the NIM client which manages this client. Specifies the name of the system as known on the managing system. This may be different than the name of the NIM object for the system. This attribute must not be used in conjunction with the mgmt_source attribute and should be used for WPAR clients.
107
-a mgmt_source=Value
Stores managing system information for a NIM client that is managed by a hardware control point. The value must point to an existing NIM object, which can be one of the following object: v A VIOS object for logical partitionsLPAR (LPARs), that are attached to a Virtual I/O Server object. v A CEC object for LPAR (LPARs) that are defined on a CEC v An IVM object for LPAR (LPARs) that are attached to an IVM v A BCMM object for blades Stores the client identifier information for a NIM client that is managed by a hardware control point. The value must be the client identifier on the hardware control point, which is one of the following: v The LPAR identifier for LPARs v The blade slot on the BCMM for blades Specifies the TCP/IP port number that is used to transfer dump images from the diskless (<= Missing "=" value), and dataless clients to the dump resource server. This port number is used by a dump resource server, and otherwise has no meaning. The default value is 32600.
-a identity=Value
-a dump_portValue
Standalone NIM clients: Standalone NIM clients can be booted and operated from local resources. Standalone clients mount all file systems from local disks and have a local boot image. Standalone clients are not dependent upon network servers for operation. Booting a standalone client from the network: Although an installed standalone client is capable of booting from the local disk, it may be necessary to perform a network boot of the client for certain NIM operations. Clients must boot over the network in order for NIM to perform a BOS installation (bos_inst) of the client or to boot into maintenance mode (maint_boot) and diagnostics (diag). If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. Managing software on standalone clients: The AIX Base Operating System can be installed directly on standalone clients using the NIM bos_inst operation. Additional software and updates can be installed and managed on standalone clients using the NIM cust and maint operations. For more information about these and other operations, see Using NIM operations on page 246. Diskless and dataless clients: Diskless and dataless clients are machines that are not capable of booting and running without the assistance of servers on a network. As their names imply, diskless clients have no hard disk, and dataless clients have disks that are unable to hold all the data that may be required for operation. Diskless machines must mount paging space and all file systems from remote servers. Dataless machines can only use a local disk for paging space and the /tmp and /home file systems. Neither diskless nor dataless clients have a local boot image, and they must boot from servers on the network. Defining a machine as diskless or dataless has the following advantages: v Cost savings No hard disk is required for diskless clients. Only a small hard disk is needed for dataless clients.
108
v Manage software configurations on machines On diskless and dataless clients, the file system containing the BOS is mounted from a server. All client systems that mount the same file system for BOS run from identical software. v Manage storage of user data User data for diskless and dataless clients are stored on remote servers. A system administrator can manage storage allocation and data backups for the client machines by managing the data on the server, rather than on each machine separately. Resources for diskless and dataless clients: The file systems that are mounted by the diskless and dataless client machines are treated as resources in the NIM environment. Like other resources, they exist on a server in the NIM environment, and they are NFS-exported to the clients that use them. The following resources are managed by NIM to support diskless and dataless clients:
boot SPOT Defined as a network boot image for NIM clients. The boot resource is managed automatically by NIM and is never explicitly allocated or deallocated by users. Defined as a directory structure that contains the AIX run-time files common to all machines. These files are referred to as the usr parts of the fileset. The SPOT resource is mounted as the /usr file system on diskless and dataless clients. Contains the root parts of filesets. The root part of a fileset is the set of files that may be used to configure the software for a particular machine. These root files are stored in special directories in the SPOT, and they are used to populate the root directories of diskless and dataless clients. The network boot images used to boot clients are constructed from software installed in the SPOT. A SPOT resource is required for both diskless and dataless clients. Defined as a parent directory for client "/" (root) directories. The client root directory in the root resource is mounted as the "/" (root) file system on the client. When the resources for a client are initialized, the client root directory is populated with configuration files. These configuration files are copied from the SPOT resource that has been allocated to the same machine. A root resource is required for dataless clients. It is required that either a root resource or a shared_root resource be allocated for diskless clients. Defined as a parent directory in which client dump directories are maintained. When a dump resource is allocated to a client, NIM creates a subdirectory identified by the client's name for the client's exclusive use. After initialization, the client uses this subdirectory to store any dump images it creates. Note that such dumps are firmware-assisted. A dump resource is optional for both diskless and dataless clients. Defined as a parent directory for client paging files. The client paging file in the paging resource is mounted as the paging device for the client. A paging resource is required for diskless clients and optional for dataless clients. Defined as a parent directory for client /home directories. The client directory in the home resource is mounted as the /home file system on the client. A home resource is optional for both diskless and dataless clients. Defined as a /home directory shared by clients. All clients that use a shared_home resource will mount the same directory as the /home file system. A shared_home resource is optional for both diskless and dataless clients.
root
dump
paging
home
shared_home
109
shared_root
Defined as a / (root) directory shared by one or more diskless clients. All clients that use a shared_root resource will mount the same directory as the / (root) file system. Because STNFS is used to mount the shared_root, any change made by a client to its root filesystem is kept local and is invisible to other clients or to the server of the shared_root resource. Any change a client makes to its root filesystem is also lost when the client is rebooted. It is required that either a shared_root resource or a root resource be allocated for diskless clients. A shared_root resource cannot be allocated by dataless clients. Defined as a parent directory for client /tmp directories. The client directory in the tmp resource is mounted as the /tmp file system on the client. A tmp resource is optional for both diskless and dataless clients. Contains nameserver IP addresses and a network domain name. Unlike the other resources used by diskless/dataless clients, the resolv_conf resource does not remain mounted by the client. Instead, it is copied to the /etc/resolv.conf file in the client's root directory. A resolv_conf resource is optional for both diskless and dataless clients.
tmp
resolv_conf
Initializing diskless and dataless clients: Diskless and dataless clients are not installed in the same way as standalone machines. Instead, they are initialized. Initialization of diskless and dataless clients involves several phases of operation.
Resource Allocation The resources required to support a diskless/dataless client must be allocated to the client before or during the initialization operation. If the resource is a parent directory of client directories, the allocation will create an empty subdirectory for the client. The client subdirectory is then NFS-exported to the client. The client subdirectories are not populated until the initialization is actually performed. The dkls_init and dtls_init operations are used in NIM to initialize the resources for client use. Among the operations performed during client initialization are the following: v The boot image is made available to the client for performing a network boot. v If a root resource is used instead of a shared_root resource, then the root files, which are used for machine-specific customization, are copied into the client's subdirectory in the root resource. The files that are copied into the client root directories come from the SPOT resource that has been allocated to the client. v The /tftpboot/Client.info file is created on the boot server (which is the SPOT server). This file contains information that will be needed by the client during the start-up configuration processing to successfully configure as a diskless or dataless client. The following are some of the variables defined in the Client.info file: export export export export NIM_CONFIGURATION=diskless RC_CONFIG=rc.dd_boot ROOT=Host:Client_Root_Directory SPOT=Host:SPOT_Location
Client Initialization
The paging location is set in the client's root directory in the /etc/swapspaces file. The client machine is booted over the network using standard bootp procedures for the machine type. The client obtains the boot image and begins running a mini-kernel in a file system in RAM. The client tftp's the Client.info file from the /tftpboot directory on the SPOT server. The information in the Client.info file is used to properly configure the client as a diskless or dataless machine. The dump is configured once the client is running if a dump resource is allocated to the client machine. The remote file systems are mounted from the resource servers. If the client is a dataless client, and no paging, tmp, home, or shared_home resource is allocated, then the client will create the missing file system on the local hard disk.
110
Managing software on diskless and dataless clients: The /usr and root file systems of diskless and dataless clients are resources that have been mounted from a server. Therefore, in order to install or uninstall software on a diskless or dataless client, the processing must actually occur on the resources that the clients use. The SPOT contains the directory structure for an installed /usr file system. It also contains subdirectories for the "root" parts of installed filesets. Because the SPOT contains both usr and root files, software maintenance must be performed on the SPOT in order to update the software that is running on the clients. Such actions must be performed using the NIM cust and maint operations. For more information about the cust and maint operations, see Using NIM operations on page 246. If the SPOT is currently allocated for client use, NIM will prevent software customization operations from being performed on it. This is to safeguard the SPOT from changes that may adversely affect running client machines. However, this restriction can be overridden by specifying the force option when performing the operation unless there are shared_root objects that were defined from the SPOT and are allocated for client use. When NIM is used to install software in a SPOT, the following operations are performed to manage the software for diskless and dataless clients: 1. The /usr files are installed in the SPOT. These files are automatically seen by all the clients that mount the SPOT as their /usr file systems. 2. The root files are installed in special subdirectories in the SPOT. 3. After all the filesets have been installed in the SPOT, the root files are copied to the root directories of any diskless or dataless clients that have been initialized with the SPOT and to any shared_root directory that has been defined from the SPOT. When NIM is used to uninstall software in a SPOT, the following operations are performed to manage the software for diskless and dataless clients: 1. The /usr files are removed from the SPOT. This also automatically "removes" the files from the client systems. 2. The root files of the software are removed from the client root directories and from any shared_root directory that has been defined from the SPOT. NIM also provides a sync_roots operation to perform consistency verification and correction to ensure that the client root directories, and the shared_root directories defined from the SPOT, match the root parts stored in the SPOT. Defining WPAR clients: Workload partitions are software-based partitions that provide separate regions of application space within a single instance of the operating system. System WPARs are a unique instance of AIX with associated file systems and security domains. The operations to manage the WPAR are performed by a managing system that shares its operating system kernel with the WPARs on that system. Application WPARs are isolated process environments that do not have separate operating system environments (file systems and security domains). Only system WPARs may be managed by NIM. For more information on workload partitions, see IBM Workload Partitions for AIX. Workload partitions (WPAR) are represented in NIM as the wpar machine class.A WPAR can either be managed or unmanaged. A managed WPAR is associated with the managing system that hosts the WPAR. The managing system can perform management tasks to create, start, stop, and remove the WPAR. A WPAR must have a sequenced mgmr_profile attribute. This attribute identifies the name of the NIM object for the managing system and the local WPAR name on the managing system. For example, if
Installation and migration
111
the goslin WPAR is created on the ranger system, the mgmt_profile1 attribute would be ranger goslin. Operations on the goslin WPAR (that must be run through the managing system) are executed on the ranger system. A NIM administrator can use several NIM commands to perform WPAR-system-management tasks. For more information about managing WPAR clients, see Managing WPAR clients. The following optional resources are managed by NIM to support WPAR clients: resolv_conf Contains the name-server IP addresses and a network domain name. Managing WPAR clients: WPAR clients are installed and started differently than stand-alone clients. The WPAR file systems are created on a managing system. The WPAR is started through the processes which are running on the managing system and sharing the kernel of the managing system. The file systems for the WPAR can be remote. Creating WPAR clients: A WPAR has unique file system, device, network, security, and resource characteristics. A WPAR can be created with either default or customized characteristics. These characteristics can be changed after the WPAR is created. You can use NIM resources and flags to customize the client when it is created. After a WPAR system is defined with a mgmt_profile, use the create operation to create the WPAR on the managing system:
nim -o create -a attr=value... WPARName
The following optional resources can be used to create WPAR clients: wpar_spec A WPAR specification file. For a comprehensive description of the format and permitted contents of a specification file, see the /usr/samples/wpars/sample.spec file. devexports An alternate file that can be used as the master device-exports file. This file must match the format of a device-exports file (devexports). If a devexports resource is not allocated when the WPAR is created, the /etc/wpars/devexports file on the managing system is used. secattrs The initial security-attributes file used when the WPAR is created. If a secattrs resource is not allocated at the time the WPAR is created, the /etc/wpars/secattrs file on the managing system is used. The secattrs resources are not used when creating a WPAR from a savewpar backup image. savewpar A WPAR backup image. If a WPAR backup image is allocated, this image is used to create the WPAR through the restwpar command on the managing system. The savewpar image must be at the same operating system level as the managing system. resolv_conf A resolv_conf resource represents a file that contains valid /etc/resolv.conf file entries. These entries define the Domain Name Protocol name-server information for local resolver routines. To use the /etc/resolv.conf file from the managing system, include the -r flag with the cmd_flags attribute value.
112
fb_script A script which runs when the WPAR is booted for the first time. image_data An image_data resource is a file which contains detailed logical-volume and file-system characteristics used to create a system. An image_data resource should only be used by advanced system adminstrators who need to control these settings. The following optional attributes can be used to create WPAR clients: cmd__flags Flags that pass directly to the command that is used to create the WPAR on the managing system. If a savewpar resource is allocated to the WPAR, the restwpar command is run. If savewpar resource is not allocated, the mkwpar command is run. Starting WPAR clients: Use the activate operation to start a managed WPAR client on the managing system. For more information about the activate operation, see Using the NIM activate operation on page 247. Stopping WPAR clients: Use the deactivate operation to stop a managed WPAR client on the managing system. For more information about the deactivate operation, see Using the NIM deactivate operation on page 256. Checking WPAR clients: Use the check operation to check the status of a WPAR client. For more information about the check operation, see Using the NIM check operation on page 254. Listing characteristics of WPAR clients: Use the lswpar operation to check the characteristics of a managed WPAR client on the managing system or the characteristics of WPARs on a named standalone client. For more information about the lswpar operation, see Using the NIM lswpar operation on page 261. Change characteristics of WPAR clients: Use the chwpar operation to change the characteristics of a managed WPAR client on the managing system or the characteristics of WPARs on a named stand-alone client. For more information about the chwpar operation, see Using the NIM chwpar operation on page 255. Synchronizing software on WPAR clients: Use the syncwpar operation to synchronize the software levels of a managed WPAR with its managing system or the managed WPARs on a named stand-alone client. For more information about the syncwpar operation, see Using the NIM syncwpar operation on page 266. Creating backups of WPAR clients:
Installation and migration
113
Use the define -t savewpar operation to create a backup image of a managed WPAR client. For more information about the define -t savewpar operation, see Using the NIM define operation on page 257. Installing software on WPAR clients: When a WPAR shares the /usr and /opt file systems with a managing system, the recommended WPAR default file-system configuration permits only the following software installation operations: synchronization operations and relocatable installation packages that can be installed outside of the /usr and /opt file systems. If a WPAR is configured to have detached and writable /usr file systems, use the nim -o cust operation to install software on a WPAR client or stand-alone client. For more information about the nim -o cust operation, see Using the NIM cust operation on page 255.
NIM Commands
The following references provide more information on NIM commands. The nim_master_setup command: The nim_master_setup command installs the bos.sysmgt.nim.master fileset, configures the NIM master, and creates the required resources for installation, including a mksysb system backup. The nim_master_setup command uses the rootvg volume group and creates an /export/nim file system, by default. You can change these defaults using the volume_group and file_system options. The nim_master_setup command also allows you to optionally not create a system backup, if you plan to use a mksysb image from another system. The nim_master_setup usage is as follows:
Usage nim_master_setup: Setup and configure NIM master. nim_master_setup [-a mk_resource={yes|no}] [-a file_system=fs_name] [-a volume_group=vg_name] [-a disk=disk_name] [-a device=device] [-B] [-v] -B -v Do not create mksysb resource. Enable debug output.
Default values: mk_resource = yes file_system = /export/nim volume_group = rootvg device = /dev/cd0
The nim_clients_setup command: The nim_clients_setup command is used to define your NIM clients, allocate the installation resources, and initiate a NIM BOS installation on the clients. The nim_clients_setup command uses the definitions in the basic_res_grp resource to allocate the necessary NIM resources to perform a mksysb restore operation on the selected clients. The usage for nim_clients_setup is as follows:
Usage nim_clients_setup: Setup and Initialize BOS install for NIM clients. nim_clients_setup [-m mksysb_resource] [-c] [-r] [-v] client_objects
114
-m -c -r -v
specify mksysb resource object name -OR- absolute file path. define client objects from client.defs file. reboot client objects for BOS install. Enables debug output.
Note: If no client object names are given, all clients in the NIM environment are enabled for BOS installation; unless clients are defined using the -c option. Other NIM commands reference: The AIX Version 6.1 Commands Reference set provides reference information about the NIM commands, AIX operating system commands, and commands for other licensed programs for end users, system administrators, and programmers. These books contain examples and descriptions entries are arranged in alphabetic order: v AIX Version 6.1 Commands Reference, Volume 1 v AIX Version 6.1 Commands Reference, Volume 2 v AIX Version 6.1 Commands Reference, Volume 3 v AIX Version 6.1 Commands Reference, Volume 4 of the commands and their available flags. The command contains contains contains contains commands commands commands commands ac through cx da through hy ib through mw na through rw
v AIX Version 6.1 Commands Reference, Volume 5 contains commands sa through uu v AIX Version 6.1 Commands Reference, Volume 6 contains commands va through yp For example, AIX Version 6.1 Commands Reference, Volume 3 contains reference information for the NIM lsnim command. The AIX Version 6.1 Commands Reference, Volume 4 contains reference information for the following NIM commands: v nim v v v v v v nimclient nimconfig nimdef niminit nimquery nim_update_all
115
export NSORDER=nis,bind,local
For more information on TCP/IP name resolution, refer to Networks and communication management.
The control attribute can be displayed from the NIM master by entering:
lsnim -l StandaloneClientName
116
Configuring NIM
You can use several methods for performing basic NIM operations and configuration tasks. You can perform basic NIM operations and configuration tasks using the following methods: v Web-based System Manager NIM interface v System Management Interface Tool (SMIT) v Command line Note: For tasks performed at the command line, the root user must be using ksh. Unexpected results can occur if the root user is set to another shell, such as csh.
117
3. Using the LIST option, select /dev/cd0 for the INPUT device/directory for software. 4. Specify bos.sysmgt.nim.master as the SOFTWARE to install. 5. Accept the default values for all other fields on this screen. After successful completion of this installation, exit SMIT. 6. To configure the NIM master, enter the smit nim_config_env fast path. 7. Using the LIST option, select the Primary Network Interface for the NIM Master. 8. Using the LIST option, select /dev/cd0 or /dev/rmt0 for the Input device for installation / images field. 9. If you will be supporting diskless and dataless clients, select yes at the Create Diskless/Dataless Machine Resources? field, and supply names for the resources to be created. 10. Select yes at the Remove all newly added NIM definitions and file systems if any part of this operation fails? field. This will make it easier to restart this procedure if failures occur. 11. Accept the default values for all other fields on this screen. Note: 1. Depending on the speed of your machine, creating the basic NIM resources could be a lengthy process. 2. This procedure provides the capability for much more than just configuring the NIM master and creating the lpp_source and SPOT resources. However, for this simple configuration, only a subset of the available functions will be used. Advanced NIM administrators can use the SMIT screens accessed through this procedure to create a more complex environment. 3. As you develop a better understanding of configuration tasks, you may prefer to not automatically undo all configuration when failures occur (as in step 10 in the previous procedure). Continuing from the last point of failure results in faster configuration for experienced administrators. Configuring the NIM master and creating basic installation resources from the command line: Use this procedure for configuring the NIM master and creating basic installation resources from the command line. 1. Insert the AIX Volume 1 media into the appropriate drive of the designated master machine. 2. To install the bos.sysmgt.nim.master fileset from the disk, enter: # installp -agXd /dev/cd0 bos.sysmgt.nim.master To install the bos.sysmgt.nim.master fileset from a tape, enter: # installp -agXd /dev/rmt0 bos.sysmgt.nim.master 3. To configure the NIM master with the following configuration, enter: # nimconfig -a netname=network1 -a pif_name=tr0 -a ring_speed1=16 -a platform=chrp -a netboot_kernel=mp
master host name = master1 primary network interface = tr0 ring speed = 16 platform = chrp kernel type = mp
Note: For additional attribute information, see the nimconfig command. 4. To create a file system in the rootvg volume group with 400 MB of space with a mount point of /export/lpp_source, enter:
# crfs -v jfs -g rootvg -a size=$((2000*400)) \ -m /export/lpp_source -A yes -p rw -t no \ -a frag=4096 -a nbpi=4096 -a compress=no
118
6. The lpp_source contains the installation images copied from the source device (in this example, the CD-ROM). The server of the lpp_source will be the NIM master. The images will be stored in the /export/lpp_source/lpp_source1 directory. To create the lpp_source resource named lpp_source1, enter:
# nim -o define -t lpp_source -a source=/dev/cd0 \ -a server=master -a location=/export/lpp_source/lpp_source1 \ lpp_source1
7. To create a file system in the rootvg volume group with 200 MB of space with a mount point of /export/spot, enter:
# crfs -v jfs -g rootvg -a size=$((2000*200)) \ -m /export/spot -A yes -p rw -t no \ -a frag=4096 -a nbpi=4096 -a compress=no
8. To mount the file system, enter: # mount /export/spot 9. The SPOT resource will be installed from images in the image source (in this case, the lpp_source that was created in step 6). The server of the resource will be the NIM master, and the SPOT will be stored in the /export/spot/spot1 directory. To create the SPOT resource named spot1, enter:
# nim -o define -t spot -a source=lpp_source1 \ -a server=master -a location=/export/spot spot1
10. If you are not supporting diskless and dataless clients, you do not need to continue with this procedure. If you are supporting diskless and dataless clients, create and mount a file system for their resources. To create a file system in the rootvg volume group with 150 MB of space and a mount point of /export/dd_resource, enter:
# crfs -v jfs -g rootvg -a size=$((2000*150)) \ -m /export/dd_resource -A yes -p rw -t no \ -a frag=4096 -a nbpi=4096 -a compress=no
11. To mount the file system, enter: # mount /export/dd_resource 12. Create the diskless and dataless client resources in subdirectories of the /export/dd_resource directory. Not all resources are required. Create only the resources to be used in your environment. v To create the root resource named root1, which is required for diskless and dataless clients unless a shared_root resource (for diskless clients only) is used instead, enter:
# nim -o define -t root -a server=master \ -a location=/export/dd_resource/root1 root1
v To create the shared_root resource named shared_root1, which is required for diskless clients unless a root resource is used instead, enter:
# nim -o define -t shared_root -a server=master \ -a location=/export/dd_resource/shared_root1 \ -a spot=spot1 shared_root1
v To create the paging resource named paging1 (required for diskless clients), enter:
# nim -o define -t paging -a server=master \ -a location=/export/dd_resource/paging1 paging1
119
v Performs a network boot and the client is installed by using the following command:
nim -o bos_inst -a boot_client=yes
v Opens a virtual console xterm when you use the -a open_console parameter on selected NIM operations. v Defines and uses virtual optical devices so that VIOS clients can mount ISO images from a virtual CD. Management objects are represented by Hardware Management Console (HMC), Central Electronic Complex (CEC), Integrated Virtualization Manager (IVM), Virtual Input or Output Server (VIOS) or Blade Center Management Module (BCMM) objects. Adding HMC management objects to the NIM environment: Follow the instructions to add a Hardware Management Console management object. HMC object represents a Hardware Management Console (HMC) system. To add an HMC object, the operation requires the dsm.core fileset to be installed on the NIM master. To add an HMC object from the command line, follow these steps: 1. Create an encrypted password file that contains the login ID and related password on the NIM master to access the HMC. It must be created using the dpasswd command from the dsm.core fileset. If you do not want the password displayed in clear text, exclude the -P parameter and the dpasswd command will prompt for the password.
# dpasswd -f EncryptedPasswordFilePath -U hmcLogin -P hmcPassword
2. Pass the encrypted password file in the passwd_file attribute by using the define command of the HMC.
# nim -o define -t hmc -a passwd_file=EncryptedPasswordFilePath \ -a if1=InterfaceDescription \ -a net_definition=DefinitionName \ HMCName
3. If the network object that describes the network mask and the gateway used by HMC does not exist, use the net_definition attribute. After you remove the HMC objects, the file specified by the passwd_file attribute must be removed manually.
120
Example To add an HMC object with the host name hmc1 that has the following configuration:
host name=hmc1 password file path=/etc/ibm/sysmgt/dsm/config/hmc1 network type=ethernet subnet mask=255.255..240.0 default gateway=gw1 default gateway used by NIM master=gw_maste
For additional information, see/opt/ibm/sysmgt/dsm/doc/dsm_tech_note.pdf of the dsm.core fileset. Adding CEC management objects to the NIM environment: Follow the instructions to add a Central Electronic Complex management object. A Central Electronic Complex (CEC) object is managed by a Hardware Management Console (HMC), which requires the dsm.core fileset to be installed on the NIM master. To define a CEC object, the CEC type, model, and serial number must be retrieved. You can use one of the following method to obtain the required information. Note: The following methods describe the procedure to add a CEC object from the command line: v Method 1: Use the nimquery command to retrieve information and define the CEC objects. If the HMC object is defined in NIM and the openssh.base.client fileset is installed, you can use the nimquery command to define the CEC managed by a given HMC. On the NIM master, type the following command:
# nimquery -a hmc=hcmObjectName -d
The name of each NIM CEC object that is defined by the nimquery command is in the form: cec_type cec_model_cec_serial_number v Method 2: Use the nimquery command to retrieve the information that is required to define the CEC object. On the NIM master, type:
# nimquery -a hmc=hcmObjectName -p
The CEC object is defined on the output. v Method 3: Log in to the HMC object and use the lssyscfg command to retrieve the CEC information. On the NIM master, type:
# ssh hmcLogin@hmcHost lssyscfg -r sys -F name,type_model,serial_num
Defining CEC object When you use any of these methods to define a CEC object, follow these steps: For Method 1, the CEC object is defined by the nimquery command. For Method 2 and Method 3, retrieve the information from the CEC and type the following command on the NIM master:
# nim -o define -t cec -a hw_serial=cecSerialNumber \ -a hw_type=cecType -a hw_model=cecModel \ -a mgmt_source=hmcObject cecName
121
Example To add the CEC object with HMC name hmc1 that has the following configuration:
cec hmc cec cec cec object name=cec1 object name=hmc1 type=9115 model=505 serial number=10069DA
Adding VIOS management objects to the NIM environment: Follow the instructions to add a Virtual I/O Server management object. A Virtual Input or Output Server (VIOS) object is managed by a CEC object in NIM. These operations require the dsm.core fileset to be installed on the NIM master. To add VIOS object from the command line, follow these steps: To define a VIOS object, the VIOSLPAR identifier must be retrieved. You can use one of the method to obtain the information. 1. Method 1: Use the nimquery command to retrieve the information. Define the CEC object in NIM and if the openssh.base.client fileset is installed, use the nimquery command to retrieve the VIOS attributes. On the NIM master, type:
# nimquery -a cec=cecObjectName -p
Part of the information about each LPAR of the CEC object including the Virtual I/O Server is displayed. 2. Method 2: Log into the HMC object and use the lssyscfg command to retrieve the VIOS information. For example, to use the following configuration:
cec name on the hmc = cec1 HMC login = hmcLogin HMC host name = hmcHost
3. If the network object that describes the network mask and the gateway used by the IVM does not exist, use the net_definition attribute. Note: You must manually remove the file pointed to the passwd_file attribute after you remove the IVM objects. Defining the VIOS object On the NIM master, type the following after you have retrieved the VIOS object:
# nim -o define -t vios -a platform=PlatformType \ -a netboot_kernel=NetbootKernelType \ -a if1=InterfaceDescription \ -a mgmt_source=cecObjectName -a identity=viosLPARIdentifier \ -a net_definition=DefinitionName -a ring_speed1=SpeedValue \ -a cable_type1=TypeValue -a iplrom_emu=DeviceName ViosName
122
Example To add a machine with the host name machine1 that has the following configuration:
host name=vios1 cec object name=cec1 vios lpar identifier=2 platform=chrp kernel=64 network type=ethernet subnet mask=255.255.240.0 default gateway=gw1 default gateway used by NIM master=gw_master cable type=N/A network boot capability=yes (no emulation needed)
For additional information, see the file /opt/ibm/sysmgt/dsm/doc/dsm_tech_note.pdf of the dsm.core fileset. Adding IVM management objects to the NIM environment: Follow the instructions to add an integrated virtualization manager management object. An IVM represents an Integrated Virtualization Management (IVM) logical partition (LPAR). These operations require the dsm.core fileset to be installed on the NIM master. To add an IVM object from the command line, follow these steps: 1. Create an encrypted password file that contains the login ID and related password to access the IVM object on the NIM master by using the dpasswd command from the dsm.core fileset. If you do not want the password to display in clear text, exclude the -P parameter. The dpasswd command will then prompt for the password.
# dpasswd -f EncryptedPasswordFilePath -U ivmLogin -P ivmPassword
2. Pass the encrypted password file that is created in the passwd_file attribute by using the define command of the IVM object:
# nim -o define -t ivm -a passwd_file=EncryptedPasswordFilePath \ -a if1=InterfaceDescription \ -a net_definition=DefinitionName \ ivmName
3. If the network object describing the network mask and the gateway used by the IVM object does not exist, use the net_definition attribute. Note: You must manually remove the file pointed to the passwd_file attribute after you remove the IVM objects. Example To add the IVM object with the host name ivm1, that has the following configuration:
123
host name=ivm1 password file path=/etc/ibm/sysmgt/dsm/config/ivm1 network type=ethernet subnet mask=255.255.240.0 default gateway=gw1 default gateway used by NIM master=gw_maste
For additional information, see the/opt/ibm/sysmgt/dsm/doc/dsm_tech_note.pdf file of the dsm.core fileset. Adding BCMM management objects to the NIM environment: Follow the instructions to add a blade center management module management object. A BCMM object represents a Blade Center Management Module (BCMM). These operations require the dsm.core fileset to be installed on the NIM master. To add a BCMM object from the command line, follow these steps: 1. Create an encrypted password file that contains the login ID and related password to access the BCMM object. The BCMM object is accessed on the NIM master by using the dpasswd command from the dsm.core fileset. If you do not want the password to be displayed in clear text, exclude the -P parameter. The dpasswd command prompts for the password.
# dpasswd -f EncryptedPasswordFilePath -U bcmmLogin -P bcmmPassword
2. Pass the encrypted password file in the passwd_file attribute by using the define command of the BCMM as follows:
# nim -o define -t bcmm -a passwd_file=EncryptedPasswordFilePath \ -a if1=InterfaceDescription \ -a net_definition=DefinitionName \ bcmmName
3. If the network object that describes the network mask and the gateway used by the BCMM object does not exist, use the net_definition attribute. Note: The file pointed to the passwd_file attribute must be manually removed when you remove the BCMM objects. Example To add the BCMM object with host name bcmm1 that has the following configuration:
host name=bcmm1 password file path=/etc/ibm/sysmgt/dsm/config/bcmm1 network type=ethernet subnet mask=255.255..240.0 default gateway=gw1 default gateway used by NIM master=gw_maste
124
125
Adding a client with the network information using SMIT when client is running (method B): Follow these steps to add a client with the network information using SMIT when the client is running. 1. On a system that you have chosen to be a NIM client, verify that if the bos.sysmgt.nim.client fileset is installed by typing the following: # lslpp -L bos.sysmgt.nim.client 2. If the bos.sysmgt.nim.client fileset is not installed, then install the fileset from the AIX Volume 1 CD/DVD by typing the following: # installp -acXd /dev/cd0 bos.sysmgt.nim.client 3. Enter the smit niminit fast path. 4. Supply the values for the required fields or accept the defaults. Use the help information and the LIST option to help you specify the correct values for defining your client machine. Adding a client with the network information from the command line: Follow these instructions to add a standalone NIM client to the NIM environment from the command line. To add a standalone NIM client to the NIM environment from the command line, use Method A if the client machine is not running or if the client does not have AIX installed. Method A can also be used if BOS is to be installed on the client and the client is to be network-booted manually or to initiate the installation from a force-push operation. This procedure automatically adds NIM networks when needed. To add a standalone NIM client that already has AIX installed, use Method B. If the NIM client being defined is on a network that is not currently defined in the NIM environment, the niminit command will fail. If this is the case, use Method A of this procedure to define the client on the NIM master, and then follow the steps in Method B to complete the configuration. Prerequisites v The NIM master must be configured. For more information, see Configuring the NIM master and creating basic installation resources on page 117. v You must know the subnet mask, the default gateway for the client machine, and the default gateway for the NIM master. Adding a client with the network information from the command line when client machine is not running (method A): Follow these steps to add a client with the network information from the command line when client machine is not running. On the NIM master, type:
# nim -o define -t standalone -a platform=PlatformType \ -a netboot_kernel=NetbootKernelType \ -a if1=InterfaceDescription \ -a net_definition=DefinitionName -a ring_speed1=SpeedValue \ -a cable_type1=TypeValue -a iplrom_emu=DeviceName MachineName
Example 1: To add the machine with host name machine1 with the following configuration:
host name=machine1 platform=chrp kernel=up network type=ethernet subnet mask=255.255.240.0
126
default gateway=gw1 default gateway used by NIM master=gw_master cable type=bnc network boot capability=yes (no emulation needed)
Example 2: To add the machine with host name machine2 with the following configuration:
host name=machine2 platform=chrp netboot_kernel=up network type=token ring subnet mask=255.255.225.0 default gateway=gw2 default gateway used by NIM master=gw_master ring speed=16
Note: 1. If the find_net keyword in the if attribute causes NIM to successfully match a network definition to the client definition, the net_definition attribute is ignored. 2. For more information about the attributes you can specify when defining NIM clients, see Defining NIM clients on page 105 Adding a client with the network information from the command line when client machine is running (method B): Follow these steps to add a client with the network information from the command line when the client machine is running. 1. Install the bos.sysmgt.nim.client fileset on the client machine. 2. From the machine being defined as a client, enter:
# niminit -a name=ClientDefinitionName -a master=MasterName \ -a pif_name=Interface -a platform=PlatformType \ -a netboot_kernel=NetbootKernelType -a ring_speed1=SpeedValue \ -a cable_type1=TypeValue -a iplrom_emu=DeviceName
Note: For detailed attribute information, see the niminit command. Example 1: To add the machine with host name machine1 with the following configuration:
host name=machine1 NIM masters host name=master_mac primary interface adapter=en0 platform=chrp kernel=up cable type=bnc network boot capability=yes (no emulation needed)
127
Example 2: To add the machine with host name machine2 with the following configuration:
host name=machine2 NIM masters host name=master_mac primary interface adapter=tr0 platform=chrp netboot_kernel=up ring speed1=16
Adding a client without the network information using SMIT: You can use a new remote service for defining clients in the NIM environment. Follow these directions to use this new service with SMIT. The new service is called the NIM Service Handler (NIMSH), and it runs on potential NIM clients. When you define a system using NIMSH, no information is required for defining the client object. For additional information, see Using the NIM service handler for client communication on page 146. To define NIM clients using nimquery, complete the following steps: 1. Type the fast path smitty nim_query on the NIM master. 2. Specify the hostname of the machine to query. Note: The machines must have NIMSH daemon active. 3. Select yes as the option for Adding Machine to the NIM Environment if you are adding the machine as a NIM client object. 4. Specify the new client object name. Adding a client without the network information from the command line: You can use a new remote service for defining clients in the NIM environment. Follow these directions to use the new service from the command line. The new service is called the NIM Service Handler (NIMSH), and it runs on potential NIM clients. When you define a system using NIMSH, no information is required for defining the client object. For additional information, see Using the NIM service handler for client communication on page 146. To define NIM clients using the nimquery command on the command line, type the following:
# nimquery -a host=hostname -a name=obj_name -d
For more information on defining NIM clients using NIMSH, see the nimquery command. Verifying the status of your client machine: Use the niminit command to verify the status of your client machine.
128
To verify that the niminit command completed successfully, enter the following command at the NIM client:
# nimclient -l -l MachineObjectName
If the system output to this query indicates any errors, you must validate all of your data, checking for accurate spelling, nonduplication of NIM names, and so forth, and redo the niminit operation. Be sure to coordinate this operation with the system administrator of the NIM master, and ensure that all NIM object names are unique in the entire NIM environment. Note: You cannot perform this task with Web-based System Manager or SMIT.
For example, the command to add the wpar1 WPAR client that is managed by the nim_std1 NIM stand-alone client to the NIM environment is as follows:
129
For detailed attribute information, see Diskless and dataless clients on page 108.
The adapter names for the client interfaces on the ATM network will automatically be set to at0 in the NIM database.
130
Recovering a client on an ATM network after boot failure: Follow this procedure for recovering a client on an ATM network after boot failure. Because BOS installation over ATM requires a special boot image to be written to the hard disk of the client, the original boot image on the machine will be lost. If the installation is stopped or fails before BOS is reinstalled, it will not be possible to perform a normal reboot of the client unless system maintenance is performed. By performing system maintenance, a new boot image can be created on the hard disk to allow the machine to be booted for normal use. Use the following procedure: 1. Boot the client from the CD/DVD. 2. When the installation options are displayed, select the option to perform system maintenance. 3. Make the necessary selections to access the machine's root volume group. 4. In the maintenance shell, run the following sequence of commands: a. bosboot -ad /dev/ipldevice b. BLVDISK=lslv -l hd5 | grep hdisk | head -1 |cut -d -f1 c. d. e. f. g. bootlist -m normal $BLVDISK sync sync sync reboot -q
Stopping the reboot of a client on an ATM network: Follow this procedure for stopping the reboot of a client on an ATM network. If errors are detected during the NIM bos_inst operation and the client machine has not rebooted, it is possible to stop the machine from rebooting, and then execute the sequence of commands in the above step 4 on the running system. To stop the reboot, use the following procedure: 1. List the at jobs on the machine by entering the command: at -1 The first name in the output field will be the name of the job. For example:
$ at -1 root.884205595.a Wed Jan 7 14:39:55 1998
2. To remove the at job, enter the following command: at -r name of job For example:
$ at -r root.884205595.a at file: root.884205595.a deleted
Note: The reboot can also be prevented by removing the shutdown script that the at job was instructed to run by typing:
rm/tmp/_NIM_shutdown
131
v If the software is to be installed on a SPOT resource, the server of the SPOT must be running. v The installation image to be installed on the target is available in an lpp_source resource, and a check operation was performed on the lpp_source at some point after the image was first copied there. (The check operation updates the .toc file with information about the images present in the lpp_source.) Customizing NIM clients and SPOT resources using Web-based System Manager: Follow this procedure for customizing NIM clients and SPOT resources using Web-based System Manager. 1. From the NIM container, select the Machines container. 2. In the contents area, select a target machine (master or standalone), or in the Resources container, select a target SPOT. 3. From the Selected menu, choose Install/Update Software > Install Additional Software (Custom) to display the Install Software dialog. 4. Use the dialog to complete the task. Customizing NIM clients and SPOT resources using SMIT: Follow this procedure for customizing NIM clients and SPOT resources using SMIT. The SMIT screens follow the same structure as those used for local installation operations performed on a system. When performing NIM customization operations, select the SMIT screen that most closely describes the installation you want to perform. 1. From the command line, enter the smit nim_task_inst fast path. 2. 3. 4. 5. Select Select Select Select the SMIT menu item that matches the type of installation you want to perform. a TARGET for the operation. the lpp_source that contains the installation images to be used. any other required resources.
6. In the final SMIT dialog, supply the values for the required fields or accept the defaults. Use the help information and the LIST option to help you specify the correct values. Customizing NIM clients and SPOT resources from the command line: Follow this procedure for customizing NIM clients and SPOT resources from the command line. To perform the installation operation, enter:
nim -o cust -a lpp_source=Lpp_Source -a filesets=FilesetsList \ -a installp_bundle=InstallpBundle \ -a installp_flags=InstallpFlags TargetName
You will specify the resources to use to support the installation and any additional attributes for customization. The software to be installed on the client can be specified on the command line using either the filesets attribute or by specifying an installp_bundle resource that lists the software. The default installp flags to be used to install the software are -a, -g, -Q, and -X. To specify a different set of installp flags, you can list them in the installp_flags attribute. Example 1: To install the bos.diag and bos.dosutil filesets on the client, machine1, using the lpp_source resource named lpp_source1, enter:
132
Example 2: To install software into the SPOT resource, spot1, using the lpp_source resource, lpp_source1, and the list of filesets specified in the installp_bundle resource, installp_bundle1, enter:
nim -o cust -a lpp_source=lpp_source1 \ -a installp_bundle=installp_bundle1 spot1
Note: Several other resources and attributes can be specified on the command line with the cust operation. For a complete description of the cust operation, see Using NIM operations on page 246.
Configuring the NIM master and creating resources to support diskless and dataless clients
Use this procedure only if the NIM environment is to be used exclusively for diskless and dataless client management. If the NIM environment is also to be used for installing and maintaining software on standalone machines, follow the procedure for Configuring the NIM master and creating basic installation resources on page 117. Note: This procedure produces a large amount of output, especially when creating the SPOT resource. Be sure to scan through the output to look for nonfatal errors and warnings that may not be evident from a successful return code. Prerequisites The NIM master must have at least 300 MB of available disk space. If such space is not available, see Using client machines as resource servers on page 153, and Defining an lpp_source on CD/DVD-ROM versus hard disk on page 141. Configuring the NIM master and creating resources to support diskless and dataless clients using Web-based System Manager: Follow this procedure for configuring the NIM master and creating resources to support diskless and dataless clients using Web-based System Manager. 1. Insert the AIX media into the appropriate drive of the designated master machine. 2. Start the Web-based System Manager application by typing wsm. 3. In the navigation area, select and expand the Software container. 4. While still in the navigation area, select the Installed Software container. 5. From the Software menu, choose New Software (Install/Update) > Install Additional Software. 6. In the Install Software dialog, select /dev/cd0 as the software source. 7. Specify bos.sysmgt.nim as the software to install. 8. In the navigation area, select the NIM container. 9. From the NIM menu, select Configure Environment. 10. Follow the wizard instructions to guide you through the configuration. Configuring the NIM master and creating resources to support diskless and dataless clients using SMIT: Follow this procedure for configuring the NIM master and creating resources to support diskless and dataless clients using SMIT. 1. Insert the AIX media into the media or tape drive of the designated master machine.
Installation and migration
133
2. 3. 4. 5.
To install the bos.sysmgt.nim fileset, enter the smit install_latest fast path. Using the LIST option, select /dev/cd0 or /dev/rmt0 for the INPUT device / directory for software. Specify bos.sysmgt.nim as the SOFTWARE to install. Accept the default values for all other fields on this screen. After completion of this installation, exit SMIT. 6. To configure the NIM master, enter the smit nimconfig fast path. 7. Specify a name in the Network Name field to be assigned to the NIM master's network. 8. Using the LIST option, select the Primary Network Interface for the NIM Master. Accept the default values for all other fields on this screen. After the master is configured, exit SMIT. Restart SMIT using the smit nim_mkres_dd_name_server fast path. When prompted, select the NIM master as the server of the client resources. Select yes in the Create a new SPOT? field, because there is not a SPOT currently defined in your environment. Using the LIST option, select /dev/cd0 or /dev/rmt0 as the input device for installation images. Specify a name in the SPOT Name field. Specify names for the other resources to be created in the NIM environment. If a name is not specified, the resource will not be created. Select yes at the Remove all newly added NIM definitions and file systems if any part of this operation fails? field. This will make it easier to restart this procedure if failures occur. Accept the default values for all other fields on this screen. Note: In most NIM environments, the SPOT will already exist to support base operating system installation operations on standalone machines. In such environments, it is not necessary to create a new SPOT.
Configuring the NIM master and creating resources to support diskless and dataless clients from the command line: Follow this procedure for configuring the NIM master and creating resources to support diskless and dataless clients from the command line. 1. Insert the AIX media into the media or tape drive of the designated master machine. 2. If installing from a tape, skip to step 5. To create a mount point for the CD, type: mkdir /cdfs. 3. To create a cdrom file system, type: crfs -v cdrfs -p ro -d'cd0' -m'/cdfs' 4. To mount the disk, type: mount /cdfs 5. To install the bos.sysmgt.nim fileset from the disk, type: installp -agX -d /cdfs/usr/sys/ inst.images bos.sysmgt.nim. or to install the bos.sysmgt.nim fileset from a tape, type: installp -agX -d /dev/rmt0 bos.sysmgt.nim 6. If installing from CD/DVD, to unmount the cdrom file system, type: unmount /cdfs 7. To configure the NIM master using the nimconfig command, type:
nimconfig -a attr1=value1 \ -a attr2=value2 \ ...
134
Note: For additional attribute information, see the nimconfig command. 8. To create a file system in the rootvg volume group with 200 MB of space and a mount point of /export/spot, enter:
crfs -v jfs -g rootvg -a size=$((2000*200)) \ -m /export/spot -A yes -p rw -t no \ -a frag=4096 -a nbpi=4096 -a compress=no
10. The SPOT resource will be installed from images in the image source (in this example, the CD). The server of the resource will be the NIM master, and the SPOT will be stored in the /export/spot/spot1 directory. To create the SPOT resource, enter:
nim -o define -t spot -a source=/dev/cd0 -a server=master \ -a location=/export/spot spot1
11. To create a file system in the rootvg volume group with 150 MB of space and a mount point of /export/dd_resource, enter:
crfs -v jfs -g rootvg -a size=$((2000*150)) \ -m /export/dd_resource -A yes -p rw -t no \ -a frag=4096 -a nbpi=4096 -a compress=no
12. To mount the file system, enter: mount /export/dd_resource 13. Create the diskless and dataless client resources in subdirectories of the /export/dd_resource directory. Not all resources are required. Create only the resources to be used in your environment. To create the root resource named root1, which is required for diskless and dataless clients unless a shared_root resource (for diskless clients only) is used, enter:
nim -o define -t root -a server=master \ -a location=/export/dd_resource/root1 root1
To create the shared_root resource named shared_root1, which is required for diskless clients unless a shared_root resource is used, enter:
# nim -o define -t shared_root -a server=master \ -a location=/export/dd_resource/shared_root1 \ -a spot=spot1 shared_root1
To create the paging resource named paging1 (required for diskless clients), enter:
nim -o define -t paging -a server=master \ -a location=/export/dd_resource/paging1 paging1
135
Note: a. The file systems created for the NIM resources are not required, but they can be beneficial for storage management. b. For more information about NIM resources, see Using NIM resources on page 217.
Note: For detailed attribute information, see the descriptions of diskless and dataless clients in NIM machines on page 104.
136
Example 1: To add the diskless client with the host name diskless1 to the NIM environment with the following configuration:
host name=diskless1 platform=rspc kernel=up network type=ethernet subnet mask=255.255.240.0 default gateway=gw1 default gateway used by NIM master=gw_master cable type=bnc network boot capability=yes (no emulation needed)
Example 2: To add the dataless client with the host name dataless1 to the NIM environment with the following configuration:
host name=dataless1 platform=rs6k netboot_kernel=up network type=token ring subnet mask=255.255.225.0 default gateway=gw2 default gateway used by NIM master=gw_master ring speed=16 network boot capability=no (use emulation on a diskette)
Note: If the find_net keyword in the if attribute causes NIM to successfully match a network definition to the client definition, the net_definition attribute is ignored.
137
4. Use the dialog to uninitialize and, if desired, deallocate all resources from the client. Uninitializing diskless and dataless machines using SMIT: Follow this procedure for uninitializing diskless and dataless machines using SMIT. 1. To uninitialize diskless and dataless machines, enter the smit nim_dd_uninit fast path. 2. Select the Target. 3. If you want to remove all root data, change the DEALLOCATE Resources field to yes. Uninitializing diskless and dataless machines from the command line: Follow this procedure for uninitializing diskless and dataless machines from the command line. 1. To uninitialize the client machine, enter the following on the NIM master:
nim -F -o reset ClientName
2. To deallocate all resources and remove root data, enter the following on the NIM master:
nim -o deallocate -a subclass=all ClientName
138
Note: The multithreaded option alone will not allow more machines to be installed simultaneously. The multithreaded option should be used in conjunction with global export of NIM resources, distribution of NIM resources throughout the NIM environment, and a network environment capable of handling a large volume of throughput. Tuning client-request processing using SMIT: You can tune client-request processing from the SMIT interface. Type the SMIT fast path:
smit nim_tune_nimesis
Tuning client-request processing using the Web-based System Manager: You can tune client-request processing using the Web-based System Manager. To tune client-request processing from the NIM application: 1. From the NIM menu, select Advanced Configuration > Tune Client Request Processing. 2. Use the dialog to complete the task. Tuning client-request processing from the command line: You can tune client-request processing from the command line. The max_nimesis_threads attribute can be used to tune client-request processing. To enable the multithreaded nimesis daemon, set a value to the max_nimesis_threads attribute on the NIM master using the following command:
nim -o change -a max_nimesis_threads=value master
Note: The range for the value attribute above is 20 to 150. To disable the multithreaded nimesis daemon, set a null value to the max_nimesis_threads attribute on the NIM master:
nim -o change -a max_nimesis_threads="" master
139
The SMIT screen will prompt you to first back up your NIM database before unconfiguring the NIM master. Unconfiguring the NIM master from the command line: Follow this procedure for unconfiguring the NIM master from the command line. Enter nim -o unconfig master.
Example: To convert the /usr file system on the machine, client1, to a SPOT named usrspot using lppsource1 as the source for additional installation images, enter:
nim -o define -t spot -a server=client1 -a location=/usr \ -a source=lpp_source1 usrspot
140
After you convert a /usr file system to a SPOT, it is not recommended that you use the installp command to install or maintain software on the machine serving the SPOT. The diskless and dataless clients and network boot images associated with the SPOT will not be updated by the installp command unless it is invoked using NIM's cust or maint operations. If you need to use the installp command to install or maintain software on a /usr SPOT server, use the following steps: 1. 2. 3. 4. Ensure that all NIM operations on the server and any clients associated with the SPOT are complete. Deallocate the SPOT from all standalone clients. Run the installp command. Run the check operation on the SPOT after the installp command has completed:
nim -o check -F usrSPOTName
Note: The -F flag is required for rebuilding the boot images. 5. If this SPOT is being used to serve diskless or dataless clients, resynchronize all diskless and dataless clients with the SPOT after the installp command completes by issuing the nim command with the sync_roots operation for the /usr SPOT:
nim -o sync_roots usrSPOTName nim -o check -F usrSPOTName
The cust and maint operations must be used to manage software installed on non-/usr SPOTs.
Example: A SPOT named spot1 was created on the NIM master in the /export/spot directory. Later, the NIM database became corrupted and has to be rebuilt. The SPOT files are still on the machine, but the SPOT must be redefined to NIM using the following command:
/usr/lpp/bos.sysmgt/nim/methods/m_mkspot -o -a server=master \ -a location=/export/spot -a source=no spot1
141
Follow this procedure for defining an lpp_source on CD/DVD-ROM versus hard disk using the Web-based System Manager. 1. Select the Resources container. 2. From the Resources menu, select New Resource. 3. Follow the wizard instructions to create the lpp_source resource. Note: You can also define an lpp_source resource through the Configure NIM wizard, both when you are configuring your environment, and after configuration. Defining an lpp_source on CD/DVD-ROM versus hard disk using SMIT: Follow this procedure for defining an lpp_source on CD/DVD-ROM versus disk using SMIT. 1. Mount the CD/DVD as a CDROM file system. The installation images can be found in the /usr/sys/inst.images directory under the mount point of the CDROM file system. 2. To define the lpp_source using the directory of install images, enter the smit nim_mkres fast path. 3. Specify the name of the machine with the CD/DVD-ROM as the Server. 4. Specify CD_MountPoint/ usr/sys/inst.images as the location of the lpp_source, and leave the Source field blank. Defining an lpp_source on CD/DVD-ROM versus hard disk from the command line: Follow this procedure for defining an lpp_source on a CD/DVD-ROM versus a disk from the command line. 1. Mount the CD/DVD as a CDROM file system. The installation images can be found in the /usr/sys/inst.images directory under the mount point of the CDROM file system. 2. Define the lpp_source using the directory of install images for the location attribute. Do not specify a value for the source attribute, since an existing set of images will be used. With the CD/DVD mounted at /cdfs on the NIM master, to define an lpp_source named cd_images, enter:
nim -o define -t lpp_source -a server=master \ -a location=/cdfs/usr/sys/inst.images cd_images
The secondary adapter stanza file is processed by the nimadapters command and turned into a file that contains one stanza for each secondary adapter or interface on the NIM client. During a BOS installation,
142
NIM processes this information and configures the secondary adapters.. If a secondary adapter is already configured in the requested manner, NIM does not reconfigure the secondary adapter. Note: Before using the nimadapters command, you must configure the NIM master. For information on configuring the NIM master, see Configuring the NIM master and creating basic installation resources on page 117. Secondary adapter files: This is an example a secondary adapter file.
# Set default values. default: machine_type = secondary subnet_mask = 255.255.240.0 network_type = en media_speed = 100_Full_Duplex # Define the machine "lab1" # Take all defaults and specify 2 additional attributes. # Unlike the case of the client definitions that are input to the # nimdef command, the secondary adapter definition includes at least # one required field that cannot be defaulted. lab1: netaddr = 9.53.153.233 location = P2-I1/E1 # Change the default "media_speed" attribute. default: media_speed = 100_Half_Duplex
# define the machine "test1" # Take all defaults and include a comment. test1: comments = "This machine is a test machine." # define a machine with a VIPA interface that uses interfaces en2 and en3. lab2: machine_type = secondary interface_type = vi interface_name = vi0 netaddr = 9.53.153.235 subnet_mask = 255.255.255.0 secondary_hostname = lab3 interface_attributes = "interface_names=en2,en3" # define a machine with an etherchannel adapter that uses the adapters at # the following location codes P1-I4/E1 and P1/E1 lab4: machine_type = etherchannel interface_type = en interface_name = en2 netaddr = 9.53.153.237 subnet_mask = 255.255.255.0 multiple_physloc = P1-I4/E1,P1/E1 # define a machine with an etherchannel adapter that uses the # ent2 and ent3 adapters and uses mode 8023ad. lab6: machine_type = etherchannel interface_type = en interface_name = en2 netaddr = 9.53.153.239 subnet_mask = 255.255.255.0 adapter_attributes = "adapter_names=ent2,ent3 mode=8023ad"
143
Using secondary adapter file keywords: The secondary adapter file uses these keywords to specify machine attributes. Using required adapter attributes: The following attributes are required for configuring adapters. machine_type = secondary | etherchannel | install Specifying the machine_type attribute as secondary clearly distinguishes the nimadapters input from nimdef input. If a secondary adapter's file is mistakenly passed to the nimdef command, the error can be detected. Stanzas with a machine_type of install are ignored. netaddr Specifies the network address for the secondary adapter. interface_type = en | et | sn | ml |vi Specifies the type of network interface. The network interface can be en (ethernet interface), et (ethernet interface), sn (switch network interface), ml (multi-link interface), or vi (virtual interface). This attribute replaces the deprecated network_type attribute. subnet_mask Specifies the subnet mask used by the secondary adapter. Note: Configuring a secondary adapter on the same subnet as another adapter does not provide failover. Packets alternate between adapters when they are configured on the same subnet. If one of the adapters fails, the other adapter will not take over the failed adapter's workload, and the subnet will have connectivity problems. Commands, such as mount, might fail if this occurs. Using optional attributes: The following attributes are optional for configuring adapters. adapter_attributes Blank-separated list of physical adapter attributes and values. For example, Attribute1=Value1 Attribute2=Value2. To see the list of attributes that can be set for the requested adapter, run the command lsattr -E -l AdapterName. interface_attributes Blank-separated list of interface attributes and values. For example, Attribute1=Value1 Attribute2=Value2. To see the list of attributes that can be set for the requested interface, run the command lsattr -E -l InterfaceName. This attribute replaces the deprecated attributes attribute. cable_type Specifies the cable type (optional if network_type is en or et). comments Specifies a comment to include in the secondary adapter definition. Enclose the comment string in quotation marks. interface_name Specifies the name of the network interface for the secondary adapter (for example, en1, sn0, ml0). Do not specify both location and interface_name. Note: The value of the interface_name attribute must be consistent with the value of the network_type attribute. location Specifies the physical location of the adapter corresponding to this network interface. Do not specify both the location and the interface_name attributes.
144
Note: Except for the multilink pseudo-device, use of the location attribute is highly recommended. If the location attribute is not specified and the user adds multiple adapters or adds an adapter at the same time that the operating system is reinstalled, the adapter and network interface names might be reassigned by the operating system in unexpected ways. multiple_physloc Specifies the physical adapters to associate with an interface when you use an etherchannel or VIPA stanza. media_speed Specifies the media speed (optional if the network_type attribute's value is either en or et). secondary_hostname Host name to save in the /etc/hosts file with the netaddr attribute. This host name is not set using the hostname command or the uname -S command. Working with secondary adapter file rules: The format of the secondary adapter file must comply with these rules. v After the stanza header, follow attribute lines of the form: Attribute = Value v If you define the value of an attribute multiple times within the same stanza, only the last definition is used. v v v v If you use an invalid attribute keyword, that attribute definition is ignored. Each line of the file can have only one header or attribute definition. More than one stanza can exist in a definition file for each machine host name. Each stanza for a machine host name represents a secondary adapter definition on that NIM client. No two secondary adapter definitions for the same machine host name can have the same location or interface_name. There should be only one definition per adapter or interface on a given NIM client.
v If the stanza header entry is the default keyword, this specifies to use that stanza for the purpose of defining default values. v You can specify a default value for any secondary adapter attribute. However, the netaddr and secondary_hostname attributes must be unique. Also, the location and interface_name attributes must be unique on a NIM client. v If you do not specify an attribute for a secondary adapter but define a default value, the default value is used. v You can specify and change default values at any location in the definition file. After a default value is set, it applies to all definitions that follow. v To turn off a default value for all following machine definitions, do not set the attribute value in a default stanza. v To turn off a default value for a single machine definition, do not set the attribute value in the machine stanza. v You can include comments in a client definition file. Comments begin with the number sign (#). v When parsing the definition file for header and attribute keywords and values, tab characters and spaces are ignored. Note: During a nim -o bos_inst or nim -o cust operation, if NIM examines the configuration data on the client and determines that a secondary adapter is already configured with precisely the attributes requested in the adapter_def resource, this secondary adapter is not reconfigured. Working with secondary adapter definitions: Follow these procedures to work with NIM secondary adapter definitions. 1. To preview the secondary_adapters.defs client definition file, type:
nimadapters -p -f secondary_adapters.defs adapter_def
Installation and migration
145
2. To add the NIM secondary adapters described in the secondary_adapters.defs secondary adapters definition file, type:
nimadapters -d -f secondary_adapters.defs adapter_def
3. To define the NIM secondary adapters for the pilsner client, type:
nimadapters -d \ -a info="en,P2-I1/E1,N/A,1000_Full_Duplex,9.53.153.233,255.255.254.0" \ -a client=pilsner adapter_def
4. To remove the NIM secondary adapter definitions for a client called pilsner from the my_adapter_def resource, type:
nimadapters -r -a client=pilsner my_adapter_def
5. To remove the NIM secondary adapter definitions for clients defined in the file secondary_adapters.defs, type:
nimadapters -r -f secondary_adapters.defs my_adapter_def
6. To remove all the NIM secondary adapter definitions from the my_adapter_def resource, type:
nimadapters -r my_adapter_def
Troubleshooting secondary adapter file stanza errors: A secondary adapter stanza causes an error under any of the following conditions. v The host name that was used in the stanza header for the definition cannot be resolved. v A required attribute is missing. v An invalid value was specified for an attribute. v An attribute mismatch occurs. For example, if the network_type attribute's value is not set to either en or et, you cannot specify cable_type=bnc or media_speed=1000_Full_Duplex. v The stanza contains both a location attribute and an interface_name attribute. v Secondary adapter definitions occur multiple times for the same adapter location and the same host name. v Secondary adapter definitions occur multiple times for the same interface_name and the same host name. If a secondary adapter stanza is incorrect, the errors are reported, the stanza is ignored, and the following input is processed without regard to the incorrect stanza.
146
Basic NIMSH functions are explained. NIMSH service port: The client daemon has two ports registered with the Internet Assigned Numbers Authority (IANA) for use during network communication. These ports are referred to as the primary and secondary ports. The nimsh client daemon listens on these ports for requests initiated by the master using the TCP protocol. The primary port listens for service requests on reserved port 3901. When a request is accepted, the primary port is used for stdin and stdout requests. The stderr requests are redirected to secondary port 3902. This behavior is similar to auxiliary connections in rcmd(). This implementation allows the NIM master connection to stay consistent with current support of client connections through the rsh command. Using a reserved secondary port in NIMSH allows firewall administrators to write firewall rules for accepting incoming connections on privileged ports from the secondary port. These rules can have the requirement that the originating socket address (hostname : secondary port) comes from a trusted source. NIMSH system resource control: NIMSH is registered with the System Resource Controller (SRC). The SRC group name is nimclient and the subsystem defined is NIMSH. The client daemon is started by SRC when the configuration routine is run using the nimclient command. NIMSH authentication process: Service requests from the communicating host (the NIM master) will build packets with the following data for authentication. v Hostname of NIM client v CPUID of NIM client v CPUID of NIM master v Return port for secondary (stderr) connection v Query flag (used to obtain registration information) When a connection to the primary port is received, the service handler obtains peer information from the connecting socket. The source port must be in the privileged port space (only root user can bind to privileged ports). Using the privileged port space ensures that the originating user has the root UID. The return port number is retrieved and connected to from the secondary port, which is the reserved port in /etc/services. The following sections describe the phases of the authentication process: query flag set When the query flag is set to 1, the service handler treats the incoming request as a client discovery for information. The client service handler obtains all relevant information necessary for defining itself as a NIM client and returns the information to the requesting NIM master then terminates the connection. The following data is returned when query flag is set: v Default hostname (value obtained from inet0) v v v v Default route (value obtained from inet0) Network address (value obtained from hostname) Subnet mask (value obtained from hostname) Network interface (value obtained from hostname)
147
Method request If the query flag is not set, then a request for service (NIM operation) is pushed by the NIM master. The service handler validates the method request as follows: 1. 2. 3. 4. 5. Verify hostname of NIM master is the client's recognized master hostname. Check the client CPUID passed, it should match the client's machine ID. Check the master CPUID passed, it should match the master's machine id stored in memory. Verify the operation passed is a method in the path /usr/lpp/bos.sysmgt/nim/methods. Check for cryptographic authentication setting.
For additional security, NIMSH supports push disablement. Push disablement disables method requests unless the request is a response to an active NIM client call being processed by the client's NIM master. When push disablement is set, NIMSH does not process any NIM operations controlled by the NIM master. Client control (nimclient commands) is the only way to perform NIM operations on the client when push disablement is set. Logging NIMSH operations: The NIM client daemon logs data in the /var/adm/ras/nimsh.log file during its operation. The log is used only for debug purposes. Setting up NIMSH: You can configure existing standalone clients to use NIMSH as the communication protocol. You can also define clients using NIMSH as the service option. For more information on doing this, see Adding a Standalone NIM Client to the NIM Environment. Preparing to set up NIMSH: These prerequisites must be met prior to configuring NIMSH. v The NIM client must already be configured (see Adding standalone clients to the NIM environment on page 125). v The client and the client's NIM master must have one of the following installed: AIX 5.2 with the 520007 Technology Level (or later) AIX 5.3 with the 530003 Technology Level (or later) AIX 6.1 Setting up NIMSH using SMIT: Follow this procedure for configuring existing standalone clients with NIMSH using SMIT. Complete the following steps: 1. Type the smitty nim_config_services fast path on the NIM client. 2. Select nimsh as the Communication Protocol used by client. Setting up NIMSH from the command line: Rename the /etc/niminfo file to another name on the NIM client. You also can delete it, but renaming it allows you to keep a copy if you should need it for some reason. Use the niminit command to register the client with the NIM master.
# niminit -a name=<client_name> -a master=<master_name> -a connect=nimsh
148
If OpenSSL is installed on the NIM client and NIMSH is configured as the communication protocol, type the following command on the NIM client to disable cryptographic authentication with NIMSH. Type the following command on the NIM client:
# nimclient -C
Enabling cryptographic authentication: You can configure existing standalone clients to use the NIMSH communication protocol with SSL enabled. NIM supports OpenSSL versions 0.9.6e and higher. When OpenSSL is installed, NIMSH uses SSL-encrypted certificates for authenticating the connecting NIM master. Preparing to enable cryptographic authentication: These prerequisites must be met to enable cryptographic authentication. v The NIM master must already be configured for SSL authenticating within the NIM Environment. For more information, see Using NIM to install clients configured with SSL authentication on page 172. v The client must be at AIX 5.3 or AIX 6.1. v The client's NIM master must be at AIX 5.3 or AIX 6.1. Enabling cryptographic authentication using SMIT: Complete these steps to configure existing standalone clients to use NIMSH communication protocol with SSL enabled. 1. Type the smitty nim_config_services fast path on the NIM client. 2. Select nimsh as the Communication Protocol used by client. 3. Select enabled as the option for Enabling Cryptographic Authentication. 4. Select yes as the option for Installing Secure Socket Layer Software, if OpenSSL is not installed on the client. 5. Specify the absolute path for the RPM package or select the lpp_source resource that contains the OpenSSL RPM package. Enabling cryptographic authentication from the command line: Complete these steps to configure existing standalone clients to use the NIMSH communication protocol with SSL enabled from the command line. v If OpenSSL is installed on the NIM client and NIMSH is configured as the communication protocol, type the following command:
# nimclient -c
If OpenSSL is not installed on the NIM client, complete the following steps 1. Install OpenSSL if not already installed. It can be installed from the base media using the installp command, geninstall command, or smitty command. 2. Type the following command on the NIM client after OpenSSL is installed:
# nimclient -c
Enabling a secondary port: This procedure describes how to configure existing standalone clients to use the NIMSH communication protocol with a secondary port option enabled.
149
By default, NIMSH uses a reserved port for returning stderr output during command execution. The default setting allows administrators to specify a specific port for opening behind a firewall, but it can cause performance issues when several connections are attempted in a short amount of time. When TCP connections are closed, the closing sockets enter TIME_WAIT state. The length of time for this state may last up to 240 seconds depending on system settings. The secondary port option allows you to specify any specific range of ports to cycle through during NIMSH operation. For firewalls, administrators might want to open a specific range on the firewall, and then for each machine on the internal network, ensure that the port range on the machine coincides with the open range on the firewall. When changing the NIMSH secondary port, you should choose a range of ports outside of the range used for system services. Try using ports 49152 through 65535. Preparing to enable a secondary port: These prerequisites must be met to enable a secondary port. v The NIM client must already be configured (see Adding a Standalone NIM Client to the NIM Environment). v The client must have AIX 5.3 or AIX 6.1 installed. v The client's NIM master must have AIX 5.3 or AIX 6.1 installed. Enabling a secondary port from SMIT: Complete these steps to configure existing standalone clients to use the NIMSH communication protocol with a secondary port range. 1. Type the smitty nim_config_services fast path on the NIM client. 2. Select nimsh as the Communication Protocol used by client. 3. Specify a start value for the secondary port number. 4. Specify an increment value for the secondary port range. Enabling a secondary port from the command line: Complete these steps to configure existing standalone clients to use the NIMSH communication protocol with a secondary port range from the command line. 1. Edit the /etc/environment file. 2. Add the variable NIM_SECONDARY_PORT=60000:5, to use ports 60000 - 60005 within NIMSH. 3. Use the desired nimclient command option to restart the NIMSH daemon. Disabling push operations using NIMSH: NIM clients can prohibit the NIM master from allocating resources or initiating operations by disabling push operations. Although master control is disabled, the client can still control the allocation of NIM resources and the initiation of NIM operations. To configure existing standalone clients to use NIMSH communication protocol with NIM master control disabled, see Disabling master push permissions in the NIM environment on page 199. Verifying NIMSH startup: Run this command to verify that the NIMSH daemon is enabled on the client.
# lssrc -s nimsh
150
For Ethernet:
nim -o change -a ifseq_no=NetworkObjectName AdapterHostName \ AdapterHardwareAddress -a cable_typeseq_no=Type master
For FDDI:
nim -o change -a ifseq_no=NetworkObjectName AdapterHostName \ AdapterHardwareAddress master
151
Note: If you do not know the name of the NIM network to which the interface is attached or if a network corresponding to the interface has not been defined, use the find_net keyword and net_definition attribute as described in Defining NIM clients on page 105. In the example, the following command is run:
nim -o change -a if2=Network2 srv1_ent 0 -a \ cable_type2=bnc master
With this syntax, another if attribute is created for the master, which tells NIM that the master has an Ethernet interface that uses a host name of srv1_ent, that the Ethernet adapter's hardware address is 0 (not used), and that the master connects to the Network2 network object. To display detailed information about the master which will now show the if2 attribute, enter:
lsnim -l master
Creating network boot images to support only the defined clients and networks
You can create network boot images in the /tftpboot directory using the Web-based System Manager, SMIT, or the command line interface. When a SPOT resource is created, network boot images are created in the /tftpboot directory to support certain NIM operations. NIM only creates network boot images to support clients and networks that are defined. If a new client is defined and there is no network boot image already created for it in the environment, then the boot image will not be created until either the SPOT is allocated to the client or a check operation is performed on the SPOT to rebuild the boot images. When clients are removed from the NIM environment, boot images are not automatically removed. To remove boot images that are no longer necessary for a NIM environment, the list of required machine-network combinations in the environment must be rebuilt. The boot images must then be rebuilt for each SPOT. Creating network boot images to support defined clients and networks using Web-based System Manager: Follow this procedure to limit or enable boot image creation according to whether the interface is defined. 1. From the NIM menu, select Advanced Configuration > Control Network Boot Image Creation. 2. Use the dialog to complete the task.
152
Creating network boot images to support defined clients and networks using SMIT: Use this method to manage the creation of boot images from the SMIT interface. Type the SMIT fast path:
smit nim_control_boot
Creating network boot images to support defined clients and networks from the command line: Use this information to manage network boot images to support only the defined clients and networks. To rebuild the list of machine types and networks that must be supported by network boot images in the NIM environment, perform a change operation on the NIM master with the if_discover=yes attribute:
nim -o change -a if_discover=yes master
To rebuild network boot images from a SPOT, perform a check operation on the SPOT with the force option:
nim -Fo check spot_name
If an administrator prefers to have NIM always create all possible boot images from the SPOT resources, the if_prebuild=yes attribute can be specified on the master:
nim -o change -a if_prebuild=yes master
To return NIM to the behavior of creating only the boot images that are required for the environment, remove the if_prebuild attribute from the master by setting it to "no":
nim -o change -a if_prebuild=no master
153
3. In the displayed dialog fields, supply the correct values for the resource options. Be sure to specify the name of the client machine for the Server of the Resource field. Use the help information or the LIST option to help you. All attributes specified when the resource is defined (such as location and source) must be local to the server machine. Using client machines as resource servers from the command line: Follow this procedure for using client machines as resource servers from the command line. To create a resource on a NIM client, specify the client's NIM name for the server attribute when defining the resource. Example: To create an lpp_source resource named images2 from a CD on the NIM client machine, client_mac1, in the /resources/images directory, enter:
nim -o define -t lpp_source -a server=client_mac1 \ -a location=/resources/images -a source=/dev/cd0 images2
154
Using concurrency control from the command line: The concurrent and time_limit attributes can be used in conjunction with the bos_inst, cust and alt_disk_install operations. For example, to have the bos.games fileset installed on only five machines from the client group tmp_grp at one time, enter the following command:
nim -o cust -a lpp_source=lpp_source1 -a filesets=bos.games \ -a concurrent=5 tmp_grp
In this example, to BOS install only 10 clients from tmp_grp, using lpp_source, lpp_source1, and SPOT, spot1, with no other installs permitted after three hours have elapsed, enter the following command:
nim -o bos_inst -a lpp_source=lpp_source1 -a spot=spot1 \ -a concurrent=10 -a time_limit=3 tmp_grp
Note: The concurrency controlled operation can complete and leave the group in one of the following states: v All machines install successfully. v Some machines may fail the installation. v If the time_limit attribute was used, time may have expired before the installation operation was complete. In the first situation, the group will revert to the state prior to the operation. In the second and third situations, the group will be left in a state that indicates some machines have completed and some have not. Problems with failing machines should be investigated. At this point, the user can continue with the machines that did not complete by rerunning the command on the group. Alternatively, the user can "reset" the group, which will set the group back to its state prior to the concurrency controlled operation.
Prerequisites
The Virtual I/O Server installation media is required. In addition, the following system requirements must be met: v A system running AIX 5.3 with 5300-03 or higher which contains a file system with at least 700 MB available. v A logical partition of type Virtual I/O Server containing an Ethernet adapter connected to an active network for installing the Virtual I/O Server. For information about creating logical partitions, see Creating the Virtual I/O Server logical partition and partition profile. v A storage controller containing at least 16 GB of disk space. After the prerequisites have been met, follow these steps to use NIM to migrate the Virtual I/O Server: 1. Insert the Virtual I/O Server Migration DVD into the DVD drive. 2. Run the installios command without any arguments to start the installation wizard. The installios wizard then guides you through the process of filling-out the necessary information to start an installation on the Virtual I/O Server or on an Integrated Virtualization Manager. If you run installios on a NIM client, then you are prompted for the location to the bos.sysmgt.nim.master fileset. The NIM client is then configured as a NIM master. For more information about command-line usage of installios, see the installios command. The installios setup process creates the following NIM resources to start the migration installation:
Installation and migration
155
v v v v v
v Client definition If you are installing the Virtual I/O Server logical partition, and if Secure Shell (SSH) and credentials have been configured on the NIM master, then the partition is network-booted from the HMC to begin the installation. If you are installing the Virtual I/O Server logical partition without SSH, or if you are installing the Integrated Virtualization Manager, then go to step 3. 3. On the system on which the Virtual I/O Server software will be installed, boot the Virtual I/O Server logical partition or the Integrated Virtualization Manager into System Management Services (SMS) mode by following these steps: v To boot the Virtual I/O Server logical partition into SMS: a. On the HMC, right-click the partition to open the menu. b. Click Activate. The Activate Partition menu opens with a selection of partition profiles. Be sure the correct profile is highlighted. c. Select the Open a terminal window or console session check box to open a virtual terminal (vterm) window. d. Click (Advanced...) to open the advanced options menu. e. f. g. h. i. j. For the Boot mode, select SMS. Click OK to close the advanced options menu. Click OK. A vterm window opens for the partition. In the vterm window, select Setup Remote IPL (Initial Program Load). Select the network adapter that will be used for the installation. Select IP Parameters.
k. Enter the client IP address, server IP address, and gateway IP address. Optionally, you can enter the subnet mask. After you have entered these values, press Esc to return to the Network Parameters menu. l. Select Ping Test to ensure that the network parameters are properly configured. Press Esc twice to return to the Main Menu. m. From the Main Menu, select Select Boot Options. n. Select Select Install/Boot Device. o. Select Network. p. Select the network adapter whose remote IPL settings you previously configured. q. When prompted for Normal or Service mode, select Normal. r. When asked if you want to exit, select Yes. v To boot the Integrated Virtualization Manager into SMS: a. Begin with the machine turned off. b. Switch on the machine, and as icons begin to appear from left to right on the bottom of your display, press F1. Note: If the last icon is displayed before pressing F1, then you get the normal mode boot list instead of SMS, so try again. c. The System Management Services menu opens. Select Utilities. d. From the System Management Services Utilities menu, select Remote Initial Program Load Setup.
156
e. From the Network Parameters panel, select IP Parameters. f. Set or change the displayed values so they are correct for your client system. Specify the IP address of the following: The client machine you are booting in the client address field. Your NIM master server in the server address field. Your client's gateway in the gateway address field. Your client's subnet mask in the subnet mask field. g. After you specify the addresses, press Enter to save the addresses and continue. h. The Network Parameters window opens. Select the Ping option. i. Select the network adapter to be used as the client's boot device. j. Verify that the displayed addresses are the same as the addresses you specified for your boot device. If the addresses are incorrect, press Esc until you return to the main menu. Then, go back to step e. If they are correct, continue with k. k. If the addresses are correct, press Enter to perform the ping test. The ping test might take several seconds to complete. l. If the ping test fails, verify that the addresses are correct, and analyze the network problem. If the ping test is successfull, press Enter to acknowledge the success message. m. Press Esc until you return to the System Management Services menu. n. From the System Management Services menu, choose the Select Boot Devices option. o. Select the network adapter to be used for the network boot from the list of displayed bootable devices After the migration installation is complete, the Virtual I/O Server logical partition or the Integrated Virtualization Manager is booted to its configuration prior to the migration installation. To remove all the NIM resources that were created from the installios setup process, run the installios command with the -u flag. If the installios command fails to perform the cleanup, run installios -u and specify the -f flag to force NIM to reset and deallocate resources to the client. The NIM environment still exists, but all resources and directory structures created from the installios wizard are removed. If, however, you want to unconfigure NIM, or uninstall the bos.sysmgt.nim.master fileset and return the NIM master to a NIM client (if it was configured from a NIM client), specify installios -u with a -U flag.
Using installation images to install the base operating system on a NIM client
Using installation images to install the base operating system (BOS) on a NIM client is similar to the traditional BOS installation from a tape or media device because the BOS image is installed from the installation images in the lpp_source resource. Prerequisites v The NIM master must be configured, and lpp_source and SPOT resources must be defined. See Configuring the NIM master and creating basic installation resources on page 117. v The NIM client to be installed must already exist in the NIM environment. To add the client to the NIM environment, see Adding standalone clients to the NIM environment on page 125. Using installation images to install the base operating system on a NIM client using Web-based System Manager: With this procedure you can use installation images to install the base operating system on a NIM client using Web-based System Manager.
Installation and migration
157
1. 2. 3. 4.
From the NIM container, select the Machines container. In the contents area, select a target standalone machine for the installation. From the Selected menu, choose Install Operating System. If the client machine being installed is not already a running, configured NIM client, NIM will not automatically reboot the machine over the network for installation. If the client was not rebooted automatically, initiate a network boot from the client to install it. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot.
5. After the machine boots over the network, the display on the client machine will begin prompting for information about how to configure the machine during installation. Specify the requested information to continue with the installation. Note: To perform a nonprompted installation, follow the instructions in Performing a nonprompted BOS installation on page 159 to complete the prerequisite tasks. Using installation images to install the base operating system on a NIM client using SMIT: Follow this procedure to install use installation images to install the base operating system a NIM client using SMIT. 1. To install BOS on a NIM client using an rte installation, type smit nim_bosinst from the NIM master. 2. Select the TARGET for the operation. 3. Select rte as the installation TYPE. 4. Select the SPOT to use for the installation. 5. Select the LPP_SOURCE to use for the installation. 6. In the displayed dialog fields, supply the correct values for the installation options or accept the default values. Use the help information and the LIST option to help you. 7. If the client machine being installed is not already a running, configured NIM client, NIM will not automatically reboot the machine over the network for installation. If the client was not rebooted automatically from SMIT, initiate a network boot from the client to install it. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. 8. After the machine boots over the network, the display on the client machine will begin prompting for information about how the machine should be configured during installation. Specify the requested information to continue with the installation. Note: To perform a nonprompted installation, follow the instructions in Performing a nonprompted BOS installation on page 159 to complete the prerequisite tasks. Using installation images to install the base operating system on a NIM client from the command line: Follow this procedure for using installation images to install the base operating system on a NIM client from the command line. 1. To initiate the bos_inst operation, type:
# nim -o bos_inst -a source=rte -a lpp_source=Lpp_Source \ -a spot=SPOTName -a accept_licenses=yes -a boot_client=yes/no ClientName
Specify the resources to be used to support the installation and any additional options for customizing the installation. To perform a simple rte installation, specify the lpp_source and SPOT resources. If the client machine being installed is not already a running, configured NIM client, NIM will not automatically reboot the machine over the network for installation. A network boot must be performed manually on the machine. If that is the case, supply the boot_client=no attribute to the bos_inst command. If the boot_client attribute value is not specified, it defaults to boot_client=yes.
158
2. If the client was not rebooted automatically, initiate a network boot from the client to install it. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. 3. After the machine boots over the network, the display on the client machine will begin prompting for information about how to configure the machine during installation. Specify the requested information to continue with the installation. Example The client machine, machine1, is not a running, configured NIM client. You should specify boot_client=no. To install the client using the lpp_source named lpp_source1 and the SPOT named spot1, enter:
# nim -o bos_inst -a source=rte -a lpp_source=lpp_source1 \ -a spot=spot1 -a accept_licenses=yes -a boot_client=no machine1
Note: a. The steps to perform an rte installation are almost identical to the steps to perform other types of BOS installations. The main difference is that rte must be specified in the source attribute of the nim bos_inst command. b. To perform a nonprompted installation, follow the instructions in Performing a nonprompted BOS installation to complete the prerequisite tasks. c. For a complete description of the different ways that a BOS installation can be customized by NIM, see Using the NIM bos_inst operation on page 249.
159
2. Follow the wizard instructions to create a bosinst_data resource. The wizard creates a basic bosinst.data file, which can be used "as is" or can be enhanced according to sample files. For a sample bosinst.data file, see bosinst.data file nonprompted network installation on page 54. To do a nonprompted installation, the bosinst_data resource must be created first. Performing a nonprompted BOS installation using SMIT: You can perform a nonprompted BOS installation using SMIT. 1. On the NIM master or any running NIM client, create a bosinst.data file that describes how a machine should be configured during a BOS installation. For a sample bosinst.data file, see Using the bosinst.data file on page 54. 2. To define the bosinst.data file as a bosinst_data resource in the NIM environment, enter the smit nim_mkres fast path. 3. Select bosinst_data from the list of resource types displayed on your screen. 4. Supply the values for the required fields. Use the help information and the LIST option to help you specify the correct values for defining your bosinst_data resource. 5. After the bosinst_data resource has been defined, follow the procedures for performing an rte or mksysb installation on a standalone machine. Be sure to specify the bosinst_data resource to use during the installation. Performing a nonprompted BOS installation from the command line: You can perform a nonprompted BOS installation from the command line. 1. On the NIM master or any running NIM client, create a bosinst.data file that describes how a machine should be configured during a BOS installation. Note: To accept license agreements for software to be installed during the BOS installation, specify -a accept_licenses=yes on the nim -o bos_inst command. 2. To define the bosinst.data file as a bosinst_data resource, enter:
# nim -o define -t bosinst_data -a server=ServerName \ -a location=LocationName NameValue
Using the server attribute, specify the name of the machine where the bosinst.data file is located. Using the location attribute, specify the full path name of the bosinst.data file that is to be used as a resource. 3. After the bosinst_data resource has been defined, follow the normal procedure for performing an rte or mksysb installation on standalone machines. Be sure to specify that the bosinst_data resource be used for the installation. For example, to perform a nonprompted rte installation of machine1 using the lpp_source1, spot1, and bosinst_data1 resources, enter:
# nim -o bos_inst -a source=rte -a lpp_source=lpp_source1 \ -a spot=spot1 -a accept_licenses=yes -a bosinst_data=bosinst_data1 \ machine1
Using a mksysb image to install the base operating system on a NIM Client
A mksysb installation restores BOS and additional software to a target from a mksysb image in the NIM environment. For a complete description of different ways to customize a BOS installation using NIM, see Using the NIM bos_inst operation on page 249. The mksysb images enable you to clone one system image onto multiple target systems. The target systems might not contain the same hardware devices or adapters, require the same kernel (uniprocessor or multiprocessor).
160
Because NIM configures TCPIP at the end of an installation, it is recommended that a bosinst_data resource be allocated for cloning mksysb installations with the RECOVER_DEVICES field set to no. This will prevent the BOS installation process from attempting to configure the devices as they were on the source machine of the mksysb image. Note: A NIM customization that affects the ODM database is not reflected after a mksysb installation on the same system. Restoring the mksysb backup causes the ODM to be restored to the state it was in when the backup was created. In AIX, devices are not recovered if the mksysb image that is being installed was not created on the same system. Attention: If the system you have cloned is using OpenGL or graPHIGS, there may be some device filesets from these LPPs that must be installed after a clone. OpenGL and graPHIGS have graphics adapter-specific filesets, so if you cloned onto a system with a different graphics adapter, you will need to create a bundle as follows:
echo OpenGL.OpenGL_X.dev > /usr/sys/inst.data/user_bundles/graphic_dev.bnd echo PEX_PHIGS.dev >> /usr/sys/inst.data/user_bundles/graphic_dev.bnd
You can allocate this bundle when you install the mksysb, and the device filesets will be installed automatically if OpenGL and graPHIGS are in your lpp_source. Prerequisites v The NIM master must be configured, and SPOT and mksysb resources must be defined. See Configuring the NIM master and creating basic installation resources on page 117. v The NIM client to be installed must already exist in the NIM environment. To add the client to the NIM environment, see Adding standalone clients to the NIM environment on page 125. v The mksysb must be available on the hard disk of the NIM master or a running NIM client, or the mksysb image is created during this procedure from either the NIM master or a running NIM client. v The SPOT and mksysb resources should be at the same level of AIX when used for NIM BOS installations. v Many applications, particularly databases, maintain data in sparse files. A sparse file is one with empty space, or gaps, left open for future addition of data. If the empty spaces are filled with the ASCII null character and the spaces are large enough, the file will be sparse, and disk blocks will not be allocated to it. This situation creates an exposure in that a large file will be created, but the disk blocks will not be allocated. As data is then added to the file, the disk blocks will be allocated, but there may not be enough free disk blocks in the file system. The file system can become full, and writes to any file in the file system will fail. It is recommended that you either have no sparse files on your system or that you ensure you have enough free space in the file system for future allocation of the blocks. Using a mksysb image to install the base operating system on a NIM Client using Web-based System Manager: Follow this procedure for using a mksysb image to install the base operating system on a NIM Client using Web-based System Manager. 1. In the NIM container, select the Resources container. 2. From the Resources menu, select New > Resource > New Resources. 3. Use the wizard to complete the task. Note: To perform a nonprompted installation, follow the instructions in Performing a nonprompted BOS installation on page 159 to complete the prerequisite tasks.
Installation and migration
161
Using a mksysb image to install the base operating system on a NIM Client using SMIT: Follow this procedure for using a mksysb image to install the base operating system on a NIM Client using SMIT. 1. If the mksysb resource has already been created, skip to step 6. Otherwise, to create the mksysb resource, enter the smit nim_mkres fast path. 2. Select mksysb from the list of resource types that can be defined. 3. In the displayed dialogs, supply the values for the required fields. Use the help information and the LIST option to help you specify the correct values for defining your mksysb resource. 4. If the mksysb image does not exist, create it by supplying the values for the fields under System Backup Image Creation Options. Note: If the mksysb image already exists as a file on the hard disk of the NIM master or client, no additional information is needed to define your mksysb resource. 5. Upon successful completion of this task, exit SMIT. 6. To use the mksysb resource to install a NIM client, enter the smit nim_bosinst fast path. 7. Select a TARGET for the operation. 8. Select mksysb as the installation TYPE. 9. Select the MKSYSB to use for the installation. 10. Select the SPOT to use for the installation. 11. In the displayed dialog fields, supply the correct values for the installation options or accept the default values. Use the help information or the LIST option to help you. 12. Run the SMIT dialog to install the NIM client. 13. If the client machine being installed is not already a running, configured NIM client, NIM will not automatically reboot the machine over the network for installation. If the client was not rebooted automatically from SMIT, initiate a network boot from the client to install it. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. 14. After the machine boots over the network, the display on the client machine will begin prompting for information about how to configure the machine during installation. Specify the requested information to continue with the installation. Note: To perform a nonprompted installation, follow the instructions in Performing a nonprompted BOS installation on page 159 to complete the prerequisite tasks. Using a mksysb image to install the base operating system on a NIM client from the command line: Follow this procedure for using a mksysb image to install the base operating system on a NIM client from the command line. 1. If the mksysb resource has already been created, skip to step 2. To create the mksysb resource, enter:
nim -o define -t mksysb -a server=ServerName \ -a location=LocationName -a mk_image=yes \ -a source=SourceMachine ResourceName
Specify the server name and location of the mksysb image. The mk_image and source attributes are used to create the mksysb image if it does not already exist. For a complete description of all the options that can be specified when creating a mksysb resource, see Using a mksysb resource on page 235. Example 1: To define a mksysb resource, mksysb_res1, from an existing mksysb image located in /export/backups/client_mksysb on the master, enter:
162
Example 2: To create a mksysb image of the client machine, client1, in /export/resources/new_mksysb on the master, and to define a mksysb resource, mksysb_res2, enter:
nim -o define -t mksysb -a server=master \ -a location=export/resources/new_mksysb -a mk_image=yes \ -a source=client1 mksysb_res2
Specify the resources to be used to support the installation and any additional options for customizing the installation. To perform a simple mksysb installation, specify the mksysb and SPOT resources. If the client machine being installed is not already a running, configured NIM client, NIM will not automatically reboot the machine over the network for installation. A network boot must be performed manually on the machine. If that is the case, supply the boot_client=no attribute to the bos_inst command. If the boot_client attribute value is not specified, it defaults to boot_client=yes. 3. If the client was not rebooted automatically, initiate a network boot from the client to install it. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. 4. After the machine boots over the network, the display on the client machine will begin prompting for information about how to configure the machine during installation. Specify the requested information to continue with the installation. Example 3: To perform a mksysb installation using the mksysb, mksysb1, an optional lpp_source, lpp_source1, and the SPOT, spot1, on client machine, machine1, which is not a running, configured NIM client, enter:
nim -o bos_inst -a source=mksysb -a mksysb=mksysb1 \ -a lpp_source=lpp_source1 -a spot=spot1 -a boot_client=no machine1
Note: 1. The steps to perform a mksysb installation are almost identical to the steps to perform other types of BOS installations. The main differences are that mksysb must be specified in the source attribute of the nim bos_inst command, and a mksysb resource must be allocated for the operation. 2. To perform a nonprompted installation, follow the instructions in Performing a nonprompted BOS installation on page 159 to complete the prerequisite tasks. Using an ios_mksysb image to install the base operating system on a NIM client from the command line: Procedure for using an ios_mksysb image to install the base operating system on a NIM client from the command line. 1. If the ios_mksysb resource has already been created, skip to step 2. To create the ios_mksysb resource, enter:
nim -o define -t ios_mksysb -a server=ServerName \ -a location=LocationName -a mk_image=yes \ -a source=SourceMachine ResourceName
Specify the server name and location of the ios_mksysb image. The mk_image and source attributes are used to create the ios_mksysb image if it does not already exist. For a complete description of all the options that can be specified when creating a ios_mksysb resource, see Using an ios_mksysb resource on page 230. Example 1:
163
To define a ios_mksysb resource, ios_mksysb_res1, from an existing ios_mksysb image that is located in the /export/backups/client_ios_mksysb on the master, enter:
nim -o define -t ios_mksysb -a server=master \ -a location=/export/backups/client_ios_mksysb ios_mksysb_res1
Example 2: To create a ios_mksysb image of the client system, client1, in /export/resources/new_ios_mksysb on the master, and to define an ios_mksysb resource, ios_mksysb_res2, enter:
nim -o define -t ios_mksysb -a server=master \ -a location=export/resources/new_ios_mksysb -a mk_image=yes \ -a source=client1 ios_mksysb_res2
Specify the resources to be used to support the installation and any additional options for customizing the installation. To perform a simple mksysb installation, specify the ios_mksysb and SPOT resources. If the client system being installed is not already a running, configured NIM client, NIM will not automatically reboot the system over the network for installation. A network boot must be performed manually on the system. If that is the case, supply the boot_client=no attribute to the bos_inst command. If the boot_client attribute value is not specified, it defaults to boot_client=yes. 3. If the VIOS or IVM client was not rebooted automatically, initiate a network boot from the client to install it. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. 4. After the system boots over the network, the display on the client system will begin prompting for information about how to configure the system during installation. Specify the requested information to continue with the installation. 5. If the client was not rebooted automatically, initiate a network boot from the client to install it. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. 6. After the system boots over the network, the display on the client system will begin prompting for information about how to configure the system during installation. Specify the requested information to continue with the installation. Example 3: To perform a mksysb installation using the ios_mksysb1, mksysb1, an optional lpp_source, lpp_source1, and the SPOT, spot1, on client system, machine1, which is not a running, configured NIM client, enter:
nim -o bos_inst -a source=mksysb -a ios_mksysb=ios_mksysb1 \ -a lpp_source=lpp_source1 -a spot=spot1 -a boot_client=no vios1
Note: 1. The steps to perform an mksysb installation are almost identical to the steps to perform other types of BOS installations. The main differences are that mksysb must be specified in the source attribute of the nim bos_inst command, and an ios_mksysb resource must be allocated for the operation. 2. To perform a non-prompted installation, follow the instructions in Performing a nonprompted BOS installation on page 159 to complete the prerequisite tasks. Using an ios_mksysb image to install the base operating system on a NIM Client using SMIT: Follow this procedure for using an ios_mksysb image to install the base operating system on a NIM VIOS management client using SMIT. 1. If the ios_mksysb resource has already been created, skip to step 6. Otherwise, to create the ios_mksysb resource, enter the smit nim_mkres fast path.
164
2. Select ios_mksysb from the list of resource types that can be defined. 3. In the displayed dialogs, supply the values for the required fields. Use the help information and the LIST option to help you specify the correct values for defining your ios_mksysb resource. 4. If the ios_mksysb image does not exist, create it by supplying the values for the fields under System Backup Image Creation Options. Note: If the ios_mksysb image already exists as a file on the hard disk of the NIM master or client, no additional information is needed to define your ios_mksysb resource. Upon successful completion of this task, exit SMIT. To use the ios_mksysb resource to install a NIM client, enter the smit nim_mgmt_obj_op fast path. Select a TARGET for the operation. Select bos_inst for the operation to perform. In the displayed dialog MKSYSB field, select the ios_mksysb resource.
5. 6. 7. 8. 9.
10. In the displayed dialog SPOT field, select the SPOT to use for the installation. The SPOT must be one created from the ios_mksysb resource. 11. In the displayed dialog fields, supply the correct values for the installation options or accept the default values. Use the help information or the LIST option to help you. 12. Run the SMIT dialog to install the NIM VIOS client. 13. If the VIOS client machine being installed is not already a running, configured NIM VIOS client, NIM will not automatically reboot the machine over the network for installation. If the client was not rebooted automatically from SMIT, initiate a network boot from the client to install it. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. 14. After the machine boots over the network, the display on the client machine will begin prompting for information about how to configure the machine during installation. Specify the requested information to continue with the installation. Note: To perform a non-prompted installation, follow the instructions in Performing a nonprompted BOS installation on page 159 to complete the prerequisite tasks.
165
2. In the contents area, select the standalone machine for the alternate disk installation. 3. From the Selected menu, choose Alternate Disk Installation > Clone the Rootvg to an Alternate Disk or Install Mksysb on an Alternate Disk. 4. Use the dialog to finish the installation. Installing to an alternate disk on a NIM Client using SMIT: Follow this procedure for installing to an alternate disk on a NIM Client using SMIT. 1. Enter the smit nim_alt_mksysb fast path from the NIM master. 2. Select the Target Machine or Target Group to Install. 3. Enter the Target Disk or Disks on the Target machine. 4. Accept the default installation options, or supply different ones in the displayed dialog fields. Use the help information and the LIST option for guidance. 5. The alternate disk installation will be initiated on the client, and progress can be seen with the lsnim command (smit lsnim). If the Reboot when complete? option is set to yes and the Phase to execute is all or includes Phase 3, the client will reboot from the newly installed disk when the alt_disk_install command is complete. 6. To clone a disk onto a NIM client's alternate disk, enter the smit nim_alt_clone fast path from the NIM master. Installing to an alternate disk on a NIM Client from the command line: The alt_disk_install command is initiated on the target system, and progress is shown with the lsnim command. A log kept on the target system, /var/adm/ras/alt_disk_inst.log, contains progress messages and any error or warning messages that might occur. The /var/adm/ras/nim.alt_disk_install log will contain debug information, if requested. Installing mksysb on an alternate disk: Use this code for initiating the alt_disk_install operation. Initiate the alt_disk_install operation by entering:
nim -o alt_disk_install -a source=mksysb -a mksysb=Mksysb \ -a disk=diskname(s) ClientName
Specify the mksysb resource to be used and any additional options for customizing the installation. To perform a simple alternate disk mksysb install, specify the source, mksysb, and disk resources. Note: For detailed information about the mksysb resources, see Using a mksysb resource on page 235. Cloning the rootvg to an alternate disk: Use this command for cloning the rootvg to an alternate disk. To clone a disk onto a NIM client's alternate disk, enter:
nim -o alt_disk_install -a source=rootvg -a disk=diskname(s) ClientName
Specify any additional options for customizing the installation. Installing to an alternate disk on a NIM client from the command line - examples:
166
Here is an examples of performing an installation to an alternate disk on a NIM client from the command line. The client machine machine1 is a running system with a disk, hdisk2, that is not currently occupied by a volume group. v To install this disk with a mksysb resource named 51mksysb enter:
nim -o alt_disk_install -a source=mksysb -a mksysb=51mksysb \ -a disk=hdisk2 machine1
167
If you are installing the Virtual I/O Server logical partition, and if Secure Shell (SSH) and credentials have been configured on the NIM master, then the partition is network-booted from the Hardware Management Console (HMC) to begin the installation. If you are installing the Virtual I/O Server logical partition without SSH, or if you are installing the Integrated Virtualization Manager, then go to step 3. 3. On the system on which the Virtual I/O Server software will be installed, boot either the Virtual I/O Server logical partition or the Integrated Virtualization Manager into System Management Services (SMS) mode by following these steps: v To boot the Virtual I/O Server logical partition into SMS: a. On the HMC, right-click the partition to open the menu. b. Click Activate. The Activate Partition menu opens with a selection of partition profiles. Be sure the correct profile is highlighted. c. Select the Open a terminal window or console session check box to open a virtual terminal (vterm) window. d. e. f. g. h. Click (Advanced...) to open the advanced options menu. For the Boot mode, select SMS. Click OK to close the advanced options menu. Click OK. A vterm window opens for the partition. In the vterm window, select Setup Remote IPL (Initial Program Load).
i. Select the network adapter that will be used for the installation. j. Select IP Parameters. k. Enter the client IP address, server IP address, and gateway IP address. Optionally, you can enter the subnet mask. After you have entered these values, press Esc to return to the Network Parameters menu. l. Select Ping Test to ensure that the network parameters are properly configured. Press Esc twice to return to the Main Menu. m. From the Main Menu, select Select Boot Options. n. o. p. q. Select Select Install/Boot Device. Select Network. Select the network adapter whose remote IPL settings you previously configured. When prompted for Normal or Service mode, select Normal.
r. When asked if you want to exit, select Yes. v To boot the Integrated Virtualization Manager into SMS: a. Begin with the machine turned off. b. Switch on the machine, and as icons begin to appear from left to right on the bottom of your display, press F1. Note: If the last icon is displayed before pressing F1, you get the normal mode boot list instead of SMS. Repeat steps a and b. c. The System Management Services menu opens. Select Utilities. d. From the System Management Services Utilities menu, select Remote Initial Program Load Setup. e. From the Network Parameters panel, select IP Parameters. f. Set or change the displayed values so they are correct for your client system. Specify the IP address of the following, then press Enter: The client machine you are booting in the client address field. Your NIM master server in the server address field. Your client's gateway in the gateway address field.
168
Your client's subnet mask in the subnet mask field. g. When the Network Parameters window opens, select the Ping option. h. Select the network adapter to be used as the client's boot device. i. Verify that the displayed addresses are the same as the addresses you specified for your boot device. If the addresses are incorrect, press Esc until you return to the main menu. Then, go back to Step e. If they are correct, continue with Step j. j. Press Enter to perform the ping test. The ping test might take several seconds to complete. k. If the ping test fails, verify that the addresses are correct, and analyze the network problem. If the ping test is successful, press Enter to acknowledge the success message. l. Press Esc until you return to the System Management Services menu. m. From the System Management Services menu, choose the Select Boot Devices option. n. Select the network adapter to be used for the network boot from the list of displayed bootable devices. After the installation is complete, the Virtual I/O Server logical partition or the Integrated Virtualization Manager is ready to be configured and managed. To remove all of the NIM resources that were created from the installios setup process, run the installios command with the -u flag. If the installios command fails to perform the cleanup, run installios -u and specify the -f flag to force NIM to reset and deallocate resources to the client. The NIM environment remains, but all of the resources and directory structures created from the installios wizard are removed. If, however, you want to unconfigure NIM, or to uninstall the bos.sysmgt.nim.master fileset and return the NIM master back to a NIM client if it was configured from a NIM client, specify installios -u with a -U flag. You can also install a Virtual I/O Server or an Integrated Virtualization Manager through the SMIT interface. 1. To access the SMIT interface to the installios command, run smitty installios on a NIM master. 2. You will have two options: to Setup for Virtual I/O and Integrated Virtualization Manager Installation and Cleanup after Virtual I/O and Integrated Virtualization Manager Installation, where Configure Client as Master for Virtual I/O and Integrated Virtualization Manager Installation is the only available option on a NIM client. 3. Complete the required fields from the installios wizard to invoke the installios command that will setup the installation or perform a cleanup. Installing the Virtual I/O Server using ios_mksysb: You can use the following procedures to install the Virtual I/O Server (VIOS) into environments managed by the Hardware Management Console (HMC) or the Integrated Virtualization Manager using the ios_mksysb resource. Prerequisites v The Network Installation Management (NIM) master must be configured, and SPOT and mksysb resources must be defined. See Configuring the NIM master and creating basic installation resources on page 117. The mksysb resource can be created from a VIOS NIM management client. Note: The mksysb on the VIOS media is split into multiple files due to the file size constraint when you generate the mksysb file for the VIOS media. The split mksysb files need to be joined together when copied from media to the hard disk of the system. The following example shows the VIOS media mounted to the /mnt directory.
cat /mnt/nimol/ioserver_res/mksysb \ /mnt/nimol/ioserver_res/mksysb2 > /export/mksysb/vio_mksysb
Installation and migration
169
The mksyb file may be split across multiple VIOS media. In that case, the mksysb file must be concatenated into a single file using the cat command describe in the example above from a multivolume VIOS media. Define the mksysb file as a NIM ios_mksysb resource. The mksysb image can also be created from the VIOS by using the following command:
nim -o define -t ios_mksysb
See Defining a mksysb resource on page 235. v The NIM VIOS client to be installed must already exist in the NIM environment. To add the client to the NIM environment, see Adding VIOS management objects to the NIM environment on page 122. v The SPOT resource must be created from the ios_mksysb resource. To do this, define the SPOT resource, by specifying a ios_mksysb NIM object as the value for the source attribute. v The bosinst_data resource can be copied from the VIOS media and defined as a NIM bosinst_data resource or defined as new. To define a new bosinst_data resource, copy the bosinst.data template from a system at /usr/lpp/bos.inst/bosinst.template and set RECOVER_DEVICES=Default. If the ios_mksysb resource is to be deployed to a specific disk then the target_disk_data section of the bosinst.data must be populated with disk information from the VIOS server. For more information about the bosinst.data, consult the documentation about the bosinst.data file. v An ios_mksysb installation restores the VIOS and the Base Operation System to a Virtual I/O Server. v The ios_mksysb images enable you to clone one system image onto multiple target systems.
170
For more information on installing and configuring Kerberos 4, see the SP Administration Guide (GC233897). Using NIM to install clients configured with Kerberos 5 authentication: In AIX 4.3.3 and later, NIM can be used to install machines in an environment configured for Kerberos 5 authentication. Clients configured for Kerberos 5 authentication will contain a $HOME/.k5login file for the root user. This file will contain an entry that specifies what host token is required to allow remote command execution. This entry uses the following form:
hosts/hostname/self@cell
The NIM master and all secure clients must have DCE installed and configured at a level greater than or equal to 2.2.1. If secure clients will be reinstalled with BOS, the authentication methods on the NIM master should be set for both Kerberos 5 and Standard UNIX. Because the client will not have DCE or Kerberos 5 configured and running after the BOS is installed. NIM will therefore have to rely on standard rhosts to remotely execute commands on the client until it can be configured with Kerberos 5 and made into a secure client. If only software customization and maintenance will be performed, the NIM master must have its authentication methods set to match those of the clients. To manage secure clients, the master will need authentication methods set to include Standard UNIX. Using NIM to install clients with NIM resources that are exported with Kerberos authentication: You can install NIM clients with NIM resources that are set with Kerberos security export. This method provides added protection for NIM resources by preventing access from unacceptable hosts. To use this authentication method, the NIM master must be configured to be the Kerberos server. Do the following: 1. Set up and configure the Kerberos server by using one of the following methods. Note: To avoid a base image installation failure, you must run one of the following commands. v If the NIM master is not configured as a Kerberos server, use the sample script that NIM provides by running the following command:
/usr/samples/nim/krb5/config_rpcsec_server u <user> -p <password>
The config_rpcsec_server script runs the /usr/lpp/bos.sysmgt/nim/methods/nimcrypt u <user> -p <password> command to setup the credentials for Kerberos authentication. v If the NIM master is configured as a Kerberos server, run the nimcrypt command:
/usr/lpp/bos.sysmgt/nim/methods/nimcrypt u <user> -p <password>
2. Set the nfs_domain attribute for the nim master by using one of the following methods. v Run the following command from the command line:
nim o change a nfs_domain=austin.ibm.com master
3. Set the NIM resources attributes for nfs_sec to krb5 and nfs_vers to 4 as follows:
nim o change a nfs_sec=krb5 a nfs_vers=4 <resource_object>
Note: Setting nfs_sec=krb5 for the SPOT resource is not supported for the install environment.
Installation and migration
171
After the nfs_sec and nfs_vers attributes are set for the NIM resources and a NIM network installation is initialized, NIM uses NFS to export the location for the resource set with krb5. The client uses Kerberos authentication and mounts NIM resources over Kerberos security. Installing a client with a Kerberos protected mount is only supported for NIM installations where source=rte or source=mksysb. A Kerberos installation will only work for NIM resources that reside on the NIM master. After a client authenticates with the Kerberos server, there is usually a time lease for the exported location to be active. This time lease defaults to 24 hours. If an installation exceeds 24 hours because of a system or network error, the installation will hang. If a hang occurs, troubleshoot the installation and restart the installation process by rebooting the client to network boot. The time lease can also be extended.
172
Follow this procedure for using NIM to install clients configured with SSL authentication using SMIT. To configure the NIM environment for SSL authentication, complete the following steps: 1. Type the fast path smitty nim_ssl on the NIM master. 2. Select enabled as the option for Enabling Cryptographic Authentication. 3. If OpenSSL is not installed on the client, select yes as the option for Installing Secure Socket Layer Software. 4. If OpenSSL is selected for install, specify the absolute path for the RPM package or select the lpp_source resource which contains the OpenSSL RPM package. Using NIM to install clients configured with SSL authentication from the command line: Follow this procedure to configure the NIM environment for SSL authentication from the command line. 1. If OpenSSL is installed on the NIM master, type:
# nimconfig -c
2. If OpenSSL is not installed on the NIM master, complete the following steps: v Locate the AIX Toolbox for Linux Applications media. v Install the OpenSSL RPM package using geninstall. For additional information on using geninstall, see Add Open Source Applications to Your AIX System. v After OpenSSL is installed on the NIM master, type:
# nimconfig -c
173
where FilesetName is the name of a single fileset (or a name with the * wildcard character), and ObjectName is the name of the machine or SPOT which is the target of the lppchk operation. Valid lppchk_flags are defined as follows:
-f -c -v -l -u -mn Fast check (file existence, file length) Checksum verification Fileset version consistency check (default) File link verification Note: Only one of the flags -f, -c, -v, or -l may be specified. Update inventory (only valid with -c or -l) Controls detail of messages. n equals 1 to 3, where 3 is the most verbose.
For example, to perform the lppchk operation while verifying checksums for all filesets on the machine named Standalone1, enter the following:
nim -o lppchk -a lppchk_flags="-c" Standalone1
Performing a network installation of an IBM eServer p5 over a virtual I/O Ethernet adapter
To perform a network installation on a IBM eServer p5 partition over a virtual I/O Ethernet adapter, the NIM master must be configured to receive packets from the partition adapter's default virtual local area network (VLAN). One of the following configurations must exist: v The master has a virtual I/O Ethernet adapter configured to receive packets from the partition's default VLAN, if the master is also a partition. v A gateway exists that can route packets between the master's interface and the partition's default VLAN. v The master has a VLAN interface associated with a physical Ethernet adapter that is configured to receive packets from the partition's default VLAN through the I/O Server, if the IBM eServer p5 has an I/O Server partition. If you are performing a broadcast bootp install, then either you must have either the first or the third configuration. For additional information on configuring and using VLANs, see TCP/IP local area network adapter cards.
v The source of the BOS image is a SPOT, and the LPs value for the single paging entry is set to the default value of 16. The default paging size is calculated from the smaller value of optimal_ps and recommended_ps where: v RAM = amount of memory on the target system measured in megabytes (MB).
174
v optimal_ps = maximum between RAM and (0.2 size of rootvg) v IF CDE (Common Desktop Environment) is installed, recommmended_ps = amount of RAM is less than 32 MB, then recommended_ps = 3 * RAM amount of RAM is 32 MB or more, then recommended_ps = RAM + 64 MB v IF CDE (Common Desktop Environment) is not installed, recommmended_ps = amount of RAM is less than 32 MB, then recommended_ps = 2 * RAM amount of RAM is 32 MB or more, then recommended_ps = RAM + 32 MB The default paging space set by this process is never greater than 512 MB.
v Generic Network boot support is provided for Ethernet, Token-Ring, and FDDI. Unlike other network adapters, ATM adapters cannot be used to boot a machine. Therefore, installing a machine over an ATM network requires special processing. See Using NIM with ATM networks on page 130. The Generic network type is used to represent all other network types where network boot support is not available. For clients on Generic networks, NIM operations that require a network boot, such as bos_inst and diag, are not supported. However, non-booting operations, such as cust and maint, are allowed. Diskless and dataless clients cannot be associated with Generic networks, because they inherently rely on network boot capability.
175
Specifies the IP address of the network being defined. If the network address is not known, see Determining a network's IP address. Specifies the subnet mask for the network. Specifies the type of network being defined. Valid values are atm, tok, ent, fddi, and generic.
-a routing=Value ...
This attribute can be used to add a default route or static route. To add a default route, specify default for Value 1. Then, specify the default gateway for the network in Value 2. Leave Value 3 blank. For more information on adding and changing routes, see Defining NIM routes on page 177, Establishing a default NIM route between networks on page 179, and Establishing a static NIM route between networks on page 180. Displays information for debugging. Use verbose=5 to show maximum detail.
-a verbose=Value
It is also possible to define NIM networks automatically when client machines are defined. To do this, use the find_net and net_definition attributes when defining the client. For more information, see NIM machines on page 104.
176
177
Master
Bridge
Ethernet Segment
Client
Heterogeneous Network
Figure 1. Heterogeneous Network. This illustration shows a single IP network in which the master server uses its token-ring connection and a bridge to communicate with its client on an Ethernet segment.
Because a single NIM network object is used to represent one network, the other_net_type attribute is reserved for a different type of interface that can exist in a network. The other_net_type attribute can be added to the definition of a network object. When present in a network definition, the other_net_type attribute tells NIM that this logical network uses a bridge to connect the other network type to the network type that was specified when the object was defined. When you define a machine object to be connected to a network object, NIM checks to see if the network has any other_net_type attributes. If so, NIM requires that the fourth field, which is usually optional, in the if attribute, be specified. This field specifies the logical name of the client's network adapter. The following example defines a network object that has a bridge joining a Token-Ring and an Ethernet segment:
nim -o define -t tok -a net_addr=129.35.129.0 \ -a snm=255.255.240.0 -a other_net_type1=ent b905net lsnim -l b905net class type net_addr snm other_net_type1 Nstate prev_state = = = = = = = network tok 129.35.128.0 255.255.240.0 ent ready for use information is missing from this objects def>
The other_net_type attribute requires a sequence number because a network could be composed of all three types of interfaces linked by bridges. When you define a client's interface that is physically connected to an Ethernet segment joined with a Token-Ring network using a bridge (with master being on the Token-Ring side), you must supply the fourth field:
nim -o define -t standalone -a if1=find_net mymac 08005ac9430c \ ent -a cable_type1=bnc mymac
178
Follow this procedure for adding another network type to a NIM network using Web-based System Manager. 1. In the NIM Network container, double-click on a network. The General page of the properties notebook opens. 2. Use the General page to add a type of network to the network. Adding another network type to a NIM network using SMIT: Follow this procedure for adding another type of network to a NIM network using SMIT. 1. To add another network type, enter the smit nim_chnet fast path. 2. Select the network to change. 3. Specify the additional network type to be supported. Adding another network type to a NIM network from the command line: Follow this procedure for adding another network type to a NIM network from the command line. To define a NIM network, enter:
nim -o change -a other_net_typeSequenceNumber=NetworkType NetworkName
For example, to change a Token-Ring network called network1 to also support Ethernet and FDDI, enter:
nim -o change -a other_net_type1=ent -a other_net_type2=fddi network1
179
where default is the reserved keyword used by NIM to indicate a default route, and Gateway is the host name (or IP address) of the interface that clients on NetworkObject use to contact other networks in the NIM environment. For example, to establish default NIM routes for Network1 and Network3, enter:
nim -o change -a routing1=default gw1_tok Network1 nim -o change -a routing1=default gw1_fddi Network3
where gw1_tok is the host name of the default gateway for machines on Network1, and gw1_fddi is the host name of the default gateway for machines on Network3. The detailed information for the network objects now shows the added default routes. To display the detailed information for the two networks, enter:
lsnim -l Network1 Network3
networks fddi 9.101.3.0 255.255.255.0 ready for use information is missing from this objects definition = default gw1_fddi
180
Establishing a static NIM route between networks from the command line: Follow this procedure for establishing a static NIM route between networks from the command line. To create a static NIM route between two networks, enter:
nim -o change -a routingseq_no=DestinationNetworkObject \ Gateway1 Gateway2 NetworkObject
where Gateway1 is the host name of the interface that clients on NetworkObject use to get to DestinationNetworkObject, and Gateway2 is the host name that clients on DestinationNetworkObject use to get back to NetworkObject. For example, to establish a NIM route between Network1 and Network3, enter:
nim -o change -a routing1=Network3 gw1_tok gw1_fddi Network1
where gw1_tok is the host name of the gateway that machines on Network1 use to communicate with machines on Network3, and gw1_fddi is the host name of the gateway that machines on Network3 use to communicate with machines on Network1. The detailed information for the network objects now shows the added routing attributes. To display the detailed information about the two networks, enter:
lsnim -l Network1 Network3
networks fddi 9.101.3.0 255.255.255.0 ready for use information is missing from this objects definition = Network1 gw1_fddi
181
Access a Root Volume Group Copy a System Dump to Removable Media Access Advanced Maintenance Function
This option allows you maintenance shell with This option allows you This option allows you commands.
to activate the root volume group and start the a full set of commands. to copy a previous system dump to external media. to start a maintenance shell with a limited set of
Booting in maintenance mode using the Web-based System Manager: Follow this procedure for booting in maintenance mode using the Web-based System Manager. 1. 2. 3. 4. Select the Machines container. In the contents area, select a target standalone machine you want to enable for maintenance boot. From the Selected menu, choose Troubleshooting > Enable Maintenance Boot. Use the dialog to select a SPOT resource from which to boot.
Booting in maintenance mode using SMIT: Follow these procedures for booting in maintenance mode using SMIT. Initiating the maint_boot operation from the client: Follow this procedure for initiating the maint_boot operation from the client. 1. Enter the smit nim_client_op fast path. 2. Select the maint_boot operation. 3. Select the SPOT to be used for the operation. 4. Press Enter to enable the client for maintenance boot. Initiating the maint_boot operation from the master: Follow this procedure for initiating the maint_boot operation from the master. 1. Enter the smit nim_mac_op fast path. 2. Select the client's machine object. 3. Select the maint_boot operation. 4. Select the SPOT to be used for the operation. 5. Press Enter to enable the client for maintenance boot. Booting in maintenance mode from the command line: Follow these procedures for booting in maintenance mode from the command line. To issue the maint_boot operation from the client, enter:
nimclient -o maint_boot -a spot=SPOTNAME
To verify that the maintenance boot operation worked: 1. On the client, enter:
nimclient -l -l ClientMachineObjectName
If the operation was successful, the client's Cstate output will look similar to the following:
182
For the machine to boot into maintenance mode, follow the procedure for issuing the BOOTP request from the client. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot.
Verifying the diag operation: After you have enabled the client to perform a diagnostic boot, you can verify the success of the operation by querying the client's control state (Cstate).
183
For the client to boot the diagnostics, you need to reboot the client. If it is a diskless or a dataless client, you have already defined a network adapter as the default boot device (BOOTP request), so no additional action is required. For a standalone machine, the boot list for normal boot lists the hard disk as the primary boot device. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. Loading diagnostics without the diag operation: In addition to the procedure using the diag operation, diskless and dataless clients have another way of loading diagnostics from the network. You can boot a diskless or dataless client from the network the same way you do for normal use, but with the machine's key mode switch in the Service position. If the client's key mode switch is in the Service position at the end of the boot process, hardware diagnostics from the server's SPOT are loaded. If a standalone client boots with the key mode switch in the Service position, the diagnostics (if installed) are loaded from the hard disk.
184
Initializing and booting a diskless or dataless machine using SMIT: Follow this procedure for initializing and booting a diskless or dataless machine using SMIT. 1. On the NIM master, enter the smit nim_dd_init fast path. 2. Select the client to be initialized from the list of clients displayed on your screen. 3. Supply the values for the required fields. Use the help information and the LIST option to help you specify the correct values for the initialization options. 4. After completion of the initialization operation, boot the client machine over the network. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. Note: On older model rspc systems, it may be necessary to permanently set the bootlist from the firmware menus to make the client always boot over the network. For other systems, the bootlist is automatically set the first time the machine is booted as a diskless/dataless client. 5. After the client boots over the network and performs some initialization, the client will display instructions for you to select the console for the machine. Initializing and booting a diskless or dataless machine from the command line: Follow this procedure for initializing and booting a diskless or dataless machine from the command line. 1. To initialize the client resources for diskless clients, complete one of the following depending on which resource is used: v If a root resource is used, enter the following on the NIM master:
nim -o dkls_init -a spot=SPOTName -a root=RootName \ -a dump=DumpName -a paging=PagingName ClientName
2. To initialize the client resources for dataless clients, enter the following on the NIM master:
nim -o dtls_init -a spot=SPOTName -a root=RootName \ -a dump=DumpName ClientName
Note: For detailed information about other attributes you can specify for the dkls_init and dtls_init operations, see Using the NIM dkls_init operation on page 258 and Using the NIM dtls_init operation on page 259. 3. After completion of the initialization operation, boot the client machine over the network. If you are booting from a network device, follow the procedures in your hardware documentation to perform the network boot. Note: On older model rspc systems, it may be necessary to permanently set the bootlist from the firmware menus to make the client always boot over the network. For other systems, the bootlist is automatically set the first time the machine is booted as a diskless/dataless client. 4. After the client boots over the network and performs some initialization, the client will display instructions for you to select the console for the machine.
Administering NIM
You can use NIM to complete different types of task including backing up and restoring a NIM database.
Installation and migration
185
186
/etc/objrepos/nim_object.vc
187
Enter:
nim -o remove MachineName
For example, to remove the machine Standalone2, and add the machine Standalone4 to the group MacGrp1, enter:
nim -o change -a rm_member=Standalone2 \ -a add_member=Standalone4 MacGrp1
188
smit nim_client_reg
Preventing machines from adding themselves as clients from the command line: Use this information to set from the command line whether machines can add themselves as clients in a NIM environment. To prevent machines from adding themselves as clients in a NIM environment, set the attribute client_reg=no on the NIM master:
nim -o change -a client_reg=no master
To allow machines to add themselves as clients of a NIM master, remove the client_reg attribute by setting it to yes on the master:
nim -o change -a client_reg=yes master
Exporting NIM resources globally from the command line: Global exporting of NIM resources for use by clients can be managed with the global_export attribute. To enable global exporting of NIM resources, set the attribute global_export=yes on the NIM master:
nim -o change -a global_export=yes master
189
To disable global exporting of NIM resources, remove the global_export attribute from the master by setting it to no:
nim -o change -a global_export=no master
Do not change the enablement and disablement of global exports when there are resources allocated to clients because this could lead to situations where resources are exported with incorrect permissions. All NIM operations should be completed and resources deallocated before any attempts are made to change the global_export value. If resources are currently allocated to clients, the nim command will fail to change the global_export value.
190
v The niminit command creates an alternate_master object for the registering machine. In this example, master B is defined as an alternate_master object on master A when master B registers with master A. v The niminit command configures the alternate_master as a NIM master if it is not already configured as one. v The niminit command notifies the master that the machine is registering with remote access permissions through rsh. In this example, when master B registers, master B gives master A remote access permissions. v Once an alternate master has been added to the NIM environment, clients should initialize themselves again to recognize the alternate master. Initializing again gives the alternate master remote access to the clients either through rsh or nimsh. Once clients have initialized themselves again, their sync_required attribute is set to no, indicating that they recognize the alternate master. Initializing the alternate master from the command line: Follow this procedure for initializing the alternate master from the command line. In this scenario, "master A" is already configured as a NIM master, and "master B" will be initialized as an alternate master. 1. Insert the AIX Volume 1 media into the appropriate drive of the designated alternate master machine (master B). 2. To install the bos.sysmgt.nim.master fileset from the disk, enter:
# installp -agXd /dev/cd0 bos.sysmgt.nim.master
For example, to initialize alternate master (master B) with existing NIM master (master A):
alternate master host name = masterb master host name with which to register = mastera primary network interface = en0 cable type = N/A platform = chrp
For additional attribute information, see the niminit command. 4. Register master A with master B, using the niminit command. For example, enter the following on master A:
# niminit -a is_alternate=yes -a master=masterb -a pif_name=en0 \ -a cable_type1=N/A -a platform=chrp -a name=mastera
Synchronizing the alternate master's NIM database: You can synchronize the NIM database for the alternate master using SMIT or from the command line. In this scenario, master A is configured as a NIM master and has objects, such as clients and resources, defined. Master B is initialized as an alternate master, but its database does not match that of master A. You can use the sync operation to synchronize the NIM database on master B with master A's database. The sync operation backs up master A's database, restores it onto master B, and then ensures that all the object definitions are consistent. You should consider the following issues when synchronizing the alternate master's NIM database: v The resources served by master A are removed from the database when it is restored on master B. v Object definitions are reset when the database is restored on master B.
Installation and migration
191
v After the database is restored on master B, master B does not control any NIM objects until you perform the takeover operation. As a result, master B can not run any NIM operations to any objects in its database. Synchronizing the alternate master's NIM database using SMIT: Follow this procedure for synchronizing the alternate master's NIM database using SMIT. 1. On master A, enter the smit nim_altmstr fast path. 2. Select Synchronize an Alternate Master's NIM database. 3. Type the name of the NIM object for master B. 4. Select yes for the force option if master B has been configured as a NIM master. 5. Select yes for the replicate option if the resources have to be replicated onto the alternate master. Synchronizing the alternate master's NIM database from the command line: Follow this procedure to synchronize the alternate master's NIM database from the command line. To synchronize master B's database with master A's, enter the following on master A:
# nim -o sync masterb
To synchronize master B's database with master A's, and also replicate the resources served by master A:
# nim -o sync -a replicate=yes masterb
Note: v You must use the force option to overwrite the existing database that was created by the niminit command. v Resources are replicated only if they are not present in the appropriate file system locations of the alternate master. For example:
# nim -Fo sync masterb
The replicate option can be used along with the force option. For example:
# nim -Fo sync -a replicate=yes masterb
Taking control of the NIM environment: You can take control of the NIM environment using SMIT or from the command line. In this example, master B is initialized as an alternate master and has had its NIM database synchronized with master A. Master B takes control of the objects in the NIM environment. You should consider the following issues when taking control of the NIM environment: v If you perform this operation while master A is running, and master A has a network connection to master B, the database on master A is updated to reflect the change in masters. You should reset the clients on master A before running this operation. This operation prints warnings for any clients on master A that are currently set up to run NIM operations. This operation will not reset those clients to complete successfully. v If master B is unable to update master A during the takeover operation, master A should have its database synchronized with master B once it is running. v This operation updates the current master of each client by running a remote command on the clients. Clients that are unavailable to switch masters are displayed. When the client is available, initialized it with master B or perform the takeover operation again from master B.
192
Taking control of the NIM environment using SMIT: Follow this procedure for taking control of the NIM environment using SMIT. 1. Enter the smit nim_altmstr fast path on master B and select Takeover control of NIM clients from an Alternate Master. 2. Type in the name of the NIM object for master A. Taking control of the NIM environment from the command line: Follow this procedure for taking control of the NIM environment from the command line. To have master B take control of the NIM environment, enter the following on master B:
# nim -o takeover mastera
Master A can retake control of the NIM environment by running the takeover command with master B as the target. Removing an alternate master from the NIM environment: You can remove an alternate master from the NIM environment using SMIT or from the command line. In this example, master B is removed from the NIM environment. Master A should be in control of the NIM environment prior to removing master B. You should consider the following issues when removing an alternate master from the NIM environment: v Clients re-initialize themselves with master A after removing master B from the environment. Re-initializing updates the niminfo files and remote access permissions. v You can unconfigure Master B by running the unconfig operation locally on master B. Removing an alternate master from the NIM environment using SMIT: Follow this procedure for removing an alternate master from the NIM environment using SMIT. 1. On master A, enter the smit nim_altmstr fast path and select Remove an Alternate Master. 2. Select the NIM name of master B. Removing an alternate master from the NIM environment from the command line: Use this command to remove an alternate master from the NIM environment. To remove master B from the NIM environment, enter the following command on master A:
# nim -o remove masterb
193
AIX product media version, or equivalent lpp_source and SPOT NIM resources v Server and resource requirements v A POWER5 server with sufficient hardware resources to support the target clients' equivalent POWER5 configuration v If virtual resources will be used to migrate the clients, an installed and configured Virtual I/O Server is required v HMC controlling the POWER5 server, along with sufficient privileges to start, stop, and create LPARs v root user authority This nim_move_up process requires no downtime on the part of the original client. In addition, nim_move_up is capable of migrating a client onto virtualized hardware, such as virtual disks, using the Virtual I/O capabilities of the POWER5 server. This migration process can be completed by the nim_move_up application in phases to allow more control over the process, or it can be completed all at once without any user interaction required. With the nim_move_up application, you can use a NIM master and its clients as the starting point for a migration that produces the following hardware environment: v The original NIM master v LPARs on POWER5 server that correspond to the original NIM clients and are controlled by the NIM master v HMC to control the LPARs on the POWER5 servers, communicated with by the NIM master through SSH v The original NIM clients The nim_move_up migration process is completed in the following phases to allow more control over the process. 1. The Create NIM Resources phase creates the needed NIM resources to perform the migration steps if they don't already exist or are not provided beforehand. 2. The Pre-migration Software Assessment phase performs an assessment on each target client to determine what software is installed and can be migrated. Any software that is missing from the lpp_source will be added from the source of installation images that should be provided to nim_move_up. 3. The Client Hardware and Utilization Data Gathering phase gathers data about each target client's hardware resources and attempts to assess how much of those resources are utilized on average over a given amount of time. 4. The POWER5 Resource Availability Data Gathering and Client Resource Data Translation phase searches the given managed system for available hardware resources. Uses the data gathered in the previous phase to create an equivalent LPAR configuration that utilizes the managed system's available resources. Creates the client LPARs with virtual I/O resources instead of physical I/O resources if nim_move_up was provided a Virtual I/O Server LPAR to work with. Creates the appropriate adapters and configuration on the Virtual I/O Server as they are needed. 5. The Create System Backups of Target Clients phase creates an installable image of each target client and its resources using the mksysb command. 6. The Migrate Each System Backup phase uses the nimadmin command to migrate the newly-created installable images to the new level of AIX. 7. The Allocate NIM Resources to New LPARs phase uses the network information provided to the nim_move_up application to create NIM standalone client objects for the new LPARs created in the POWER5 Resource Availability Data Gathering and Client Resource Data Translation phase. Allocates the appropriate NIM resources and runs a bos_inst pull operation (i.e. NIM will not attempt to boot the client) on each NIM client. 8. The Initiate Installation on LPARs phase reboots each LPAR via the control host (HMC partition) and initiates the installation.
194
Note: This phase ends when the installation begins. The actual progress of the installation is not monitored. 9. Post-migration Software Assessment Assesses the overall success of the migration after each installation, and reports on any software migration issues. It may be necessary to manually correct the errors reported for filesets that fail to migrate. 10. Post-installation Customization Performs a NIM customization operation on each client with the values provided if an alternate lpp_source, fileset list, or customization script was provided to the nim_move_up application. This allows for the optional installation of additional software applications or for any additional customization that may be needed. Migrating a NIM client to a POWER5 logical partition using SMIT: The SMIT fastpath to the root menu of nim_move_up is smitty nim_move_up. After all prerequisites needed to run the nim_move_up application have been met, nim_move_up performs the migration process in two steps: configuration and phase execution. You can run the nim_move_up allocation from SMIT by completing the following steps: 1. Enter smitty nim_move_up_config. The Configure nim_move_up Input Values panel opens. 2. Enter information in the required fields. This information is retained by the nim_move_up application, unless the application is reset. You can change this information at any time from the Configure nim_move_up Input Values panel. 3. To begin the actual migration process, enter smitty nim_move_up_exec. The Execute nim_move_up Phases panel opens. 4. Provide an appropriate answer to the option Execute All Remaining Phases? on the Execute nim_move_up Phases panel and press Enter. You can use other panels to interact with the nim_move_up application, in addition to the Configure nim_move_up Input Values panel and the Execute nim_move_up Phases panel: Display the Current Status of nim_move_up Selecting this menu option is equivalent to running nim_move_up with the -S flag. The next phase to be executed and a listing of all the saved options are displayed. Configure SSH Keys on Target HMC This SMIT panel provides a simple interface to setting up SSH keys on the remote control host (HMC). Using this panel is the equivalent of using the -K command line option. Configuring SSH keys on the remote control host enables the unattended remote execution of commands from the NIM master. Unconfigure nim_move_up This SMIT panel provides an interface to unconfiguring the nim_move_up environment. Unconfiguring the environment removes all state information, including what phase to execute next, saved data files generated as a result of the execution of some phases, and all saved input values. Optionally, all NIM resources created through nim_move_up can also be removed. Using this panel is the equivalent of using the -r command line option. Migrating a NIM client to a POWER5 logical partition using the command line: Once all prerequisites needed to run the nim_move_up application have been met, nim_move_up performs the migration process in two steps: configuration and phase execution. Command-Line Usage
195
nim_move_up {[-S] | [-K [-h control_host] ] | [-r [-R] ]} | { [-c NIM_client] [-i target_ip[-ending_ip]] [-s subnet_mask] [-g gateway] [-h control_host] [-m managed_sys] [-V vio_server [-e] [-D] ] [-I img_src] [-l resource_dir] [-t seconds] [-p loops] [-j nimadm_vg] [-L lpp_source] [-U spot] [-B bosinst_data] [-E exclude_files] [-C script_resource] [-b installp_bundle] [-f fix_bundle] {{[-n] [-d]} | -O} [-q] }
Table 9. Required Flags
Flag -c NIM_client Either a NIM standalone client (standalone object type), or a NIM machine group (mac_group object type). The indicated clients must be reachable via the network from the NIM master and must allow the NIM master to execute commands on them. If you specify a NIM machine group in this argument, they must all reside in the same NIM network. The clients will be the target machines that will be migrated onto equivalent LPARs on a POWER5 server. The IP address that the new migrated client will be configured with after it is installed onto the POWER5 server. If a NIM machine group is supplied to the -c option, a range of IP addresses must be supplied here and there must be enough addresses in the range to enumerate the amount of clients that will be migrated. The subnet mask that the clients will be configured with after the migration to the POWER5 server. The IP address of the default gateway that the clients will be configured with after the migration to the POWER5 server. The hostname or IP address of the HMC that is used for hardware control of the POWER5 server that nim_move_up is to use. The name of the managed system corresponding to the POWER5 server as tracked by the HMC. Path to the source of the installation images to be used to create the NIM resources needed to perform the migration and installation. This path can be a device, such as dev/cd0 if using AIX product media, or a path to a location on the file system containing the installation images. Path to a location on the file system that will contain any new NIM resources created through nim_move_up. The location should have enough space to accommodate an lpp_source and a spot unless existing resources were provided through the -L and -U options.
-i target_ip[-ending_ip]
-m managed_sys -I img_src
-l resource_dir
-n
-d
-q
196
-K
-r
-R
-D
-p loops
-t seconds -j nimadm_vg
-L lpp_source
-U spot
-B bosinst_data
197
-C script_resource
-b installp_bundle
-f fix_bundle
Example: To configure the nim_move_up application with the required options and to start the first phase of the migration process, you would enter the following:
nim_move_up -c client1 -i 192.168.1.100 -s 255.255.255.0 -g 192.168.1.1 -h hmc1.mydomain.com -m my-p5 -l /big/dir -I /dev/cd0 -n
where v -c client1 is a NIM standalone client reachable via the network from the NIM master v -i 192.168.1.100 is the IP address that the new migrated client will be configured with after it is installed onto the POWER5 server v -s 255.255.255.0 is the subnet mask that the clients will be configured with after the migration to the POWER5 server v -g 192.168.1.1 is the IP address of the default gateway that the clients will be configured with after the migration to the POWER5 server v -h hmc1.mydomain.com is the hostname or IP address of the HMC that is used for hardware control of the POWER5 server to be used by the nim_move_up application v -m my-p5 is the name of the managed system corresponding to the POWER5 server as tracked by the HMC v -l /big/dir is the path to a location on the file system that will contain any new NIM resources created by the nim_move_up application v -I /dev/cd0 is the path to the source of the installation images to be used to create the NIM resources needed to perform the migration and installation v -n begins the next phase of the migration process. Then, to execute all remaining phases of the migration process in the background and save your agreement to accept all licenses, you would enter
nim_move_up -Y -d
198
Output from the installation of key system and device-driver software Output from the installation of user-specified software (including installation of NIM client software during a bos_inst operation) Output from the BOS installation program The machine's boot log A log of the output from the lppchk operation executed on a standalone NIM client Output from any configuration script resources allocated for a bos_inst operation Errors encountered during execution of the nim command.
By default, the showlog operation applied to a standalone machine displays the niminst log and shows the output logged when software was last installed on the machine using NIM. The last entry is also shown by default for the script and lppchk logs. The entire contents of the niminst, script, and lppchk logs can be displayed by assigning the full_log attribute a value of yes when executing the showlog operation. The entire log is shown for all other log types. Viewing installation, configuration, and boot logs using the Web-based System Manager: Follow this procedure for viewing installation, configuration, and boot logs using the Web-based System Manager. 1. Select the Machines container. 2. In the contents area, select a target machine (master, standalone, diskless, or dataless), or in the Resources container, select a target SPOT. 3. From the Selected menu, choose Troubleshooting > Show NIM Logs. 4. Use the dialog to select the log you want to examine. Viewing installation, configuration, and boot logs using SMIT: Follow this procedure for viewing installation, configuration, and boot logs using SMIT. 1. Enter the smit nim_mac_op fast path to view a machine's log, or enter smit nim_res_op to view a SPOT's log. 2. Select the object name of the machine or SPOT whose log you want to view. 3. Select showlog from the list of operations. 4. Select the log type to be viewed. 5. Specify if the full log should be viewed (only applicable to script, lppchk, and niminst logs). Viewing installation, configuration, and boot logs from the command line: Follow this procedure for viewing installation, configuration, and boot logs from the command line. To view a log on a standalone machine or SPOT, enter:
nim -o showlog -a LogType=value ObjectName
where LogType represents the log you want to view, and ObjectName is the name of the machine or SPOT whose log will be viewed.
199
1. From the main Web-based System Manager container, select the Software icon. 2. From the Software menu, select NIM Client > Permissions. 3. Select whether to grant or deny permission for the NIM master to initiate push installations. Disabling master push permissions using SMIT: You can use the smit nim_perms fast path to disable the master push permissions. To disable the master's push permissions, enter the smit nim_perms fast path from the client machine. Disabling master push permissions from the command line: You can disable and re-enabling the master push permissions from the command line. To set control on the client to push_off, enter the following on the client machine:
nimclient -P
To re-enable push permission on the client, enter the following on the client machine:
nimclient -p
You can also do this task from Troubleshooting. From the Selected menu, choose Troubleshooting > Clean Up Failed or Interrupted Installation. Resetting the NIM state using SMIT: Follow this procedure for resetting the NIM state using SMIT. 1. To return a machine to the ready state, enter the smit nim_mac_op fast path. 2. Select the target machine for the operation. 3. Select reset as the Operation to Perform. 4. To deallocate resources, change the Deallocate All Resources? field to yes. 5. Change the Force field to yes. Resetting the NIM state from the command line:
200
Follow this procedure for resetting the NIM state from the command line. 1. To return a machine to the ready state, enter:
nim -Fo reset MachineName
where ResourceType is the type of the resource being deallocated (for example, lpp_source, SPOT, Script, etc.), ResourceName is the name of the resource being deallocated, and MachineName is the name of the machine that has been allocated the resources. Note: Resetting a machine will not automatically deallocate all the resources that were allocated for the operation. To deallocate resources, use the NIM deallocate operation.
Rebuilding network boot images for a SPOT from the command line: Follow this procedure to force the rebuild of the boot images for a SPOT from the command line. Enter:
nim -Fo check SPOTName
For information on how to install additional software on standalone clients and SPOT resources, see Customizing NIM clients and SPOT resources on page 131.
201
A /usr SPOT served by a client in the NIM environment can be reinstalled with a new level of AIX using the migration procedure, but the SPOT object must be removed and then redefined after the migration completes. Any diskless or dataless clients served by that SPOT must be reinitialized. To reinitialize diskless and dataless clients after migrating a /usr SPOT server, deallocate, then reallocate the root resources, and then perform the dtls_init or dkls_init operation accordingly. To reinitialize diskless and dataless clients, enter:
nim nim nim nim -o -o -o -o reset -F ClientName deallocate -a root=RootResourceName ClientName allocate -a root=RootResourceName ClientName dkls_init ClientName
Attention: Any customization that was done previously will be erased, because deallocating the root resource will delete all the files in the root directory.
202
4. Select a machine from the list on the right, and click the < button to add the machine to the new group. Repeat this step until all the desired members of the machine group are in the Members list on the left. 5. Click OK. Defining a machine group using SMIT: Follow this procedure for defining a machine group using SMIT. 1. To define a machine group, enter the smit nim_mkgrp fast path. 2. Select the type of group you want to define. 3. Enter the name of the group and member information. Defining a machine group from the command line: Follow this procedure for defining a machine group from the command line. To define a machine group, enter:
nim -o define -t mac_group -a add_member=MemberName GroupName
For example, to create a machine group named MacGrp1 containing previously defined machines Standalone1, Standalone2, and Standalone3, enter:
nim -o define -t mac_group -a add_member=Standalone1 \ -a add_member=Standalone2 -a add_member=Standalone3 \ -a comments="Machines for Department d03" MacGrp1
Adding new members to machine groups: New members can be added to machine groups, however, the new member must be of the same machine type as existing members. Members can be added to machine groups using the Web-based System Manager NIM application. Adding new members to machine groups using Web-based System Manager: Follow this procedure for adding new members to machine groups using Web-based System Manager. 1. Select the Groups container. 2. In the contents area, select a group. 3. From the Selected menu, choose Add/Remove Members.... 4. Select a machine from the list on the right, and click on the < button to add the machine to the new group. Continue with this step until all the desired members of the machine group are in the list on the left. 5. Click on OK. Adding new members to machine groups using SMIT: Follow this procedure for adding new members to machine groups using SMIT. 1. To add members to a machine group, enter the smit nim_chgrp fast path. 2. Select the machine group to modify. 3. Specify members to add to the group. Use the LIST option to select members to add. Adding new members to machine groups from the command line: Follow this procedure for adding new members to machine groups from the command line.
203
For example, to add the diskless client, diskless5, to the machine group, diskless_grp, enter the following command:
nim -o change -a add_member=diskless5 diskless_grp
Alternatively, you could have specified group members in both the define and change operations by using sequenced member attributes, such as -a member1=Standalone1 -a member2=Standalone2 and so forth. Including and excluding group members from operations on the group: Group members may be included or excluded by using the Web-based System Manager NIM application, SMIT, or from the command line. Use the select operation from the command line to indicate that specific members of a machine group should be included or excluded from operations on that group. This capability is useful if an operation needs to be tried again on specific group members that failed during an initial operation on the group. When a group member is marked as being excluded, it remains so until it is included again. Including and excluding a group member from operations on the group using Web-based System Manager: Follow this procedure for including and excluding a group member from operations on the group using Web-based System Manager. 1. Select the Groups container. 2. In the contents area, expand a group container to view the members included in that group. 3. Select a machine from those listed in the container. 4. From the Selected menu, choose Properties. Including and excluding a group member from operations on the group using SMIT: Follow this procedure for including and excluding a group member from operations on the group using SMIT. 1. To include or exclude a group member from operations on the group, enter the smit nim_grp_select fast path. 2. Select the name of the group from which you want to include or exclude members. 3. Select the members to include or exclude. Including and excluding a group member from operations on the group from the command line: Follow this procedure for including and excluding a group member from operations on the group from the command line. To include or exclude a group member, enter the following:
nim -o select -a include_all=Value -a exclude_all=Value \ -a include=MemberName -a exclude=MemberName GroupName
As an example, to exclude the machine, Standalone2, from further operations on machine group, MacGrp1 and to include a previously excluded machine, Standalone3, enter:
nim -o select -a exclude=Standalone2 -a include=Standalone3 MacGrp1
The special attributes include_all and exclude_all, when assigned a value of yes, can be used respectively to include or exclude all members in a group. The select operation evaluates command line
204
attributes from left to right. The following example shows how to exclude all members except Standalone2 from subsequent operations on the MacGrp1 machine group:
nim -o select -a exclude_all=yes -a include=Standalone2 MacGrp1
Using the special -g option shows the excluded status of the group's members:
lsnim -g MacGrp1
Updating a SPOT with new device support for a new level of AIX
A NIM SPOT may be updated from one level of AIX to another using the update_all option of the NIM cust operation. This process will update all current SPOTs with the latest level of code on the installation media. However, this process will not automatically install new software packages or device drivers from the installation media. Machines in the NIM environment that are being upgraded to a new level of AIX require that new applicable device support be updated for any existing NIM SPOTs intended to support network boot and installation. This must be done after the SPOT is updated to the new level of AIX. The new device support can be installed in the SPOT using NIM's cust operation, specifying the desired device-specific filesets in an installp_bundle resource or by using the filesets attribute. Alternatively, a fileset name of devices can be specified as the value of the filesets attribute to install all devices on the installation media. For further details about the cust operation, see Using the NIM cust operation on page 255.
Managing NIM
You can manage Network Installation Management (NIM) using the Web-based System Manager NIM interface, System Management Interface Tool (SMIT), and the command line.
205
206
For more information about the RPCSEC_GSS authentication process, see the readme files, Network File System security. NFS V4 host authorization: Host authorization in an Network File System (NFS) context means controlling which NFS client hosts can mount exported directories from the NFS server. This is accomplished in AIX with a combination of the /etc/exports file and the exportfs command. NFS V4 has the security-related options as shown in the following table.
Option vers Description Controls which version NFS mounts you can use. Possible values are 2, 3, and 4. Versions 2 and 3 cannot be enforced separately. Specifying Version 2 or 3 allows access by clients using either NFS protocol Versions 2 or 3. Version 4 can be specified independently and must be specified to allow access by clients using Version 4 protocol. The default value in NIM is 3. Valid values in NIM are 3 and 4. sec Controls which security methods can be used. Possible values are: sys dh krb5 krb5i krb5p none UNIX authentication, default option DES authentication Kerberos, authentication only Kerberos, authentication, and integrity Kerberos, authentication, integrity, and privacy Allows mount requests to proceed with anonymous credentials
The default value in NIM is sys. Valid values in NIM are sys and krb5.
The sec option can appear more than once in the exports definition for a directory. This allows different access options, such as ro, rw, and root, to be specified for the different security options. For example, hosts using the sys security method might only be allowed read access, while hosts using the krb5 security method might be allowed read and write access. Using NIM in NFS, there is a standard set of export options that you can use. You can also use user-defined options, but they require you to manage NFS exports for the directory or file system using the NFS export commands, such as mknfsexp, chnfsexp, and rmnfsexp. These export options are separate from NIM export options. Prerequisites for setting up a NIM environment with NFS security using Kerberos 5: Your system must meet these prerequisites before you can configure Kerberos 5. v The NIM master must have AIX 6.1 or later installed. v The NIM master must be configured. v IBM Network Access Server (NAS) Version 1.4 or later from the AIX Expansion Pack CD server files must be installed: krb5.lic krb5.client krb5.server modcrypt.base v Kerberos services must be configured and authenticated with the Key Distribution Center (KDC) server. v Any participating NIM clients must have AIX 6.1 or later installed. v IBM NAS Version 1.4 or later from the AIX Expansion Pack CD client files must be installed:
Installation and migration
207
krb5.lic krb5.client modcrypt.base v The Kerberos client must be configured and authenticated with the KDC server. While NIM is capable of configuring NFS V4, due to the variation of Kerberos configurations, you must manage the KDC configuration and services outside of NIM. Use the sec option in the NIM database for export-list generation only. You can use the sample scripts in the bos.sysmgt.nim.client fileset to set up Kerberos. After Kerberos 5 is configured in the NIM environment, you must authenticate and obtain tickets for each client and the NIM master. Use the usr/krb5/bin/kinit command for ticket-granting options. For additional help for NIM and Kerberos 5, see the /usr/lpp/bos.sysmgt/nim/README file. Managing NFS client communication options using SMIT: Use the following procedure to configure the NFS client communication options using SMIT. v Type smitty nim_global_nfs on the NIM client. v Select any of the NFS client options as shown in the following table.
Option Enable/Disable Global Usage of NFS Reserved Ports? Allow NIM to enable port-checking on NIM master? Specify the NFS Local Domain Value Specifies that a non-reserved IP port number is to be used. The value is disable. A value of enable uses a reserved IP port number when the NFS client-communicates with the NFS server. Checks whether an NFS request originated from a privileged port. The default value is no. A value of yes directs the NFS server to do port checking on the incoming NFS requests. Specify that the NFS local domain of the system should be changed. The value that you specify is used to create the NIM environment attribute nfs_domain and is used as the domain name in the /etc/nfs/local_domain file. Note: You must set this option before exporting NIM resources as NFS V4 mounts.
Managing NFS client-communication options from the command line: Use these commands to configure NFS client-communication options on the NIM master. Use the following commands on the NIM master: v To enable global usage of NFS reserved ports, use the following command:
nim -o change -a nfs_reserved_port=yes master
v To disable global usage of NFS reserved ports, use the following command:
nim -o change -a nfs_reserved_port=no master
v To enable port checking on the NIM master NFS server, use the following command:
nfso -o portcheck=1
v To disable port checking on the NIM master NFS server, use the following command:
nfso -o portcheck=0
v To create a simple KDC server and principals on the NIM master NFS server, use the following command:
/usr/samples/nim/krb5/config_rpcsec_server -p <password> -u <user principal name>
This command creates a new-system user name based on the principal name and password provided. See Sample KDC Server Definition File. v To delete the KDC server and principals on the NIM master NFS server, use the following command:
/usr/sbin/unconfig.krb
208
where LslppFlags are the flags to be passed to the lslpp command, and TargetName is the name of the client or SPOT object. For example:
Installation and migration
209
Listing software updates, installed on a standalone client or SPOT, by keyword: You can list software updates, installed on a standalone client or SPOT, by keyword using the Web-based System Manager, SMIT, or the command line. Listing software updates, installed on a standalone client or SPOT, by keyword using Web-based System Manager: Follow this procedure for listing software updates, installed on a standalone client or SPOT, by keyword using Web-based System Manager. 1. Select the Machines container. 2. In the contents area, select a target machine (master or standalone), or in the Resources container, select a target SPOT resource. 3. From the Selected menu, choose List Installed Software > Fix (APAR) Status. 4. Use the dialog to list the installation status of specific installed fixes. Listing software updates, installed on a standalone client or SPOT, by keyword using SMIT: Follow this procedure for listing software updates, installed on a standalone client or SPOT, by keyword using SMIT. 1. To list fixes installed on a standalone client or SPOT by APAR number or keyword, enter the smit nim_mac_op fast path for standalone clients, or enter the smit nim_res_op fast path for SPOTs. 2. Select the standalone client or SPOT resource object. 3. Select the fix_query operation. 4. Select the desired fix_query flags or accept the default settings. Specify the fix_bundle object name; or to check the installation status of an APAR, specify the fix APAR numbers. If you leave both blank, all known fixes are displayed. Listing software updates, installed on a standalone client or SPOT, by keyword from the command line: Follow this procedure for listing software updates, installed on a standalone client or SPOT, by keyword from the command line. Enter the following command:
nim -o fix_query [ -afixes="FixKeywords" ] \ [-afix_bundle=FixBundleName ] [ -afix_query_flags=FixQueryFlags ] \ TargetName
where FixKeywords are APAR numbers; FixBundleName is the object name of the fix_bundle resource; FixQueryFlags are optional flags to the fix_query operation, and TargetName is the client, group, or SPOT for which to display fix information. Valid FixQueryFlags are as follows:
-a -c -F -q -v Displays symptom text. Displays output in colon-separated format. Returns failure unless all filesets associated with a fix are installed. Quiet option; if -q is specified, no heading is displayed. Verbose option; gives information about each fileset associated with a fix (keyword).
For example: v To query the fix database on standalone1 to determine if all fileset updates for fix IX12345 are installed, enter:
210
v To list fix information for all known fixes installed on spot1, with symptom text, enter:
nim -o fix_query -afix_query_flags=a spot1
Maintaining software on standalone clients and SPOT resources: This kind of task is accomplished by performing the NIM maint operation on a SPOT using the Web-based System Manager NIM application, SMIT, or command line interface. NIM uses the installp command to construct a SPOT by installing in the SPOT the software products that each SPOT needs to support the NIM environment. Because the installp command also supports software maintenance tasks, you can perform these tasks on SPOT resources as well. For example, you can remove previously installed optional software from a SPOT when they are no longer being used. You interact with the installp command by supplying the installp_flags, and either filesets or installp_bundle attributes. Maintaining software on standalone clients and SPOT resources using Web-based System Manager: Follow this procedure for software maintenance on standalone clients and SPOT resources using Web-based System Manager. 1. Select the Machines container. 2. In the contents area, select a target standalone machine, or in the Resources container, select a target SPOT resource. 3. From the Selected menu, choose Software Utilities > Commit Applied Updates, Reject Applied Updates, or Remove Software, depending upon the task you want to perform. Maintaining software on standalone clients and SPOT resources using SMIT: Follow this procedure for software maintenance on standalone clients and SPOT resources using SMIT. 1. Enter the smit nim_task_maint fast path. 2. Select the menu item that describes the maintenance that you want to perform. 3. Select the target for the operation. 4. In the displayed dialog fields, supply the required values. Use the help information or the LIST option to help you. Maintaining software on standalone clients and SPOT resources from the command line: Follow this procedure for maintaining software on standalone clients and SPOT resources from the command line. Enter the following command:
nim -o maint -a installp_flags="InstallpFlags" \ [-a filesets="FileSetNames" | \ -a installp_bundle=BundleResourceName ] [-F] TargetName
where InstallpFlags are the flags you want to pass to the installp command; FileSetNames are the names of the filesets or packages you want to maintain; BundleResourceName is the object name of the installp_bundle resource; and TargetName is the object name of the standalone client, group, or SPOT. For example: v To remove the bos.adt and bos.INed software packages from standalone1, enter:
nim -o maint -a filesets="bos.adt bos.INed" -a \ installp_flags="-u" standalone1
211
v To remove the bos.INed software package from spot1, which is allocated to diskless or dataless clients, without deallocating spot1 first, enter:
nim -o maint -F -a filesets=bos.INed -a installp_flags="-u" \ spot1
v To remove the packages from spot1 which are listed in the bundle pointed to by the installp_bundle resource object, bundle1, enter:
nim -o maint -a installp_flags="-u" -a installp_bundle=bundle1 \ spot1
Removing software from an lpp_source: To remove software from an lpp_source, delete the installation image from the lpp_source directory.
212
Note: This function is only available from the command line interface. Removing software from an lpp_source from the command line: Follow this procedure for removing software from an lpp_source from the command line. 1. Remove the installation image from the lpp_source directory. 2. Perform the NIM check operation on the lpp_source by entering the following command:
nim -o check Lpp_sourceName
Running the NIM check operation: After adding or removing software, you must run the NIM check operation on the lpp_source to update the installation table-of-contents file for the resource. You can run the NIM check operation from the Web-based System Manager, SMIT, or the command line. In addition to updating the table-of-contents for the lpp_source, the check operation also updates the simages attribute for the lpp_source, which indicates whether the lpp_source contains the images necessary to install the Base Operating System images on a machine. Running the NIM check operation using the Web-based System Manager: Follow this procedure for running the NIM check operation using the Web-based System Manager. 1. Select the Resources container. 2. In the contents area, select a target lpp_source resource. 3. From the Selected menu, choose Check NIM State. Running the NIM check operation using SMIT: Follow this procedure for running the NIM check operation using SMIT. 1. Enter the smit nim_res_op fast path. 2. Select the lpp_source for the operation. 3. Select check for the operation to be performed. Running the NIM check operation from the command line: Follow this procedure for running the NIM check operation from the command line. To initiate the NIM check operation on the lpp_source, enter:
nim -o check Lpp_sourceName
If the lpp_source is currently allocated to a client, use the Force option as follows:
nim -F -o check Lpp_sourceName
213
To deactivate the master using Web-based System Manager, see Unconfiguring the NIM master on page 139. 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
Increasing the number of hosts to which NIM can NFS-export a resource: Follow these instructions to increase the number of hosts to which NIM can NFS-export a resource. By default, when NIM exports a file or directory through 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 approximately one-half, effectively permitting files to be allocated to a greater number of hosts. This action 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 on page 189. Controlling the asynchronous behavior of NIM operations: Certain NIM operations are asynchronous, meaning that NIM master might initiate the operation on the client, but does not wait for the operation to finish. The reason for this asynchronous behavior is because the NIM operation running 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 the cust, maint, and lppchk operations 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
214
Follow these instructions to suppress output from NIM operations. 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 indicate to 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
Reducing space requirements for NIM resources: 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. You can reduce space consumption significantly on resource servers by creating /usr SPOTs and defining CD-ROM file-system directories as lpp_sources. 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 BOS 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 Using the SPOT (Shared Product Object Tree) resource on page 242 and Defining /usr versus non-/usr SPOTs on page 140. 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. For more information about using a CD-ROM file system as an lpp_source, see Defining an lpp_source on CD/DVD-ROM versus hard disk on page 141. Obtaining support for multiple mksysb operations in NIM: During the allocation of NIM mksysb images, only the file is exported to the NFS clients. However, during mksysb creation, the parent directory is also exported. If you use that filesystem to create a mksysb image of a system while another system is restoring a mksysb image from that filesystem, you will get NFS errors. To avoid this problem, use the environment variable NIM_MKSYSB_SUBDIRS on the NIM master. When this variable is set to yes, subdirectories are used to separate mksysb images. The subdirectories are transparent to the user, but they provide separate child locations for NFS exporting. Saving system backup information: When you are defining a mksysb NIM resource using the nim -o define -t mksysb command, the -a mksysb_flags=xxx attribute can be given the -p option, which prevents the mksysb image from being compressed. Note: Due to the amount of space that this system backup is likely to occupy, the location into which the mksysb file is saved, specified by the -a location=xxx attribute, must be large-file enabled. Otherwise, errors can occur.
215
A NIM administrator would not want this CPU ID validation to be performed in the following situations: v When the hardware of a client machine is changed, giving the client a new CPU ID. v When a single client definition is used to install different machines, as on a preinstall assembly line. v When a client machine is migrated with Logical Partition Mobility (LPM), giving the client new hardware and a new CPU ID. Managing client CPU ID validation using the Web-based System Manager: Use this information to enable or disable the NIM client CPU ID validation from the NIM application. To enable or disable NIM client CPU ID validation from the NIM application: 1. From the NIM menu, select Advanced Configuration > Control Client CPU ID Validation. 2. Use the dialog to complete the task. Managing client CPU ID validation using SMIT: Use this information to enable or disable client CPU ID validation from the SMIT interface. Type the SMIT fast path:
smit nim_cpuid_validate
Managing client CPU ID validation from the command line: Client CPU ID validation can be managed on the NIM master by using the validate_cpuid attribute. To disable client CPU ID validation, set the attribute validate_cpuid=no on the NIM master:
nim -o change -a validate_cpuid=no master
To perform client CPU ID validation, remove the validate_cpuid attribute from the master by setting it to "yes":
nim -o change -a validate_cpuid=yes master
Attention: The value of the validate_cpuid attribute should not be changed while operations are being performed on NIM clients because it could potentially disrupt client communications for active machines. Installing and managing software with detached WPARs: If a system has detached WPARs (WPARs which have separately installed writable /usr files), the system software must remain compatible between the global environment and the detached WPARs. You can use the inuwpar command to perform an installation in a global environment. After that installation is complete, the installation continues in all of the detached system WPARs or a specified set of detached system WPARs. If the -G flag is specified, the installation is first attempted in the global environment. If the installation succeeds, the installation is attempted in sequence on each of the specified WPARs. For the inuwpar command to be successful, any installation device used for the command must be available in the WPAR. For the best results, ensure that the installation device is in a directory on a local file system in the global environment. The inuwpar command attempts to mount the installation device into the WPAR file systems and repeat the operation. If the installation device cannot be mounted, the operation on that WPAR fails, and the installation proceeds to the next WPAR. Block and character devices cannot be used as the installation device for inuwpar operations. If the file system is remote, it must be accessible to each WPAR.
216
If the installation directory is already accessible to the WPARs, the following options prevent the inuwpar command from attempting to remount the device into the WPAR: v Use the -d flag to specify the installation directory. v If the installation device has the same path within the WPAR as in the global environment, us the -D flag. For more information about managing software with detached WPARs, see Managing software with detached workload partitions. For information about recovering incompatible detached WPARs, see Recovering incompatible detached workload partitions.
The Web-based System Manager and SMIT interfaces are designed to hide much of the detail required for the command line interface. Therefore, these sections only document 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.
217
Operations performed on machine groups are, by default, performed asynchronously on the non-excluded members of the group. NIM does not wait for an operation to complete on one group member before initiating the operation on the next member. When performing operations asynchronously, it is not possible for NIM to display all the output as it occurs on each client. Therefore, you should use the lsnim command to check the states of the group members to determine how far, and how successfully, the operations have executed. If errors do occur, the log files on client machines can be viewed using the NIM showlog operation. To change the behavior of NIM group operations from asynchronous to synchronous, use the async=no attribute when running the nim command.
218
The number of machines permitted in a machine group is not explicitly limited by NIM. However, the following factors limit the number for practical reasons:
Operation being Performed Operations that are not resource-intensive (such as the maint or showlog operations) may be performed on a group containing any number of machines. Operations that are resource-intensive (such as cust or bos_inst) are limited by the throughput of the network, the disk access throughput of the installation servers, and the platform type of servers. The maximum number of hosts to which a file or directory may be exported with root permissions is limited by NFS to 256. Also, the length of a line in an exports file has an upper limit which could determine the maximum number of machines permitted in a group. For information on how to increase the number of machines to which a resource can be allocated, refer to Exporting NIM resources globally on page 189.
Working with NIM resource groups: Resource groups are used to represent collections of NIM resources. A resource group can contain multiple installp_bundle and script resources, and one resource from each of the other types. If a resource group is allocated or specified for use in a NIM operation, all applicable resources in the group are allocated to the target. The use of resource groups can save NIM administrators from having to repeatedly specify the same set of resources individually, when the allocation of a single resource group would suffice. The command line syntax for defining a resource group is:
nim -o define -t res_group -a default=Value \ -a ResourceType=ResourceName ... ResourceGroupName
The allocation of individual resource group members can be overridden by specifying additional resource attributes for the members to be changed. For example, the resource group, res_grp1, contains the spot1, lpp_source1, bosinst_data1, script1, and resolv_conf1 resources. To use the resource group to perform an rte bos_inst operation on client1, but using no bosinst_data resource, and using resolv_conf2 instead of resolv_conf1, use the following command:
nim -o bos_inst -a source=rte -a group=res_group1 \ -a bosinst_data= -a resolve_conf=resolv_conf2 client1
A resource group can be specified as the default set of resources to use for all NIM operations. This is done by setting the master's default_res attribute to the name of the resource group that will be the default. When a default resource group is defined, the applicable member resources will always be automatically allocated during NIM operations, unless they are specifically overridden. To set the default resource group to res_group1, enter:
nim -o change -a default_res=res_group1 master
or enter:
nim -o change -a default=yes res_group1
219
or enter:
nim -o change -a default=no res_group1
Adding standalone clients to the smit nim_mkmac NIM environment on page 125 Using installation images to install the base operating system on a NIM client on page 157 Using a mksysb image to install the base operating system on a NIM Client on page 160 smit nim_bosinst
Performing a nonprompted BOS v smit nim_mkres installation on page 159 v smit nim_bosinst Using NIM with ATM networks on page 130 Using installation images to install the base operating system on a NIM client on page 157 Performing boot diagnostics on NIM clients on page 183
220
smit nimadm
Secondary adapter support is available for AIX. Before you enable a secondary adapter, you must verify the AIX version the client is on. The secondary adapters will fail to configure because NIM is unable to find the /usr/lpp/bos.sysmgt/nim/methods/c_cfgadptrs client method. The following example shows the outcome if you attempt to enable this support on your NIM master.
nim -o cust -a adapter_def=adapter_def1 rspc10 trigger.austin.xyz.com. 0042-001 nim: processing error encountered on "master": 0042-001 m_cust: processing error encountered on "rspc10": 0042-175 c_script: An unexpected result was returned by the "trigger.austin.xyz.com:/export/nim/scripts/rspc10.script" command: /tmp/_nim_dir_4714/script[10]: /usr/lpp/bos.sysmgt/nim/methods/c_cfgadptrs: not found.
221
v Serving resources from different machines helps avoid bottlenecks when performing NIM operations on large numbers of clients. Bottlenecks can occur on server machines or on network gateways, so it may be beneficial to distribute resources across servers running in different subnets. v Multiple resources of the same type can be created on different machines to increase the availability of resources when servers are taken offline for scheduled maintenance. v Some SPOT resources at certain levels cannot be served by some machines at certain levels. Specifically, SPOT creation is not supported when the level of AIX installed in the SPOT is higher than the level of AIX running on the server. When you are creating SPOTs at multiple levels, it may be necessary to distribute the SPOTs on different servers. 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.
As an example, to create a resource group named ResGrp1 containing previously defined resources, images1, spot1, bosinst_data1, and bundle1, enter:
nim -o define -t res_group -a lpp_source=images1 -a spot=spot1 \ -a bosinst_data=bosinst_data1 -a installp_bundle=bundle1 \ -a comments="BOS Install Resources" ResGrp1
Allocating a resource group: Use the following procedures to allocate resource groups.
222
Allocating a resource group using SMIT: Follow this procedure to allocate a resource group using SMIT. 1. To allocate a resource group, enter the smit nim_alloc fast path. 2. Select the machine or machine group from the list of defined machines (for example, Standalone1). 3. A list of resource groups is displayed. Select the resource group you want to allocate. Allocating a resource group from the command line: Follow this procedure to allocate a resource group from the command line. To allocate a resource group, enter:
nim -o allocate -a group=ResGroupName TargetName
For example, to allocate a resource group named ResGrp1 to a machine named Standalone1, enter:
nim -o allocate -a group=ResGrp1 Standalone1
Alternatively, the group resource can be specified on the command line to the operation. For example, to allocate the resource group, ddResGrp, while performing the dkls_init operation on a group of diskless machines named DklsMacs, enter:
nim -o dkls_init -a group=ddResGrp DklsMacs
Defining default resource groups: After a resource group is defined, you may want to specify the group as the set of defaults for all operations that require resources. Set the default_res attribute on the master to the name of the resource group that you want to be the default. Note: All applicable resources are allocated from the group specified as the default for all operations, except for installp_bundle for a maint operation. A resource from the default group will only be allocated if a resource of the same type is not already allocated and if a resource of that type is not specified on the command line for automatic allocation. The exceptions are the script and installp_bundle resources, of which all occurrences in the resource group and specified on the command line will be allocated. Default members can be overridden by specifying a null value in the attribute assignment for that resource. The following bos_inst operation allocates all applicable bos_inst resources from the resource group specified as the default, except for the bosinst_data resource:
nim -o bos_inst -a bosinst_data=Standalone1
Defining default resource groups using SMIT: Follow this procedure for defining default resource groups using SMIT. 1. Enter the smit nim_grp fast path. 2. Choose Select/Unselect a Default Resource Group. 3. Fill in the name of the group that is to act as the default. Defining default resource groups from the command line:
223
Follow this procedure to define default resource groups from the command line. Enter:
nim -o change -a default_res=ResGroupName master
For example, if the ResGrp1 resource group should be the set of default resources for all NIM operations, enter:
nim -o change -a default_res=ResGrp1 master
Restricting NIM client resource allocation from the command line: Use these procedures to restrict NIM client resource allocation from the command line. To restrict all clients from being able to use any resources, set the attribute client_alloc=no on the NIM master:
nim -o change -a client_alloc=no master
To restrict a particular client from being able to use any resources, set the attribute client_alloc=no on the client:
nim -o change -a client_alloc=no clientname
To restrict all clients from being able to use a particular resource, set the attribute client_alloc=no on the resource:
nim -o change -a client_alloc=no resourcename
To lift the restrictions on client-resource allocation, remove the client_alloc attribute by setting it to yes for the applicable object:
nim -o change -a client_alloc=yes master nim -o change -a client_alloc=yes clientname nim -o change -a client_alloc=yes resourcename
224
-a nfs_versValue -a nfs_secValue
225
After the devexports resource is defined, you can use the devexports resource to allocate the resource and create a WPAR, as follows:
nim -o create -a devexports=devexports_object_name client_name
-a max_dumps=Value
226
-a group=Value -a verbose=Value
Specifies the name of a resource group to which this resource should be added. Displays information for debugging. To show maximum detail, specify a value of 5.
-a nfs_versValue -a nfs_secValue
227
After the fb_script resource is defined, you can allocate the resource and initiate a BOS installation operation using the fb_script resource, as follows:
nim -o bos_inst -a fb_script=fbscript_object_name client_name
-a nfs_versValue -a nfs_secValue
228
When home 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, any time 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. Defining a home resource: You can use the following command-line syntax and attributes for defining a home resource. The command line syntax for defining a home resource is:
nim -o define -t home -a Attribute=Value ... HomeName
229
-a location=Value -a server=Value
Specifies the full path name of the image_data resource file. Specifies the name of the machine where the image_data resource file resides.
-a nfs_versValue -a nfs_secValue
The mksysb image may be split across multiple VIOS media. In which case, the mksysb image must be joined into a single mksysb file using the cat command described in the example above from a multivolume VIOS media. An ios_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, the image 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 is the source for the backup, and set the mk_image attribute to yes in the command to define the ios_mksysb resource. To exclude the /var/vio/VMLibrary file from the VIOS backup image, use the backupios_flags attribute set to the -nomedialib value. See the backupios command on the VIOS for acceptable flags when defining the ios_mksysb. Defining an ios_mksysb resource: Describes the command-line syntax, flags, and attributes for defining an ios_mksysb resource. You can use the following command-line syntax, flags, and attributes for defining an ios_mksysb resource. The syntax for defining an ios_mksysb resource is:
nim -o define -t ios_mksysb -a Attribute=Value ... ios_mksysbName
The following flags are valid for defining the ios_mksysb resource when using the backupios_flags attribute:
230
v nosvg v nomedialib For the descriptions of these flags and more flags used by the backupios command but not listed here, see the backupios command. The following attributes are required for the ios_mksysb resource:
Attribute -a location=Value -a server=Value Description Specifies the full path name of the ios_mksysb image. Specifies the name of the system where the ios_mksysb image resides or is to be created.
-a nfs_vers=Value -a nfs_sec=Value
231
-a nfs_versValue -a nfs_secValue
232
POWER processor-based bos bos.64bit bos.rte.up bos.rte.mp bos.up bos.mp bos.net bos.diag bos.sysmgt bos.terminfo bos.terminfo.data devices.base devices.buc devices.common devices.graphics devices.mca devices.rs6ksmp.base devices.scsi N/A devices.sio devices.sys devices.tty xlC.rte
Itanium processor-based bos N/A N/A N/A N/A bos.mp bos.net bos.diag bos.sysmgt bos.terminfo bos.terminfo.data devices.ia64.base N/A devices.common devices.graphics devices.pci N/A devices.scsi devices.ide devices.isa_sio N/A devices.tty xlC.rte
Note: When copying device images to a directory that you plan to define as an lpp_source, be sure to copy all the device images for a given type of device. For example:
cp /cdfs/usr/sys/inst.images/devices.pci.* lpp_source_directory
You can define an lpp_source in several ways: v If a directory containing installation images already exists, it can be directly defined as an lpp_source resource. v If a directory should be created and populated by NIM with the default set of support images for a BOS install, use the source attribute when defining the resource. This attribute specifies either the name of the device, absolute directory pathname or absolute ISO image pathname that contains the installation images. NIM copies the software images from this source into the location specified for the lpp_source. The images copied will include those from the simages list, all available device support, and some additional software that is typically installed as well (for example, X11). v If an lpp_source should be created from a source device using a list of software other than the default set of images, specify the packages attribute when defining the lpp_source. Use the packages attribute to list the alternative set of software images to copy. v If an lpp_source should be created from a source device using a list of software based on the source's simages list, specify the use_source_simages attribute with a value yes when defining the lpp_source. When using this attribute, you must specify a source attribute and the packages attribute cannot be supplied. 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 100 MB, but a default lpp_source created from a CD-ROM may be over 350 MB. It is recommended that a separate file
Installation and migration
233
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 simages message displays only if the user is creating an lpp_source resource with the default installation packages. The simages message will display if the simages attribute could not be set for the lpp_source. If a user creates an lpp_source and specifies a list of packages, the simages message is not printed. The simages attribute is set correctly, whether or not a simages message is printed or not. If a user attempts to do an rte BOS installation with an lpp_source that does not have the simages attribute, the user receives an error. The error message instructs the user to run nim -o check on the lpp_source to determine the missing packages needed for an rte BOS installation. Whenever a user runs nim -o check on an lpp_source after it has been created, the simages message is printed if the lpp_source does not contain all the images needed for a rte BOS installation. Defining an lpp_source resource: You can use the following command-line syntax and attributes for defining a lpp_source resource. The command-line syntax for defining an lpp_source resource is:
nim -o define -t lpp_source -a Attribute=Value ... lpp_sourceName
-a packages=Value -a show_progress=Value
-a source=Value
-a use_source_simages=Value
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.
234
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.
power ia64 POWER processor-based architecture (used for platforms of the type rs6k, rspc, and chrp) Itanium processor-based architecture (used for platform of type ia64)
v -p For descriptions of these flags, see the nim command. The following attributes are required for the mksysb resource:
-a location=Value -a server=Value Specifies the full path name of the mksysb image. Specifies the name of the machine where the mksysb image resides or is to be created.
235
-a nfs_versValue -a nfs_secValue
Describes the mksysb. Specifies an exclude_files resource to use to exclude files and directories from the system backup. Specifies the name of a resource group to which this resource should be added. Specifies the flag to use to create a mksysb image from a machine in the NIM environment. Specifies the flags to use to tell the command how to create the backup. Specifies the flag to verify that space is available before creating a mksysb image. Specifies the name of the machine to be backed up in the mksysb image. Displays information for debugging. To show maximum detail, specify a value of 5. Specifies the name of the machine to be backed up in the mksysb image if the mk_image attribute is specified. If the mk_image attribute is not specified, this value specifies an existing mksysb resource to be replicated when defining a new mksysb resource. The file pointed to by the source resource will be copied to the new location. Specifies the NFS protocol version required for NFS access. Specifies the security method required for NFS access.
236
-a location=Value -a server=Value
Specifies the full path name of the parent directory for the client paging files. Specifies the name of the machine where the directory for the paging resource will be created.
Defining a resolv_conf resource: You can use the following command-line syntax and attributes for defining a resolv_conf resource. The command line syntax for defining a resolv_conf resource is:
nim -o define -t resolv_conf -a Attribute= ... resolv_confName
-a nfs_versValue -a nfs_secValue
237
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. Defining a root resource: You can use the following command-line syntax for defining a root resource. The command line syntax and attributes for defining a root resource is:
nim -o define -t root -a Attribute=Value ... RootName
238
-a -a -a -a
-a nfs_versValue -a nfs_secValue
Describes the resource. Specifies the name of a resource group to which this resource should be added. Displays information for debugging. To show maximum detail, specify a value of 5. Specifies an existing script resource to be replicated when defining a new resource. The file pointed to by the source resource will be copied to the new location. Specifies the NFS protocol version required for NFS access. Specifies the security method required for NFS access.
After the savewpar resource is defined, you can use the savewpar resource to allocate the resource and create a WPAR, as follows:
nim -o define -t savewpar -a Attribute=Value ... savewparName
The following flags are valid for the savewpar resource: -A, -a, -b, -e, -i, -m, -N, -p, -V, -v, -X, -Z. For a description of the savewpar resource valid flags, see the savewpar command. The following attributes are required for the savewpar resource:
-a location=Value -a server=Value Specifies the full path name of the file being defined as the savewpar resource. Specifies the name of the machine where the file for the savewpar resource resides or is created.
239
-a verbose=Value
Describes the resource. Specifies an exclude_files resource that is used to exclude files and directories from the system backup. Specifies the name of a resource group to which this resource should be added. Specifies the flag that is used to create a savewpar image from a machine in the NIM environment. Specifies the NFS protocol version required for NFS access. Specifies the security method required for NFS access. Specifies the flags that are used in the command to create the backup. Specifies the name of the machine to be backed up in the savewpar image if the mk_image attribute is specified. If the mk_image attribute is not specified, this value specifies an existing savewpar resource to be replicated when defining a new savewpar resource. The file pointed to by the source resource will be copied to the new location. Displays information for debugging. To show maximum detail, specify a value of 5.
After the secattrs resource is defined, you can use the secattrs resource to allocate the resource and create a WPAR, as follows:
nim -o create -a secattrs=secattrs_object_name client_name
240
Note: Whenever this resource is deallocated, NIM changes only the client's configuration, so the client no longer uses this directory. NIM does not remove the common directory. Defining a shared_home resource: You can use the following command-line syntax and attributes for defining a shared_home resource. The command line syntax for defining a shared_home resource is:
nim -o define -t shared_home -a Attribute=Value ... shared_homeName
241
Specifies the full path name of the directory to use as a common / (root) directory among clients. Specifies the name of the system where the shared_root resource is created. Specifies the name of the SPOT resource used to create the shared_root resource.
The following example defines a shared_root named my_local_shroot based on the SPOT resource named my_local_spot. The shared_root directory /export/my_local_shroot will be located on the master because the -a server=master parameter is specified. This command must be run on the master, and my_local_spot must be located on the master. The SPOT resource and the shared_root resource must be located on the same machine.
# nim -o define -t shared_root -a server=master -a location=/export/my_local_shroot -a spot=my_local_spot my_local_shroot \ \ \ \
The following example defines a shared_root resource named my_remote_shroot based on the SPOT resource my_remote_spot. The shared_root directory /export/my_remote_shroot will be located on NIM client named my_client because the -a server=my_client parameter is specified. The command must be run on the master, but the my_remote_spot resource must be located on the my_client NIM client.
# nim -o define -t shared_root -a server=my_client -a location=/export/my_remote_shroot -a spot=my_remote_spot my_remote_shroot \ \ \ \
242
machine serving the SPOT will be included in the SPOT. The second method, creating a non-/usr SPOT, uses 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: Do not create a non-/usr SPOT in a subdirectory of the /usr file system. A SPOT varies in size from 100 MB up to, and sometimes in excess of, 300 MB depending on the software that is installed. Because all device support is installed in the SPOT and the number of device filesets typically increases, the size is not easily predictable from one release of AIX to another. SPOTs are used to support all NIM operations that require a machine to boot over the network. These operations are as follows: v bos_inst v maint_boot v diag v dkls_init v dtls_init 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 12 MB 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 POWER processor-based 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: v The BOS image is retrieved from archive or, for /usr conversion, just the root directory is retrieved from archive (/usr/lpp/bos/inst_root). v The device support required to support NIM operations is installed. v Network boot images are created in the /tftpboot directory. 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.
243
For information about software installation and maintenance tasks you can perform on a SPOT, see Customizing NIM clients and SPOT resources on page 131. Using network boot images for AIX 4.3 or later SPOTs: You can use network boot images for AIX 4.3 or later to reduce the amount of disk space used and the time required to create boot images from SPOT resources. In AIX 4.3 or later, by default NIM only creates the boot images required to support the machines and network types that are defined in the environment. This situation should significantly reduce the amount of disk space used, and the time required to create boot images from SPOT resources. Note: Due to kernel changes, AIX 5.2 or later, does not provide NIM support to create or use AIX 4.2 or earlier SPOTs. In AIX 5.3 with 5300-03 or later, to create SPOT resources for AIX 4.3.3, the environment variable INST_DEBUG must be set as shown: export INST_DEBUG=yes If the INST_DEBUG variable is not set, NIM cannot create SPOT resources for AIX 4.3.3. Defining a SPOT resource: You can use the following command-line syntax and attributes for defining a SPOT resource. The command line syntax for defining a SPOT resource is:
nim -o define -t spot -a Attribute=Value ... SPOTName
Note: The creation of a SPOT, by default, produces a large amount of output. Be sure to scan the output to look for nonfatal errors and warnings that may not be evident from a successful return code.
244
After the wpar_spec resource is defined, you can use the wpar_spec resource to allocate the resource and create a WPAR, as follows:
nim -o create -a wpar_spec=wpar_spec_object_name client_name
245
To create a SPOT from a mksysb on the command line, set the source attribute to the name of the mksysb resource you want to create the SPOT from. If the mksysb resource is called "mksysb1," you would use the following command to create a SPOT called "spot1" served by the NIM master:
nim -o define -t spot -a source=mksysb1 -a server=master -a location=/export/spot spot1
To create a SPOT from a mksysb with SMIT, you can use fast paths nim_mkres_spot_only and nim_mkres. When the source attribute is expanded, all available mksysb resources, as well as other sources, are displayed as possible sources for the creation of a SPOT.
246
The target of an activate operation can be a WPAR client or group of WPAR clients. There are no required attributes for the activate operation. The following optional attributes can be specified for the activate operation: -a cmd_flags=Value Specifies flags to pass through to the operation on the managing system to activate the system. For WPAR clients, see the command for allowable flags. -a group=Value Specifies the name of a WPAR group to use for the operation. -a show_progress=Value Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes.
The target of an allocate operation may be a NIM client or group of NIM clients. The following attribute can be specified for the allocate operation:
-a ResourceType=ResourceName (required) Specifies the resource to allocate to the client, for example, lpp_source=42_images.
When a resource is allocated to a client, an entry is added to the /etc/exports file on the resource server to NFS export the resource to the client. The allocation count for the resource is also incremented. When the allocation count is greater than 0, the resource cannot be modified. During NIM operations, a client mounts and uses the resources that have been allocated to it.
The command line syntax for the alt_disk_install rootvg clone operation is as follows:
Installation and migration
247
The target of an alt_disk_install operation can be a standalone NIM client or a group of standalone NIM clients. The clients must also have the bos.alt_disk_install.rte fileset installed. To display the alternate disk installation status while the installation is progressing, enter the following command on the master:
lsnim -a info -a Cstate ClientName
OR
lsnim -l ClientName
-a mksysb=mksysb_resource
The following are required attributes for the alt_disk_install rootvg clone operation:
-a source=rootvg -a disk=target_disk(s) Specifies the type of alt_disk_install to perform. Specifies the disks on the client system that the mksysb image will be restored. This disk or these disks must not currently contain any volume group definition. The lspv command shows these disks as belonging to volume group None. If you are specifying more than one disk, the disk names must be enclosed in a set of single quotes; for example, hdisk2 hdisk3.
The following are optional attributes that can be specified for both alt_disk_install mksysb and the alt_disk_install rootvg clone operation:
-a concurrent=Value Specifies the maximum number of machines from the selected group that should be installing at any given time. This attribute is only valid when the target of the operation is a machine group. If specified, NIM will monitor the progress of all machines in the group and attempt to keep no more or less than the number specified installing until all machines in the group are installed. Specifies whether to set the bootlist to point to the new rootvg when the install is complete. Value can be yes or no, where yes is the default value. The next time the system is rebooted, it will boot from the newly installed alternate disk if Value is set to yes. Specifies whether to reboot the client when the alt_disk_install operation is completed. Value can be yes or no, where no is the default value. This attribute would normally be set only if the set_bootlist attribute was also set to yes. Specifies whether to print debug (set -x) output from the alt_disk_install script. Value can be yes or no, where no is the default value. This output does not go to the screen, but is saved to the NIM log, /var/adm/ras/nim.alt_disk_install, on the client system. This file can be checked after the alt_disk_install has completed. Specifies the image_data resource to use when creating the new alternate rootvg and its logical volumes and file systems. The new volume group created must be large enough to restore the mksysb image or a copy of the running rootvg. An exclude_files attribute can also be used with an alt_disk_install rootvg clone to specify files or directories that should not be backed up. Specifies the resolv_conf resource to use for configuring the domain and name resolution on the client system when the system is rebooted. This is the /etc/resolv_conf file that will be copied into the alternate disk's file system. This may be useful if the mksysb image you are using has a different /etc/resolv_conf file than the one you want the client to retain.
-a set_bootlist=Value
-a boot_client=Value
-a debug=Value
-a image_data=Value
-a resolv_conf=Value
248
-a script=Value
-a time_limit=Value,
-a verbose=Value
Specifies the script resource to call at the end of the alt_disk_install operation. This script is called on the running system before the /alt_inst file systems are unmounted, so files can be copied from the running system to the /alt_inst file systems before the reboot. This is the only opportunity to copy or modify files in the alternate file system because the logical volume names will be changed to match those of rootvg, and they will not be accessible until the system is rebooted with the new alternate rootvg. Specifies the maximum number of hours that should elapse before ceasing to initiate installation of additional members of the selected group of machines. This value can only be specified when limiting the number of concurrent operations on a group. Specifies whether to show files as they are being backed up for a rootvg clone, or to show files as they are being restored for a mksysb install. Value can be yes or no, where no is the default value. The output goes to the alt_disk_install log on the client, /var/adm/ras/alt_disk_inst.log.
The following are optional attributes that can be specified only for the alt_disk_install rootvg clone operation:
-a exclude_files=Value -a filesets=Value -a fixes=Value -a fix_bundle=Value -a installp_bundle=Value -a installp_flags=Value Specifies an exclude_files resource to use to exclude files and directories from the rootvg. Files and directories specified in this file will not be copied to the new cloned rootvg. Specifies the list of filesets to install into the alternate rootvg after the clone of the rootvg is complete. Specifies the APARs to install into the alternate rootvg after the clone of the running rootvg. The fixes are in the format "IX123456" or "update_all". Specifies the fix_bundle resource that lists the APARs to install into the alternate rootvg after the clone of the running rootvg. Specifies an installp_bundle resource that lists filesets to install into the alternate rootvg after the clone of the running rootvg. Tells installp how to apply the filesets, installp_bundle, fixes, or fix_bundles attributes. The default value is installp_flags=-acgX.
The target of a bos_inst operation can be a standalone NIM client or a group of standalone NIM clients. The following NIM resources are required attributes that can be specified for the bos_inst operation to install and customize a machine: -a lpp_source=Value Identifies the lpp_source resource to be used. The lpp_source resource is only required for an rte installation. The lpp_source resource specified must have the simages attribute set. However, if you are performing a bos_inst operation using a mksysb resource and an lpp_source resource, then the simages attribute is optional. The lpp_source provides software for machine customization. It also provides the BOS image for installation if the source attribute is rte. -a source=Value Identifies the source for BOS run-time files. Valid values are: rte mksysb Installs the machine from a mksysb image. spot Installs the machine from a SPOT copy. Installs from a BOS image in the lpp_source.
249
Note: If a SPOT copy is not complete, the installation will succeed, but the target machine might not be bootable. A SPOT copy must have the proper device support to boot the target system. While installing from a SPOT copy is the fastest installation method, using rte ormksysb is more reliable and functional. Note: A SPOT copy will also install the file sets that are part of the BOS.autoi bundle. -a spot=Value Identifies the SPOT resource to be used. The SPOT provides support for network boot and operations in the boot environment. The following NIM resources are optional attributes that can be specified for the bos_inst operation: -a accept_licenses=Value Specifies whether license agreements should be accepted during BOS installation. Before the installation process can complete, this attribute must be set to yes. The default value is accept_licenses=no. If the bosinst_data resource resides on the NIM master, the ACCEPT_LICENSES field in the bosinst_data resource can also be set to yes. You can also set the NIM_LICENSE_ACCEPT global environment variable to yes on the NIM master. -a adapter_def=Value Specifies the directory containing secondary adapter definition files. The nimadapters command parses a secondary-adapters stanza file to build the files required to add NIM secondary adapter definitions to the NIM environment as part of the adapter_def resource. The nimadapters command does not configure secondary adapters. The actual configuration takes place during a nim -o bos_inst or nim -o cust operation that references the adapter_def resource. -a async=Value Specifies whether NIM should perform operations on group members asynchronously and not wait for the operation to complete on one member before beginning the operation on the next. The default value is async=yes. -a auto_expand=Value Indicates whether to expand file systems when setting up a client for a force_push installation. The default value is auto_expand=yes. -a boot_client=Value Indicates whether NIM should attempt to reboot the client immediately for BOS installation. The boot_client attribute is the converse of the no_client_boot attribute. The default value is boot_client=yes, indicating that NIM should attempt to reboot the client. -a bosinst_data=Value Specifies the bosinst_data resource to use for nonprompted installation. -a concurrent=Value Specifies the maximum number of machines from the selected group that should be installing at any given time. This attribute is only valid when the target of the operation is a machine group. If specified, NIM will monitor the progress of all machines in the group and attempt to keep no more or less than the number specified installing until all machines in the group are installed. -a filesets=Value Specifies a list of filesets to install on the target after BOS installation. -a force_push=Value Indicates whether or not a force_push installation should occur. A force_push should be used for installing machines that are running, but are not configured with the NIM client fileset. See Using the force_push attribute on page 253 for more information. -a group=Value Specifies the name of a resource group to use for installation. A resource group can be specified
250
as an alternative to specifying multiple resources as separate attributes. If a resource group is specified, and it contains a SPOT and lpp_source, the spot and lpp_source attributes are no longer required. -a image_data=Value Specifies an image_data resource to describe how physical and logical data is organized on the client. -a installp_bundle=Value Specifies an installp_bundle resource that lists filesets to install on the target after BOS installation. -a installp_flags=Value Tells installp how to apply the filesets specified by the filesets or installp_bundle attributes. The default value is installp_flags=-agQX. -a mksysb=Value Provides the run-time files for BOS and other filesets if the source attribute is mksysb. The level of BOS run-time files in the mksysb must be equal to the level of the SPOT resource used for the installation. If the level of the SPOT resource is greater than the level of the mksysb resource, then an lpp_source resource must be used and match the level of the SPOT resource. When this situation occurs, an update operation is performed by default. -a no_client_boot=Value Indicates whether the target should remain in the NIM environment after installation completes. The default value is no, indicating that the target system should remain in the NIM environment. -a physical_loc=Value Specifies the physical location code or AIX location code of the installation disk to the BOS installation process. This attribute allows you to specify the location code for the installation disk or disks on the command line, and allows you to have a generic bosinst.data file that does not contain location code information. To determine a disk's physical location code, type the following:
lsdev -Cc disk -l hdisk0 -F "name physloc"
For more information about location codes, see Device Location Codes in Operating system and device management . -a preserve_res=Value Indicates whether resources in non-rootvg file systems should be preserved on the client system being installed. The default value is preserve_res=no. -a resolv_conf=Value Specifies the resolv_conf resource to use for configuring domain and name resolution on a client. -a script=Value Specifies the script resource to be run on the target system after all software has been installed. -a set_bootlist=Value Indicates whether NIM should set the bootlist of the client so that the client boots over the network on the next reboot. Usually, set_bootlist would be yes if the client is not going to be rebooted immediately for installation (no_client_boot=yes or boot_client=no). The default value is set_bootlist=no. -a show_progress=Value Indicates whether status should be displayed for each group member when the installation target is a group of machines. The default value is yes. -a time_limit=Value Specifies the maximum number of hours that should elapse before ceasing to initiate installation
Installation and migration
251
of additional members of the selected group of machines. This value can only be specified when limiting the number of concurrent operations on a group. -a verbose=Value Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output. When a bos_inst operation is performed on a client, the following occurs: On the SPOT server: 1. A link is created in /tftpboot to a boot image matching the platform type, kernel type, and network adapter of the client. 2. The /etc/bootptab file is updated with client information to allow the boot image to be used. 3. A ClientName.info file is created in /tftpboot to provide client-specific installation and configuration information in the boot environment. 4. The /etc/tftpaccess.ctl file is modified, if necessary, to allow access to the /tftpboot directory. On the target system: 1. The bootlist is modified so the network adapter is the default boot device for normal mode boot, unless no_client_boot=yes, set_bootlist=no, and force_push=no are specified. 2. The client is rebooted to begin the installation, unless no_client_boot=yes, boot_client=no, and force_push=no are specified. When the client boots over the network adapter, it obtains the boot image from the SPOT server. The boot image configures devices and sets up the machine for the BOS installation. The Client.info file is transferred to the client machine; and based on its contents, the network adapter is configured, routes are added, and NIM resources are mounted in the boot environment. Processing control is then passed to the BOS installation program. NIM BOS installation data: The BOS installation program requires access to an image that contains the BOS run-time files. This image is used by the BOS installation program to populate the target's /usr filesystem. In the NIM environment, this image can come from one of the following resources: v A BOS run-time image that is part of the lpp_source resource that has been allocated to the target v A SPOT resource that has been allocated to the target v A mksysb image that has been allocated to the target A spot and lpp_source are always required to support the bos_inst rte operation. A bos_inst mksysb operation only requires a spot resource be used. To indicate which BOS image to use, specify the source attribute when performing the bos_inst operation. The source attribute may have one of the following values: rte When an rte value (the default) is used for the source attribute, NIM directs the BOS installation program to use the BOS run-time image that is in the lpp_source directory. This image contains only the BOS run-time files; it does not contain any optional software packages. Selecting an rte source may increase the BOS installation time, because the BOS installation program installs the appropriate device support after populating the target's /usr file system to make the target viable. The installation time may also be increased due to additional installp activity during the NIM customization phase. Note: The rte source must be used when performing BOS migration installation.
252
mksysb Using mksysb as the source results in a target machine that has the same configuration as the machine from which the mksysb image was created. This may save installation and configuration time. The mksysb images could be very large, and the installation will fail if the target does not have enough disk space to accommodate the image. After the installation is initiated from the master, the NIM master attempts to contact the target and execute a script that will force the system to reboot. The target system issues a BOOTP request to the server after it has shut down. The bos_inst operation is considered complete even if the target does not immediately issue a BOOTP request. The target must issue a BOOTP request to load a network boot image from the server to start the installation. If the master is unable to contact the target system for any reason (for example, the system is turned off, it is not a running NIM client, or there is a network problem), a message is displayed and user intervention is then required at the target to issue the BOOTP request using the IPL ROM. By default (no_nim_client=no), NIM also includes the customization required for the target to remain a NIM client after the install. This customization includes the installation and configuration of the bos.sysmgt.nim.client fileset and its requisite filesets, bos.net.tcp.client and bos.net.nfs.client, so that the NIM master can communicate with and control the client after installation. The installp_flags are passed to the installp command for installing the software on the standalone client. The filesets attribute can be used to install a list of additional filesets or software packages from the allocated lpp_source. To display BOS installation status information while the installation is progressing, enter the following command on the master:
lsnim -a info -a Cstate ClientName
OR
lsnim -l ClientName
Errors in the allocation of a nim_script or boot resource type are fatal errors because the network BOS installation process cannot proceed without these resources. On the other hand, any error encountered during the attempt to cause the target to issue a BOOTP request is a nonfatal error to NIM because, at that point, NIM has successfully initialized the environment to perform a network installation. As soon as the target has successfully loaded its allocated network boot image, the BOS installation process begins. Using the force_push attribute: When assigned a value of yes, the force_push attribute tells NIM that the target of the bos_inst operation does not necessarily have the bos.sysmgt.nim.client fileset installed and configured. NIM will attempt to NFS mount or copy the minimal client support to the target system to perform an unattended installation or migration of the base operating system. If client support is copied to the target machine, NIM will automatically expand the necessary file systems on the target unless the auto_expand attribute to bos_inst is set to no. The force_push attribute requires that the client grant root rsh permissions to the master and that the key on the client be in the normal position. The force_push attribute also requires that a bosinst_data file be allocated to the target machine to indicate that a no-prompt installation should occur. The force_push attribute is set to yes by setting the Force Unattended Installation Enablement? option to yes when using SMIT to perform the bos_inst operation. Using the boot_client attribute:
253
When assigned a value of no, the boot_client attribute is used to instruct NIM not to attempt to initiate the BOS installation on the target machine after setting up the installation with the bos_inst operation. This allows a BOS installation to be set up while deferring the actual installation until the client is rebooted at a later time. Also, if the client is not a running machine, this attribute will avoid waiting for the reboot attempt to time-out or fail. If the installation of the client system is going to be initiated later from the server, the normal mode boot device list on the client must be set so that a network boot is attempted when the client is rebooted. No attempt is made to modify the boot list when boot_client is set to no unless the force_push or set_bootlist attributes are specified and set to a value of yes. The boot_client attribute is set to no by setting Initiate Boot Operation on Client to no when using SMIT to perform the bos_inst operation. Using the set_bootlist attribute: The set_bootlist attribute can be used with the boot_client attribute to modify the boot device list on the client for normal mode so a network boot is attempted when the client is rebooted. It is not necessary to specify the set_bootlist attribute if the force_push attribute is set to yes or if boot_client is unspecified or set to yes. In both instances, the boot list will be modified as the default. The only valid values for set_bootlist are yes and no. The set_bootlist attribute is set to yes by setting Set Boot List if Boot not Initiated on Client? when using SMIT to perform the bos_inst operation. Using the preserve_res attribute: The preserve_res attribute can be used to preserve the NIM database definitions for resources residing on a NIM client that is being reinstalled. When the preserve_res is set to yes, any resources that reside in file systems, which are being preserved by the BOS installation process, will also be preserved. accept_licenses attribute: The accept licenses attribute can be used to control when license acceptance takes place. If accept_licenses=yes is specified, license acceptance takes place automatically as packages are installed. If it is set to no, the user is prompted at the client to accept software licenses after the client is rebooted. The default is accept_licenses=no.
254
The target of a check operation can be any NIM client, a group of NIM clients, a Virtual Input or Server client, a SPOT resource, or a LPP_Source resource. The flags and attributes that can be specified for the check operation are as follows:
-F (optional) Notifies the NIM to force the operation, if the target is currently in use. If the -F flag is specified when the target is a SPOT resource, the flag forces the SPOT network boot images to be rebuilt. The -F flag is not required when you perform the check operation on client machines. If the-F flag is used in a check operation on a client machine, the default_profile attribute is re-created in case the attribute is old. Builds network boot images for aSPOT network in debug mode, if debug=yes is specified. This attribute is only valid if the target is a SPOT resource. The default value is debug=no. For more information on the debug attribute, refer to Producing debug output from a network boot image on page 302.
-a debug=Value (optional)
When applied to NIM clients, the check operation updates the machine state (Mstate) of the client. A ping test is performed to check whether the client is reachable. After the check operation is performed, the Mstate of the client is set to either running or not running. When the mgmt_profile attribute is set, the check operation checks the related HMC, CEC, IVM, VIOS, or BCMM object connection by using the ssh command for the NIM client object. When applied to SPOT resources, the check operation performs root synchronization for diskless and dataless clients. If required, the operation rebuilds the boot images of the SPOT network. When applied to LPP_Source resources, the check operation rebuilds the contents views (.toc) file in the LPP_Source directory. It also determines whether all filesets are included in the resources to qualify for the LPP_Source simages attribute.
The target of an chwpar operation can be a WPAR client or group of WPAR clients. There are no required attributes for the chwpar operation. The following optional attributes can be specified for the chwpar operation: -a cmd_flags=Value Specifies flags to pass through to the operation on the managing system to activate the system. See the command for allowable flags. -a group=Value Specifies the name of a WPAR group to use for the operation. -a show_progress=Value Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes.
255
See Customizing NIM clients and SPOT resources on page 131 for information on performing a software customization of standalone NIM clients. The command line syntax for the cust operation is as follows:
nim -o cust -a Attribute=Value ... TargetName |TargetNames
The target of a cust operation can be a standalone NIM client, a group of standalone NIM clients, or a SPOT resource. The following are required attributes that can be specified for the cust operation:
-a filesets=Value -a installp_bundle=Value -a lpp_source=Value Specifies a list of filesets to install on the target. This attribute is required unless an installp_bundle is used for the operation. Specifies an installp_bundle resource that lists filesets to install on the target. This attribute is required unless the filesets attribute is specified. Identifies the lpp_source resource that will provide the installation images for the cust operation.
The following are optional attributes that can be specified for the cust operation:
-a accept_licenses=Value Specifies whether software licenses should be automatically accepted during installation. If accept_licenses=yes, the -Y flag is passed on the installp command and licenses are automatically accepted. If accept_licenses=no, license processing is controlled by the installp_flags attribute. The default value is accept_licenses=no. Specifies whether NIM should perform operations on group members asynchronously and not wait for the operation to complete on one member before beginning the operation on the next. The default value is async=yes. Specifies the maximum number of machines from the selected group that should be installing at any given time. This attribute is only valid when the target of the operation is a machine group. If specified, NIM will monitor the progress of all machines in the group and attempt to keep no more or less than the number specified installing until all machines in the group are installed. Contains a list of fixes to install on the target. Fixes should be listed in the fix_bundle resource by APAR number with one number per line. Identifies a list of fixes to install on the target. Fixes should be listed by APAR number. For example, fixes="IX12345 IX54321". Specifies the name of a resource group to use for the installation. A resource group can be specified as an alternative to specifying multiple resources as separate attributes. If a resource group is specified, and it contains an lpp_source, the lpp_source attribute is no longer required. Identifies the flags that tell installp how to apply the filesets specified by the filesets, installp_bundle, fixes, and fix_bundle attributes. The default value is installp_flags=agQX. Specifies a resolv_conf resource for configuring domain and name resolution on a client. Specifies a script resource to be run on the target system after all software has been installed. Indicates whether status should be displayed while software is installed. The default value is show_progress=yes. Specifies the maximum number of hours that should elapse before ceasing to initiate installation of additional members of the selected group of machines. This value can only be specified when limiting the number of concurrent operations on a group.
-a async=Value
-a concurrent=Value
-a installp_flags=Value
The target of a deactivate operation can be a WPAR client or group of WPAR clients.
256
There are no required attributes for the deactivate operation. The following optional attributes can be specified for the deactivate operation: -a cmd_flags=Value Specifies flags to pass through to the operation on the managing system to deactivate the system. For WPAR clients, see the command for allowable flags. -a group=Value Specifies the name of a WPAR group to use for the operation. -a show_progress=Value Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes.
The target of a deallocate operation may be a NIM client or group of NIM clients. The following list includes all the attributes that can be specified for the deallocate operation:
-a ResourceType=ResourceName -a subclass=all Specifies the resource to deallocate from the client, for example, lpp_source=42_images. This attribute is required. Specifies that all resources should be deallocated from the target. This attribute is optional.
When a resource is deallocated from a client, the /etc/exports file on the resource server is modified to unexport the resource from the client. The allocation count for the resource is also decremented.
The attributes for the define operation vary for the different object types. For a complete description of the attributes required to define the various NIM objects, see Setting up NIM networks on page 175, NIM machines on page 104, Using NIM resources on page 217, and Using NIM groups on page 218. Note: NIM resource class objects should not be defined with a location attribute of /tmp or /tmp subdirectories (including filesystems mounted under /tmp).
257
The target of a diag operation can be any standalone NIM client or group of standalone NIM clients. The following are required attributes that can be specified for the diag operation:
-a spot=Value Specifies the SPOT resource to be used to provide network boot and diagnostics support.
The following are optional attributes that can be specified for the diag operation:
-a group=Value -a verbose=Value Specifies the name of a resource group to use for the operation. A resource group can be specified as an alternative to specifying multiple resources as separate attributes. Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output.
The target of a dkls_init operation can be any diskless NIM client or group of diskless NIM clients. The following are required attributes that can be specified for the dkls_init operation:
-a paging=Value -a spot=Value Specifies the paging resource that contains client paging files. Specifies the SPOT resource to be used to provide network boot support and the /usr file system for clients.
One of the following two attributes must be specified for the dkls_init operation:
-a root=Value -a shared_root=Value Specifies the root resource that contains the client root (/) directories. The root resource must be served by the same machine that serves the SPOT resource. Specifies the shared_root resource that contains the client root (/) directories. The shared_root resource must have been created from the same SPOT resource that is specified by the -a spot attribute.
The following are optional attributes that can be specified for the dkls_init operation:
-a dump=Value -a configdump=Value Specifies the dump resource that contains client dump files. Specifies the type of firmware-assisted dump to configure on the client. Valid values are: v selective, which avoids dumping user data. v full, which dumps all of the memory of the client partition. v none, which unconfigures the dump. The selective and full memory dumps are collected in the dump resource allocated to the client. Only POWER6 or later clients that have the appropriate firmware installed can dump to the dump resource. Specifies the name of a resource group to use for the installation. A resource group can be specified as an alternative to specifying multiple resources as separate attributes. Specifies the home resource that contains client /home directories. Specifies the resolv_conf resource to configure Domain Name Protocol name server information on the client. Specifies the shared_home resource that contains a common /home directory for multiple clients. Specifies the size in megabytes for client paging files. Specifies the tmp resource that contains client /tmp directories.
258
-a verbose=Value
Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output.
The dkls_init operation populates client directories and creates client paging files. A network boot image is also allocated to the client. When the client boots over the network, it obtains the boot image and is configured to mount the remaining resources.
The target of a dtls_init operation can be any dataless NIM client or group of dataless NIM clients. The following are required attributes that can be specified for the dtls_init operation:
-a dump=Value -a spot=Value -a root=Value Specifies the dump resource that contains client dump files. Specifies the SPOT resource to be used to provide network boot support and the /usr file system for clients. Specifies the root resource that contains the client root (/) directories. The root resource must be served by the same machine that serves the SPOT.
The following are optional attributes that can be specified for the dtls_init operation:
-a paging=Value -a group=Value -a home=Value -a resolv_conf=Value -a shared_home=Value -a size=Value -a tmp=Value -a verbose=Value Specifies the paging resource containing client paging files. Specifies the name of a resource group to use for the installation. A resource group can be specified as an alternative to specifying multiple resources as separate attributes. Specifies the home resource that contains client /home directories. Specifies the resolv_conf resource to configure Domain Name Protocol name server information on the client. Specifies the shared_home resource that contains a common /home directory for multiple clients. Specifies the size in megabytes for client paging files. Specifies the tmp resource that contains client /tmp directories. Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output.
The dtls_init operation populates client directories and creates client paging and dump files. A network boot image is also allocated to the client. When the client boots over the network, it obtains the boot image and is configured to mount the remaining resources.
The target of a fix_query operation can be any standalone NIM client, group of standalone NIM clients, or SPOT resource. The following are optional attributes that can be specified for the fix_query operation:
259
-a fix_bundle=Value -a fixes=Value
Specifies a fix_bundle resource containing a list of fix keywords. This attribute is required unless the fixes attribute is specified for the operation. Specifies a list of keywords for the fix_query operation. Fix keywords are APAR numbers used to identify software updates that can span multiple filesets. This attribute is required unless a fix_bundle is used for the operation. Specifies the name of a resource group to use for the operation. A resource group can be specified as an alternative to specifying multiple resources as separate attributes. Tells the fix_query operation how to display information. Valid flags are those used by the instfix command. Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes.
The target of a lppchk operation can be any standalone NIM client, a group of standalone NIM clients, or a SPOT resource. The following are optional attributes that can be specified for the lppchk operation:
-a async=Value Specifies whether NIM should perform operations on group members asynchronously and not wait for the operation to complete on one member before beginning the operation on the next. The default value is async=yes. Specifies a list of filesets on the target on which the lppchk operation will be performed. Tells the lppchk command how to perform software verification. Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes. Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output.
The NIM lppmgr operation is also available in SMIT using the nim_lppmgr fast path. The lppmgr operation does not check the lppmgr_flags attribute for conflicts. Note: Do not use the -p flag for prompting to move or remove installation images.
260
To list the names of duplicate filesets which should be removed with space usage information, type the following:
nim -o lppmgr -a lppmgr_flags="-lsb" lpp_source1
For more information on the lppmgr command, see the AIX Version 6.1 Commands Reference.
The target of a lswpar operation can be a WPAR client, group of WPAR clients, stand-alone client, or group of stand-alone clients. If the target is a stand-alone client or group of stand-alone clients, the operation lists information for WPARs which are on the target, regardless of whether or not those WPARs are NIM clients. There are no required attributes for the lswpar operation. The following optional attributes can be specified for the lswpar operation: -a cmd_flags=Value Specifies flags to pass through to the operation on the managing system to activate the system. See the command for allowable flags. -a group=Value Specifies the name of a WPAR group to use for the operation. -a show_progress=Value Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes.
The target of a maint operation can be a standalone NIM client, a group of standalone NIM clients, or a SPOT resource. The following are required attributes that can be specified for the maint operation:
-a installp_flags=Value Identifies the flags that tell installp what to do with the installed software.
The following are optional attributes that can be specified for the maint operation:
261
-a async=Value
Specifies whether NIM should perform operations on group members asynchronously and not wait for the operation to complete on one member before beginning the operation on the next. The default value is async=yes. Specifies a list of filesets to be maintained on the target. Specifies the name of a resource group to use for the operation. A resource group can be specified as an alternative to specifying multiple resources as separate attributes. Specifies an installp_bundle resource that contains a list of filesets to be maintained on the target. Indicates whether status should be displayed as maintenance is performed. The default value is show_progress=yes.
The target of a maint_boot operation can be any standalone NIM client or group of standalone NIM clients. The following are required attributes that can be specified for the maint_boot operation:
-a spot=Value Specifies the SPOT resource to be used to provide network boot and maintenance mode support.
The following are optional attributes that can be specified for the maint_boot operation:
-a group=Value -a verbose=Value Specifies the name of a resource group to use for the operation. Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output.
After the maint_boot operation is performed, the client must be rebooted over the network to load the network boot image and enter maintenance mode.
The target of a reboot operation can be any standalone NIM client or group of standalone NIM clients. The following are optional attributes that can be specified for the reboot operation:
262
-a inst_warning=Value
Indicates whether a warning should be displayed to warn users that the machine will be rebooted. The default value is inst_warning=yes.
The remove operation does not take any attributes. The target of this operation can be any network, machine, resource, or group in the NIM environment.
The target of a reset operation can be any NIM client, a group of NIM clients, or a SPOT resource. The following list includes all the flags and attributes that can be specified for the reset operation:
-F (optional) Tells NIM to "force" the operation if the target is currently in use.
When applied to NIM clients, the reset operation updates the control state (Cstate) of the client. After the reset operation is performed, the client's Cstate is set to ready, and it is possible to perform NIM operations on the client. Although the Cstate of the client is reset by the operation, resources are not deallocated automatically. For information on deallocating resources, see Using the NIM deallocate operation on page 257. When applied to SPOT resources, the reset operation updates the resource state (Rstate) of the SPOT. After the reset operation is performed, the SPOT's Rstate is set to ready, and you can use the SPOT in NIM operations.
The target of a select operation must be a group of NIM clients. The following are optional attributes that can be specified for the select operation:
263
Specifies the name of the group member to exclude from operations on the group. Indicates that all members of the group should be excluded from operations on the group. Valid values are yes and no. Specifies the name of the group member to include in operations on the group. Indicates that all members of the group should be included in operations on the group. Valid values are yes and no. Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output.
To display the group members that are included and excluded from operations, use the lsnim -g GroupName command syntax.
The target of a showlog operation can be any standalone NIM client, a group of standalone NIM clients, or a SPOT resource. The following are optional attributes that can be specified for the showlog operation:
-a full_log=Value -a log_type=Value Indicates whether the entire log is displayed or only the last entry. The default value is full_log=no. Specifies the type of log to display. The log types supported for both standalone clients and SPOT resources are: boot bosinst devinst lppchk nimerr Machine's boot log Output from the BOS installation program Output from the installation of key system and device-driver software Log of the output from the lppchk operation executed on a standalone NIM client Errors encountered during execution of the nim command
niminst Output from the installation of user-specified software (including installation of NIM client software during a bos_inst operation) Output from any configuration script resources allocated for a bos_inst operation. Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes. Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output. script
-a show_progress=Value -a verbose=Value
The target of a showres operation may be a SPOT, lpp_source, script, bosinst_data, image_data, installp_bundle, fix_bundle, resolv_conf, exclude_files, or an adapter_def resource.
264
The following are optional attributes that can be specified for the showres operation: -a client=Value Specifies which client's secondary adapter configuration file is displayed from an adapter_def resource. This attribute is only applicable when the target of the operation is an adapter_def resource. -a filesets=Value Specifies a list of filesets for which information should be displayed. This attribute is only applicable to lpp_source and SPOT targets. -a installp_flags=Value Specifies flags that tell the installp command how to format the display of filesets. This attribute is only applicable to lpp_source and SPOT targets. -a instfix_flags=Value Specifies flags that tell the instfix command how to format the display of fixes. This attribute is only applicable to lpp_source targets. -a lslpp_flags=Value Specifies flags that tell the lslpp command how to format the display of installed software. This attribute is only applicable to SPOT targets. -a reference=Value Specifies a reference machine or SPOT resource for fileset comparison. This attribute is only applicable when the target of the operation is an lpp_source. Available filesets in the lpp_source are compared against installed filesets in the reference machine or SPOT. If the showres operation is performed from a NIM client, the reference attribute is automatically set to the name of the client. -a resource=Value Specifies the name of the resource whose contents should be displayed. This attribute is only necessary when the showres operation is performed from a NIM client. -a sm_inst_flags=Value Specifies flags that tell the sm_inst command how to format the display of filesets. This attribute is only applicable to lpp_source and SPOT targets. This attribute must be used in conjunction with the reference attribute and is normally used only within the SMIT application. Note: There are no required attributes for the showres operation. v When the target of the showres operation is a SPOT, the list of filesets installed in the SPOT is displayed. v When the target of the showres operation is an lpp_source, the list of filesets contained in the lpp_source is displayed. v For all other resources that are valid targets for the showres operation, the character contents of the files are displayed.
The target of a sync operation must be an alternate_master. The following are optional attributes that can be specified for the sync operation:
Installation and migration
265
-a verbose=Value -F
Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output. Specifies that NIM should force the operation. Use the force operation if the database on the alternate_master should be overwritten.
The target of a sync_roots operation must be a SPOT resource. The following are optional flags and attributes that can be specified for the sync_roots operation:
-a num_parallel_syncs=Value Specifies the number of client root directories to simultaneously synchronize with the SPOT's root files. Valid values are numeric. The default value is num_parallel_syncs=5. Specifies that NIM should force the operation.
-F
A sync_roots operation can be performed automatically when the check operation is performed on a SPOT.
The target of an syncwpar operation can be a WPAR client, group of WPAR clients, stand-alone client, or group of stand-alone clients. If the target is a stand-alone client or group of stand-alone clients, the operation applies to the WPARs which are on the target, regardless of whether those WPARs are NIM clients. There are no required attributes for the syncwpar operation. The following optional attributes can be specified for the syncwpar operation: -a cmd_flags=Value Specifies flags to pass through to the operation on the managing system to activate the system. See the command for allowable flags. -a group=Value Specifies the name of a WPAR group to use for the operation. -a show_progress=Value Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes.
266
The alternate master attempts to become the current master of each client defined in its database by updating each client's /etc/niminfo file. This operation also attempts to update the database on the target alternate_master. The command line syntax for the takeover operation is as follows:
nim [-F] -o takeover -a Attribute=Value ... TargetName
The target of a takeover operation must be an alternate_master. The following are optional attributes that can be specified for the takeover operation:
-a verbose=Value -a show_progress [yes | no] -a async= [yes | no] -F Displays information for debugging. Valid values are 1-5. Use verbose=5 to show maximum detail. The default is to show no debugging output. Indicates whether status should be displayed as the operation is performed. The default value is show_progress=yes. If this attribute is set to "yes", then the clients will be updated with the new master information asynchronously. The default is to run this command asynchronously. Specifies that NIM should force the operation. Use the force operation if the database on the alternate_master should be overwritten.
The target of the unconfig operation must be the NIM master. No attributes can be specified for the unconfig operation. The unconfig operation completely unconfigures the NIM master by performing the following: v Removes the nimesis and nimd daemon entries from the System Resource Controller (SRC) v Removes all data from the nim_attr and nim_object databases
The NIM update operation is also available in SMIT using the nim_update fast path. The source attribute must be a directory or device that is local to the server of the target lpp_source resource or an existing NIM lpp_source resource. The default operation is to add packages to the target
Installation and migration
267
lpp_source. If the rm_images attribute is present, the operation will remove packages from the lpp_source. A user must specify either the source or rm_images attribute and must specify the packages, installp_bundle, or smit_bundle attribute, but not more than one. Generally, the all keyword means to perform a multi-volume installation when the source is a CD-ROM. However, the update operation will only do a single volume copy (equivalent to passing the gencopy -S flag). The default behavior for this command is to display output. To turn off the output, pass show_progress=no. To add packages to an lpp_source resource, run the following:
# nim -o update -a packages=all -a source=/tmp/inst.images lpp_source1
The target of an updateios operation can be a VIOS NIM management client or an IVM NIM management client. The following are optional attributes that can be specified for the updateios operation:
Attribute -a filesets=Value -a installp_bundle=Value -a lpp_source=Value -a accept_licenses=Value Description Specifies a list of file sets to remove from the target. Specifies an installp_bundle resource that lists file sets to remove on the target. Identifies the lpp_source resource that will provide the installation images for the updateios operation. Specifies whether the software licenses should be automatically accepted during the installation. The default value is accept_licenses=no. Identifies the flags that tell updateios what operation to perform on the VIOS. The valid values are -install, -commit, -reject, -cleanup and -remove. The default value is updateios_flags=-install. Specifies a preview operation for the updateios operation. The default value is preview=yes.
-a updateios_flags=Value
-a preview=Value
Using EZNIM
The SMIT EZNIM feature organizes the commonly used NIM operations and simplifies frequently used advanced NIM operations. Features of SMIT EZNIM include: v Task-oriented menus v Automatic resource naming that includes the level of the software used to create NIM resources. v The user can review what steps will take place before executing a task, whenever possible.
268
Use the SMIT eznim fast path to open the EZNIM main menu. If the NIM environment has not been set up on your system, the EZNIM main menu displays the following options: v Configure as a NIM Master v Configure as a NIM Client
v To configure your current system as a NIM master, select Setup the NIM Master environment. You can select the software source to configure from, select the volume group to use for the NIM resources, and select the file system to use for the NIM resources. When the NIM master environment is configured, the basic NIM resources are created. To view the NIM resources created by EZNIM, select Show the NIM environment, or run the lsnim command on the NIM master. v To configure your NIM master for SSL authentication, select Enable Cryptographic Authentication. This option allows you to install and configure the cryptographic software in the OpenSSL RPM package. After you configure OpenSSL, NIM clients with OpenSSL installed can request cryptographic authentication during service requests from the NIM master. v To install updates and maintenance or technology level packages to the NIM master, select Add fixes to the NIM Master environment. This option performs an update installation of a specified set of fixes onto the default SPOT resource. A second SPOT resource containing the newly installed fixes is created by this operation. You can optionally select to update all your NIM clients during this operation. v To update a client using EZNIM, select Update clients. This option allows you to perform an update_all operation on a selected client (or clients) using an lpp_source resource. v To back up a client using EZNIM, select Backup a client. This option allows you to create a system backup image of a selected client and store the backup image on the NIM master. v To reinstall a client using EZNIM, select Reinstall clients. This option allows you to perform a mksysb restore or native, rte install on a selected client (or clients). You must then select a system backup image to restore or an lpp_source to install and decide whether to reboot and install the client now. v To reset a NIM client to the ready state, select Reset clients. This option resets the state of a client or clients in the NIM environment. Use this option after a NIM operation has failed, and you want to return the client to the ready state.
269
Add this system to a NIM environment Configure Client Communication Services Update this system Reinstall this system Reset this system Show the NIM environment
v To define your client in the NIM environment, select Add this system to a NIM environment. v To configure your NIM client for SSL authentication, select Configure Client Communication Services. This option allows you to install and configure the cryptographic software in the OpenSSL RPM package. After you configure OpenSSL, you can select nimsh as the communication protocol used by the client. Any incoming NIM master service requests are then authenticated through SSL socket connections. v To update your client, select Update this system. This option allows you to perform an update_all operation on your client using an lpp_source resource. v To reinstall your client, select Update this system. This option allows you to perform a mksysb restore or native, rte install on a selected client (or clients). You must then select a system backup image to restore or an lpp_source to install and decide whether to reboot and install the client now. v To reset your client in the NIM environment, select Reset this system. This option resets the state of the client in the NIM environment. Use this option after a NIM operation has failed, and you want to return the client to the ready state. v To view the default resources in the EZNIM environment, select Show the NIM environment. The resources are defined using EZNIM Master Operations.
Select or specify software source to initialize environment: Select Volume Group for resources Select Filesytem for resources Options CREATE system backup image? CREATE new Filesystem? DISPLAY verbose output?
[rootvg] [/export/eznim]
+ + +
For Select Volume Group for resources, select your volume group. If you prefer to use a different filesystem than the default /export/eznim, then fill in the desired value in the Select Filesystem for resources field. The nim_master_setup command can also be used to select a different volume group or filesystem by specifying the flag attribute (-a file_system=<value> or -a volume_group=<value>). You can enter the value for filesystem and rootvg. To define NIM resources in using install media located in device /dev/cd0, and create a new filesystem named /export/nimfs under volume group myvg, type:
270
Note: If the /export/nimfs filesystem does not currently exist, then is created under the myvg volume group. If the myvg volume group does not exist, it is created using the next empty physical volume (disk) since the disk attribute was not specified.
# Truncate the host name # if the host name is set to the fully qualified host name # #NOTE: This procedure will NOT result in a truncated host name if #the bos installation operation is installing a mksysb image #(ie. -a source=mksysb) unless the bos_inst operation is #instructed not to configure the target as a NIM client upon #completion (ie. unless -a no_nim_client=yes is specified) # chdev -l inet0 -a hostname =$(/usr/bin/hostname | cut -d. -f1) # Set Name server and Domain Name if [[ -f /etc/resolv.conf ]] then /usr/sbin/namerslv -E /etc/resolv.conf.sv fi /usr/sbin/namerslv -a -i 9.101.1.70 /usr/sbin/namerslv -c enterprise.ca # Flush routing table and add default route /etc/route -n -f odmdelete -o CuAt -q "name=inet0 and attribute=route" chdev -l inet0 -a route=net,,0,9.101.1.70
# Define the machine "lab1" # Take all defaults. lab1: # Define the machine "lab2" # Take all defaults and specify 2 additional attributes. # The machine "lab2" uses IPL ROM emulation, and will be added to
Installation and migration
271
# the machine groups "all_machines" (by default) and "lab_machines". lab2: ipl_rom_emulation = /dev/fd0 machine_group = lab_machines # Define the machine "lab3" # Take all defaults, but do not add the machine to the # default group. lab3: machine_group= # # # # Define the machine "lab4" Take all defaults, but do not add "lab4" to the default group "all_machines". Instead add it to the groups "lab_machines" and "new_machines".
lab4: machine_group = machine_group = lab_machines machine_group = new_machines # Change the default "platform" attribute. default: platform = rspc # define the machine "test1" # Take all defaults and include a comment. test1: comments = "This machine is a test machine."
To print out the subject, issuer, and enddate values for certificate(s):
# certview -I certificate_name
272
The file is located in the /usr/samples/nim/ssl directory. The file is provided for helping users store a desired password for decrypting the NIM master's client key. The password provided must match the password used to encrypt the NIM master's client key during NIM SSL configuration. To load the encrypted key's password in the NIM environment:
# certpasswd
Only the NIM master's client key may be password encrypted. To password encrypt the NIM master's client key, complete the following steps: 1. On the NIM master, edit the /ssl_nimsh/configs/client.cnf config file. 2. Locate the encrypt_key variable and change the value to yes. 3. Add the output_password variable underneath encrypt_key and specify the password. If you do not specify output_password, you will be prompted for the password during key generation. 4. Type the following command:
# make -f /usr/samples/nim/ssl/SSL_Makefile.mk client
5. On each SSL client, copy the new server.pem file using the nimclient -c command. 6. Load the password into the NIM environment using certpasswd. When you use password encrypted keys, NIM commands may fail with the following error if the correct password is not loaded:
0042-157 nconn: unable to access the "clientkey.pem" file
After the password is loaded, it will be used for client key decrypting until you unload the password.
v Refines the exports list v Recycles the NFS services v Re-exports NFS file systems and directories
Examples
To create a simple KDC environment using default values, type the following command:
config_rpcsec_server
273
To create a KDC environment using system user nimadmin as the user principal and password l0gin1 for the kadmin principal, type the following command:
config_rpcsec_server -p l0gin1 -u nimadmin
Examples
To create a simple KDC slim client using default values, type the following command:
config_rpcsec_client
To create a simple KDC slim client using system user nimadmin as the user principal, type the following command:
config_rpcsec_client -u nimadmin
Troubleshooting NIM
Solutions for network boot problems and procedures for producing debug output for NIM BOS installations is described. Refer to NIM error and warning messages for information about error messages.
274
of the problem cannot be readily determined by NIM. In the latter case, additional messages or output from the command often reveal the nature of the problem. All NIM error messages begin with 0042 and are followed by a three-digit error code. Note: 1. If you require usage information for a NIM command, type the command without any parameters or with a question mark as a parameter (for example, nim -?). Additional information can be obtained from the lsnim command, which provides several options to display NIM help and usage information. For more information, refer to the -q, -O, and -P options of the lsnim command. You can also use the lsnim -p -a command to display information for all NIM classes, subclasses, types, and attributes. For example, to determine the list of valid values for an attribute, enter:
lsnim -p -a AttributeName
2. In some cases, a nim or nimclient operation that is being blocked because an object is in a particular state may be permitted with the use of the force option (the -F flag). However, by using the force option, you may adversely affect part of the NIM environment by forcing an operation that should only proceed after other actions are complete. Use error messages that are displayed without using the force option to determine if the force operation is a reasonable action. 3. If you believe that your problem is the result of a software defect, or if the User Actions provided here do not provide adequate resolution to a problem, contact your point of sale. Information about each message listed in this chapter is organized in the following manner:
Message Explanation User Action Indicates the warning or error message ID number returned by the command Describes what is likely to have caused the message to be displayed Suggests a possible resolution to the problem
Note: If a User Action for a given error or warning specifies using the lsnim command for recovery hints, and if you are operating from a NIM client, use nimclient -l lsnimOperations, substituting the suggested lsnim options as appropriate.
Message Explanation 0042-001 An error was detected by an underlying NIM method (a subcommand). This message describes where the error occurred with respect to the NIM client or master and may be useful in troubleshooting the problem. The messages that are displayed subsequent to this error are normally the true source of the problem. Read the additional information and error messages, and refer to their explanation and recovery hints as appropriate. 0042-002 An interrupt signal has been received, perhaps because the user entered Ctrl-C or used the kill command on a NIM process. The NIM operation that was active has been interrupted. Perform the operation again. Note: This error is expected if it occurs after the nimclient -o bos_inst operation is performed on a client. 0042-003 and 0042-004 An error has been returned from a system call. Fix the condition that caused the system call to fail and perform the operation again. 0042-005 The Object Data Manager (ODM) has returned an error. Refer to the Message Database located on the Information Center Web page for specific details of the error. Fix the ODM problem and perform the NIM operation again. 0042-006 Generic error message used for rarely occurring NIM errors.
User Action
Message Explanation
275
User Action
Phrases contained in this error message are constructed from debug information and from messages returned by commands called by NIM. If the content of the message does not give insight into the true cause of failure, contact your point of sale. 0042-007 An internal NIM error has occurred. Try the operation again. 0042-008 NIM has attempted to establish socket communications with a remote machine, and it has refused the connection. If the failing operation occurred on the master, verify that the master has rsh permissions on the client and that inetd is active on the client; otherwise, verify that the nimesis daemon is active on the master. If the failing operation was the niminit command on the client, a possible cause of failure is that the master does not have a network object that corresponds to the client's network. A network object that represents the client's network needs to be added to the database on the master; then a route needs to be added from the master's network to the client's network. If the failure occurs during operations initiated from a client, using the nimclient command, or during a NIM installation of the base operating system, the cpuid attribute on the client's machine definition may be obsolete (for example, if the machine's system planar was recently replaced). To guarantee that this is not the case, erase the cpuid from the machine definition by issuing the following from the master: nim -Fo change -a cpuid= ClientName
0042-011 The /etc/niminfo file is not accessible. The niminfo file is required by all NIM commands and methods. This file is created when the bos.sysmgt.nim.master and bos.sysmgt.nim.client packages are configured. If this file is not available, this indicates that the NIM package has not been initialized or that this file has been deleted. To create the niminfo file, execute the nimconfig command on the master or the niminit command on the client. To recreate a deleted or corrupted niminfo file, enter from the master: nimconfig -r OR enter from the client: niminit -aname=ClientName -amaster=MasterHostName -amaster_port=MasterPortValue
0042-012 The specified command may only be executed on the master. Execute the desired operation on the NIM master. 0042-013 The global lock used for synchronized access to the NIM database could not be obtained. Try the operation again. If the same error is returned, verify that there are no active NIM commands. If this is true, remove the /var/adm/nim/glock file and try the operation again. If the file does not exist and the error persists, contact your point of sale. 0042-014 An internal NIM error has occurred. Perform the remove operation on the NIM object followed by the appropriate define operation. 0042-015 A syntax error has been detected. Refer to the appropriate man page for the NIM command and try again using valid syntax. 0042-016 An invalid option has been specified. Refer to the appropriate man page for the NIM command and try again using valid syntax. 0042-017 An invalid value was specified for an option argument.
Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation
276
User Action Message Explanation User Action Message Explanation User Action Message Explanation
Refer to the appropriate man page for the NIM command and try again using valid syntax. 0042-018 A required option was not supplied. Refer to the appropriate man page for the NIM command and try again using valid syntax. 0042-019 An option that requires an argument was specified without its argument. Refer to the appropriate man page for the NIM command and try again, specifying the missing argument. 0042-20 An operand was required but not supplied. Usually, the operand is the NIM object to which a given operation is being applied (that is, a NIM name for a network, machine or resource object that is the target of the NIM operation). Refer to the appropriate man page for the NIM command and try again using valid syntax. If you do not know the name of an operand, and if the failing operation was targeted toward an existing NIM object, enter: lsnim -l -t ObjectType OR lsnim -l to determine the operand name.
User Action
0042-021 A NIM attribute was required for the operation. Specify the missing attribute. If the failing command is the nim or nimclient command, to obtain a list of attributes, enter from the master: lsnim -q ObjectName OR lsnim -q -t ObjectType OR enter from the clients: nimclient -l lsnimOptions For the other NIM commands, see the appropriate NIM man page.
0042-022 A value was specified that exceeds the bounds of acceptable values. Supply a value within the acceptable bounds. 0042-023 The specified value is not valid. Try the command again with a valid value. To determine the valid values for classes of objects and operations as they pertain to those objects, enter: lsnim -Pc ObjectClass AND lsnim -POc ObjectClass where ObjectClass is one of machines, networks, or resources.
0042-024 An invalid NIM object type was specified. Specify a valid NIM object type. See user actions for error 023 for lsnim options to determine a valid object type. 0042-025 The specified operation cannot be supplied to the specified NIM object.
Message Explanation
277
User Action
Specify an operation that can be applied to the object. Enter lsnim -O ObjectName for a list of valid operations that can be applied to the object. 0042-027 The specified object is missing an attribute that is required to complete the specified operation. Redefine the object that is missing an attribute by performing the remove operation followed by the define operation. 0042-028 and 0042-029 The specified information cannot be supplied in the current context. Try the operation again without supplying the offending attribute. 0042-030 A sequence number was opened to an attribute that doesn't allow sequence numbers. Try the operation again without a sequence number on the offending attribute. 0042-031 An internal NIM error has occurred. NIM is unable to generate a unique object ID. Try the operation again. 0042-032 The specified value for the attribute is not unique and it must be. Supply a unique value for the attribute. 0042-033 The specified value is not unique and it must be. An attribute with a sequence number requires a unique value. Supply a unique value. 0042-034 The specified value is not unique and it must be. Supply a unique value. 0042-035 NIM was attempting to access an attribute that had the specified characteristics, but the attribute doesn't exist. Make sure the attribute exists and retry the operation. 0042-036 The define operation failed for a resource because the specified server does not have a standalone configuration. Try the operation again using a NIM client that is a standalone machine. 0042-037 The NIM state of the specified object prevents the operation from succeeding. NIM states are used to synchronize activity among NIM objects. To perform the desired operation, the state of the specified object must be changed. If the specified object is in an unexpected state, check the system to make sure another user or process is not manipulating the object. Use the reset operation to set the object to a known state and try the operation again. 0042-038 An object that NIM would operate on is already locked and thus cannot be operated on. NIM object locks are used to synchronize activity among NIM objects. These locks are temporary, so try the operation again after some delay. The value of the lock is the process ID of a NIM process that is using the lock. If the lock persists and no NIM commands are active, reset all NIM locks by stopping the nimesis daemon, then restarting it. 0042-039 The operating system version or release level of the specified object is unacceptable. Perform the desired operation on objects that have the appropriate operating system version and release levels.
Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action
278
0042-040 A NIM object could not be removed because it is being used by some other NIM object. Remove all references to the object to be removed before the remove operation is specified. If NIM states are such that you cannot remove references to the object and you want to remove the object anyway, provide the -F flag to the remove operation. 0042-041 A specified value has already been defined to NIM. Specify a value that isn't already known to NIM. Note: If /etc/niminfo is the value and the NIM command producing this error is niminit, this means that niminit has already been performed. If you want to reinitialize your NIM master or client, deinstall the appropriate fileset, and then reinstall and reconfigure the NIM master or client fileset. 0042-042 The specified machine could not be reached with the ping command from the master. If the operation you were attempting to perform requires that the target machine be running and that it can be reached, then verify that the machine is currently running. If not, turn it on; otherwise, perform network diagnostic procedures to determine why the master could not reach the target machine. 0042-043 The remove operation cannot be performed, because the target machine currently serves a NIM resource that has been allocated for use. Performing the operation at this time could lead to processing failures on clients that are attempting to use the served resources. You need to deallocate all resources that the target serves before you can remove the machine. 0042-044 You have specified a NIM attribute without an accompanying value. Most NIM attributes can only be specified with a value assigned to them in the form of attr=value. Retry the operation with a value assigned to the specified attribute. 0042-045 Some NIM attributes can be added to an object's definition more than once. In these cases, a sequence number is used to uniquely identify each attribute of that type. In this case, you have specified an attribute of this type without its required sequence number and, therefore, NIM is unable to determine which attribute you are attempting to specify. Verify the sequence number and try the operation again. 0042-046 NIM was unable to perform an operation on the specified file. This may be due to the permissions on the file. The file usually needs read, write, and, in some cases, execute permissions for root. Change the permissions of the specified file and try the operation again. 0042-047 Some types of NIM resources may only be used by specific machine types. In this case, you attempted to allocate a NIM resource to a type of machine that is not allowed to use that type of resource. Specify a resource type that the machine is allowed to use when performing allocation for the target machine. To determine the valid resource types, enter: lsnim -p -s ResourceSubclassForMachineType To view the subclasses that are available, enter: lsnim -p -S
Message Explanation
User Action Message Explanation User Action Message Explanation User Action
Message Explanation
0042-048 When resource allocation is requested, NIM verifies that the designated client has the potential to communicate with the server of the resource. NIM does this by checking the NIM routing between the network that the client's primary interface connects to and all the networks that the server connects to. In this case, a NIM route is missing between the client and the server. Either establish a NIM route between the client and the server or choose a different resource to allocate. 0042-049
279
Only one resource of this type may be allocated to the client and one has already been allocated. Choose the resource that you want to use and deallocate the currently allocated resource of this type if you want to use the new one. 0042-051 NIM was unable to resolve a host name to an IP address or the other way around. All host names that are used in the NIM environment must be resolvable. Perform the appropriate network administration tasks to ensure that the specified host name is resolvable and try the operation again. 0042-052 One or more NIM resources are still allocated to the machine that you have requested to be removed from the NIM environment. To remove a machine, it cannot have any resources allocated to it. Deallocate all resources that have been allocated to the target machine and try the operation again. 0042-053 You have specified the name of a NIM object that does not currently exist in the NIM environment. NIM can only operate on objects that have been defined to NIM. Verify that you have spelled the name of the object correctly and that it has already been defined. The name of a target machine for a NIM operation must be the NIM name, not the host name. Enter: lsnim -l -t ObjectType OR lsnim -l to obtain listings of currently defined objects in the NIM environment. If you need to define the object, use the define operation.
Message Explanation
0042-055 Many NIM operations require a source for installable images. You have specified a source that cannot be used for this operation. Examples of valid sources for NIM operations are: v /dev/rmt0, /dev/cd1 for lpp_source definition v rte, spot, mksysb for bos_inst operation Try the operation again using a source that the operation can use. 0042-056 You have specified the same attribute assignment more than once. Try the operation again using only one instance of the attribute assignment. 0042-058 You have attempted to allocate a SPOT to a client whose primary network interface type or platform is not supported by the SPOT. For a client to use a SPOT, the SPOT must support the network interface type and platform of the client's primary interface. Install the appropriate device support into the SPOT, which will allow the SPOT to support the client's primary interface type and platform, or choose a different SPOT that supports the client's primary interface type and platform. 0042-059 In an attribute assignment (in the form of attr=value), the value you have specified represents a NIM object whose type conflicts with the object type of the specified attr. Try the operation again using the attr that corresponds to the type of object that value represents. 0042-060 You have specified multiple attribute assignments for an attribute that may only be specified once. Try the operation again, using only one instance of the attribute. 0042-061 You have requested an operation to be performed on a NIM resource object that is currently allocated for client use. NIM is not allowing this operation to be performed because it may interrupt the client's use of the resource.
User Action
Message Explanation User Action Message Explanation User Action Message Explanation
280
User Action
Try the operation again when the resource is not allocated for client use. If necessary, try the force option (-F flag) to disregard the preventive check by NIM. In some cases, NIM will allow the operation to be performed. 0042-062 The NIM object that was operated on is missing something that is required for its definition to be complete. List information about the object using the lsnim command. Each item that is missing from the object's definition will be represented by a missing attribute. Perform the appropriate NIM operation that will add the missing item to the object's definition. For a SPOT, if network boot images are missing, apply the check operation to the SPOT. If software filesets are missing from a SPOT, allocate an lpp_source that contains the required filesets and apply the cust operation to the SPOT. 0042-063 Some NIM operations require access to one or more NIM resources to complete successfully. This access is granted through the allocate operation. In this case, you have not allocated all the resources that are required for this operation. Allocate all the required resources and try the operation again. For a list of required and optional resources for a given operation, enter: lsnim -q Operation ObjectName OR lsnim -q Operation -t ObjectType
Message Explanation
User Action
Message Explanation
0042-064 The machine that is the target of the requested operation currently serves a NIM resource that is allocated for client use. The requested operation cannot be performed until all resources that the target serves have been deallocated for use. Deallocate all resources that the target serves and try the operation again. 0042-065 You have specified a name that is reserved for NIM internal use only. Try the operation again using a different name. To determine what names are reserved, enter: lsnim -a reserved
Message Explanation
0042-066 You have specified one or more characters that are not allowed in NIM object names. NIM uses regular expressions to perform many of its operations, so any character that has special meaning for regular expressions cannot be used (for example, ^). Also, any character that has special meaning to the shell cannot be used (for example, /). Try the operation again using valid characters. 0042-067 You have requested an operation to be performed on a NIM object that has been reserved for NIM internal use only. Try the operation again, using a NIM object that is not reserved. To determine what objects are reserved, enter: lsnim -a reserved
Message Explanation
User Action
0042-069 The requested operation cannot be performed at this time because it conflicts with the current NIM state of the target. NIM uses states to synchronize NIM activity so that operations don't interfere with each other. Try the operation again when the state changes or, if necessary, try using the force option (-F flag). In some cases, NIM will allow you to override this state checking. If you encounter this error as a result of trying to remove, using the reset operation, the boot resource from a client that incorrectly has a state of "ready for a NIM operation", you can remove the boot resource from the NIM master by entering: /usr/lpp/bos.sysmgt/nim/methods/m_dealloc_boot client_name where client_name is the name of the NIM object for the client.
281
Message Explanation
User Action
0042-073 To perform customization on a machine, NIM constructs a shell script that is executed on the target. To construct this script, some type of resource that can be used for customization must be used. In this case, NIM could not create the customization script because no resources have been allocated to the target that could be used for customization purposes. Allocate one or more resources that can be used for customization and try the operation again. To display the subclass of resources that can be used for customization, enter: lsnim -p -s cust_res
Message Explanation User Action Message Explanation User Action Message Explanation User Action
0042-074 You have specified an attribute assignment in which the value represents a relative path name. NIM only allows absolute path names (that is, path names that begin with /) to be used. Try the operation again, using an absolute path name. 0042-075 The requested operation requires that a NIM resource be exported for a machine's use. In this case, NIM attempted to export the resource but an error was returned by an NFS utility. Fix the error condition that the NFS utility reported and try the operation again. 0042-076 You have specified a port number that is already in use. Try the operation again, using a port number that is currently not being used. Check the /etc/services file. Note: NIM uses both the specified port number and its successor. Therefore, ensure that the port number after the specified port number is also free. 0042-077 The niminit command is used to join the NIM environment. When executed, this command attempts to add routing information that the NIM master has determined the client needs to participate in the NIM environment. In this case, one or more of the required routes could not be added. Perform the appropriate network diagnostic task to determine why the route could not be added. 0042-078 You have specified a change to a NIM routing attribute in which the destination network is different from its current value. This is not allowed because only the gateway field of the routing attribute may be changed. If you are trying to change the connectivity between NIM networks, then you must remove the current NIM route by supplying a NULL value for the appropriate routing attribute. Otherwise, specify the same destination network when attempting to change the gateway field of the routing attribute. 0042-079 In the NIM environment, one resource may depend on another for information. In this case, an allocated resource has a dependency on the resource you have specified for deallocation. Deallocate the resource that is dependent on the resource causing the error. 0042-081 NIM uses NFS to make remote resources available for client use. To avoid NFS export errors, NIM enforces some restrictions on where a resource can be defined. In general, a NIM resource cannot be defined within a directory that is already a NIM resource. Conversely, a NIM resource cannot be defined for a directory that already contains an existing NIM resource. Move the resource to a location that adheres to NIM export rules and try the operation again. 0042-083 Each network communications adapter has an associated network hardware address that is unique. In this case, you attempted to define a NIM network interface using a network hardware address already being used by a NIM machine object. Only one NIM interface attribute may be defined for each network communications adapter a client might have. If you are attempting to add another interface definition, then verify that the hardware address is correct. If so, then you must first change the interface attribute that is currently using that address. If not, try the operation again with the correct hardware address.
Message Explanation
User Action
User Action
282
0042-084 The machine has already been configured to be a NIM master. If you want to reconfigure the machine as a NIM master, enter nim -o unconfig master, then deinstall and reinstall the master fileset. You may then run the nimconfig command. 0042-086 You have attempted to add a NIM route between two NIM networks that already have a NIM route between them. Only one NIM route can be specified between any two NIM networks. If you are attempting to change NIM routing, delete the existing NIM route and try the operation again. 0042-093 NIM attempted to create a directory, and the mkdir command returned an error. Fix the error reported by the mkdir command and try the operation again. 0042-109 To complete the requested operation, NIM requires information about one or more file systems about which it was unable to obtain information. Verify that the file systems exist. If not, either specify the correct path name when performing the NIM operation or redefine the NIM environment so that all the participating file systems exist. 0042-111 When a sequence number is specified for a NIM attribute, it must be within a specific range. You have specified a sequence number that falls outside of the acceptable bounds. Try the operation again using a sequence number that is within the acceptable bounds. 0042-113 To complete the requested operation, NIM requires information about the size of one or more objects, which NIM was unable to determine. If the object is a file or directory that does not exist, then create the file or directory and try the operation again. 0042-118 You have requested to change characteristics of a NIM network on which there is currently one or more active NIM operations. NIM is not allowing the change because changing the network characteristics at this time could result in failures in the active operations. Wait until the NIM resources allocated to machines that use the network being changed have been deallocated and try the operation again. 0042-121 An invalid value has been specified. Try the operation again, using a valid value. 0042-124 An NFS option was specified that is not supported. Try the operation again using valid NFS options. Refer to NFS Problem Determination in Networks and communication management. 0042-129 An invalid resource type was specified for this operation. Use the lsnim -q Operation -t TargetType command to view a list of required and optional resources for Operation when applied to TargetType. 0042-130 You have specified an attribute that cannot be used for this requested operation. Try the operation again, without using the attribute you specified. 0042-131 You have specified two or more attributes that conflict with each other. Try the operation again, using only one of the attributes. 0042-132 Installation and migration
Message Explanation User Action Message Explanation User Action Message Explanation User Action
Message Explanation
User Action
283
You have specified a value for an attribute assignment that is invalid in the context in which the operation is being performed. Try the operation again, using a different value for the attribute assignment. 0042-133 The physical entity that is represented by the NIM resource object you have requested to be deleted could not be deleted. Delete the file or directory, using the rm command. 0042-134 The operation you requested requires the designated target to reboot using a network boot image. NIM has automatically initialized the environment to enable the target to do this; however, NIM was unable to force the target to load the network boot image. Intervention at the target is required. Follow the procedures for initiating a BOOTP request. 0042-135 To synchronize NIM operations that can be initiated from a client or on the master, NIM keeps track of which machine (the client or the master) is used to allocate the first resource to the client; this machine is said to be in control. For example, if the first resource allocation occurs from the client, then the client is in control. Once a machine has control, it remains in control until all resources for that client have been deallocated. You have requested an operation to be performed from a machine that is currently not in control of the specified target. Perform the desired operation from the machine that is in control of the target, or from the controlling machine deallocate the resources (to remove the control), or override this behavior by using the force (-F flag) option when performing the operation from the master. 0042-136 The requested operation cannot be performed because a NIM route does not exist between two machines that participate in this operation. Establish a NIM route between the networks. 0042-137 The /etc/niminfo file contains information about the NIM environment that all NIM commands require. In this case, the /etc/niminfo file is missing some information that is required to continue, which indicates that the file has been corrupted. Reinitialize the NIM environment. 0042-138 Unable to update the rhost file. Edit the $HOME/.rhosts file for root on the client machine to add an entry for the host name of the NIM master. 0042-139 The process of installing a machine prevents any attached disks from being used as the source for installable images. You have allocated a resource to the target of the install operation that is served by the target itself. Deallocate the resource, allocate another resource of this type that is served by another machine, and try the operation again. 0042-140 You have requested that a machine object be removed from the NIM environment and this has been done; however, NIM was unable to remove the /etc/niminfo file on the machine that has been removed from the NIM environment. Remove the /etc/niminfo file from the machine that was removed from the NIM environment. Note: Verify that the .rhost permissions for the master have been removed from the client. 0042-141 By specifying an attribute assignment with a NULL value, you have requested NIM to remove the specified attr. However, in this case, the specified attr is not currently part of the specified object's definition. Try the operation again, using an attribute that is part of the object's definition.
User Action
Message Explanation
User Action
Message Explanation
User Action
Message Explanation
User Action
284
0042-142 All attribute values must be unique. You have specified a value in an attribute assignment that already exists. Try the operation again, using a unique value for the attribute. 0042-143 Some NIM attributes can only be added to an object's definition once. In this case, you have specified an attribute of this type when one already exists for the specified object. Only one attribute of this type can be used in the object's definition. Perform the change operation on the object if you want to replace the current value with a new one. 0042-144 Some NIM attributes require a unique sequence number so that NIM can distinguish between multiple attributes of that type. In this case, you have specified a sequence number that is already being used. Try the operation again, using a sequence number that is not currently being used. To display the sequence number that are being used, enter: lsnim -a AttributeName ObjectName
0042-145 You have specified an attribute that does not exist in the NIM environment. Try the operation again, using a valid NIM attribute. To display a list of valid attribute names, enter: lsnim -p -s info_subclass
0042-146 You have specified an object type that does not exist in the NIM environment. Try the operation again, using a valid NIM object type. On the NIM master, the lsnim command can be used to display the valid NIM object types. 0042-147 You have attempted to execute a NIM command on the NIM master that can only be executed on NIM clients. Execute the command on a NIM client. 0042-148 The information contained in the specified attribute is no longer valid. Change the information in the attribute to reflect valid information and try the operation again. 0042-150 Any directory used to store NIM resources must be local to the machine that serves those resources. This is required because NIM can only NFS export local directories. In this case, you have specified a directory that is not local to the designated server of the directory. NIM has obtained this information from the file system of the designated server and the vfstype listed corresponds to values in the /usr/include/sys/ vmount.h file. Either copy the desired resources onto the designated server and perform the operation again, or specify the correct server when performing the operation. 0042-151 For NIM to use a file, it must be of a specific type. In this case, you have specified a file whose type cannot be used by NIM. NIM has obtained this information from the file system of the designated server of the file and the file type corresponds to values in the /usr/include/sys/mode.h file. Change the file type of the file and try the operation again. 0042-152 When an installp operation is performed on a SPOT, the root directories of all diskless and dataless clients that use that SPOT must be synchronized with the changes made within the SPOT. In this case, one or more errors occurred when performing the root sync operation on a root directory. Investigate why some of the root syncs failed and perform the operation again. The nim.installp log for the client root is located in RootResrcParentDir/ClientName/var/adm/ras. 0042-153
Message Explanation User Action Message Explanation User Action Message Explanation
User Action
Message Explanation
User Action
Message
285
Explanation
For NIM to use a file, it must have specific file permissions. In this case, you have specified a file whose permissions conflict with those required by NIM. NIM has obtained this information from the file system of the designated server of the file, and the value of the file permissions comes from the /usr/include/sys/mode.h file. Change the file permissions of the file and try the operation again. 0042-154 For NIM to use a file, it must exist. You have specified a file that does not exist. Create the file and try the operation again. 0042-155 For NIM to keep diskless and dataless root directories in sync with their corresponding SPOTs, NIM requires that the client's root directory be served from the same machine as its SPOT. In this case, you have requested a resource to be allocated that violates that requirement. Try the operation again using resources that do not violate the NIM requirement. 0042-156 You have requested an operation to be performed that involves a directory that does not exist. Create the missing directory and try the operation again. 0042-157 The operation you have requested could not be performed because a required file could not be accessed. Create the missing file and try the operation again. For example: v If the missing file is a boot image with a name whose format is SpotName.NetworkInterface.Platform (for example, myspot.tok.up), recreate the boot image by performing the check operation on the SPOT. v If the missing files are directories with which root or paging resources are associated, delete the resource definition with the remove operation, create the directories, and then redefine the resource. v If a SPOT's image.template file is missing, this indicates that the SPOT has been corrupted or was not constructed successfully. To recover, you may need to remove and rebuild the SPOT with the remove and define operations.
User Action Message Explanation User Action Message Explanation User Action
Message Explanation User Action Message Explanation User Action Message Explanation User Action
0042-158 The operation you have requested requires NIM to modify a file that it was unable to modify successfully. Check the file permissions on the file and try the operation again. 0042-159 Required software is missing which prevents the target machine from acting as a SPOT server. Install the missing software and retry the operation. 0042-160 The operation you requested requires the construction of network boot images and NIM was unable to do that. Fix the problem that prevented the network boot images from being constructed and try the operation again. 0042-161 There is insufficient free disk space to complete the requested operation. Increase the amount of available space, as detailed in the error message. 0042-162 To perform the requested operation, NIM requires an lpp_source type resource object that has the simages attribute as part of its definition. This attribute is used to designate that an lpp_source contains the total set of optional packages that are required to support NIM install operations. In this case, you have not supplied an lpp_source that fulfills this requirement. Try the operation again using an lpp_source that has the simages attribute in its definition. 0042-163
286
Explanation
User Action
NIM coordinates access between a client and the server of the resource. To do this, NIM must identify a network interface that can be used by the client. This becomes a complex problem when the server has more than one network interface. NIM uses a connectivity algorithm to establish which network interface to use. This error message occurred because the connectivity algorithm detected a problem with the client's routing and the interface the algorithm has selected to use. NIM does not allow the interface on the server that the client uses as a gateway to be used to serve resources because the operation requiring the resource could fail. If the server has other network interfaces that are not known to NIM, change the server machine object to add the interfaces. Define a NIM route between the client's primary network and one of the other networks to which the server connects.
Message Explanation
0042-164 Some NIM operations do not allow the source of installable images to be a CD-ROM. NIM is not always able to construct an environment that supports the use of a CD-ROM for the operation being performed. This is true for the operation you tried to perform. Try the operation again using a different source for installable images. 0042-165 Some attributes can only be specified together; others are mutually exclusive. In this case, you specified one or more attributes that conflict. Try the operation again, omitting the attribute that was in conflict. For example, the ring_speed and cable_type attributes cannot be used with the same if attribute; the one you should use depends on the type of network interface referenced by the corresponding if attribute. 0042-166 The if attribute specifies network interface information, which includes a reference to the network object that the interface connects to. In this case, you have omitted a required attribute which is associated with the if attribute. Try the operation again, including the required attribute. For example, the ring_speed attribute corresponds with the Token-Ring network interface, and the cable_type attribute corresponds with the Ethernet network interface. 0042-167 The device which you have specified as the source for the IPL ROM emulation, does not contain a valid, bootable image of the IPL ROM emulation. If the specified device has media in it, this media either does not contain the IPL ROM emulation, or the media has been corrupted. Remake the IPL ROM emulation, and try the operation again. If the specified device has no media in it, make the IPL ROM emulation, put it in the device, and try the operation again. 0042-168 You have specified that the originating and destination network are the same. Machines that are on the same network do not need routing to communicate; therefore, adding a route from a network to itself is not allowed. Specify a different originating and destination network when adding a NIM route. 0042-169 You have allocated an lpp_source, but you have not specified which filesets are to be installed using that lpp_source. Specify the filesets to install using the filesets attribute in the command, or by allocating an installp_bundle that contains a list of the filesets to install. 0042-170 You entered a platform type that is not known to NIM. The valid platform types are rs6k, rs6ksmp, and rspc. Correct the platform type attribute and try the operation again. 0042-171 Not all platform types are supported on all configuration types. For example, the diskless configuration type is not supported on the platform type rs6ksmp. Use the correct platform type and try the operation again.
Message Explanation
User Action
Message Explanation
287
Message Explanation
0042-172 You have specified the incorrect name of the machine object for the NIM client machine. When the niminit command is used to rebuild the niminfo file, the master registration process checks the CPU ID of the machine with the value stored in the NIM database for the named machine. If the stored value does not match the value passed by niminit, this message is issued. Use the correct name and try the command again. 0042-173 You specified that the installp command should expand file systems (using the -X flag) while specifying that NIM should not auto expand (using the auto_expand attribute). This is not an allowable combination for the command invoked. Use either the -X flag or the auto_expand attribute, but not both. 0042-174 You specified an invalid value for an attribute whose only valid values are yes and no. Retry the operation with a value of yes or no for the attribute indicated. 0042-175 An unexpected result has been returned from a command that NIM tried to execute. Fix the problem that caused the executed command to fail and try the operation again. If the command failed due to a shortage of space, its error messages indicating this should be displayed. Expand the indicated file system, (for most NIM operations use the auto_expand attribute) and retry the operation. If a space failure occurred during SPOT creation, and if the bosboot command failed to make boot images as a result, increase the free space and run the check operation. If the command listed by NIM in this message is the installp command, check the nim.installp log for failure and recovery information. (For standalone client operations, this is located in the /var/adm/ras directory of the client. For SPOT cust and maintoperations, this is located in SPOTParentDir/SPOTName/ usr/lpp/bos/inst_root/var/adm/ras on the SPOT. For diskless and dataless clients, this is located in RootResrcParentDir/ClientName/var/adm/ras.
User Action Message Explanation User Action Message Explanation User Action
Message Explanation
User Action
0042-176 The resource cannot serve as a support image (simages)lpp_source. When an lpp_source serves as a support image resource, it contains a minimal set of software packages for facilitating installation and the use of the base operating system. No action is necessary if this resource does not need to serve as a support images lpp_source. If the resource needs to be a support images lpp_source, add the missing software to the lpp_source. If the lpp_source is a directory, you can do this by copying the missing packages to the location of the lpp_source and running the check operation. 0042-177 The operation you requested could not be completed due to insufficient free space in one or more file systems. Make more space available if possible, by extending the file system displayed. For most NIM operations, the auto_expand attribute is available to automatically expand file systems. 0042-178 The if attribute is made up of four fields. The fourth field is optional in most cases. In this case. the network object that you specified (in field one) has more than one type of network. In this case, NIM requires that the fourth field has a value that specifies the logical device name of the network adapter. Add the appropriate value to the if attribute, and try the operation again. 0042-179 You are attempting to remove an if or other_net_type attribute on which one or more NIM clients have a dependency. If this is not a mistake, remove the NIM clients that are dependent on the network, or remove the if attribute from the NIM client object definition. 0042-180 The address of the machine that is being defined is not connected to the network that is represented by the specified network object.
Message Explanation
Message Explanation
288
User Action
Define a network object that represents the physical network to which the machine is connected. Use this network object when defining the machine. 0042-181 The fix_query_flags attribute has an illegal value. Use lsnim -Pa fix_query_flags for a list of legal values. Determine the correct flags and retry the operation. 0042-182 A resource of one type cannot be allocated for the current operation at the same time as a resource of another type. Allocate one or the other, but not both. The resources specified are mutually exclusive. Determine which one is needed for the operation, and omit the other. 0042-183 An attribute cannot be specified for the current operation when a type of resource is allocated. Use one or the other, but not both. The attribute and the resource specified are mutually exclusive. Determine which one is needed for the operation, and omit the other. 0042-184 The network address (net_addr) or subnet mask (snm) cannot be changed for the network, because NIM clients are currently defined as being connected to that network. Remove the client definitions before changing the network. The nimdef command can be used to quickly redefine NIM clients after they have been removed to update the network definition. 0042-185 Failed to link or copy files. Check permissions and file system space. Verify that space and inodes are available for the files and links specified in the error message. 0042-186 Failed to copy setup programs. Either start NFS on the client or free 1000 512-byte blocks in the file system. Programs required to set up the operation could not be copied to the client system. Either start NFS on the client, or increase space in the file system specified in the error message. 0042-187 Failed to expand file system. Attempt to manually expand the file system specified in the error message, then retry the operation. 0042-188 Failed to NFS mount. Verify that NFS is running on both the resource server and the client specified in the error message. Retry the operation when the NFS problems have been resolved. 0042-189 Failed saving existing boot image. Check space in the file system. Increase space in the file system specified by the error message, and retry the operation. 0042-190 The key is not in the NORMAL position. Unattended installation cannot complete unless the key is in the NORMAL position. Turn the key on the client machine to the NORMAL position and retry the operation. 0042-191 Unable to write the IPLROM emulation. The mkboot command failed to write the IPLROM emulation on the client. Boot the client manually over the network to begin the BOS installation. 0042-192 Unable to find boot logical volume. Installation and migration
Message Explanation
User Action
Message Explanation User Action Message Explanation User Action Message Explanation User Action
Message Explanation
289
User Action
Verify that a boot logical volume is defined for the machine. NIM attempts to use the lslv -l hd5 command to determine the boot logical volume. 0042-193 The client does not have an .rhosts entry for the master, or the client host ID is not resolvable. Verify that the client host name is resolvable by the master. Then verify that an entry exists for the master in the $HOME/.rhosts file for root on the client machine. 0042-194 The client does not allow NIM push operations. Remove /etc/nimstop on %s if push operation is necessary. On the client machine, run the nimclient -p command to re-enable master push permissions. 0042-195 Unable to order boot device list. An error was returned by the bootlist command on the client. If a network boot must be performed for a bos_inst, diag, or maint_boot operation, manually set the boot list and reboot the client, or follow the normal procedure to boot the client over the network. 0042-196 The set_bootlist attribute is only valid when used in combination with the no_client_boot or boot_client attributes. Only specify the set_bootlist attribute to the nim command when changing the default behavior with the no_client_boot or boot_client attributes. 0042-197 If the target machine has more than one interface for a given network type, the network adapter's logical device name must be specified in the if1 attribute of the target machine's NIM definition when using the force_push attribute. Modify the client's if1 attribute using the NIM change operation. Change the if1 attribute to include one of the client's network adapter logical device names listed in the error message. 0042-198 When converting a machine's /usr file system to a SPOT, the bos image on the media (lpp_source) being used to create the SPOT must match the bos image that was used to install the machine. When defining the /usr SPOT, use the same installation media that was used to install the machine originally. 0042-199 The no_client_boot and boot_client attributes may not be specified together. To avoid the possibility of giving conflicting instructions to the NIM command, do not supply both the no_client_boot and boot_client attributes in the same NIM operation. 0042-204 The mk_image and source attributes are only valid when specified together. When creating a mksysb resource from a running client machine, use the mk_image=yes attribute to indicate that a mksysb should be created, and use the source=ClientName attribute to specify the name of the client that is to be backed up. 0042-205 The bos.sysmgt.sysbr fileset must be installed on the client to perform the system backup. You may install this fileset with the NIM cust operation. Install the bos.sysmgt.sysbr fileset on the client machine before retrying the operation. 0042-206 There is already a resource allocated. Only one resource of the type specified can be allocated to the client. Deallocate the first resource before attempting to allocate the other. 0042-207 Unable to allocate a resource to a client.
Message Explanation
User Action
Message Explanation
290
User Action
Look for other NIM error messages that may accompany this error and which may provide more information about the problem. Verify that the resource specified is NFS-exportable to the client. 0042-208 Unable to lock a client. This could mean that the client is already locked, or the name given does not refer to a valid NIM client. If another NIM operation is being performed on the same client, wait for the process to complete before retrying the operation. If no other NIM operations are being performed, stop and restart the nimesis daemon to remove locks. 0042-209 The mksysb_flags attribute contains an illegal value. Use the lsnim -Pa mksysb_flags command to get a list of legal values. Specify the correct values for the mksysb_flags attribute, and retry the operation. 0042-210 The maximum space required for the backup is greater than the amount of free space in the target file system. To ignore space requirements, use the -F flag when defining the mksysb resource. Either increase the space of the target file system where the mksysb is to be created, or use the -F flag as specified in the error message. 0042-211 The member already exists in group. No additional action is required, since the member is already added to the group. 0042-212 The member was not added to the group, because it is not a valid NIM name. The name of a member to add to a group was invalid. Verify that the member was specified correctly. 0042-213 The group was not created, because it did not contain any valid members. A group must contain at least one member. Redefine the group with valid members to add it to the NIM environment. 0042-214 Unable to add a member to a group. Look for other NIM error messages that may accompany this error and which may provide more information about the problem. 0042-215 An invalid log type for the showlog operation was specified. Specify one of the valid log types listed in the error message. 0042-216 An invalid log type for the showlog operation was specified for a SPOT. Specify one of the valid log types listed in the error message. 0042-217 An invalid log type for the showlog operation was specified for a diskless or dataless machine. Specify one of the valid log types listed in the error message. 0042-218 The log file is either empty or does not exist. No information is available in the log file for the machine or SPOT specified. 0042-219 The object is incompatible with the group. The object cannot be added to the group, because its type is not allowed in the group. Machine groups can only contain one type of NIM client, and that type is determined by the first member added. Resource groups can only contain members whose types are resources.
Message Explanation User Action Message Explanation User Action Message Explanation User Action
Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action
291
0042-220 You cannot have more than one resource of the specified type in a resource group. You must remove the current member with the specified type from the resource group before the new member with the same type can be added. 0042-221 The group GroupName is being removed, because its single remaining member was removed during this operation. A group cannot be empty. Redefine the group with at least one member if it should remain in the NIM environment. 0042-222 An unknown error occurred allocating resources to the machine. Look for other NIM error messages that may accompany this error and which may provide more information about the problem. Verify that the resource specified is NFS-exportable to the client. 0042-223 Invalid input file. The file either cannot be read, is empty, or contains no valid entries. Verify that the file specified in the error message is the correct file for the operation. 0042-224 The limit on the length of a line in an NFS exports file was exceeded. The export operation cannot be performed. Manually edit the /etc/exports and /etc/xtab files to remove any obsolete entries. The number of hosts to which NIM can NFS-export a resource can also be increased by setting the restrict_nfs_exports attribute to no on the master by running the nim -o change -a restrict_nfs_exports=no master command. 0042-225 An error occurred while updating the exports file. Check for corruption in the file. Manually edit the /etc/exports and /etc/xtab files to fix any file corruption problems. Attempt to determine why NIM was unable to successfully update the files. Check file and directory permissions, and verify that file systems are not full. 0042-226 A timeout occurred while attempting to initiate the operation on the client. The operation may not have started successfully. If the operation that was performed was bos_inst, the client only needs to be rebooted manually over the network to begin the installation. For all other operations, the problem is most likely due to network communication problems between the master and the client. Verify that the client is reachable by the master and that rsh permission is still granted by the client to the master. 0042-227 The state of the machine indicates that it may not be ready for certain NIM operations. Check to see if any NIM operations are still being performed on the machine. If not, reset the state of the machine with the nim -Fo reset MachineName command. This returns the machine to the ready state so NIM operations can be performed on it. The reset operation does not deallocate resources, so deallocate resources if necessary using the nim deallocate operation. 0042-228 Invalid release level. The release level of the resource is incomplete, or incorrectly specified. The level of the resource can be obtained by running the lsnim -l ResourceName command and viewing the version, release, and mod attributes. To correct the problem, either recreate the resource, or modify the NIM database to contain the correct level using the command on the NIM master:/usr/lpp/bos.sysmgt/nim/methods/m_chattr -a Attribute = Value ResourceName, where Attribute is version, release, or mod; Value is the correct value; and ResourceName is the name of the resource with the incorrect level specification. 0042-229 When installing a system using a mksysb as the source for the installation, the level of the SPOT used for the installation must match the level of the mksysb image being installed. The release levels of the SPOT and the mksysb do not match.
Message Explanation
292
User Action
Create a SPOT that matches the level of the mksysb being installed, and use that SPOT when performing a mksysb BOS installation. The level of mksysb and SPOT resources can be obtained by running the lsnim -l ResourceName command and viewing the version, release, and mod attributes. 0042-230 When installing a system using a mksysb as the source for the installation, the level of the SPOT used for the installation should match the level of the mksysb image being installed. If this convention is not followed, the installation may not complete successfully. Create a SPOT that matches the level of the mksysb being installed, and use that SPOT when performing a mksysb BOS installation. The level of mksysb and SPOT resources can be obtained by running the lsnim -l ResourceName command and viewing the version, release, and mod attributes. 0042-231 A temporary list of software that should be installed is created and used for this operation. The list could not be created. Check previous error messages to understand why the error occurred. Correct the problem and try the operation again. 0042-232 A temporary installp_bundle resource is created and used for this operation. The temporary resource could not be created. Check previous error messages to understand why the creation of the resource failed. Correct the problem and try the operation again. 0042-233 The operation cannot be performed because the NIM Master is already initialized. Unconfigure the NIM Master and try the operation again. 0042-234 You cannot restore a NIM database backup onto a machine that has an earlier level of the NIM master fileset installed. For example, a NIM database backup of a system with level 4.2.0.0 of the NIM master cannot be restored to a system that has a level of the NIM master lower than 4.2.0.0. Install a level of the NIM master fileset that is at the same level or a later level than that from which the backup was created. Then attempt to restore the NIM database backup. 0042-235 An image source was not specified for creating the SPOT. Specify a device containing installation images or specify an lpp_source with the simages attribute for creating the SPOT. 0042-236 A name for the lpp_source and/or a directory to contain the lpp_source was not specified for the lpp_source that will be created. Specify a name and a directory for the lpp_source and try the operation again. 0042-237 A name for the SPOT and/or a directory to contain the SPOT was not specified for the SPOT that will be created. Specify a name and a directory for the SPOT and try the operation again. 0042-238 A parent directory was not specified for the diskless and dataless machine resources that will be created. Specify a directory for the diskless/dataless machine resources and try the operation again. 0042-239 A name for the resource and/or directory to contain the resource was not specified for the resource that will be created. Specify a name and a directory for the resource and try the operation again. 0042-240 A parent directory was not specified for the diskless and dataless machine resources that will be created.
Message Explanation
User Action
User Action
Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action Message Explanation
293
User Action Message Explanation User Action Message Explanation User Action Message Explanation User Action
Specify a directory for the diskless/dataless machine resources and try the operation again. 0042-241 The size and/or volume group was not specified for the creation of a new file system to contain a NIM resource. Specify both the size and volume group for the file system and try the operation again. 0042-242 The size and/or volume group was not specified for the creation of a new file system to contain diskless and dataless machine resources. Specify both the size and volume group for the file system and try the operation again. 0042-243 An attempt was made to create the same file system twice: once for an lpp_source and once for a SPOT. Specify a different directory for either the lpp_source or the SPOT. This will cause different file systems to be created for the resources. If a new file system really should be created to contain both resources, then only specify that the file system should be created for one of the resources, but specify the same directory for both resources. 0042-244 An attempt was made to create the same file system twice: once for an lpp_source and once for diskless/dataless machine resources. Specify a different directory for either the lpp_source or the diskless/dataless resources. This will cause different file systems to be created for the resources. If a new file system really should be created to contain both sets of resources, then only specify that the file system should be created for one of the resources, but specify the same directory for both resources. 0042-245 An attempt was made to create the same file system twice: once for a SPOT and once for diskless/dataless machine resources. Specify a different directory for either the SPOT or the diskless/dataless resources. This will cause different file systems to be created for the resources. If a new file system really should be created to contain both sets of resources, then only specify that the file system should be created for one of the resources, but specify the same directory for both resources. 0042-246 Not enough space on the volume group to create the specified file system. Specify a different volume group for the file system to be created and try the operation again. 0042-247 Creation of the file system failed. Check the previous output for error messages to understand what caused the file system creation to fail. Correct the error and try the operation again. 0042-248 An error occurred during file system creation. Check the previous output for error messages to understand what caused the file system creation to fail. Correct the error and try the operation again. 0042-249 NIM master initialization failed. Check the previous output for error messages to understand what caused the configuration of the NIM master to fail. Correct the error and attempt to reinitialize the master. The most frequent cause of this failure is that the master is already initialized. The master can be unconfigured with the nim -o unconfig master command and reinitialized. However, this should be done with extreme caution, since unconfiguring the master will remove all definitions from the NIM database. 0042-250 Unable to continue with configuration. Check the previous output for error messages to understand what caused the configuration to fail. Correct the error and attempt to configure the system again from the point of failure.
294
0042-251 A route cannot be added to the network, because a required default route is missing. Add a default route to the network, and try this operation again. Add a default route to the network specified in the error message, and retry the operation. 0042-252 Unable to locate a matching network. The find_net keyword was used in the if attribute of the machine. However, no matching network was found. Either define the network prior to defining the machine interface, or use the net_definition attribute in conjunction with the find_net keyword to define the network while the interface is being defined. 0042-253 You cannot use the net_definition attribute when the find_net keyword is not specified as the first field of the if attribute. The net_definition attribute is invalid when using a known network in the if attribute. Specify the find_net keyword in the if attribute, or omit the net_definition attribute, and retry the operation. 0042-254 Invalid format for the specified value of net_definition. The value of the attribute should be as follows: NetType snmName Dotted decimal subnet mask for the network. Client_gwName Optional default gateway IP address or host name used by the machine being defined to communicate with the master. Master_gwName Optional default gateway IP address or host name used by the master to communicate with clients on other subnets. NetName Optional name given to the NIM definition created for the network. (Otherwise, a unique default name is used.) If you want to specify NetName and if Client_gwName or Master_gwName are not applicable, specify 0 in their place. If Client_gwName is 0, Master_gwName cannot be nonzero. Correct the syntax error, and retry the operation. 0042-255 The master already has a default route, and the gateway you specified as being the default for the master is different from that which is already defined. Use the change operation if you want to modify the master's default gateway. To change the default gateway for a network, use the following command: nim -o change -a routingX="default GtName" NetName where X is the sequence number for the routing attribute; GtName is the default gateway to use; and NetName is the name of the master's network. Network type (for example, tok, ent, fddi, etc.).
Message Explanation
User Action
0042-256 A default route already exists for the network. You can modify the default gateway, but you cannot define more than one default route. To change the default gateway for a network, use the following command: nim -o change -a routingX="default GtName" NetName where X is the sequence number for the routing attribute; GtName is the default gateway to use; and NetName is the name of the network to modify.
Message Explanation
0042-257 You cannot specify the net_definition attribute without specifying the if attribute when changing a machine definition.
295
User Action
The net_definition must reference a machine interface, so specify an if attribute when using the net_definition attribute. 0042-258 You cannot specify the net_definition attribute when creating or modifying more than one if attribute in the same change operation. Use two separate operations. To avoid ambiguity, manipulate only one machine interface (if attribute) at a time when using the net_definition attribute. 0042-259 The value of default_res specified on the master's database definition is not a valid NIM resource group. Specify a valid NIM resource group as the default resource. Obtain a list of resource groups by running the lsnim -t res_group command. 0042-260 The default attribute is only applicable when manipulating a resource group. Setting the default=yes/no attribute on a resource group makes it the default set of resources to use in NIM operations. The default attribute is invalid when used as an attribute in other NIM operations. 0042-261 Illegal use of the async attribute. This attribute can only be specified for the lppchk operation when the target is a standalone machine or a group of standalone machines. Omit the async attribute when performing the lppchk operation, unless the target is a standalone machine or a group of standalone machines. 0042-262 The file name of the client definition file is missing for this operation. Specify the client definition file that should be used to add machines to the NIM environment. For more information, see NIM Commands on page 114. 0042-263 The netboot_kernel attribute can only be assigned a value of up or mp. Correct the value specified for the netboot_kernel attribute. 0042-264 The image source that was used to define the lpp_source is missing one or more requested packages. Installation images were not copied into the lpp_source directory. The source for installation images may not contain all of the filesets specified to populate the lpp_source. Copy the missing installation images to the lpp_source directory, and then perform the NIM check operation on the lpp_source. 0042-265 The image source that was used to define the lpp_source is missing one or more items from the list of default packages. Installation images were not copied into the lpp_source directory. The source for installation images may not contain all of the default filesets used to populate the lpp_source. Copy the missing installation images to the lpp_source directory, and then perform the NIM check operation on the lpp_source. 0042-266 Requested packages are missing from the defined lpp_source. Installation images were not copied into the lpp_source directory. The fileset names may have been specified incorrectly, or the source for installation images may not contain all of the specified filesets. Copy the missing installation images to the lpp_source directory, and then perform the NIM check operation on the lpp_source. 0042-267 The defined lpp_source does not have the simages attribute, because one or more packages are missing. Copy the missing installation images to the lpp_source directory, and perform the NIM check operation on the lpp_source to add the simages attribute. 0042-268
Message
296
Explanation
User Action Message Explanation User Action Message Explanation User Action
The operation cannot be performed, because all members of the target group specified are currently excluded from operations on the group. You must unmark (or include) excluded group members before proceeding. Perform the NIM select operation on the group to include members in further operations. 0042-269 Only one type of verification can be performed at a time when verifying installed filesets on a NIM client. Disable or deselect all but one verification option and try the operation again. 0042-270 The operation is only supported on SPOTs and NIM clients installed with a version and release level of AIX 4.2 or greater. The NIM client fileset on the target is at an earlier level and does not support the attempted operation. The client software on the target must be upgraded before the operation can be performed. 0042-271 A resource matching the type is already allocated. You cannot allocate more than one resource of this type to a machine. Deallocate the first resource before attempting to allocate the second. It may be necessary to reset the machine before the resource can be deallocated. 0042-272 A value specified is not a valid value for default_re because it is not a valid NIM resource group. Specify a different resource group for the default_res attribute, or correct the resource group in question. 0042-273 A value specified cannot be used as the location for the mksysb image because it is a directory. You must specify the filename where the mksysb image currently resides or will reside after creation. Specify a file name instead of a directory for the location of the mksysb resource. 0042-274 The -e flag in the mksysb_flags attribute and the exclude_files attribute cannot be specified together. Specify the -e flag with the mksysb_flags attribute to exclude the files in /etc/exclude.rootvg from the backup, or specify an exclude_files attribute. Do not specify both the -e mksysb flag and an exclude_files resource when performing this operation. 0042-275 Unable to obtain possession of a lock file. If no NIM operations are currently in progress, remove the file and repeat the operation. Use the ps -ef | grep nim command to list the running NIM processes on the system. If any NIM processes other than the nimesis daemon are running, wait for them to finish and then remove the file specified by the error message. 0042-276 A fileset must be installed before this operation can be performed. Install the fileset listed in the error message before retrying the operation. Generally, the fileset needs to be installed on the client system. However, depending on the operation being performed, the NIM master may also need to have the fileset installed before the operation will succeed. 0042-277 Diskless and dataless machines cannot be defined with a primary network install interface residing on a generic NIM network. It is presumed that a network adapter defined on a generic NIM network does not support network boot. To define the systems as diskless or dataless clients, they must first be connected to a NIM network that is known to support network boot, such as ethernet, token-ring, or FDDI. 0042-278 The interface specified does not correspond to a network adapter that is known to support network boot. As a result, the NIM master has been defined on a generic NIM network. Network boot-dependent operations, such as base operating system installation, will not be possible on any NIM client whose primary network install interface is defined on the same network as the NIM master.
Message Explanation User Action Message Explanation User Action Message Explanation
Message Explanation
User Action
Message Explanation
297
User Action
Operations that rely on network boot capability cannot be performed on clients on generic NIM networks. Such operations must be performed using local media on the system. 0042-279 The interface specified maps to a subnet which has been defined as a generic NIM network. It will not be possible to perform network boot-dependent operations, such as base operating system installation, on the machine definition created by this operation. Operations that rely on network boot capability cannot be performed on clients on generic NIM networks. Such operations must be performed using local media on the system. 0042-280 Specify a complete date and time for the scheduled operation in the form: YYMMDDhhmm. Use the format described in the error message to correctly schedule a date and time for the operation. 0042-281 The /usr file system on the specified server cannot be converted to a NIM SPOT. Either the RM_INST_ROOTS variable was set to yes in a bosinst.data file during initial installation of the machine or inurid -r was subsequently invoked. The only way to create a SPOT on this machine is to specify the location to be something other than /usr or reinstall the machine and then create a SPOT in /usr. The system is unable to support the creation of a /usr SPOT. A non-/usr SPOT may be created on the system by specifying a different value for the location attribute. 0042-282 The BOS installation has been enabled but could not be initiated, because the following file was not found on the target. To start the installation, do one of the following: 1. Initiate a network boot operation from the target. 2. Correct the state of the target with NIM's reset operation and invoke the bos_inst operation again using one of the following: a. The Force Push option (-a force_push=yes) b. After installing and configuring the bos.sysmgt.nim.client fileset on the target. The NIM client fileset is not properly installed and configured on the target system. Follow the directions specified in the error message to correct the problem. 0042-283 The existence of a file on the server indicates that a NIM SPOT may still be mounted in a subdirectory which will be removed by this operation. Before attempting the operation again, unmount the SPOT's directory along with any other directories that may be mounted beneath the directory being removed. Failure to do so will result in loss of data on the SPOT server. A SPOT operation failed, and NIM was unable to unmount all the directories mounted into the SPOT. Manually unmount the directories specified in the error message before retrying the operation. The mount command can be used to list the directories mounted on the system, and the unmount command can be used to unmount directories. Use the -f option with the unmount command if necessary to force the unmount.
Message Explanation
User Action
User Action
Message Explanation
User Action
Message Explanation
User Action
Message Explanation User Action Message Explanation User Action Message Explanation User Action
0042-323 To perform an operation on a NIM object, the NIM resource allocated to the object must be of the same architecture as the NIM object. Deallocate the conflicting resource and allocate a resource with the same architecture as the object. 0042-324 Cross-platform resources and operations are not allowed on servers with an operating system level prior to AIX 5.1. Try performing operation on a server with an operating system level of AIX 5.1 or later. 0042-325 To perform the operation, the resource and server must be of the same architecture. Perform the operation with a server and resource of the same architecture.
298
Message Explanation User Action Message Explanation User Action Message Explanation User Action
0042-326 If an architecture value is specified during the creation of a cross-platform resource, then it should correctly identify the architecture of the source being used. Give the correct architecture of the resource or do not specify an architecture when defining the resource. 0042-327 Cross-platform SPOT resources may only be created from an existing SPOT resource. Use an existing cross-platform SPOT as the source to create the new SPOT resource. 0042-330 NIM cannot determine the architecture of the source being used for the current operation. In an lpp_source resource is being created, then supply a value for the arch attribute.
If an entry does not exist, either the NIM command used to set up the current operation failed, or the machine was reset before the boot operation could occur. Rerun the NIM bos_inst, diag, or maint_boot operation to prepare the server for the client boot request.
Installation and migration
299
If the entry exists in /etc/bootptab, verify that the specified data is correct. If a field contains incorrect data, the information that was used to define the machine or network in the NIM database was probably incorrect. Correct this problem by resetting the client machine, correcting the invalid data in the client or network definition, retrying the NIM operation, and rebooting the client. 3. If the /etc/bootptab file is correct, verify that the inetd daemon is running. If it is not running, start it and retry the network boot from the client. If the inetd daemon is running, it should automatically start the bootpd daemon when the bootp request is received at the server. 4. If the bootpd daemon is not started, verify that the bootps entry in the /etc/inetd.conf file is not commented out. If it is commented out, uncomment it and restart inetd with the refresh -s inetd command. Retry the network boot from the client. 5. If a bootp reply is still not received at the client, manually start the bootpd daemon in debug mode: a. Comment out the bootps entry from the /etc/inetd.conf file on the server. b. Stop all running bootpd processes. c. Restart inetd using the refresh -s inetd command. d. Start bootpd from the command line, using the /usr/sbin/bootpd -s -d -d -d command. 6. Retry the network boot from the client. If no output is displayed from the running bootpd command, the client bootp request is not reaching the server. Verify that the addresses specified in the bootp menus are correct. If they are correct, perform network debugging procedures to determine why the packet is not reaching the server. If the server receives the client bootp request, the running bootpd command displays output matching the client data in the /etc/bootptab file. Verify that the specified addresses are correct. This information is sent back to the client in the bootp reply. 7. If the client is still not receiving the bootp reply, perform network-debugging procedures to determine why the reply packet is not reaching the client. After the client receives the bootp reply, it will tftp the boot image from the server. The number of tftp packets transferred to the client will be displayed at the client machine. The boot image has been successfully retrieved at the client machine when the LED shows 299 on rs6k-platform machines or when the bottom third of the screen turns gray on other platform machines. 8. If the tftp of the boot image does not complete successfully, the client may be trying to get the wrong boot image. Verify that the client definition in the NIM database shows the correct platform and kernel type. If the data is incorrect, correct it, reset the client machine, rerun the NIM operation, and reboot the client over the network. 9. Verify that the /tftpboot directory on the boot server contains a link with the client name to the correct boot image. If the link does not exist, reset the client machine, rerun the NIM operation, and reboot the client over the network. 10. If the link with the client name is pointing to the correct boot image and the tftp of the boot image does not complete successfully, the boot image may be corrupted. Re-create the boot image by performing a NIM check operation with the force flag on the SPOT. If the client is not an rs6k-platform machine, also make sure the client has the latest version of the firmware installed. Running the boot image on the client: After the client machine has successfully received the boot image from the server, the most common errors encountered are hangs with the LED showing 608, 611, or 613. Some machines may not have LED displays. Debugging such problems on these machines will require using debug-enabled boot images. For information on building debug boot images, see Producing debug output from the BOS installation program on page 302.
300
tftp retrieve of client info file failure. If a 608 hang is encountered, verify that the ClientName.info file exists in the /tftpboot directory. If it does not exist, retry the NIM operation to create it. If it does exist, verify that tftp access to the /tftpboot directory is not restricted in the /etc/tftpaccess.ctl file. It is also possible that the network adapter was not configured properly in the boot environment. Use debug-enabled network boot images to look for errors in the boot environment. If the client is not an rs6k-platform machine, make sure that it has the latest version of firmware installed. Remote mount of NFS file system failure. 611 hangs occur when the client machine is unable to mount a resource from a server. Ensure that NFS is running on the resource server. Verify that the resources specified for the operation are exported properly by checking the /etc/exports and /etc/xtab files on the server. Also, confirm that the resources have permissions set correctly for reading. Debug-enabled network boot images can also be used to determine exactly which mount command is failing on the client. Failure setting up route tables. 613 hangs usually occur because a route is incorrectly defined for a network in the NIM database. Verify that the correct gateways are specified between networks, and all gateways are functional. Use debug-enabled network boot images to determine which routes could not be defined.
301
where SPOTName is the name of your SPOT. 2. Obtain the address for entering the debugger by doing the following: From Web-based System Manager: a. From the NIM Resources container, double-click the SPOT resource to open the properties notebook. b. Click the Boot Image Information tab in the properties notebook to obtain the address. Alternatively, you can use the following command to get the address:
lsnim -a enter_dbg SPOTName
where SPOTName is the name of your SPOT. The displayed output will be similar to the following:
spot1: enter_dbg enter_dbg enter_dbg enter_dbg enter_dbg enter_dbg = = = = = = "chrp.mp "chrp.up "rs6k.mp "rs6k.up "rspc.mp "rspc.up 0x001840d4" 0x00160b7c" 0x001840d4" 0x00160b7c" 0x001840d4" 0x00160b7c"
Write down the enter_dbg address for the client you are going to boot. For example, if your client is an chrp-uniprocessor machine, you would write down the address 160b7c. 3. Attach a tty device to your client system (port 1). 4. Set up and perform the NIM operation that will require the client to boot over the network. Boot the client over the network. 5. After the client gets the boot image from the SPOT server, the debug screen will appear on the tty. At the > prompt, enter:
st Enter_dbg_Value 2
where Enter_dbg_Value is the number you wrote down in step 2 as your machine type's enter_dbg value. Specifying a 2 at the address of the enter_dbg value prints the output to your tty. 6. Type g (for go) and press Enter to start the boot process. 7. Use Ctrl-s to temporarily stop the process as you watch the output on the tty. Use Ctrl-q to resume the process. 8. To rebuild your boot images in non-debug mode, use the following command:
nim - Fo check SPOTName
where SPOTName is the name of your SPOT. If the boot image is left in debug mode, every time a client is booted from these boot images, the machine will stop and wait for a command at the debugger ">" prompt. If you attempt to use these debug-enabled boot images and there is not a tty attached to the client, the machine will appear to be hanging for no reason.
302
1. To enable debugging for the BOS installation program, start by performing all the processing you would normally do to install a client. Because you are not using a bosinst_data resource, you will be prompted to supply information about the installation to the BOS installation program. 2. Select your console. 3. Select your language. 4. The Welcome to Base Operating System Installation and Maintenance menu is displayed. Instead of selecting one of the options, type 911 at the prompt and press Enter. 5. Continue the normal procedure for selecting options and specifying data until the installation begins. Debug output will be sent to the client's display while the installation proceeds. Producing debug output when using a bosinst_data resource (Method B): Use this procedure to produce debug output when using a bosinst_data resource. 1. To enable debugging for the BOS installation program, set the value BOSINST_DEBUG = yes in the control_flow stanza of the bosinst.data file that you are using for your bosinst_data resource. A minimum bosinst.data file for debugging purposes would contain the following lines:
control_flow: BOSINST_DEBUG = yes
2. In addition to the processing you would normally do to install a client, include the modified bosinst_data resource as a resource for the operation. After the client boots over the network, it will use the bosinst_data resource to obtain settings for the installation. If the only data specified in your bosinst.data file is BOSINST_DEBUG = yes, you will be prompted for the remaining required information before the installation will continue. Debug output will be sent to the client's display while the installation continues.
Debugging when port number conflicts with NIM and other applications
Follow this procedure if the nimesis daemon will not run. When the NIM Master is configured, two port numbers are selected to be used by the nimesis daemon for client communications. The default port numbers are 1058 and 1059. If either port is taken by another application, the nimesis daemon will not run and nimclient commands will fail with an error similar to the following: 0042-006 nimclient: (To master) rcmd connection refused If the nimesis daemon cannot be started, it may be necessary to stop the other applicants on the system to free the port. Rebooting the system will usually eliminate the problem, because when a machine is booted, the nimesis daemon is started very early by init and the likelihood that the ports are taken will be very small.
303
The cdromd daemon can interfere with scripts, applications, or instructions that attempt to mount the CD or DVD device without first checking to see if the device is already enabled. A resource or device busy error occurs in such a condition. Use the cdumount or cdeject command to unmount the device. Then mount the device as specified in the program or instructions. Alternatively, use the cdcheck -m or mount command to determine the current mount point of the device. For further information, see the cdromd command documentation in AIX Version 6.1 Commands Reference, Volume 1. The installation code allows for this automatic mounting. If cdromd is enabled and the mkcd command is run, the CD-R or DVD-RAM is ejected after the image is completed. If you do not want to have the media ejected, then the cdromd daemon should be put in the inoperative state with the following command:
# stopsrc -s cdromd
304
backup program by default writes a boot image, which makes the medium suitable for installing. For more information, see Creating a system backup to CD-R, DVD-R, or DVD-RAM on page 308. If you have problems with installations from a mksysb image, see Troubleshooting problems with installation from mksysb backup.
Installing all device and kernel support before the backup is created
Create a system backup that contains all devices and kernel types. All devices and kernels are installed by default when performing a base operating system installation. This allows you to create a system backup that contains all devices and kernel types. Because the system backup contains all the devices and kernel support, the system backup can be used to install another system without the need for the AIX product media. This option is available in the Install Options menu in the BOS installation menus. If you change the default (yes) to no, only the devices and kernel type for your system configuration will be installed. This value is read from the ALL_DEVICES_KERNELS field in the /var/adm/ras/bosinst.data file on the product media that you used to boot the system. After the system is installed, you can check if all the devices and kernel types have been installed on the system as follows:
# grep ALL_DEVICES_KERNELS bosinst.data
For more information about the bosinst.data file, refer to Customizing your installation on page 79.
305
v All hardware must already be installed, including external devices, such as tape and media drives. v The bos.sysmgt.sysbr fileset in the BOS System Management Tools and Applications software package must be installed. The bos.sysmgt.sysbr fileset is automatically installed. To determine if the bos.sysmgt.sysbr fileset is installed on your system, type:
lslpp -l bos.sysmgt.sysbr
If your system has the bos.sysmgt.sysbr fileset installed, continue with one of the following procedures: Creating a root volume group backup to tape, USB disk, or file Creating a system backup to CD-R, DVD-R, or DVD-RAM on page 308 Backing-up a user volume group on page 312 If the lslpp command does not list the bos.sysmgt.sysbr fileset, install it before continuing with the backup procedure. Refer to Optional products and service updates on page 321 for instructions, or enter the following command:
installp -agqXd device bos.sysmgt.sysbr
where device is the location of the software; for example, /dev/cd0 for CD-ROM drive.
306
To exclude certain files from the backup, select yes in the Exclude Files field, then create a /etc/exclude.rootvg file with an ASCII editor, and enter the file names that you do not want included in your system backup image. You can use patterns for the file names that conform to the pattern matching conventions of the grep command. For example, to exclude all the contents of the directory called scratch, put the following line in the exclude file:
/scratch/
For another example, exclude the contents of the directory called /tmp and avoid excluding any other directories that have /tmp in the pathname by adding the following line to the exclude file:
^./tmp/
Note: All files are backed up relative to the current working directory. This directory is represented by a . (dot character). To exclude any file or directory for which it is important to have the search match the string at the beginning of the line, use a ^ (caret character) as the first character in the search string, followed by a . (dot character), and then followed by the file name or directory to be excluded. If the file name or directory being excluded is a substring of another file name or directory, use ^. (caret character followed by dot character) to indicate that the search should begin at the beginning of the line and/or use $ (dollar sign character) to indicate that the search should end at the end of the line. To list each file as it is backed up, select yes in the List files as they are backed up? field. Otherwise, you see a percentage-completed progress message while the backup is created. If you modified the image.data file and do not want a new one created, select no for Generate new /image.data file?. (The image.data file contains information about the sizes of all the file systems and logical volumes in your rootvg.) If you are creating a bootable backup (to tape or USB disk) and you want to expand the system /tmp file system (if required by the backup program), select yes for EXPAND /tmp if needed?. If the tape drive you are using provides packing (or compression), set the Disable software packing of backup? field to yes. If you chose tape as the backup medium, either leave the default in the Number of BLOCKS to write in a single output field or enter a different number. If you chose file as the backup medium, press Enter. If you chose tape or USB disk as the backup medium, insert the first blank tape or USB disk into the drive and press Enter. 3. The COMMAND STATUS screen displays, showing status messages while the system makes the backup image. If you chose tape or USB disk as the backup medium, the system might prompt you to insert the next tape or USB disk during the backup by displaying a message similar to the following:
Mount next Volume on /dev/rmt0 and press Enter.
If this message displays, remove the tape or USB disk and label it, including the BOS version number. Then insert another tape or USB disk and press Enter. When the backup process finishes, the COMMAND: field changes to OK. 4. When the backup completes, press F10 to exit SMIT. 5. If you selected tape or USB disk as the backup medium, remove the last tape or USB disk and label it. Write-protect the backup tapes or USB disks. 6. Record any backed-up root and user passwords. Remember that these passwords become active if you use the backup to either restore this system or install another system. You have created the backup of your root volume group (rootvg). If you created bootable tapes or USB disks, you can use these tapes or USB disks to start your system if for some reason you cannot boot from hard disks.
307
Both Web-based System Manager and SMIT use the mkcd command, which calls the mksysb or savevg command, if needed. For system backups, the CDs or DVDs can be created as: v Non-bootable CDs or DVDs v Bootable CDs or DVDs A bootable system backup contains a boot image and all the device and kernel packages necessary to install a system. A backup CD or DVD can be used to install (clone) a large number of machines, which is convenient when each machine in the system environment needs to have the same image installed. Note: It is possible that a backup CD or DVD would not boot all machines of the same type because not every machine has the same hardware configuration. Depending on what packages were made available during the creation of the backup, the backup might not have all the necessary packages to boot an individual system. Most required packages for systems are present on the BOS AIX media. Web-based System Manager and SMIT interfaces are available for the mkcd command. Online help can guide you through the required steps. Meeting hardware and software requirements for system backups: These are the hardware and software requirements for system backup to CD-R, DVD-R, or DVD-RAM. The mkcd command requires that you already have the software installed to create a CD or DVD file system in Rock Ridge format and to burn or write the CD or DVD. The GNU versions of the cdrecord and mkisofs commands are installed with a BOS installation. Hardware and software that have been tested with this command include the following:
Software GNU and Free Software Foundation, Inc. readcd command version 1.9 mkisofs command version 1.13 Hardware DVD-RAM
Preparing to run the mkcd command: To run the mkcd command, you need extra working space. A separate file system or directory is required for each of the following: v Storing a mksysb or savevg image
308
v Storing the CD or DVD file system contents v Storing the CD or DVD images before they are recorded The mkcd command creates the following file systems if they are not already present or if alternative file systems or directories have not been specified: /mkcd/mksysb_image Space requirement depends on the size of the mksysb image that is to be created. The mkcd command attempts to calculate this space and verify that adequate space is available before starting to create the mksysb image. Note: When the mkcd command calculates the space requirements needed for the /mkcd/mksysb_image directory, it also adds the space used by the excluded files (/etc/exclude.rootvg). It is therefore possible that the mkcd command might not be able to create the /mkcd/mksysb_image directory. /mkcd/cd_fs Requires 645 megabytes (up to 4.38 GB for DVD) /mkcd/cd_images Requires at least 645 megabytes (up to 4.38 GB for DVD) of space. If the -R or -S flags are used to specify not removing the images and there are multiple volumes required, more space must be provided. The space used in these file systems is only temporary (unless the -R or -S flag is specified to save the images). If the mkcd command creates the file systems, it also removes them. Each file system or directory might require over 645 megabytes (up to 4.38 GB for DVD). If your machine does not have sufficient space, you can use NFS to mount some space from another server system; however, the file systems must be writable. You can create a /mkcd file system that is very large (1.5 GB for CD or 9 GB for DVDs). The /mkcd file system can then be mounted onto the clients when they want to create a backup CD or DVD for their systems. When creating very large backups (larger than 2 GB) with the mkcd command, the file system must be large-file enabled and the ulimit values must be set to unlimited. The mkcd command with the -L flag allows the creation of DVD-sized ISO9660 images. The mkcd command with the -U flag allows the creation of UDF DVD images. You can also use the mkdvd command to create DVD-sized ISO9660 images. Creating a root volume group backup on CD or DVD with the ISO9660 format: Follow this procedure to create a root volume group backup on CD or DVD with the ISO9660 format. You can use Web-based System Manager or SMIT to create a root volume group backup on CD or DVD with the ISO9660 format, as follows: v Use the Web-based System Manager Backup and Restore application and select System backup wizard method. This method lets you create bootable or non-bootable backups on CD-R, DVD-R, or DVD-RAM media. OR v To create a backup to CD, use the smit mkcd fast path. v To create a backup to DVD, use the smit mkdvd fast path and select ISO9660 (CD format). The following procedure shows you how to use SMIT to create a system backup to CD. (The SMIT procedure for creating a system backup to an ISO9660 DVD is similar to the CD procedure.) 1. Type the smit mkcd fast path. The system asks whether you are using an existing mksysb image.
309
2. Type the name of the CD-R device. (This can be left blank if the Create the CD now? field is set to no.) 3. If you are creating a mksysb image, select yes or no for the mksysb creation options, Create map files? and Exclude files?. Verify the selections, or change as appropriate. The mkcd command always calls the mksysb command with the flags to extend /tmp. You can specify an existing image.data file or supply a user-defined image.data file. See step 16 on page 311. 4. Enter the file system in which to store the mksysb image. This can be a file system that you created in the rootvg, in another volume group, or in NFS-mounted file systems with read-write access. If this field is left blank, the mkcd command creates the file system, if the file system does not exist, and removes it when the command completes. 5. Enter the file systems in which to store the CD or DVD file structure and final CD or DVD images. These can be file systems you created in the rootvg, in another volume group, or in NFS-mounted file systems. If these fields are left blank, the mkcd command creates these file systems, and removes them when the command completes, unless you specify differently in later steps in this procedure. 6. If you did not enter any information in the file systems' fields, you can select to have the mkcd command either create these file systems in the rootvg, or in another volume group. If the default of rootvg is chosen and a mksysb image is being created, the mkcd command adds the file systems to the exclude file and calls the mksysb command with the -e exclude files option. 7. In the Do you want the CD or DVD to be bootable? field, select yes to have a boot image created on the CD or DVD. If you select no, you must boot from a product CD at the same version.release.maintenance level, and then select to install the system backup from the system backup CD. 8. If you change the Remove final images after creating CD? field to no, the file system for the CD images (that you specified earlier in this procedure) remains after the CD has been recorded. 9. If you change the Create the CD now? field to no, the file system for the CD images (that you specified earlier in this procedure) remains. The settings that you selected in this procedure remain valid, but the CD is not created at this time. 10. If you intend to use an Install bundle file, type the full path name to the bundle file. The mkcd command copies the file into the CD file system. You must have the bundle file already specified in the BUNDLES field, either in the bosinst.data file of the mksysb image or in a user-specified bosinst.data file. When this option is used to have the bundle file placed on the CD, the location in the BUNDLES field of the bosinst.data file must be as follows:
/../usr/sys/inst.data/user_bundles/bundle_file_name
11. To place additional packages on the CD or DVD, enter the name of the file that contains the packages list in the File with list of packages to copy to CD field. The format of this file is one package name per line. If you are planning to install one or more bundles after the mksysb image is restored, follow the directions in the previous step to specify the bundle file. You can then use this option to have packages listed in the bundle available on the CD. If this option is used, you must also specify the location of installation images in the next step. 12. Enter the location of installation images that are to be copied to the CD file system (if any) in the Location of packages to copy to CD field. This field is required if additional packages are to be placed on the CD (see the previous step). The location can be a directory or CD device. 13. You can specify the full path name to a customization script in the Customization script field. If given, the mkcd command copies the script to the CD file system. You must have the CUSTOMIZATION_FILE field already set in the bosinst.data file in the mksysb image or else use a user-specified bosinst.data file with the CUSTOMIZATION_FILE field set. The mkcd command copies this file to the RAM file system. Therefore, the path in the CUSTOMIZATION_FILE field must be as follows:
/../filename
310
14. You can use your own bosinst.data file, rather than the one in the mksysb image, by typing the full path name of your bosinst.data file in the User supplied bosinst.data file field. 15. To turn on debugging for the mkcd command, set Debug output? to yes. The debug output goes to the smit.log. 16. You can use your own image.data file, rather than the image.data file in the mksysb image, by typing the full path name of your image.data file for the User supplied image.data file field. Creating system backups using DVD-RAM media and Universal Disk Format: Universal Disk Format (UDF) allows you to manipulate files directly on the DVD-RAM media. The system backup image is an archived file composed of many files that cannot be manipulated. However, the installation packages and any files that are not contained in the backup image, can be directly manipulated on the DVD-RAM. After the DVD is mounted the files can be changed by using an editor or new files can be copied to the DVD using the various copy and restore commands such as the cp, mv, restore commands. With UDF and DVD-RAM, system space is only needed for the backup image. A high-level description of the UDF backup process is as follows: 1. Create a backup of a volume group to a file (archive) on a hard disk containing enough space to hold the backup image. 2. Populate UDF with files needed to boot and install a system. 3. Copy backup to DVD-RAM media. The mkcd or the mkdvd command with the -U flag is used to create a UDF file system on the DVD-RAM. UDF allows for the possibility of changing files directly on the DVD-RAM media, such as a bosinst.data file and image.data or vgname.data file. Without UDF for example, to add a user-defined bosinst.data file to a backup image, you must restore the backup image to a location, add the file, and then back up the files again. Or, you had to create a supplemental diskette containing the changed bosinst.data file, and use the supplemental diskette in conjunction with the backup. However, some system configurations might not provide diskette drives, making this procedure more difficult. Creating a root volume group backup on DVD-RAM with Universal Disk Format: Use this procedure to creating a root volume group backup on DVD-RAM with Universal Disk Format (UDF). To create a root volume group backup on DVD-RAM with UDF, do the following: v Use the Web-based System Manager Backup and Restore application and select System backup wizard method. This method lets you create bootable or non-bootable backups on DVD-RAM media. OR v Use SMIT to create a backup to DVD-RAM with UDF, as follows: 1. Enter the smit mkdvd fast path. The system asks whether you are using an existing mksysb image. 2. Select UDF (Universal Disk Format). 3. Enter the name of the DVD-RAM device. 4. If you are creating a mksysb image, select yes or no for the mksysb creation options. The options are as follows: Create map files?
Installation and migration
311
Exclude files? The mkcd command always calls the mksysb command with the flags to extend /tmp. You can specify an existing image.data file or supply a user-defined image.data. See step 14. 5. Enter the file system or directory in which to store the mksysb image. This can be a file system you created in the rootvg, in another volume group, or in NFS mounted file systems with read-write access. If left blank, the mkcd command creates the file system and removes it when the command completes. 6. If you did not enter information in the file system field, you can select to have the mkcd command either create these file systems in the rootvg, or in another volume group. If the default of rootvg is chosen and a mksysb image is being created, the mkcd command adds the file systems to the exclude file and calls the mksysb command with the exclude files option -e. 7. Do you want the DVD to be bootable? If you select no, you must boot from a product CD at the same version.release.maintenance level, and then select to install the system backup from the system backup DVD. 8. If you intend to use an Install bundle file, enter the full path name to the bundle file. The mkcd command copies the file into the DVD file system. You must have the bundle file already specified in the BUNDLES field, either in the bosinst.data file of the mksysb image or in a user-specified bosinst.data file. When this option is used to have the bundle file placed on the DVD, the location in the BUNDLES field of the bosinst.data file must be as follows:
/../usr/sys/inst.data/user_bundles/bundle_file_name
9. Additional packages can be placed on the CD by entering the name of the file that contains the packages list in the File with list of packages to copy to DVD field. The format of this file is one package name per line. If you are planning to install one or more bundles after the mksysb image is restored, follow the directions in the previous step to specify the bundle file. You can then use this option to have packages listed in the bundle available on the DVD. If this option is used, you must also specify the location of installation images in the next step. 10. Enter the location of installation images that are to be copied to the CD file system (if any) in the Location of packages to copy to DVD field. This field is required if additional packages are to be placed on the DVD (see the previous step). The location can be a directory or DVD device. 11. You can specify the full path name to a customization script in the Customization script field. If given, the mkcd command copies the script to the CD file system. You must have the CUSTOMIZATION_FILE field already set in the bosinst.data file in the mksysb image or use a user-specified bosinst.data file with the CUSTOMIZATION_FILE field set. The mkcd command copies this file to the RAM file system. Therefore, the path in the CUSTOMIZATION_FILE field must be as follows:
/../filename
12. You can use your own bosinst.data file, rather than the one in the mksysb image, by entering the full path name of your bosinst.data file in the User supplied bosinst.data file field. 13. To enable debugging for the mkcd command, set Debug output? to yes. The debug output goes to the smit.log. 14. You can use your own image.data file, rather than the image.data file in the mksysb image, by entering the full path name of your image.data file for the User supplied image.data file field.
312
This user backup contains a copy of a non-rootvg volume group, and is useful for volume groups that contain user data. The savevg command uses a data file created by the mkvgdata command. The data file created is as follows:
/tmp/vgdata/vgname/vgname.data
The vgname.data file contains information about a user volume group. The savevg command uses this file to create a backup image that can be used by the restvg command to re-create the user volume group. The savevg command with the -r flag is used to back up only a user-volume group's logical volume structure information. The data needed to list backup properties is also backed up. The -r flag runs the mkvgdata command for the volume group specified to create a vgname.data file. The -r flag backs up only the vgname.data file, any map files, and the backup.data file. The backup image that is created is used with the restvg -r command option to create only the volume group, logical volumes, and file system information contained in the file, without restoring any data. For example, to back up only the paul user volume group's structure information to the /vg_backup/paul_vg_data file, type the following:
savevg -r -f /vg_backup/paul_vg_data paul
You can also use the mkcd command to create a user volume group backup to CD or DVD. The mkcd command saves one volume group at a time to a CD or DVD. The mkcd command with the -L flag allows the creation of ISO9660 DVD sized images. The mkcd or the mkdvd command with the -U flag allows the creation of UDF DVD images. If your rootvg image and savevg image are small enough to fit on one CD or DVD, you can save them both by using the -l (stacklist) and -z (customization_script) flags. The -l flag gives a list of images to copy to the CD or DVD. The -z flag lets you create a script to restore savevg backups. For example, if you make a copy of a non-rootvg volume group ahead of time, and then write a script that calls the restvg command, your non-rootvg volume group would be restored to hdisk2 at the end of the installation of rootvg, as shown by the following command:
restvg -d /SPOT/installp/ppc/savevg_image hdisk2
This procedure is recommended only if you know you want to restore the non-rootvg volume group every time you install. Otherwise, you might just want to store it on the CD/DVD, then use restvg to restore it after reboot. The restvg command can restore from CD or DVD if the name of the image is savevg_image. If you save the non-rootvg backup on a CD or DVD with a different file name, you can insert that CD or DVD and use the full path to the file name as the device for the restvg command. Use either Web-based System Manager or SMIT to back up user volume groups to CD or DVD. Backing-up a user volume group using Web-based System Manager: You can use the wizard for creating a non-bootable CD or DVD that contains only a volume group backup image of a user volume group. Use Web-based System Manager and select System backup wizard method. Creating a user volume group backup using SMIT: With this procedure, you can use SMIT to create a backup image of a user volume group. 1. To back up a user volume group to tape, USB disk or file using SMIT, type smit savevg on the command line. Back up a user volume group to CD by typing smit savevgcd on the command line. Back up a user volume group to DVD by typing smit savevgdvd on the command line.
313
2. When the Save a Volume Group screen displays, use the steps for backing up the root volume group as a guide for backing up user volume groups. There is one exception to this procedure. If you want to exclude files in a user volume group from the backup image, create a file named /etc/exclude.volume_group_name, where volume_group_name is the name of the volume group you want to backup. 3. If you exclude files, edit the /etc/exclude.volume_group_name file and enter the patterns of file names that you do not want included in your backup image. The patterns in this file are input to the pattern-matching conventions of the grep command to determine which files are excluded from the backup.
To preview a backup image in the SMIT, use the lsbackupinfo fast path. Verifying system backup (tape only): You can list the contents of a mksysb image on tape.
314
To list the contents of a mksysb image on tape, you can use either Web-based System Manager (type wsm on the command line, then choose the Backup and Restore application) or SMIT (type smit lsmksysb on the command line). The listing verifies most of the information on the tape, but does not verify that the backup media can be booted for installations. The only way to verify that the boot image on a mksysb tape functions properly is by booting from the media. Viewing the backup log for volume group and system backups: You can view the backup log that is created each time a volume group is backed up. The log file contains information on previous volume group and system backups. You can use the lsmksysb command or the lssavevg command with the -B option to view the backup log file. Type:
# lsmksysb -B
To view the backup log in the SMIT, select View the Backup Log in the System Backup Manager menu. Viewing filesets installed in a system backup: You can view the filesets installed in a system backup using the lsmksysb command with the -L option. For example, to view the filesets installed in a system backup, type the following:
# lsmksysb -L -f generic_sysb
To view the filesets installed in a system backup in SMIT, use the lslppbackup fast path.
315
You can install a system from a backup image that is stored on tape, CD, or DVD, or in a file. Note: You can boot from a CD and use a tape for the installation. However, during a tape boot, you cannot use the CD and DVD drives to supply customized information. For more information about installing a backup stored in a directory on your network installation server, see Using a mksysb image to install the base operating system on a NIM Client on page 160. The procedures to install from backup operate either in prompted or nonprompted mode, depending on conditions set in the /bosinst.data file and on compatibility between the backup image and the installed machine. For more information about modifying the bosinst.data file to preset installation parameters when you create a system backup, see Customizing your installation on page 79 When installing the backup image, the system checks whether the target system has enough disk space to create all the logical volumes stored on the backup. If there is enough space, the entire backup is recovered. Otherwise, the installation halts and the system prompts you to choose additional destination hard disks. File systems are created on the target system at the same size as they were on the source system, unless the backup image was created with SHRINK set to yes in the image.data file, or you selected yes in the BOS Install menus. An exception is the /tmp directory, which can be increased to allocate enough space for the bosboot command. For more information about setting variables, see the image.data file in AIX Version 6.1 Files Reference. When you install a system backup on the source machine, the installation program restores the Object Data Manager (ODM) on that machine. Restoring the ODM allows devices to keep the same number they had on the original system. For example, if you install two Ethernet cards in your source machine, first en0 in slot 3 and then en1 in slot 1, the cards are not renumbered if they are detected in reverse order when you install a system backup. When you clone a system backup, the installation program rebuilds the ODM on the target system after installing the image, so devices are renumbered. In both cases, the rootvg and all logical volumes have different IDs. If you reinstall a system backup on the source machine, and the target system does not have exactly the same hardware configuration as the source system, the program might modify device attributes in the following target system files: v All files in the /etc/objrepos directory beginning with "Cu" v All files in the /dev directory The settings in the bootlist are not restored. After a system backup restore, the bootlist is reset to the primary boot device. Shared volume groups have AUTO ON set to no. Only user volume groups that have AUTO ON set to yes are imported. The reason for this is that shared volume groups might lock out other systems' access to the volume group because of installation queries on the shared volume group at the time of a mksysb restore operation. If you have problems with installations from a mksysb image, see Troubleshooting problems with installation from mksysb backup.
316
example, you can create a system backup from System_A and install System_A's mksysb image onto System_B without having to use product media to boot System_B. For more information on installing all devices and kernels, see Installing all device and kernel support before the backup is created on page 305. If you are performing a clone installation, device information will not be restored to the target system by default. During a clone installation, the BOS installation process verifies that the mksysb image is from the system you are trying to install. If the target system and the mksysb image are different, the device information is not recovered. This behavior is determined by the RECOVER_DEVICES variable in the bosinst.data file. This variable can be set to Default, yes, or no. The following list shows the resulting behaviors for each value: Default No recovery of devices yes no Attempted rebuild of ODM No recovery of devices
Note: You can override the default value of RECOVER_DEVICES by selecting yes or no in the Backup Restore menu or by editing the value of the attribute in the bosinst.data file. If the source system does not have the correct passwords and network information, you can make modifications on the target system now. Also, some products (such as graPHIGS) ship device-specific files. If your graphics adapter is different on the target system, verify that the device-specific filesets for graphics-related LPPs are installed.
Network
Note: Before you begin, select the tape or CD/DVD-ROM drive as the primary boot device. For additional information, refer to the section in your hardware documentation that discusses system management services.
317
Due to enhancements in the mksysb command, you can control how devices are recovered when you install a system backup on the source machine. This behavior is determined by the RECOVER_DEVICES variable in the bosinst.data file. This variable can be set to default, yes, or no. The following list shows the resulting behaviors for each value: default ODM is restored yes no ODM is restored No recovery of devices
Note: You can override the default value of RECOVER_DEVICES by selecting yes or no in the Backup Restore menu or by editing the value of the attribute in the bosinst.data file. To use Web-based System Manager: 1. Start the Web-based System Manager by typing wsm on the command line as root user. 2. Expand Software in the Navigation Area, select Overview and Tasks, then select Reinstall Operating System. 3. Choose the installation device: v Network If you choose this option, your machine must either be a configured NIM client, or have access to a NIM environment. If your machine is not a NIM client, the Reinstall Base Operating System wizard leads you through the process. For more information on setting up a NIM environment, see Using installation images to install the base operating system on a NIM client. v Tape or CD/DVD-ROM 4. Choose Install a system backup image (mksysb) as the installation type. 5. Follow the wizard prompts to complete the procedure. To use the command line: 1. You can use the bootlist command to display or change the primary boot device. To display the primary boot device:
bootlist -m normal -o
2. Power off your machine by following these steps: a. Log in as the root user. b. Enter the following command:
shutdown -F
c. If your system does not automatically power off, place the power switch in the Off (0) position. Attention: Do not turn on the system unit until Step 6 on page 319. 3. Turn on all attached external devices. These include: v Terminals v CD or DVD drives v Tape drives v Monitors v External disk drives Turning on the external devices first is necessary so that the system unit can identify them during the startup (boot) process.
318
4. Insert the installation media into the tape or CD or DVD drive. You might find that on certain tape drive units, the tape drive door does not open while the system is turned off. If you have this problem, use the following procedure: a. Turn on the system unit. b. Insert the boot installation tape (insert Volume 1 if you received more than one volume). c. Turn off the system unit and wait for 30 seconds. 5. If you are not using an ASCII terminal, skip to Step 6. If you are using an ASCII terminal, use the following criteria to set the communications, keyboard, and display options. Note: If your terminal is an IBM 3151, 3161, or 3164, press the Ctrl+Setup keys to display the Setup Menu and follow the on-screen instructions to set these options. If you are using some other ASCII terminal, refer to the appropriate documents for information about how to set these options. Some terminals have different option names and settings than those listed here.
Communication Options Option Line Speed (baud rate) Word Length (bits per character) Parity Number of Stop Bits Interface Line Control Setting 9600 8 no (none) 1 RS-232C (or RS-422A) IPRTS
Keyboard and Display Options Option Screen Row and Column Scroll Auto LF (line feed) Line Wrap Forcing Insert Tab Operating Mode Turnaround Character Enter Return New Line Send Insert Character Setting normal 24x80 jump off on line (or both) field echo CR return new line CR page space
6. Turn the system unit power switch from Off (0) to On (|). The system begins booting from the backup media. If your system is booting from tape, it is normal for the tape to move back and forth. If your system has an LED display, the three-digit LED should display c31. Note: You can boot from production media (tape or CD) if your backup media fails to boot. The initial Welcome screen includes an option to enter a maintenance mode in which you can continue the installation from your backup media. Refer to Troubleshooting an installation from a system backup for more information. If you have more than one console, each terminal and directly attached display device (or console) might display a screen that directs you to press a key to identify your system console. A different
Installation and migration
319
key is specified for each terminal displaying this screen. If this screen is displayed, then press the specified key only on the device to be used as the system console. (The system console is the keyboard and display device used for installation and system administration.) Press a key on only one console. Note: If the bosinst.data file lists a valid display device for the CONSOLE variable, you do not manually choose a system console. Read Customizing your installation for more information about the bosinst.data file. 7. The type of installation that begins is determined by the settings of the PROMPT field in the control_flow stanza of the bosinst.data file. Use the following criteria to determine the type of installation you will be using:
PROMPT = no PROMPT = yes Nonprompted Installation. This installation method is used if the backup image is configured to install automatically, without having to respond to the installation program. Go to step 8. Prompted Installation. This installation method is used if you need to use menu prompts to install the backup image. Also, use this installation method if a nonprompted installation halts and the Welcome to Base Operating System Installation and Maintenance screen displays. Go to step 9.
8. A successful nonprompted installation requires no further instructions because the installation is automatic. Note: If the backup image holds source system-configuration information that is incompatible with the target system, the nonprompted installation stops and a prompted installation begins. The Installing Base Operating System screen displays before the installation starts. The nonprompted installation pauses for approximately five seconds before beginning. After this time, the non-prompted installation continues to completion. However, if you decide to interrupt the automatic installation and start a prompted session, type 000 (three zeros) at the terminal and follow the remaining steps in this procedure. 9. The Welcome to the Base Operating System Installation and Maintenance screen displays. Note: You can view Help information at each screen of this installation process by typing 88. Choose the Change/Show Installation Settings and Install option. 10. The System Backup Installation and Settings displays. This screen shows current settings for the system. An ellipsis follows the disk listed in the first line if there is more than one disk selected. 11. Either accept the settings or change them. For more information on using map files, see Creating system backups. To accept the settings and begin the installation, skip to step 16. To change the settings, continue with step 12. 12. Type 1 in the System Backup Installation and Settings screen to specify disks where you want to install the backup image. The Change Disk(s) Where You Want to Install screen displays. This screen lists all available disks on which you can install the system backup image. Three greater-than signs (>>>) mark each selected disk. Type the number and press Enter for each disk you choose. Type the number of a selected disk to deselect it. You can select more than one disk. Note: You can also specify a supplemental disk by typing 66 and pressing the Enter key for the Disks not known to Base Operating System Installation option. This option opens a new menu that prompts for a device support media for the supplemental disk. BOS installation configures the system for the disk and then returns to the Change Disk(s) Where You Want to Install screen. 13. After you have finished selecting disks, press the Enter key. The screen that displays after you press the Enter key is dependent on the availability of map files for all of the selected disks. The criteria for this is as follows:
320
v If one or more selected disks have no maps, BOS installation returns directly to the System Backup Installation and Settings screen. Skip to step 15. v If all selected disks have maps, the Change Use Maps Status screen displays, where you choose whether to use maps for installation. Continue with step 14. To preserve the placement of logical volumes during a future restoration of the backup, you can create map files before backing up a system. Map files, stored in the /tmp/vgdata/rootvg directory, match the physical partitions on a drive to its logical partitions. Create map files either with the SMIT Backup the System menu, using Web-based System Manager, or using the -m option when you run the mksysb command. For more information about map files, see Using Map Files for Precise Allocation in Operating system and device management. 14. Type either 1 or 2 in the Change Use Maps Status screen to specify whether the installation program is to use maps. When you complete this choice, BOS installation returns to the System Backup Installation and Settings screen. 15. Decide whether BOS installation is to shrink file systems on the disks where you install the system. When you choose this option, the logical volumes and file systems within a volume group are re-created to the minimum size required to contain the data. This reduces wasted free space in a file system. File systems on your backup image might be larger than required for the installed files. Press the 2 key to toggle the Shrink File Systems option between Yes and No in the System Backup Installation and Settings screen. The default setting is No. Note: Shrinking the file system disables the use of maps. 16. Type 0 to accept the settings in the System Backup Installation and Settings screen. The Installing Base Operating System screen displays the rate of completion and duration. If you specified a supplemental disk in step 12, an untitled screen temporarily replaces the Installing Base Operating System screen. When this screen displays, it prompts you to place the device-support media in the drive and press the Enter key. BOS installation reconfigures the supplemental disk, then returns to the Installing Base Operating System screen. The system reboots automatically when the installation completes.
The cdromd daemon can interfere with scripts, applications, or instructions that attempt to mount the CD or DVD device without first checking to see if the device is already enabled. A resource or device busy error occurs in such a condition. Use the cdumount or cdeject command to unmount the device. Then mount the device as specified in the program or instructions. Alternatively, use the cdcheck -m or mount command to determine the current mount point of the device. For further information, see the cdromd command documentation in the AIX Version 6.1 Commands Reference. The installation code allows for this automatic mounting. If cdromd is enabled and the mkcd command is run, the CD-R or DVD-RAM is ejected after the image is completed. If you do not want to have the media ejected, then the cdromd daemon must be put in the inoperative state with the following command:
Installation and migration
321
# stopsrc -s cdromd
Each field in the software product identification is defined as follows: v The versionnumber field consists of 1 to 2 digits that identify the version number.
322
v The releasenumber field consists of 1 to 2 digits that identify the release number. v The modificationlevel field consists of 1 to 4 digits that identify the modification level. v The fixlevel field consists of 1 to 4 digits that identify the fix level. For example, 05.01.0000.0000 is a software product level number, and 05.01.0000.0032 is a software product update level. It is not necessary to include the leading zeroes in the version, release, modification level, and fix level fields of the level. Level 05.01.0000.0000 can also be written as 5.1.0.0.
Software licensing
The types of software licensing that can be implemented in the software purchase are run-time licensing and acceptance of software license agreements. Normally, software requiring run-time licenses is only selected for installation when you have a license to use that software. Although the Web-based System Manager and System Management Interface Tool (SMIT) allow you to install licensed software even if you do not own a license, you might be prevented from using the newly installed software until you have obtained the appropriate license. Accepting software license agreements requires that the license agreement be accepted as part of the installation process. If software installed as part of your BOS installation requires accepting a software license agreement, you cannot exit the Configuration Assistant (or the Installation Assistant for non-graphics consoles) until the license agreement has been accepted. You can view as well as accept the license agreement. The BOS installation can be customized to automatically accept software licenses. For more information, refer to Customizing your installation on page 79. For optional software installation, you can preview the license agreements on the installation media using the smit license_on_media fast path or the installp -El command. During the installation process, you can use the menu item to accept the software license, or you can use the installp command with the -Y flag. To view accepted license agreements on a system, you can use the SMIT smit installed_license fast path or the lslpp -E command. To view licenses using the Web-based System Manager, type wsm to start the application, and select Software. When a product is uninstalled, the license agreement acceptance is changed to the inactive state. If the product is reinstalled, you will not be prompted to reaccept the license agreement. After completing the prerequisites in the next section, your next step is deciding whether to install software with the Web-based System Manager or with SMIT. Descriptions of both applications are included in this chapter. Before you install optional software and service updates, refer to the specific instructions that accompany your installation media. If you ever need to reinstall your system, refer to the installation media instructions. Note: For information about developing software products that are installed using the installp command, refer to Packaging Software for Installation in AIX Version 6.1 General Programming Concepts: Writing and Debugging Programs.
323
or -e (enterprise) option, and an optional -d (device) flag which allows for the installation of an edition bundle file. A new ITLM signature file will be copied from the /usr/lpp/bos/editions directory to the /usr/lpp/bos directory, removing the previous signature file from the/usr/lpp/bos directory. If the optional -d flag is used, then the chedition command will call geninstall to install the content of any edition bundle files that exist, utilizing the default installp flags of acNgX. If other flags are desired, the Install Software Bundle SMIT menus (fastpath smitty install_bundle) should be used. The chedition command also supports a p (preview) flag. The optional d flag allows an edition bundle to be installed at a later time, as an edition change is not required to install an edition bundle. After successfully completing an edition change, if a previous edition of a bundle file exists, then an informational message appears reminding the user to remove any software that was specific to the previous edition. If the geninstall command returns a non-zero value while attempting to install an edition bundle file, an error message appears and the system edition will not be updated. By default, the system edition is set to express.
v To eject the documentation disk, press the eject button on the media drive for at least two seconds.
324
For example, using the sample build dates shown below (0723 represents the 23rd week of the year 2007), a Technology Level 7 fileset at level 5.3.7.0 is prevented from installing on top of Technology Level 6 fileset at level 5.3.0.80 even though 5.3.7.0 has a higher VRMF (Version, Release, Modification, Fix). Previously, only a VRMF comparison needed to be run to determine installation eligibility. Now the "build date" of the installed fileset is checked to verify that the fileset to be installed is not older.
YYWW 0723 0746 0816 -----------------------------------------------TL7 5.3.7.0 5.3.7.10 TL6 5.3.0.60 5.3.0.70 5.3.0.80
For more information about AIX service and support strategy, see Service and support best practices.
325
2. 3. 4. 5.
Expand the machine name. Expand Software in the Navigation area. Select Overview and Tasks. Select Install Software.
Installing service updates with Web-based System Manager: Follow this procedure for installing service updates with Web-based System Manager. 1. Start the Web-based System Manager by typing wsm on the command line. 2. Expand the machine name. 3. Expand Software in the Navigation area. 4. Select Overview and Tasks. 5. Select Update Software to the Latest Level. Installing software bundles with Web-based System Manager: Follow this procedure for installing software bundles with Web-based System Manager. 1. Start the Web-based System Manager by typing wsm on the command line. 2. Expand the machine name. 3. Expand Software in the Navigation area. 4. Select Installed Software. 5. From the Software menu, select New Software (Install/Update) > Install Bundles (Easy).
326
Install and Update from ALL Available Software Install or update software from all software available on the media. To use this option, type smit install_all on the command line. Note: If a problem occurs during the installation of optional software that causes the installation process to halt abnormally, you might have to complete a cleanup procedure to remove the partially installed software from the system before attempting to reinstall it. If the system instructs you to do a cleanup, go to Cleaning up optional software products and service updates on page 332.
When this message displays, insert the specified media and press Enter. When the installation finishes, the Command: status field on the COMMAND STATUS screen changes to OK or failed. OK indicates that the installation ran to completion, although some filesets may not have installed successfully. The failed status means that there was a problem with the installation. Although a preview installation always finishes with an OK status, always check the summaries. For information about error messages, refer to Interpreting installation-related system and error messages on page 92. 2. When the installation halts or finishes, the screen returns to the top of the list of messages that display during installation. You can review the message list as described in the next step, or you can exit SMIT and review the smit.log file (/smit.log or /home/user_id/smit.log). 3. Review the message list for error messages on software products or service updates that may not have been successfully installed. Use the following procedure to correct any errors in the installation: a. Look at the pre- and post-installation summaries at the end of the message list to see whether any installation failure occurred. b. Use the message list to determine problems and which software products or service updates were involved. For example, space limits might have been exceeded or the requisites might not have been met for some software. The system lists how much extra space is needed and which requisite software products or service updates to install. c. Any product that is marked as FAILED, BROKEN, or CANCELLED can be reinstalled after the condition that caused the failure has been corrected. You do not need to reinstall any service update or software product that was marked as SUCCESS in the Installp Summary report. If you need to perform the installation again, change installation settings as appropriate. For example, if requisites were missing, set AUTOMATICALLY install requisite software? to yes. If there was not enough space to complete the installation, set EXTEND file systems if space needed? to yes. If you need to install again and you have AIX BOS multivolume media, insert volume 1 of the AIX product CDs. Press F3 to return to the previous screen, then restart the installation. See Interpreting installation-related system and error messages on page 92 for information about bosboot command errors that may occur while the installation program is running, and about recovery procedures for these errors.
327
Attention: If the system log files show the following message, indicating that a reboot is required, perform the reboot as indicated in Step 6:
* * * System system and to A T T E N T I O N * * * boot image has been updated. You should reboot the as soon as possible to properly integrate the changes avoid disruption of current functionality.
d. If the installation was interrupted (for example, a power failure), you might need to use the cleanup procedure before continuing. Press F10 (or Esc+0) to exit SMIT, and refer to Cleaning up optional software products and service updates on page 332. e. If the software has been installed successfully, and you have no other software to install, go to Step 4. If you have additional software to install from a different installation media, remove the media that is in that drive and insert the new media. Press F3 (or Esc+3) to return to the previous screen and continue installing the software product or service update. 4. Press F10 (or Esc+0) to exit SMIT. 5. Remove all installation media from the drives. 6. When you are directed, reboot your system by typing: # shutdown -Fr
For more information about the install_all_updates command, refer to the AIX Version 6.1 Commands Reference.
328
329
Although applying and committing a service update are separate actions, both can be accomplished while installing the update. In fact, the default action under Web-based System Manager and SMIT is to both apply and commit the service update during installation. This default can be changed to just apply the update. Committing a service update using Web-based System Manager: 1. Start the Web-based System Manager by typing wsm on the command line. 2. Expand the machine name. 3. Expand the Software container. 4. Select Installed Software. 5. From the Software menu, choose Software Utilities > Commit Applied Updates. You can list all service updates in the applied state by selecting List Installed Software > Updates in Applied State from the Software menu. Committing a service update using SMIT: Type smit commit on the command line. You can list all service updates in the applied state by typing smit list_installed on the command line. Committing a service update from the command line: Use the installp -c command to commit applied updates. You can list all service updates in the applied state by typing installp -s on the command line.
330
The remove process also attempts to restore the system's configuration to its previous state, although this is dependent on the product and might not always be complete. After a product is removed, no version of that product remains running on the system. Use the Web-based System Manager or SMIT to remove software products. In either application, if you set the Remove dependent software? field to yes, any requisite software (software that is dependent on the product you are removing) is also removed, unless it is required by other software on your system. Removing 1. 2. 3. 4. 5. a software product using Web-based System Manager: Start the Web-based System Manager by typing wsm on the command line. Expand the machine name. Expand the Software container. Select Installed Software. Select the software product you want to remove.
6. From the Selected menu, choose Remove Software. Removing a software product using SMIT: Type smit remove on the command line. Removing a software product from the command line: Use the geninstall -u command to remove the product.
v Trusted_AIX_SYSMGT
331
332
The lppmgr command performs the following functions on an existing installp image source (also known as an lpp_source resource in the NIM environment): v Remove duplicate updates (-u flag). v Remove duplicate base levels (-b flag). v Eliminate update images that are the same level as base images of the same fileset. Such update images can create conflicts that lead to installation failure (-u flag). v Remove message and locale filesets other than the language you specify (-k flag). v Remove superseded filesets (-x flag). v Remove non-system images from a NIM lpp_source resource (-X flag). By default, lppmgr lists all images filtered by the preceding routines. The -r flag can be used to remove the filtered images and the -m flag can be used to move the images to another location. The lppmgr command does not replace the bffcreate command, perform installations, or work with installed filesets. Before using the -X flag, it is recommended that you have a good understanding of NIM, system images (known as SIMAGES in NIM), and the workings of a NIM lpp_source resource. To list all duplicate and conflicting updates in the /myimages image source directory, type:
# lppmgr -d /myimages -u
To remove all duplicate and conflicting updates in the /myimages image source directory, type:
# lppmgr -d /myimages -u -r
For more information about the lppmgr command, refer to the AIX Version 6.1 Commands Reference.
333
v v v v v
An RqType parameter specifies the type of download that is being requested (such as critical fixes, a specific fileset, or an APAR). A policy can be set up to retrieve the following types of fixes: APAR Specifies a request to download an APAR (such as IY12345). PTF ML TL SP Specifies a request to download a PTF (such as U123456). Specifies a request to download a specific maintenance level (such as 5300-03). Specifies a request to download a specific technology level (such as 5300-04). Specifies a request to download a specific service pack (such as 5300-06-01-0744).
Fileset Specifies a request to download a specific fileset (such as bos.rte.lvm). Security Specifies a request to download the latest security fixes. Critical Specifies a request to download the latest critical fixes. These resolve highly pervasive (HIPER) problems. Latest Specifies a request to download all of the latest fixes. Several flag options can be used with the suma command to further specify your request. With these command options, you can perform the list, edit, create, schedule, unschedule, and delete operations on different tasks or policies. For example, to create and schedule (-s) a task that downloads the latest critical fixes on the 15th day of every month at 2:30 a.m. (using cron format), and add a policy label through the DisplayName field (useful when listing policies through SMIT), type:
suma -s "30 2 15 * *" -a RqType=Critical \ -a DisplayName="Critical fixes - 15th Monthly"
The preceding example uses task defaults, which can be displayed by the suma -D command. Type the following command to create and schedule a task that downloads the entire 5300-02 Maintenance Level into the /lppsrc/5302 directory on Monday at 11:00 p.m., while turning off filtering against installed software (FilterSysFile), and running an lppmgr clean operation after the download to remove any superseded updates, duplicates base levels, and conflicting updates:
suma -s "0 23 * * 1" -a Action=Clean -a RqType=ML -a RqName=5300-02 \ -a DLTarget=/lppsrc/5302 -a FilterSysFile=/dev/null
Note: Prior to running a task that specifies Action=Clean, you can run suma -c to verify the SUMA global configuration settings that will be used when running lppmgr. Setting REMOVE_SUPERSEDE, REMOVE_DUP_BASE_LEVELS, and REMOVE_CONFLICTING_UPDATES to yes will result in the intended action of the preceding example. For a more complete listing of examples that detail the functionality of the suma command, refer to the suma command.
334
on a system to another source. This source could be a fix repository, such as an lpp_source or a directory of fixes, or a downloaded list from the IBM System p support Web site. If you want to verify that your lpp_source is up to date, you can also compare a fix repository to a downloaded list. You can perform these actions in the SMIT compare_report fast path or using the compare_report command. Using the Compare Installed Software to Fix Repository menu: The Compare Installed Software to Fix Repository menu allows you to compare the filesets installed on a system to a fix repository. The following report lists are generated: v Filesets on the system that are back-level (lowerlevel.rpt) v Filesets on the system that are at a later level (higherlevel.rpt) v Filesets in the fix repository that are not installed on the system (notinstalled.rpt) v Filesets installed on the system that are not in the fix repository (no_update_found.rpt) The Compare Installed Software to Fix Repository option is available using the SMIT instofix_compare fast path or the compare_report command with the following options:
compare_report -s -i FixDir {[-l] [-h] [-m] [-n]} [-t ReportDir -Z | -v] compare_report -b BaseList -i FixDir {[-l] [-h] [-m] [-n]} [-t ReportDir] -Z | -v]
When using the -l (lower) or -h (higher) flags, the compare report only shows that interim fixes are installed. The higher or lower concept is not currently available. Compare Installed Software to List of Available Updates menu: The Compare Installed Software to List of Available Updates menu allows you to compare the filesets installed on a system to a downloaded list of available updates from the IBM System p service Web site. The following report lists are generated: v Filesets on the system that are back-level from the latest (lowerthanlatest1.rpt) v Filesets on the system that are at a later level from the latest maintenance and technology levels (higherthanmaint.rpt) v Filesets on the system that are back-level from the latest maintenance and technology levels (lowerthanmaint.rpt) The Compare Installed Software to List of Available Updates option is available using the SMIT instolist_compare fast path or the compare_report command with the following options:
compare_report -s -r ServiceReport {[-l] [-h]} [-t ReportDir -Z | -v] compare_report -b BaseList -r ServiceReport {[-l] [-h]} [-t ReportDir] -Z | -v]
When using the -l (lower) or -h (higher) flags, the compare report only shows that interim fixes are installed. The higher or lower concept is not currently available. Compare Fix Repository to List of Available Updates menu: The Compare Fix Repository to List of Available Updates menu allows you to compare the filesets in a fix repository, such as a fix directory or lpp_source, to a downloaded list of available updates from the IBM System p service Web site.
Installation and migration
335
The report list that is generated contains information on filesets in the fix directory that are back-level from latest (lowerthanlatest2.rpt). The Compare Fix Repository to List of Available Updates option is available using the SMIT fixtolist_compare fast path or the compare_report command with the following options:
compare_report -i FixDir -r ServiceReport [ -t ReportDir -Z | -v ]
Compare a list of installed software on a base system to another system: The compare a list of installed software on a base system to another system option allows you to compare the filesets installed on a system to another system. The lslpp -Lc output from one system is saved to a file and compared with the lslpp -Lc output from another system. The following report lists are generated: v A list of base system installed software that is at a lower level (baselower.rpt) v Filesets not installed on the base system, but installed on the other system (otheronly.rpt) v A list of base system installed software that is at a higher level (basehigher.rpt) v Filesets installed on the base system that are not installed on the other system (baseonly.rpt) To compare a list of installed software on a base system to another system use the compare_report command with the following options:
compare_report -b BaseList -o OtherList {[-l] [-h] [-m] [-n]} [-t ReportDir -Z | -v]
You can also create a log file containing a mapping between the old names and new names, using the -s logfile option, as shown in the following example:
# /usr/sbin/bffcreate -cd /usr/sys/inst.images -s /usr/sys/inst.images/names.log
This example creates a /usr/sys/inst.images/names.log file that contains content formatted as follows:
old_fileset_name:new_fileset_name
This option is also available in SMIT Rename Software Images in Repository menu as the LOG software name changes (location of log file) option.
336
v The Remove Superseded updates option allows you to remove superseded filesets from the specified directory. This action applies only to update images. v The Remove Language software option allows you to remove language and locale filesets that are not needed on your system. This option removes all language and locale filesets from the specified directory, except the language specified in the PRESERVE language field. By default, the value of the LANG environment variable for the system is used to determine the language to preserve. v The Save Removed files option allows you to save all removed files to the location specified in the DIRECTORY for storing saved files field. Select true in this field if you want to move the images to another location instead of removing them from the hard drive. This option is available using the SMIT cleanup_software fast path.
337
information about the installation, including space requirements and file system expansion. If you do not want to proceed with the installation after viewing this information, press the CANCEL button to exit the wizard. v Use the geninstall command to install an ISMP-packaged product. To perform an interactive installation, specify the device or directory containing the product installation files with the -d flag and specify the product name. The product name is the same as the subdirectory name containing the product installation files. For example, if we have a product called MyProduct, and the product installation files are in the /usr/sys/inst.images/ismp/ppc/MyProduct/ directory, use the following command for an interactive installation:
/usr/sbin/geninstall -d /usr/sys/inst.images J:MyProduct
Use the J: prefix to inform the geninstall command that the product is an ISMP package. The geninstall command recognizes the ismp/ppc subdirectory, just as it recognizes RPMS/ppc for RPM packages and installp/ppc for installp packages, so it is only necessary to pass the /usr/sys/inst.images base directory. You can also use the directory that contains the installation files. In this example, specify the directory as follows:
/usr/sbin/geninstall -d /usr/sys/inst.images/ismp/ppc/MyProduct J:MyProduct
If you want to launch a silent or nonprompted installation with geninstall, include the -Z flag:
/usr/sbin/geninstall -d /usr/sys/inst.images -Z J:MyProduct
For more information about silent installations, see Performing a silent installation using response files on page 339. v You can use the installation files provided by the product developer to install an ISMP-packaged product. The product developer might provide a script or executable that can be used to launch an ISMP-packaged product installation. For more information, refer to the documentation provided with the product.
Note: If you select the preview option, but proceed through the entire uninstallation wizard, the product is uninstalled. Most ISMP products include a pre-uninstallation summary panel that provides preview information about the uninstallation. If you do not want to proceed with the installation after viewing this information, press the CANCEL button to exit the wizard. v You can use the geninstall command to perform an uninstallation for an ISMP-packaged product. To perform the uninstallation interactively, specify the -u flag for uninstallation, and the product name. For example, to uninstall the MyProduct product, type the following:
/usr/sbin/geninstall -u J:MyProduct
To speed processing, use the J: prefix to inform the geninstall command that you are uninstalling an ISMP-packaged product.
338
To perform a silent or nonprompted uninstallation with the geninstall command, use the -Z flag, as follows:
/usr/sbin/geninstall -Zu J:MyProduct
v You can use installation files provided by the product developer to uninstall an ISMP-packaged product. The product developer might provide instructions for performing an ISMP-packaged product uninstallation. For more information, see the documentation provided with the ISMP product.
The geninstall command searches in the ISMP-product subdirectory for each ISMP product specified in the install list or bundle for a MyProduct.response file. If a MyProduct.response file does not exist or is not found, geninstall proceeds with whatever defaults are configured in the installer. The -t ResponseFileLocation option allows you to specify an alternate location for response files or response file templates. The ResponseFileLocation can either be a file or directory name. If the ResponseFileLocation is a directory, it must already exist. If the ResponseFileLocation is not an existing directory, it is assumed that a file name is specified. To use response files with ISMP products, the following methods are available: v Create a response file template. To create an ISMP response file template in the default location, use the geninstall command with the -T flag. The -T flag creates an ISMP response file template in the default location, which is the directory containing the product installation files. The resulting template can be used to create a response file for future installations of the same product with the desired options. Creation of the response file template does not result in installation of the ISMP product. To create an ISMP response file template for the MyProduct ISMP product using the product installation files in the /usr/sys/inst.images/ismp/ppc/MyProduct/ default directory, do the following:
/usr/sbin/geninstall -d /usr/sys/inst.images -T J:MyProduct
The MyProduct.template response file template that is generated is similar to the following:
####################################################################### # # InstallShield Options File Template # # Wizard name: Setup # Wizard source: setup.jar # Created on: Tue Jun 25 10:59:55 CDT 2004 # Created by: InstallShield Options File Generator # # This file can be used to create an options file (i.e., response file) for the # wizard "Setup". Options files are used with "-options" on the command line to # modify wizard settings. # # The settings that can be specified for the wizard are listed below. To use # this template, follow these steps: # # 1. Enable a setting below by removing leading ### characters from the # line (search for ### to find settings you can change). # # 2. Specify a value for a setting by replacing the characters <value>. # Read each settings documentation for information on how to specify its # value. # # 3. Save the changes to the file.
Installation and migration
339
# # 4. To use the options file with the wizard, specify -options <filename> # as a command line argument to the wizard, where <filename> is the name # of this options file. # ##################################################################### ##################################################################### # # My Product Install Location # # The install location of the product. Specify a valid directory into which the # product is installed. If the directory contains spaces, enclose it in # double-quotes. For example, to install the product to C:\Program Files\My # Product, use # # -P installLocation="C:\Program Files\My Product" # ### -P installLocation=<value>
Although the preceding is a simple example, products often have many user-configurable options that might be set in the response file. Each of these options is presented in the template with an explanation of the expected value for that option. v Create a response file recording. To create a response file recording, use the geninstall command with the -E flag. The -E flag creates an ISMP response file recording in the default location, which is the directory containing the product installation files. This option requires running the ISMP installation interactively and completely. Creation of the response file recording will also result in installation of the ISMP product. To record the MyProduct.response response file with the MyProduct ISMP product and the product installation files in the /usr/sys/inst.images/ismp/ppc/MyProduct/ default directory, do the following:
/usr/sbin/geninstall -d /usr/sys/inst.images -E J:MyProduct
This starts the interactive installation wizard. It is necessary to run the wizard to completion to successfully create the response file recording. When completed, a message similar to the following displays:
Options record mode enabled - run the wizard to completion to create the options file response.file
340
# double-quotes. For example, to install the product to C:\Program Files\My # Product, use # # -P installLocation="C:\Program Files\My Product" # -P installLocation="/opt/MyProduct"
The -P installLocation value has been completed according to the response given while running the wizard. In the preceding example, the /opt/MyProduct directory was specified as the installation location in the wizard. The response file generated by this action can be used directly to launch a silent installation with the chosen installation location. v Use a response file for a silent installation. You can use a response file generated by the two methods mentioned previously or one provided with the product to perform a silent installation with the desired options. To use a response file for a silent installation with the geninstall command, the MyProduct product, and the installation files and response file in the /usr/sys/inst.images/ismp/ppc/MyProduct/ default directory, do the following:
/usr/sbin/geninstall -Zd /usr/sys/inst.images J:MyProduct
To use a response file for a silent installation with the geninstall command, MyProduct product, installation files in /usr/sys/inst.images/ismp/ppc/MyProduct/ directory, and the /tmp/MyProduct/ MyProduct.response response file, do the following:
/usr/sbin/geninstall -Zd /usr/sys/inst.images \ -t /tmp/MyProduct/MyProduct.response J:MyProduct
341
The interim fix management solution consists of: the interim fix packager (epkg) command and the interim fix manager (emgr) command. The epkg command creates interim fix packages that can be installed by the emgr command. The emgr command installs, removes, lists, and verifies system interim fixes. Note: When the term package is used, installp's reference is the term fileset.
For example, to get a level 1 verbosity output on the interim fix package test.102403.epkg.Z, type the following command.
# emgr -d test.102403.epkg.Z
The verbosity levels include the following information: LEVEL 1 Lists one interim fix per line with the following information: v Label for the interim fix package v Interim fix files contained in the package v Target location for each interim fix file LEVEL 2 Lists the following information: v All LEVEL 1 information v Abstract v Reboot requirement (yes or no) v Prerequisite files needed v v v v v Pre-install script Post-install script Pre-remove script Post-remove script File type for each interim fix file
LEVEL 3 Lists the following information: v All LEVEL 2 information v Packaging date for each interim fix file v Virtually unique ID (VUID) for each package
342
v v v v v v v v v
File size for each interim fix file Checksum for each interim fix file Package for each interim fix file Description of each interim fix file Contents of installation scripts and control files, if they are readable text Reboot scenario for each interim fix file Prerequisites of interim fix file on other interim fix files Packages that will be locked when the interim fix is installed Interim fixes that will be superseded when the interim fix is installed
Note: Displaying is not supported in the original release of interim fix management. You should update to the latest level of interim fix management to enable this feature. To update interim fix management, update bos.rte.install to the latest level. Installing interim fix packages: The emgr command installs interim fix packages that are created with the epkg command. The following example shows the syntax for installing an interim fix package:
emgr -e interim fixPackage | -f ListFile [-w Directory] [-b] [-k] [-p] \ [-I] [-q] [-m] [-o] [-X] [-a path]
The interim fix package installation operation consists of the following phases: The installation preview phase: These steps occur during the installation preview phase. 1. The interim fix manager initializes all commands and libraries, and extracts the interim fix metadata from the interim fix package. 2. The interim fix attributes and description are listed. 3. The emgr command performs a lock-checking procedure by checking the installed interim fix data if the target files that are being delivered by this interim fix package already have existing interim fixes installed. If one or more interim fix files that are delivered by this interim fix package are locked, the emgr command does not allow the installation or installation preview to proceed. 4. The emgr command performs installp package prerequisite verification. If the user supplied an installp prerequisite file, the emgr command checks the prerequisites at this stage. If one or more of the prerequisites is not met, the emgr command does not allow the installation or installation preview operation to proceed. 5. The emgr command performs interim fix to interim fix prerequisite verification. The emgr command checks the following: v All interim fix prerequisites for the interim fix package being checked are installed. v All interim fix xrequisites for the interim fix package being checked are not installed. v There are no previously installed interim fixes that list the interim fix being checked as an xrequisite. Note: You can use the epkg command to specify the interim fix to interim fix prerequisites for an package. For more information on checking prerequisites, see Interim fix user-specified package components on page 355. 6. The emgr command checks for space requirements by checking whether the target file systems contain adequate space for the installation of the interim fix package. This includes space for unpacking the interim fix files, creating database entries, saving replaced files, installing interim fix
343
files, creating interim fix mounts when using the -m flag, archiving library members, and other miscellaneous tasks. The emgr command also adds a small buffer to the various space calculations to account for file metadata and other factors. If the user specifies the auto-expand flag using the -X flag, then the emgr command attempts to expand the file system to the required size. If space requirements cannot be met, the emgr command stops the installation. If the user specifies a preview installation using the -p flag, then the emgr command only reports the space statistics without attempting expansion If the user specifies a preview installation using the -p flag, the emgr command does not perform the interim fix installation phase. Instead the emgr command skips to the summary and cleanup phase of installation. The installation phase: During the installation phase for installing interim fix packages, these steps occur. 1. During the interim fix installation setup step, the entire interim fix package is unpacked and the installation tools are initialized. 2. The emgr command checks whether the interim fix package supersedes any other currently installed interim fix files. If any of the installed interim fix files should be superseded, the emgr command removes them. Note: You can use the epkg command to specify that an interim fix package be superseded when you install another interim fix package. For more information on superseding, see Interim fix user-specified package components on page 355. If a pre_install script is specified, it is run. If the pre_install script returns a failure, the emgr command halts the installation. If the pre_install script succeeds, the emgr command proceeds with the installation and sets the interim fix state to INSTALLING. Any files that are replaced by interim fix files in the interim fix package are saved to a secured directory. If the interim fix package does not deliver any files, this step is skipped. From this point forward, any major failure causes the emgr command to run a failure-cleanup procedure, which attempts to clean up the failed installation. If this process fails, the interim fix is placed into the BROKEN state. All interim fix files are installed to their target locations. If the installation is a mount installation operation using the -m flag, then the emgr command creates a unique mount file within the parent directory of the target file. The target file is then over-mounted by the interim fix mount point. For more information about the mount installation operation, see Performing an interim fix mount installation operation on page 348. Package locking occurs. The interim fix package locks are processed. If the installer for which the interim fix package is created supports interim fix package locking, the emgr command locks the package associated with the interim fix files installed in step 4. For example, the installp command supports interim fix locking, so an interim fix created for an installp package will support interim fix package locking.
3.
4.
5.
6.
Note: In addition to implicit locking, you can use epkg to specify that a certain package be explicitly locked when you install another package. For more information on locking, see Interim fix user-specified package components on page 355. 7. If a post_install script is specified, it is run. If the post_install script returns a failure, the emgr command halts the installation. 8. Reboot processing occurs. If the interim fix package specifies that a reboot operation is required, the emgr command issues a message to the user and makes any necessary changes to the boot image. The emgr command does not reboot the system automatically. 9. At this point, all installation steps have succeeded and the emgr command changes the interim fix state to STABLE for a standard installation operation, or MOUNTED for a mount installation operation.
344
The summary and cleanup phase: These steps occur during the summary and cleanup phase. 1. The emgr command displays a summary of all operations and results. If more than one interim fix package was specified with an input file using the -f flag, the emgr command provides a report for each interim fix package. 2. The emgr command cleans up any temporary directories and files. It also unloads any memory modules that have been loaded into memory. Removing an interim fix package: The interim fix removal operation removes an installed interim fix. You can specify an individual interim fix by using one of the interim fix identification methods or specifying several individual interim fixes by using a list file. For more information about the interim fix identification methods, see Referencing interim fixes on page 349. The syntax for removing an installed interim fix is as follows:
emgr -r -L Label | -n interim fixNumber | -u VUID | -f ListFile [-w Directory] \ [-a path] [-b] [-k] [-p] [-I] [-q] [-X]
The removal preview phase: These steps occur during the removal preview phase. 1. The interim fix manager initializes all commands and libraries, and loads interim fix metadata from the interim fix database. 2. The interim fix attributes and descriptions are listed. 3. Space requirements are checked. The emgr command checks whether the target file systems contains adequate space to restore the saved files. This includes space-changing database entries, restoring saved files, archiving library members, and other miscellaneous tasks. The emgr command also adds a small buffer to the various space calculations to account for file metadata and other factors. If the user specifies to auto-expand the file system using the -X flag, the emgr command attempts to expand the file system to the required size. If space requirements cannot be met, the emgr command halts the remove operation. If the user specifies a preview installation operation using the -p flag, then the emgr command only reports the space statistics without attempting to expand the file system. If the user specifies a preview installation using the -p flag, the emgr command does not perform the interim fix removal and skips to the summary and cleanup phase. The removal phase: These steps occur in the removal phase. Note: Any failure in the removal phase causes the interim fix state to change to BROKEN. 1. The emgr command initializes all remove utilities and changes the interim fix state to REMOVING. 2. Package unlocking occurs. All packages that are locked by the interim fix file being removed are unlocked. Because it is possible that a single package may be locked by multiple interim fixes, the emgr command only unlocks a package if this interim fix file is the last (or the only) interim fix file still holding a lock on the given package. 3. If a pre_remove script is specified, it is run. If the pre_remove script returns a failure, the emgr command halts the remove operation. 4. emgr checks that the interim fix being removed is not a prerequisite for another installed interim fix.
345
5. The interim fix is removed. If the interim fix was installed with a standard installation operation, the emgr command replaces the current interim fix files with the previously saved files. If the installation was a mount installation operation, the emgr command unmounts the interim fix files and removes them from the system. 6. If a post_remove script is specified, it is run. If the post_remove script returns a failure, the emgr command halts the installation. 7. Reboot processing occurs. If the interim fix package specified that a reboot is required, the emgr command issues a message to the user and make any necessary changes to the boot image. The emgr command does not reboot the system automatically. Note: You can use epkg to specify the reboot scenario you want when you install another package. For more information on reboot scenarios, see Interim fix user-specified package components on page 355. 8. At this point, all removal steps have succeeded and the emgr command removes the remaining interim fix data from the database and save directories. The summary and cleanup phase: These steps occur during the summary and cleanup phase of removing an interim fix. 1. The emgr command issues a summary of all operations and results. If more than one interim fix package was specified with an input file using the -f flag, the emgr command reports for each interim fix package. 2. The emgremgr command cleans up any temporary directories and files. It also unloads any memory modules that have been loaded. Listing interim fixes: The emgr command lists data on installed interim fixes with various levels of verbosity. The syntax for listing interim fixes is as follows:
emgr -l [-L Label | -n interim fixNumber | -u VUID ] [-v{1|2|3}] [-X] [-a path]
By default, the emgr command reports data on all installed interim fix. You can specify an individual interim fix by using one of the interim fix identification methods. For information about the interim fix identification methods, refer to Referencing interim fixes on page 349. The default level of verbosity is 1. You can specify up to level 3 with the -v flag. The verbosity levels include the following information: LEVEL 1 Lists one interim fix per line with the following information: v Interim fix ID v Interim fix state v Install time v Interim fix abstract LEVEL 2 Lists the following information: v All LEVEL 1 information v Virtually unique ID (VUID) for each interim fix file v Number of interim fix files v Location for each interim fix file v Package for each interim fix file
346
v Installer for each interim fix File v Mount installation (yes or no) for each interim fix file LEVEL 3 Lists the following information: v All LEVEL 2 information v v v v v v v v v v v v v Reboot requirement (yes or no) Prerequisite files needed Pre-install script Post-install script Pre-remove script Post-remove script File type for each interim fix file File size for each interim fix file Checksum for each interim fix file Access ownership and modes for each interim fix file Prerequisite information Interim fix description Archive member name for each interim fix file
v If this is a mount installation operation, then display the mount status for each interim fix file v Reboot scenario for each interim fix file v Interim fix to interim fix prerequisites for each interim fix file v Packages that will be locked when the interim fix is installed v Interim fixes that will be superseded when the interim fix is installed Checking interim fixes: The emgr command checks the status of installed interim fixes. The syntax for interim fix checking is as follows:
emgr -c [-L Label | -n interim fixNumber | -u VUID | -f ListFile] [-w Directory] [-a path] \ [-v{1|2|3}] [-X]
By default the emgr command verifies all installed interim fixes. You can specify an individual interim fix by using one of the interim fix identification methods or specify several individual interim fixes by using a list file. For information about the interim fix identification methods, refer to Referencing interim fixes on page 349. The default level of verification is 1. You can specify up to level 3 with the -v flag. The verification levels include the following checks: LEVEL 1 Checks the following information: v Interim fix data and state v If this is a mount installation operation, then check the interim fix mount status for all files Note: If the interim fix file is unmounted, the emgr command changes the interim fix state to UNMOUNTED v Interim fix checksum for all interim fix files or archive members LEVEL 2 Checks the following information:
Installation and migration
347
v All LEVEL 1 checks v Interim fix ownership and mode for all interim fix files or archive members LEVEL 3 Checks the following information: v All LEVEL 2 checks v All prerequisites v All interim fix to interim fix prerequisites, including the following: All interim fix prerequisites for the interim fix package being checked are installed. All interim fix xrequisites for the interim fix package being checked are not installed. There are no installed interim fixes that list the interim fix being checked as an xrequisite. Performing an interim fix mount installation operation: If the -m flag is specified during interim fix installation, the emgr command performs a mount installation operation of the interim fix package. This means that the existing files that are being fixed are not removed from their present locations. Instead they are over-mounted by the interim fix files. This approach has both advantages and disadvantages. One advantage is that a system reboot unmounts all of the interim fixes. This means that any interim fix that created a serious problem is not mounted after a reboot. The disadvantages are that the administrator must monitor the mount status of interim fixes and some interim fixes may not be removed without a reboot. The mount installation operation is not supported with interim fix packages that deliver new files. The interim fix mount and unmount operation: The emgr command mounts or unmounts interim fixes that have been installed using the mount installation operation. The syntax for interim fix checking is as follows:
emgr -M | -U [-L Label | -n interim fixNumber | -u VUID | -f ListFile][-w Directory] [-a path] [-X]
By default, the emgr command applies the mount or unmount operation to all installed interim fixes. You can specify an individual interim fix by using one of the interim fix identification methods or specify several individual interim fixes by using a list file. For more information about the interim fix identification methods, see Referencing interim fixes on page 349. Using the mount operation with the -M flag, the emgr command attempts to mount all interim fix files that are unmounted. If all interim fix files are successfully mounted, and the previous interim fix state was UNMOUNTED, then the emgr command changes the interim fix state to MOUNTED. Using the unmount operation with the -U flag, the emgr command attempts to unmount all interim fix files that are mounted. If at least one interim fix file is successfully unmounted, and the previous interim fix state was MOUNTED, then the emgr command changes the interim fix state to UNMOUNTED. Using the interim fix display package locks operation: The display package locks operation displays all packages that are locked by interim fix manager, their installer, and the locking label or labels. The syntax for the display package locks operation is as follows:
emgr -P [Package] [-a path] [-X]
348
By default, the emgr command lists all locked packages. The user can specify an individual package as an argument to the -P flag. Using the interim fix force removal operation: The force removal operation removes interim fix data. This operation also unlocks all interim fix packages associated with the interim fix label without removing the actual interim fix files, executing any removal scripts, or boot processing. The force removal operation can only be run on one interim fix at a time, and the interim fix label is required to identify the target interim fix. The syntax for performing a force removal operation is as follows:
emgr -R interim fix fixLabel [-w Directory] [-a path] [-X]
Note: The force removal operation must be considered as an emergency procedure. It must only be run if all other methods to remove the interim fix have failed. This method can create inconsistencies on the target system.
The expected output is the MD5 checksum as the first word in the output. Note: This feature is not supported in the original release of interim fix management. You should update to the latest level of interim fix management to enable this feature. To update interim fix management, update bos.rte.install to the latest level. Referencing interim fixes: The following are methods for referencing interim fixes. Reference by Label Each interim fix that is installed on a given system has its a unique interim fix label. This label is called the unique key that binds the different database objects. To reference an interim fix by label, pass the label as an argument to the -L flag. For example, to run a check operation on an interim fix with label ABC123, type the following:
# emgr -cL ABC123
Reference by Interim Fix ID Each interim fix that is installed on a given system has a unique interim fix ID. This ID is the order number in which the interim fix is listed in the interim fix database. Using this option may be convenient if performing operations on interim fixes based on interim fix listings. The emgr
Installation and migration
349
command converts the interim fix ID into an interim fix label before performing the given operation. To reference an interim fix by ID, pass the ID as an argument to the -n flag. For example, to run a check operation on the first interim fix with an ID equal to 1, type the following:
# emgr -cn1
Note: Emergency fix IDs are valid for short periods of time and change as interim fixes are removed and added. Always verify the current interim fix ID number by listing the interim fix using the -l flag. Reference by VUID The VUID is used to differentiate packages that have the same label. Unlike Authorized Program Analysis Reports (APARs), which are officially tracked, emergency fixes are not tracked by any organization, so it is possible to have two interim fix packages with the same label. However, the emgr command does not allow the installation of more than one interim fix with the same label. The emgr command converts the VUID into an interim fix label before performing the given operation. For example, to list an installed interim fix with VUID equal to 000775364C00020316020703, type the following:
# emgr -l -u 000775364C00020316020703
The VUID is also displayed in the preview section of the interim fix installation and removal operations, and when using the listing operation with verbosity level 2 or greater. For more information on verbosity levels, see Listing interim fixes on page 346 Generating interim fix list files: You can perform operations on a set of interim fixes by specifying a list file. For the installation operation, the list file must contain one interim fix package location per line. For the removal operation and the mount and unmount operations, the list file must have one interim fix label name per line. You can use the -f flag on the emgr command to specify a file that contains one of the following: v A list of package locations for the installation operation (one per line) v A list of interim fix labels for the remove, mount, unmount, and check operations (one per line) The emgr command ignores any blank lines, or lines where the first non-white space character is the # character. Understanding interim fix states: The emgr command maintains a state for each installed interim fix. The following installed interim fix states are maintained by the emgr command: S=STABLE The interim fix was installed with a standard installation (-e flag), and successfully completed the last installation operation. To verify the interim fix details, run a check operation on the given interim fix or interim fixes. M=MOUNTED The interim fix was installed with a mount installation operation, and successfully completed the last installation or mount operation. A state of MOUNTED does not mean all interim fixes are currently mounted. For example, the interim fixes might have been manually unmounted. This state represents the emgr command's previous actions and determination of the mount status. To verify the interim fix details, including mount status, run a check operation on the given interim fix or interim fixes.
350
U=UNMOUNTED The interim fix was installed with a mount installation operation and one or more interim fix files were unmounted in a previous emgr command operation. The state of UNMOUNTED does not mean that all interim fixes are currently unmounted. For example, the interim fixes might have been manually mounted or partially mounted. This state represents the emgr command's previous actions and determination of the mount status. To verify the interim fix details, including mount status, run a check operation on the given interim fix or interim fixes. B=BROKEN An unrecoverable error occurred during an installation or removal operation. The status of the interim fix is unreliable. You can attempt to remove this interim fix and reinstall it from the interim fix package. I=INSTALLING The interim fix is in the process of installing. Normally, this state occurs only for a brief time during interim fix installation. However, if an interim fix installation is suddenly interrupted (such as in a sudden power loss or a system crash), and the emgr command is unable to clean up the failed installation, an interim fix might be left in the INSTALLING state. You can attempt to remove this interim fix and reinstall it from the interim fix package. Q=REBOOT REQUIRED The interim fix was installed successfully and requires a reboot to fully integrate into the target system. After you reboot the target system, emgr changes the interim fix state to STABLE. Note: 1. This feature is not supported in the original release of interim fix management. You should update to the latest level of interim fix management to enable this feature. To update interim fix management, update bos.rte.install to the latest level. 2. emgr is called by init with the -B bootup flag during system start. emgr examines the state data for all interim fixes and changes the interim fix states as necessary. The /etc/inittab entry rcemgr is created the first time emgr installs an interim fix file. rcemgr is set to not block or respawn. All rcemgr activities and output are logged to the emgr log in /var/adm/ras/emgr.log. Do not directly execute emgr with the -B flag. R=REMOVING The interim fix is in the process of being removed. Normally, this state occurs only for a brief time during interim fix removal. However, if an interim fix installation is suddenly interrupted (such as in a sudden power loss or a system crash), and the emgr command is unable to clean up the failed installation, an interim fix might be left in the REMOVING state. You can attempt to remove this interim fix and reinstall it from the interim fix package. T = TESTED Specifies that the interim fix was tested. Reflects the value of the epkg command -T flag that may be used during package creation. P = PATCHED Concurrent update has been patched directly in memory. Corresponding binaries on disk have not been modified. N = NOT PATCHED Concurrent update has been "updated by" a follow-on concurrent update, making the patch inactive. State is also set during reboot to change the state of in memory only concurrent updates that were in the PATCHED state. SP = STABLE + PATCHED Concurrent update has been patched in memory and the corresponding on-disk binaries have been replaced. The fix will now persist on the system across reboots.
351
SN = STABLE + NOT PATCHED A concurrent update in the STABLE + PATCHED state will be moved to this state when it is "updated by" a follow-on concurrent update, making the patch inactive. State may also be set if an interim fix containing a concurrent update in the NOT PATCHED state is committed to disk. QP = BOOT IMAGE MODIFIED + PATCHED Same as Stable + Patched except that, in replacing on-disk binaries, a file belonging in the boot image was modified and bosboot was invoked. QN = BOOT IMAGE MODIFIED + NOT PATCHED A concurrent update in the BOOT IMAGE MODIFIED + PATCHED state will be moved to this state when it is "updated by" a follow-on concurrent update, making the patch inactive. State may also be set if an interim fix containing a concurrent update in the NOT PATCHED state is committed to disk. RQ = REMOVING + REBOOT REQUIRED When an interim fix that was committed to disk has been removed, the system must be rebooted to remove all patched code from memory. The ifix will be removed from the Interim Fix database by the rc_emgr function called by init at boot time. Logging interim fixes: These operations are logged in the /var/adm/ras/emgr.log emgr log file. v v v v Installation Removal Checking Mounting
v Unmounting v Force Removal Cleaning up interim fix installation failures: The failure-cleanup procedure is run when an interim fix installation operation fails after the installation preview (and pre_install script, if specified). The failure-cleanup procedure attempts to reverse any of the changes that have already been made by the installation process and is similar to the removal phase of the interim fix removal operation. This procedure sets the EMGR_UNDO global environment variable to 1 and allows packaging to take different paths in the pre_remove and post_remove scripts. Managing interim fix files when using the Trusted Computing Base: The emgr command automatically detects if a system is enabled with the Trusted Computing Base (TCB). If TCB is enabled, the emgr command registers all of the installed interim fixes with the interim fix database. When the interim fixes are removed, the emgr command restores the original TCB data. Because mount installation operations can create variations in file attributes when interim fix files are mounted and unmounted, mount installation operations are not supported on a TCB-enabled system and are blocked by the emgr command. If you do not want the emgr command to automatically manage TCB data, export the EMGR_IGNORE_TCB variable and set this variable to any value that is not null. When the
352
EMGR_IGNORE_TCB variable is set, the emgr command behaves as if the system is not TCB-enabled. If the EMGR_IGNORE_TCB variable is set on a TCB-enabled system, you might be required to manually manage interim fix files within TCB. To check if TCB is enabled on your system, run the /usr/bin/tcbck command. If a usage statement is returned, TCB is enabled. Otherwise, a message indicating that TCB is not enabled is returned. Using emgr to manage interim fix command paths.: The emgr command calls one or more of the following UNIX commands. ar awk cat chmod chown compress cp date df diff du egrep fuser id ksh ln ls mkdir mount mv printf ps rm rmdir sed sleep sort sum tail tar tee touch umount uname vi wc zcat
Installation and migration
353
The emgr command calls one or more of the following AIX commands: aclget aclput bosboot lslpp odmchange odmget slibclean tcbck The emgr command looks for the UNIX and AIX commands previously listed in the following path order: 1. /usr/emgrdata/bin 2. /usr/bin 3. 4. 5. 6. 7. /usr/sbin /bin /sbin /usr/local/bin /usr/local/sbin
The /usr/emgrdata/bin directory is a secured directory that is created the first time the emgr command is run. If you are attempting to install or remove an interim fix for one of the commands that the emgr command uses, you might not be able to successfully complete the operation. To solve this problem, do the following: 1. Manually install the interim fix file into the /usr/emgrdata/bin directory. 2. Perform the emgr operation. 3. Remove the manually installed interim fix file from the /usr/emgrdata/bin directory. Using this method, the interim fix is registered and tracked with interim fix manager and all other emgr command processing takes place. If the interim fix file is the /usr/bin/ksh file and the problem it fixes prevents the emgr command's operations from succeeding, then do the following: 1. Back up the original /usr/bin/ksh file. 2. Manually install the /usr/bin/ksh interim fix file to /usr/bin/ksh. 3. Perform the emgr command installation or remove operation. Understanding interim fix integration with installp update images.: The interim fix management commands use an APAR reference file to associate interim fixes with APAR numbers. When the APAR images are available, the installp command matches the APAR numbers contained in the update image with the APAR numbers installed with the interim fix. If all APAR numbers are matched by the update, the interim fixes will automatically be removed.
354
The epkg command can be run in two modes: interactive and template-based. The interactive method prompts the user with several questions and constructs the interim fix package based on the answers. The template-based method uses an interim fix control file that is pre-filled with default answers that are then asked in interactive mode. The interim fix package can then be installed by the emgr command. By using an interim fix control file as a template, interim fix packages can be created noninteractively. For an example of a completed interim fix control file, see the epkg command. Interim fix user-specified package components: The listed interim fix control-file components are part of the overall interim fix package and are not related to specific files. ABSTRACT Describes the interim fix package. The abstract is limited to 38 bytes. DESCRIPTION Contains a detailed description of the interim fix package that is being installed. APARREF Specifies the location of a file that contains the APAR number or numbers associated with this interim fix. This component is required. The file must be contain one APAR number per line. E2E_PREREQ Lists the interim fix label names of interim fixes that are prerequisites to the interim fix package being installed. Using this file causes emgr to check if the interim fix PREREQ label is installed. If the prerequisite is not installed, emgr aborts installation of the interim fix package. You can also use this file to specify an XREQ interim fix label. Specifiying XREQ interim fix labels causes emgr to not install the interim fix package if the specified interim fix is installed. The maximum number of supported interim fix labels is 32. You can specify the interim fix labels to check for in the following ways. v Specify the file location with the -g flag. For example, to specify interim fixprereq.epkg, type the following:
# epkg -g /tmp/efixprereq.epkg myefix
v Use the -v flag in interactive mode for extended options, and type the file location when prompted by epkg. For example, to specify interim_fixprereq.epkg, when prompted, type the following:
Enter the location for the supersede file or "." to skip. -> /tmp/interim_fixprereq.epkg
v Set the E2E_PREREQ attribute in the interim fix control file to the local file location of the interim fix prerequisite file. For example, to specify interim_fixprereq.epkg, set the attribute as follows:
E2E_PREREQ=/tmp/interim_fixprereq.epkg
The format of the interim fix prerequisite file entries is as follows (where RequisiteType is PREREQ or XREQ):
EfixLabel RequisiteType
Comments beginning with a "#" sign and leading white space are ignored. For example:
oldefix1 PREREQ # Make sure oldefix1 is already installed oldefix4 XREQ # Make sure oldefix4 is NOT installed
Note: This feature is not supported in the original release of interim fix management. You should update to the latest level of interim fix management to enable this feature. To update interim fix management, update bos.rte.install to the latest level. PKGLOCKS Lists the packages that should be locked by emgr in addition to those that are automatically
Installation and migration
355
locked based on file ownership. You should specify the name of the package, the package lock action (either ALWAYS or IFINST), and the package file type. ALWAYS means always attempt to lock this package, and a failure to lock the package results in interim fix installation failure. IFINST means attempt to lock this package only if the package is installed, and failure to lock an installed package results in interim fix installation failure. The maximum number of supported interim fix labels is 32. You can specify the packages to be locked in the following ways. v Specify the file location with the -l flag. For example, to specify pkglock.epkg, type the following:
# epkg -l /tmp/pkglock.epkg myefix
v Use the -v flag in interactive mode for extended options, and type the file location when prompted by epkg. For example, to specify pkglock.epkg, when prompted, type the following:
Enter the location for the supersede file or "." to skip. -> /tmp/pkglock.epkg
v Set the PKGLOCKS attribute in the interim fix control file to the local file location of the package to be locked. For example, to specify pkglock.epkg, set the attribute as follows:
PKGLOCKS=/tmp/pkglock.epkg
The format of the interim fix package locks file entries is as follows:
PackageName PackageAction PackageType
Comments beginning with a "#" sign and leading white space are ignored. In the following example, emgr will always attempt to lock bos.rte.lvm during installation and will unlock it on removal. emgr will lock bos.games if (and only if) it is installed and will unlock it on removal (if locked).
bos.rte.lvm ALWAYS installp bos.games IFINST installp
Note: This feature is not supported in the original release of interim fix management. You should update to the latest level of interim fix management to enable this feature. To update interim fix management, update bos.rte.install to the latest level. PRE_INSTALL Runs after an installation preview and before any interim fix files are installed. Failure in the pre_install script causes the interim fix package installation to be aborted. This script is useful for doing any preinstallation checking or work. Because the emgr command does not call a failure-cleanup procedure for preinstallation failures, this script performs failure cleanup (related to the script) before it exits. This component is optional. POST_INSTALL Runs after all interim fix files have been successfully installed. A failure in the post_install script causes the installation to fail and causes interim fix manager to run a failure-cleanup procedure. This component is optional. For more information about the post_install script, refer to Installing and managing interim fix packages on page 342. PRE_REMOVE Runs after the removal preview and before any interim fix files are removed during a remove operation and in the first stage of a failure-cleanup procedure. A failure in the pre_remove script causes the given operation to fail. In the case of a failure-cleanup procedure, the emgr command sets an EMGR_UNDO global environment variable to 1. If necessary, the EMGR_UNDO variable is used to take different actions for removal as opposed to a failure-cleanup. This component is optional. POST_REMOVE Runs after interim fix files are removed during a remove operation and a failure-cleanup procedure. A failure in the post-remove script causes the given operation to fail. In the case of a failure-cleanup procedure, the emgr command sets an EMGR_UNDO global environment
356
variable to 1. The EMGR_UNDO variable is used to take different actions for removal as opposed to a failure-cleanup (if necessary). This component is optional. REBOOT Indicates whether a reboot operation is required for this interim fix. You can use this variable to specify one of the following reboot scenarios. v Reboot is not required. v Reboot is required, and the boot image will be rebuilt. v Reboot is required, and the boot image will not be rebuilt. You can specify the which of these reboot scenarios you want in the following ways. v Specify the reboot scenario with the -r flag. Arguments for this flag are n (reboot is not required), y (reboot required and the boot image will be rebuilt), and o (reboot is required, but the boot image will not be rebuilt). For example, the following command specifies that a reboot is not required:
# epkg -r n
v Use the -v flag in interactive mode for extended options, and select the reboot scenario you want when prompted by epkg. For example:
Select reboot policy for this efix package: 1) Reboot is NOT required. 2) Reboot is required. The boot image will be rebuilt. 3) Reboot is required. The boot image will NOT be rebuilt.
v Set the REBOOT and BUILD_BOOT_IMAGE attributes in the interim fix control file to the appropriate values for the reboot scenario you want. For example, to specify that a reboot is not required, set the attributes as follows:
REBOOT=no BUILD_BOOT_IMAGE=no
To specify that a reboot is required and the boot image will be rebuilt, set the attributes as follows:
REBOOT=yes BUILD_BOOT_IMAGE=yes
To specify that a reboot is required and the boot image will not be rebuilt, set the attributes as follows:
REBOOT=yes BUILD_BOOT_IMAGE=no
Note: 1. This feature is not supported in the original release of interim fix management. You should update to the latest level of interim fix management to enable this feature. To update interim fix management, update bos.rte.install to the latest level. PREREQ Contains installp prerequisites. This component is optional. v The file has one prerequisite per line. v The format of the prerequisite entry is as follows:
Fileset Min Level Max Level Type
Fileset The name of the requisite installp fileset. Min Level The minimum level for the requisite fileset. The specification of NONE indicates no minimum level.
357
Max Level The maximum level for the requisite fileset. The specification of NONE indicates no maximum level. Type The following types are supported: PREREQ and IFREQ. PREREQ is the default type and requires that the requisite fileset meets all criteria. IFREQ requires that requisite fileset meet all criteria only if it is installed.
v Blank lines or lines that start with # are ignored, as shown in the following examples:
# Require that abc.xyz is installed at any level: abc.xyz NONE NONE # Require that bos.rte.lvm is installed at level 5.1.0.10 or above: bos.rte.lvm 5.1.0.10 NONE # Require bos.mp be between 5.1.0.0 and 5.1.0.40 if it is installed: bos.mp 5.1.0.0 5.1.0.40 IFREQ
SUPERSEDE Specifies the interim fix label name of an interim fix or interim fixes that are to be superseded when an epkg is installed. Using this file causes emgr to remove any interim fix labels that are specified in this file (if they are installed) before installing the interim fix package. Failure to remove an installed superseded interim fix aborts the installation of the interim fix package. The maximum supported number of superseded labels is 32. You can specify the superseded file in the following ways. v Specify the file location with the -S flag. For example, to specify susperseded.epkg, type the following:
# epkg -S /tmp/superseded.epkg myefix
v Use the -v flag in interactive mode for extended options, and type the file location when prompted by epkg. For example, to specify susperseded.epkg, when prompted, type the following:
Enter the location for the supersede file or "." to skip. -> /tmp/superseded.epkg
v Set the SUPERSEDE attribute in the interim fix control file to the local file location of the superseded file. For example, to specify susperseded.epkg, set the attribute as follows:
SUPERSEDE=/tmp/superseded.epkg
The format for the list of superseded files is one interim fix label to be superseded per line. Comments beginning with a "#" sign and leading white space are ignored. For example:
# Requisites for efix myefix3 myefix1 myefix2
Note: This feature is not supported in the original release of interim fix management. You should update to the latest level of interim fix management to enable this feature. To update interim fix management, update bos.rte.install to the latest level. Interim fix file components: The following interim fix control-file components are related to specific files. The maximum number of interim fix files for each interim fix that the epkg and emgr commands support is 200. EFIX_FILE_NUM Number of the given file (1 - 200). SHIP_FILE Local file location that the epkg command is archiving into the interim fix package. Specify either an absolute or relative path to this file. The ship file is the interim fix that is delivered. TARGET_FILE Target file location where the SHIP_FILE is installed. This location is located on the system where
358
the interim fix package is installed. Specify the absolute path to this file. If this file is part of a registered package, such as an RPM or installp package, you must specify the tracked location. INSTALLER This variable represents the type of installer that owns the interim fix package. Valid integer choices are as follows: 1 2 3 4 5 6 7 8 9 TYPE Tracked by installp Tracked by RPM Tracked by ISMP Tracked by another installer New file that will be tracked by installp New file that will be tracked by RPM New file that will be tracked by ISMP New file that will be tracked by another installer Not tracked by any installer
This is the type of file that is being installed. The valid choices are as follows: 1 2 Standard file or executable file Library or archive member
An example of TYPE 1 is the /usr/bin/ls file or the /usr/bin/rm file. An example of TYPE 2 is the shr.o archive member as a member of the libc.a library. ACL Specifies the access attributes (mode and ownership) for a given file. If this attribute is set to DEFAULT, the emgr command maintains the current permissions of the file to be replaced. However, if the target file is a new file or the user wants to specify permissions using the -v flag, the ACL attribute can be entered with the Owner:Group:OctalModes syntax, similar to the following:
ACL= root:system:555
AR_MEM Specifies the name of the archive member. This option is only valid if TYPE=2. In this case, SHIP_FILE represents the local location of the archive member that is being shipped, TARGET_FILE represents the target archive, and ACL applies to the archive member. For example, the following attributes ship the myshr.o local file to the shr.o member in the /usr/ccs/lib/libc.a target archive:
TYPE=2 SHIP_FILE=/home/myshr.o TARGET_FILE=/usr/ccs/lib/libc.a AR_MEM=shr.o
Interim fix automatic common components: The listed components are part of the overall interim fix package and are not related to specific files. These components are automatically determined by the epkg command. Typically, the user does not set the following components: DATE Date and time that the backup was made. INSTWORK Amount of space (in 512 byte-blocks) required for unpacking the interim fix metadata. VUID Virtually Unique ID. A combination of time and cpuid, this ID can be used to differentiate fixes that are otherwise identical.
Installation and migration
359
QNEXT and QORDER Internal trackers for interactive mode. If you are using an interim fix control file in nonprompted mode, make sure QNEXT and QORDER are not set, or set to QEND. Interim fix automatic file components: The listed components are related to specific files. These components are automatically determined by the epkg command. Typically, the user does not set these components. CKSUM File checksum for the given file SIZE Size for the given file
Running the epkg command in interim fix interactive mode: By default, the epkg command is run in interactive mode. The only required parameter is the interim fix label. If you interrupt a running epkg command session, the interim fix control file is saved. If you start a new session with the same interim fix label, you are asked whether you want to keep working with the previous interim fix control file. You can use the -u flag to answer this question. The epkg command maintains a record of the question order and allows the user to navigate between questions by using subcommands. Also, the epkg command remembers the previous answer the user provided and sets that answer as the default answer. The epkg subcommands are the following: b! s! q! h! Returns to the previous question. Shows the current interim fix control file. Quits without saving interim fix control file (using the Ctrl-C key sequence will prompt this subcommand). Displays help information for the current question.
by by by by
360
*** If "-m flag" and not new go to #7.1 *** *** If new, go to #7.2 *** *** Else, go to #8 *** 7.1 Enter the ACL for file 1 in the format of <owner>:<group>:<octal modes>. For example to make the user="root", the group="system", and the modes "444", you would enter root:system:444. Enter "." if you want to keep the default (i.e. current) permissions on the existing target file. 7.2 Enter the ACL for file 1 in the format of <owner>:<group>:<octal modes>. For example to make the user="root", the group="system", and the modes "444", you would enter root:system:444. 8. Are there more interim fix files ? (yes/no): ** If "yes", increment file and go to question #3 ** ** If "no" and "-s" flag, go to #14 ** ** If "no" go to question #9 ** 9. Enter the local location for the pre-install script or "." to skip.
10. Enter the local location for the post-install script or "." to skip. 11. Enter the local location for the pre-remove script or "." to skip. 12. Enter the local location for the post-remove script or "." to skip. 14. Is a reboot required after installing this interim fix ? (yes/no): 15. Enter the location for the APAR reference file. 16. Enter the local location for the installp prerequisite file or "." to skip. *** This question is skipped if -p flag *** 17. Enter the local location for the interim fix description file or "." to compose it in an editor: *** This question is skipped if "-d" flag is specified *** *** If the description file is not specified, the user will be *** *** put into an editor to compose it. The user can specify *** *** which editor to use by setting the EDITOR global environment *** *** variable. The default editor is /usr/bin/vi. ***
After all of the questions are answered, the epkg command verifies the interim fix control file and creates a compressed tar package that can be installed by using the emgr command.
Related information
The following are links to additional information related to optional software products and service updates. v For information about developing software products that are installed using the installp command, see Packaging Software for Installation in AIX Version 6.1 General Programming Concepts: Writing and Debugging Programs. v For information about creating a new backup of your system, see Creating system backups on page 304. v For additional release information, see the AIX Version 6.1 Release Notes.
361
You can install RPM Package Manager (RPM) and InstallShield MultiPlatform (ISMP) formatted packages in addition to installp formatted packages. Use the Web-based System Manager, SMIT, or the geninstall command to install and uninstall these types of packages. The geninstall command can detect the format type of a specified package and run the appropriate installation command. The AIX product media contains installp packages and RPM packages that are installed during a base operating system (BOS) installation. The installp packages are located in the following path:
/mount_point/installp/ppc
If you have media that contains ISMP packages for AIX, the ISMP packages are located in the following path:
/mount_point/ISMP/ppc
The geninstall command recognizes the following file names as ISMP install images: v setupaix* v install* v setup.jar If you are using the geninstall command to install RPM or ISMP packages, use the prefix type to indicate to the geninstall command the type of package that you are installing. The package prefix types are the following: I: R: J: E: installp format RPM format ISMP format interim fix format
For example, to install the cdrecord RPM package and the bos.games installp package, type the following:
# geninstall -d/dev/cd0 R:cdrecord I:bos.games
The geninstall command detects that the cdrecord package is an RPM package type and runs the rpm command to install the cdrecord package. The geninstall command then detects that bos.games is an installp package type and runs the installp command to install the bos.games package. The process for uninstallation is similar to the installation process. In Web-based System Manager and SMIT, if you are selecting the packages from a software list, you need not specify the prefix type.
362
Note: The usr and root parts of a product are packaged in the same installable package.
usr part The usr part of a software product contains the part of the product that can be shared by machines that have the same hardware architecture. Most of the software that is part of a product usually falls into this category. In a standard system, the usr parts of products are stored in the /usr file tree. For example, the ls command would be in the /usr/bin/ls file. Every product has a usr part. The root part of a software product contains the part of the product that cannot be shared. The root part of a product is optional because many products may not have any files that need to be specific to each individual machine. In a client/server environment, these are the files for which there must be a unique copy for each client of a server. Most of the root software is associated with the configuration of the machine or product. In a standard system, the root parts of a product are stored in the root (/) file tree. The /etc/objrepos directory contains the root part of an installable software product's vital product data (VPD). The share part of a software product contains the part of the product that can be shared among machines, even if they have different hardware architectures, which can include nonexecutable text or data files. For example, the share part of a product might contain documentation written in ASCII text or data files containing special fonts. The share part of a product is optional because many products might not have any files that can be shared among different hardware platforms. The share part of a product is always packaged in a separately installable package. In a standard system, the share parts of products are usually stored in the /usr/share file tree. For example, a dictionary database might be stored in the /usr/share/dict/words file.
root part
share part
For more examples, refer to the /usr/lpp/bos/README.MKINSTALLP file. The mkinstallp command is included with the bos.adt.insttools fileset.
363
You can also use the SMIT list_bundle fast path to list the system bundles. The geninstall and gencopy commands handle multiple software sources to be specified when a bundle file is used. This is accomplished by grouping software images together under #MEDIA= headings in the bundle file. Any images listed under such a heading must reside on the specified media. Media can be specified as the name of a CD (such as Base Install Media Volume 1 or AIX Linux Toolbox CD) or as a local directory (such as the /usr/sys/inst.images directory). The #MEDIA= heading is used to designate the location of the file sets or packages in the bundle. For example, the BaseAndLinuxCD Bundle might contain the following information:
# BaseAndLinuxCDBundle contains packages on volume 1 of base media and on the AIX # Linux Toolbox CD #MEDIA=Base Install Media Volume 1 I:bos.adt.prof #MEDIA=AIX Linux Toolbox CD R:mtools R:vim-common
When the geninstall and gencopy commands prompt for the additional media, they use the words provided in the #MEDIA= line. In the previous examples, the geninstall and the gencopy commands
364
display a message informing you that the bos.adt.prof installp package is located on Base Install Media Volume 1, and the mtools and vim-common RPM packages are located on the AIX Linux Toolbox CD. The #MEDIA= heading can also be used to indicate a directory. For example, the CD_Directory Bundle might contain the following information:
# CD_DirectoryBundle contains packages on volume 1 of base install media # and in /usr/sys/inst.images #MEDIA=/usr/sys/inst.images I:bos.games #MEDIA=Base Install Media Volume 1 I:bos.adt.prof R:cdrecord-1.9-4
This informs the geninstall and the gencopy commands that the bos.games installp package is located in the 3 directory, and that the bos.adt.prof installp package and the cdrecord-1.9-4 RPM package are located on Base Install Media Volume 1. The geninstall and gencopy commands understand the "%L" wildcard in a bundle file. This wildcard is replaced at runtime with the value of the appropriate locale environment variable; LC_ALL is checked first, then LC_MESSAGES, and then LANG. This allows you to create a single bundle file corresponding to multiple installation configurations. As an example, assume you provide the ABC product, which requires the abc.rte and abc.com filesets, as well as a message catalog fileset and a documentation fileset. You then provide the message and documentation filesets in English, French, and German, as follows:
abc.cat.en_US abc.cat.fr_FR abc.cat.de_DE abc.doc.en_US abc.doc.fr_FR abc.doc.de_DE
The following bundle file would cause the appropriate combination of filesets to be installed, according to the locale variables on the target system:
I:abc.rte I:abc.com I:abc.cat.%L I:abc.doc.%L
Note: If expanding the %L wildcard does not yield a fileset name corresponding to a fileset available on the installation media, then the UTF-8 version of the current locale will be tried, then en_US, and then EN_US. You can determine whether or not the contents of a bundle are installed on your system with the lslpp -Lb command. For example, to determine whether the components of the Alt_Disk_Install bundle, which is located in the /usr/sys/inst.data/sys_bundles directory, are installed, run the following command:
lslpp -Lb Alt_Disk_Install.bnd
365
Fileset Level State Type Description -----------------------------------------------------------------------------------------------------bos.alt_disk_install.boot_images 6.1.00 C F Alternate Disk Installation Disk Boot Image bos.alt_disk_install.rte 6.1.00 C F Alternate disk Installation Runtime State A -B -C -E -O -? -codes: Applied. Broken. Committed. EFIX Locked. Obsolete. (partially migrated to newer version) Inconsistent State...Run lppchk -v.
Migrating AIX
During a migration, the installation process determines which optional software products are installed on the existing version of the operating system. Components from previous releases that have been replaced by new software in AIX Version 6.1 are installed at the AIX Version 6.1 level. Migration is the default installation method to move from AIX 5.1 and later to AIX Version 6.1. Note: If you only want to install the next recommended maintenance or technology level of the operating system, use the SMIT update_all fast path or the install_all_updates command to update the filesets currently installed. For more information about updating to the next recommended maintenance or technology level of AIX, see Optional products and service updates on page 321. | | | | Note: Before applying a Technology Level (TL), you must always create a backup and plan on restoring that backup if you need to rollback to your previous level. You can also use the alt_disk_install or multibos options as a way to get back to your previous level. Since TL updates cannot be rejected you must always commit the updates. Migration attempts to preserve all user configuration, while moving the operating system to a new level of software. The following steps are taken to achieve this objective: v Save configuration files v Prepare and remove old files v Restore new files v Remove unsupported or unnecessary filesets v Migrate configuration data wherever possible v Prepare VPD for install v Update additional filesets When performing a migration, the following occurs: v All files in the /usr/lib/drivers, /usr/lib/microcode, /usr/lib/methods and /dev directories are removed from the system, so software support for device drivers must be reinstalled. Non-device software products and applications remain on the system, and work correctly if they are among those files described in Ensuring binary compatibility between AIX 6.1 and earlier versions on page 367. v The following software products are removed from the system: AIXwindows Interface Composer Remote Customer Services
366
AIXwindows Development Environment Display PostScript functionality from AIXwindows Run-Time Environment Extensions Performance Tools functionality from Extended Commands OpenGL and graPHIGS Xstation Manager
In most cases, user-configuration files from the previous version of a product are saved when the new version is installed during a migration installation.
v X11R3 v X11R4 v X11 fonts All AIX operating system applications intended for use with the POWER family, POWER2, and POWER processor-based models run compatibly on AIX 6.1 without recompilation for those same models. The only exceptions to this statement are applications using the following: v Unsupported self-loadable kernel extensions v Certain High-Function Terminal (HFT) control interfaces v v v v v v X11R3 input device interfaces CIO LAN device driver interface SCSI device configuration methods (IHVs) nlist subroutine interface DCE threads Applications compiled using POWER2 or POWER processor-based compiler options, but executed on models other than POWER2 or POWER processor-based models. Note: Any program that must run in all environments (POWER family, POWER2, and POWER processor-based models 601 and higher) must be compiled using the common mode of the compiler. Programs compiled to exploit POWER2 technology must be run on POWER2 processors. Existing code need not be recompiled to run. A system using an earlier AIX version can operate as a server system for client machines using AIX 6.1 with the following exceptions: v Network installation of AIX 6.1 clients v Service SNA or X.25 to AIX 6.1 clients v Service HCON to AIX 6.1 clients
Installation and migration
367
v Service CGE extensions of PEX and PEX-PHIGS v Use of AIX 6.1 client installation formats Font servers might be required on the AIX 6.1 clients to reliably handle AIXwindows between server and client. A system using AIX 6.1 might operate as a server system for client machines using an earlier version of AIX as long as the necessary compatibility options are installed. All statements about binary compatibility apply in this case. AIX 6.1 applications might not execute reliably on earlier versions of AIX systems using remote network mounts from an AIX 6.1 file system.
368
The post_migration command performs the following actions: v Verify fileset version consistency. v Check the installation list from before the migration, and inform the user of any filesets that might still need migrating. v Compare saved and merged configuration scripts and save the differences.
v Before you begin the installation, other users who have access to your system must be logged off. v Verify that your applications runs on AIX 6.1. Also, verify that your applications are binary-compatible with AIX 6.1. If your system is an application server, verify that there are no licensing issues. Refer to your application documentation or provider to verify on which levels of AIX your applications are supported and licensed. You can also check the AIX application availability guide at the following Web address: http://www.ibm.com/servers/aix/products/ibmsw/list/ v Verify that your hardware microcode is up-to-date. v All requisite hardware, including any external devices (such as tape, CD, or DVD-ROM drives), must be physically connected and powered on. If you need further information, refer to the hardware documentation that accompanied your system. v Use the errpt command to generate an error report from entries in the system error log. To display a complete detailed report, type the following:
# errpt -a
v There must be adequate disk space and memory available. AIX 6.1 requires 256512 MB of memory and 2.2 GB of physical disk space. v Run the pre-migration script.
369
v Make a backup copy of your system software and data. For instructions on how to create a system backup, refer to Creating system backups on page 304. Note: As of AIX 6.1, the 32-bit kernel has been deprecated. Therefore, 64-bit hardware is required to run AIX 6.1 (POWER4 , POWER5, or POWER6 systems only). Architecture models that use 604e processors are not 64-bit capable and will not run AIX 6.1. These RS/6000 models include: v 7025 F50 Series v 7026 H50 Series v 9076 H50 Series v 7043 150 Series v 7046 B50 Series To verify the processor capability, run the following command:
/usr/sbin/prtconf -c
The command returns CPU Type: 32-bit or CPU Type: 64-bit depending on the system capability. If your system does not have the prtconf command, you can use the bootinfo -y command. For more information, see the AIX 6.1 Release Notes.
370
Note: If your system does not boot using the F5 key (or the 5 key on an ASCII terminal), refer to your hardware documentation for information about how to boot your system from an AIX product CD. The system begins booting from the installation media. 3. If your system has an LED display, the three-digit LED should display c31. If you have more than one console, each might display a window that directs you to press a key to identify your system console. A different key is specified for each console displaying this window. If this window displays, press the specified key only on the device to be used as the system console. (The system console is the keyboard and display device used for installation and system administration.) Press a key on one console only. A window displays, asking you to select a language to be used for installation instructions. 4. Select the language you prefer to use for installation instructions. 5. When the Welcome to Base Operating System Installation and Maintenance window displays, either begin the migration immediately by typing 1 to select Start Install Now with Default Settings, or verify the installation and system settings by typing 2 to select Change/Show Installation Settings and Install. If you want to change any settings, follow the procedure in Step 5. Verifying or changing the installation settings on page 57. Note: v You should not have to change settings simply to select the migration installation method. If a previous version of the operating system exists, the installation method defaults to migration. v The available installation methods vary, depending on the version of the operating system that is currently installed (before migration). For information about the BOS installation methods, refer to Installing the Base Operating System on page 38. For information about the installation options available for a migration installations, refer to BOS installation options on page 42. 6. Verify the selections in the Migration Installation Summary window and press Enter. 7. Confirm the migration installation process in the Migration Confirmation window, and press Enter to begin the migration installation.
371
mksysb migration
A mksysb migration allows you to restore the mksysb from an old system to a system that supports AIX 6.1 and then migrate the mksysb. Traditional migration moves the operating system of a supported hardware configuration to a newer level. A mksysb migration installation is the recommended method of installation to move unsupported hardware configurations running AIX 4.3 and later to new supported hardware running AIX 6.1. A mksysb migration is not intended for systems that you can migrate with a traditional migration. This method allows you to bypass the hardware limitation by restoring the mksysb on the new hardware configuration and migrate it without running AIX 4.3. The resulting system will be running the new level of AIX.
372
Prerequisites
v All requisite hardware, including any external devices (such as tape, CD, or DVD-ROM drives), must be physically connected. For more information about connecting external devices, see the hardware documentation that accompanied your system. v Before you begin the installation, other users who have access to your system must be logged off. v Verify that your applications run on AIX 6.1. Also, verify that your applications are binary-compatible with AIX 6.1. If your system is an application server, verify that there are no licensing issues. Refer to your application documentation or provider to verify on which levels of AIX your applications are supported and licensed. You can also check the AIX application availability guide at the following Web address: http://www.ibm.com/servers/aix/products/ibmsw/list/ v Verify that your hardware microcode is up-to-date. v There must be adequate disk space and memory available. AIX 6.1 requires 256512 MB of memory and 2.2 GB of physical disk space. For additional release information, see the AIX 6.1 Release Notes.
373
v Make a backup copy of your system software and data. For instructions on how to create a system backup, refer to Creating system backups on page 304. This backup is used during the mksysb migration installation to restore your system files prior to migration. v If the source system is available, run the pre-migration script on it. Ignore any messages that pertain to the hardware configuration of the source system because the migration takes place on the target system. Correct any other problems as recommended by the script.
374
/etc/filesystems file. After this happens the user is prompted to reinsert the product media and the installation continues. When it is time to restore the mksysb image, the same procedure repeats. The BOS menus do not currently support mksysb migration, so they cannot be loaded. In a traditional migration, if there are errors that can be fixed by prompting the user for information through the menus, the BOS menus are loaded. If such errors or problems are encountered during mksysb migration, the installation asserts and an error stating that the migration cannot continue displays. Depending on the error that caused the assertion, information specific to the error might be displayed. If the installation asserts, the LED shows "088".
Prerequisites
v All requisite hardware, including any external devices (such as tape, CD, or DVD-ROM drives), must be physically connected. For more information about connecting external devices, see the hardware documentation that accompanied your system. v Before you begin the installation, other users who have access to your system must be logged off. v Verify that your applications run on AIX 6.1. Also, verify that your applications are binary-compatible with AIX 6.1. If your system is an application server, verify that there are no licensing issues. Refer to your application documentation or provider to verify on which levels of AIX your applications are supported and licensed. You can also check the AIX application availability guide at the following Web address: http://www.ibm.com/servers/aix/products/ibmsw/list/ v Verify that your hardware microcode is up-to-date. v There must be adequate disk space and memory available. AIX 6.1 requires 256512 MB of memory and 2.2 GB of physical disk space. For additional release information, see the AIX 6.1 Release Notes.
375
v Make a backup copy of your system software and data. For instructions on how to create a system backup, refer to Creating system backups on page 304. This backup is used during the mksysb migration installation to restore your system files prior to migration. v If the source system is available, run the pre-migration script on it. Ignore any messages that pertain to the hardware configuration of the source system because the migration takes place on the target system. Correct any other problems as recommended by the script.
The SPOT file and lpp_source file should be at the AIX 6.1 level. Alternatively, the mksysb can be allocated to the client first using a separate alloc operation. Then use command line or smitty nim to perform a bos_inst operation on the client. If the mksysb is allocated to the client prior to the bos_inst operation, the specification of the mksysb is not required.
376
disk space on the machine where you want to install the migration bundle, and then you can run smit update_all to complete the installation where the migration bundle is installed. If you are not doing the installation from a graphics console, a Graphics_Startup bundle is created. For more information on this, see Optional products and service updates on page 321. For information on how to remove software from the system to release disk space, see Maintaining optional software products and service updates on page 329. If the pre-migration script ran on the source system, run the post-migration script and verify the output files.
Related information
The following are links to information related to migrating AIX. v For additional release information, see the AIX 6.1 Release Notes. v For late-breaking information, which might include information on the configuration process and installed software, refer to readme files. v For information about installing optional software, refer to Preparing to install optional software products and service updates on page 324.
Partitioning
Partitioning your system is similar to partitioning a hard drive. When you partition a hard drive, you divide a single physical hard drive so that the operating system recognizes it as a number of separate logical hard drives. You have the option of dividing the system's resources by using the Hardware Management Console (HMC) to partition your system. On each of these divisions, called partitions, you can install an operating system and use each partition as you would a separate physical system.
Partitioning concepts
Before you can start installing BOS on partitions you need to learn about general ideas and terminology.
Logical partitions
A logical partition (LPAR) is the division of a computer's processors, memory, and hardware resources into multiple environments so that each environment can be operated independently with its own operating system and applications. The number of logical partitions that can be created depends on the system's processor model and resources available. Typically, partitions are used for different purposes, such as database operation, client/server operations, Web server operations, test environments, and production environments. Each partition can communicate with the other partitions as if each partition is a separate machine. The AIX operating system supports partitioned environments. Although the AIX installation concepts are the same, the configuration and management of a partitioned environment with the AIX operating system are new. A logical partition must contain a minimum set of resources, as follows: v 1 GB of available system memory v One available system processor v One boot device on an assigned I/O slot v One available network adapter (for error reporting) v Any other adapters you might need on an assigned I/O slot
377
Processors, memory, and I/O slots can be allocated to any partition, regardless of their location. However, if you attempt to activate a partition, but the resources you specified are not available at the time, partition activation fails. It is important to keep track of your system's resources to avoid activation failures. PCI slots are assigned individually to partitions, and memory can be allocated in 256 MB increments. The granularity of the resources that can be assigned to partitions is very fine, providing flexibility to create systems with just the desired amount of resources. Each partition runs its own copy of the AIX operating system and is isolated from any activity in other partitions. Software failures do not propagate through the system, and the hardware facilities and microcode isolate the resources.
Managed system
A managed system is a system that is physically attached to and managed by the Hardware Management Console (HMC). You can use the HMC to perform tasks that affect the entire managed system, such as powering the system on and off. You can also create partitions and partition profiles within each managed system. These partitions and partition profiles define the way that you configure and operate your partitioned system.
378
any I/O drawer on the system. Other devices may be required for specific application requirements. It is a good idea to configure more PCI slots in the partition than are required for the number of adapters. This provides flexibility by allowing additional adapters to be hot-plugged into the empty slots that are part of an active partition. Because each partition requires its own separate boot device, the system must have at least one boot device and associated adapter per partition. v In order for AIX to run inside a logical partition, AIX calls the Hypervisor in place of its traditional direct access to the hardware and address-mapping facilities. v Some direct-access calls are presented for diagnostic purposes, and alternate return codes for Run-Time Abstraction Services (RTAS) calls are used whenever an illegal operation is issued. v No physical console exists on the partition. While the physical serial ports on the system can be assigned to the partitions, they can only be in one partition at a time. To provide an output for console messages and also for diagnostic purposes, the firmware implements a virtual tty that is seen by AIX as a standard tty device. Its output is sent to the HMC. The AIX diagnostics subsystems use the virtual tty as the system console. v Certain platform operations are constrained in LPARs. For example, in non-LPAR systems, platform firmware updates can be performed from AIX by a root user. Because firmware updates can affect all partitions in an LPAR system, the LPAR administrator can specify that a particular partition (or no partition) has this authority. Within that partition, firmware updates work in the same way as they do for non-LPAR systems. Apart from these considerations, AIX runs within a partition the same way it runs on a standalone server. No differences are observed either from the application or the administrator's point of view. Third-party applications need only be certified for a level of AIX that runs in a partition, and not for the LPAR environment itself.
Remote management
You can use the Hardware Management Console (HMC) to manage your partitions remotely with Web-based System Manager or with the command line. Each of the following system-management methods can be performed using the HMC interface or the command line. v Use the HMC client to remotely manage any AIX partition or system. All AIX plug-ins on the AIX system can be managed remotely from the HMC client, provided that theWeb-based System Manager framework version is compatible. The operating system checks each plug-in for compatibility with the Web-based System Manager framework. If it is not compatible for that plug-in, a message displays, indicating that the plug-in cannot be managed by the client. v Use an AIX partition or system to remotely manage an HMC. All HMC plug-ins on the HMC server may be managed remotely from the AIX system, provided that the AIX system is at a compatible Web-based System Manager framework version. Otherwise, an error message displays indicating that the AIX system cannot manage the HMC server. v Use Web-based System Manager Remote Client to remotely manage an HMC server. For instructions on how to install the Remote Client, refer to the AIX Version 6.1 Web-based System Manager Administration Guide. All HMC plug-ins on the HMC server may be managed remotely from the Remote Client, provided that the Remote Client is at a compatible Web-based System Manager framework version. Otherwise, an error message displays, indicating that the Remote Client cannot manage the HMC server. The only plug-in that is an exception is the Service Agent plug-in. v Use an HMC client remotely manage another HMC client. All HMC plug-ins on the HMC server may be managed remotely from the HMC client. The only plug-in that is an exception is the Service Agent plug-in. For information on remotely managing partitions with the command line on the HMC, see Using the HMC remote command line.
379
For more information on remotely managing partitions with Web-based System Manager, see Web-based System Manager Remote Client. You can also view the following readme files: v /usr/websm/readme.html v /usr/websm/readme.txt
Partition security
System administrators can install a server with the Controlled Access Protection Profile (CAPP) and Evaluation Assurance Level 4+ (EAL4+) option during a base operating system (BOS) installation. If you select this option, there are restrictions on the software that is installed during BOS installation and network access restrictions. Starting with AIX 5L Version 5.2 with the 5200-01 Recommended Maintenance package, the CAPP/EAL4+ technology runs on POWER4 processor hardware platforms that support logical partition configuration. The following peripherals are supported on CAPP/EAL4+ servers: v Storage devices Terminals Printers Hard disks CD-ROM drives v Backup devices Streamers Floppy disk drives v Network devices Ethernet Token ring
Server consolidation
If you have a server with sufficient processing capacity, you can logically subdivide the server into a number of separate smaller systems to enable server consolidation. Using partitioning for sever consolidation allows you to isolate applications, with the additional benefits of reduced floor space, a single point of management, and easier redistribution of resources as workloads change.
380
having a separate server for this function, a minimum set of resources can be temporarily used to create a new LPAR where you test the application. When you no longer need the partition, you can incorporate its resources back into the other LPARs.
Note: You must include the fully qualified host name in addition to the short name when a DNS is present. v If you are not using DNS and your partition is using a fully qualified host name, such as partition_1.mydomain.mycompany.com, and the HMC is also using a fully qualified host name, such as hmc123.mydomain.mycompany.com, both must be added to the local /etc/hosts file, as shown in the following:
root@partition_1.mydomain.mycompany.com -> cat /etc/hosts 127.0.0.1 loopback localhost 9.3.3.151 partition_1.mydomain.mycompany.com 9.3.3.152 hmc123.mydomain.mycompany.com
v If you are not using DNS and your partition is using a short host name, such as partition_1 and the HMC is also using a short host name, such as hmc123, both must be added to the local /etc/hosts file, as shown in the following:
381
v Your HMC is using a short host name, such as hmc123, and you would like to use both a fully qualified host name and a short host name for the HMC. In order for your partition to correctly communicate with the HMC, you must specify the short host name before the fully qualified host name in the partition's /etc/hosts file, as shown in the following:
root@partition_1.mydomain.mycompany.com -> cat /etc/hosts 127.0.0.1 loopback localhost
Installing AIX using the media device to install a partition with an HMC
In this procedure, you will perform a new and complete base operating system installation on a logical partition using the partition's media device. This procedure assumes that there is an HMC attached to the managed system.
Prerequisites
Things to consider
The information in this how-to scenario was tested using specific versions of AIX. The results you obtain might vary significantly depending on your version and level of AIX.
Note: For the installation method that you choose, ensure that you follow the sequence of steps as shown. Within each procedure, you must use AIX to complete some installation steps, while other steps are completed using the HMC interface. Before you begin this procedure, you should have already used the HMC to create a partition and partition profile for the client. Assign the SCSI bus controller attached to the media device, a network adapter, and enough disk space for the AIX operating system to the partition. Set the boot mode for this partition to be SMS mode. After you have successfully created the partition and partition profile, leave the partition in the Ready state. For instructions about how to create a logical partition and partition profile, refer to the Creating logical partitions and partition profiles article in the IBM eServer Hardware Information Center.
Step 1. Activate and install the partition (perform these steps in the HMC interface)
1. Activate the partition, as follows: a. Insert the AIX 6L Volume 1 media into the media device of the managed system. b. In the navigation panel, open Systems Management > Servers, and click the system on which the logical partition is located. c. From the Tasks menu, select partition, click Operations > Activate > Profile.
382
d. Select Open a terminal window or console session at the bottom of the menu to open a virtual terminal (vterm) window. e. Select Advanced to open the Advanced options menu. f. For the Boot mode, select SMS. g. Select OK to close the Advanced options menu. h. Select OK. A vterm window opens for the partition. 2. In the SMS menu on the vterm, do the following: a. Press the 5 key and press Enter to select 5. Select Boot Options.
PowerPC Firmware Version SF220_001 SMS 1.5 (c) Copyright IBM Corp. 2000, 2003 All rights reserved. ------------------------------------------------------------------------------Main Menu 1. 2. 3. 4. 5. Select Language Setup Remote IPL (Initial Program Load) Change SCSI Settings Select Console Select Boot Options
------------------------------------------------------------------------------Navigation Keys: X = eXit System Management Services ------------------------------------------------------------------------------Type the number of the menu item and press Enter or select Navigation Key: 5
b. Press the 2 key and press Enter to select 2. Select Boot Devices. c. Press the 1 key and press Enter to select 1. Select 1st Boot Device. d. Press the 3 key and press Enter to select 3. CD/DVD. e. Select the media type that corresponds to the media device and press Enter. f. Select the device number that corresponds to the media device and press Enter. The media device is now the first device in the Current Boot Sequence list. g. Press the ESC key until you return to the Configure Boot Device Order menu. h. Select the device number that corresponds to the hard disk and press Enter. i. Press the x key to exit the SMS menu. Confirm that you want to exit SMS. 3. Boot from the AIX Volume 1, as follows: a. Select console and press Enter. b. Select language for BOS Installation menus, and press Enter to open the Welcome to Base Operating System Installation and Maintenance menu. c. Type 2 to select Change/Show Installation Settings and Install in the Choice field and press Enter.
383
Welcome to Base Operating System Installation and Maintenance Type the number of your choice and press Enter. 1 Start Install Now with Default Settings 2 Change/Show Installation Settings and Install 3 Start Maintenance Mode for System Recovery 4 Configure Network Disks (iSCSI) 88 Help ? 99 Previous Menu >>> Choice [1]: 2 Choice is indicated by >>>.
4. Verify or Change BOS Installation Settings, as follows: a. Type 1 in the Choice field to select the System Settings option. b. Type 1 for New and Complete Overwrite in the Choice field and press Enter. Note: The installation methods available depend on whether your disk has a previous version of AIX installed. c. When the Change Disk(s) screen opens, you can change the destination disk for the installation. If the default shown is correct, type 0 in the Choice field and press Enter. To change the destination disk, do the following: 1) Type the number for each disk you choose in the Choice field and press Enter. Do not press Enter a final time until you have finished selecting all disks. If you must deselect a disk, type its number a second time and press Enter. 2) When you have finished selecting the disks, type 0 in the Choice field and press Enter. The Installation and Settings screen opens with the selected disks listed under System Settings. d. If needed, change the primary language environment. Use the following steps to change the primary language used by this installation to select the language and cultural convention you want to use. Note: Changes to the primary language environment do not take effect until after the Base Operating System Installation has completed and your system is rebooted. 1) Type 2 in the Choice field on the Installation and Settings screen to select the Primary Language Environment Settings option. 2) Select the appropriate set of cultural convention, language, and keyboard options. Most of the options are a predefined combination, however, you can define your own combination of options. v To choose a predefined Primary Language Environment, type that number in the Choice field and press Enter. v To configure your own primary language environment, do the following: a) Select MORE CHOICES. b) Select Create Your Own Combination. c) When the Set Primary Cultural Convention screen opens, type the number in the Choice field that corresponds to the cultural convention of your choice and press Enter. d) When the Set Primary Language screen opens, type the number in the Choice field that corresponds to your choice for the primary language and press Enter. e) When the Set Keyboard screen opens, type the number in the Choice field that corresponds to the keyboard attached to the system and press Enter.
384
e. After you have made all of your selections, verify that the selections are correct. Press Enter to confirm your selections and to begin the BOS Installation. The system automatically reboots after installation is complete. 5. Switch the partition to Normal Mode, as follows: a. Right-click on the partition profile to open the menu. Be sure the correct partition profile is highlighted. b. c. d. e. f. g. Select Properties. Select the Settings tab. For the Boot Mode, select Normal. Select OK to close the Properties menu. Right-click on the partition to open the menu. Select Restart Partition.
h. Select Immediate for the Restart Options. i. Confirm that you want to restart the partition. j. When the partition has restarted, right-click on the partition to open the menu. k. Select Open terminal window to open a virtual terminal (vterm) window. 6. Complete the BOS Installation, as follows: a. Type vt100 as the terminal type.
Set Terminal Type The terminal is not properly initialized. Please enter a terminal type and press Enter. Some terminal types are not supported in non-English languages. ibm3101 ibm3151 ibm3161 ibm3162 ibm3163 ibm3164 ibmpc lft tvi912 tvi920 tvi925 tvi950 vs100 vt100 vt320 sun vt330 vt340 wyse30 wyse50 wyse60 wyse100 wyse350
88 99
Help ? Exit
+-----------------------Messages-----------------------| If the next screen is unreadable, press Break (Ctrl-c) | to return to this screen. | |
b. In the License Agreement menu, select Accept License Agreements. c. Select yes to ACCEPT Installed License Agreements. d. Press F10 (or Esc+0) to exit the License Agreement menu. e. In the Installation Assistant main menu, select Set Date and Time.
Installation Assistant Move cursor to desired item and press Enter. Set Date and Time Set root Password Configure Network Communications Install Software Applications Using SMIT (information only)
F1=Help F9=Shell
F2=Refresh F10=Exit
F3=Cancel Enter=Do
F8=Image
385
f. Set the correct date, time, and time zone. Press the F3 (or Esc+3) key to return to the Installation Assistant main menu. g. Select Set root Password. Set a root password for the partition. h. Select Configure Network Communications. Select TCP/IP Startup. Select from the Available Network Interfaces and press Enter. Enter the appropriate network information in the Minimum Configuration and Startup menu and press Enter. Use the F3 (or Esc+3) key to return to the Installation Assistant main menu. i. Exit the Installation Assistant by pressing F10 (or Esc+0). j. The vterm window displays a login prompt.
Step 2. Manage your partition (perform this step in the AIX environment)
When the installation has completed and the system has rebooted, the vterm window displays a login prompt. At this point, you may want to perform several common system-administration procedures. The following table lists where to find information about performing these procedures.
Table 15. Common System Administration Procedures
Procedure Backing up and recovering system backups Managing users and groups Installing software Installing fixes/updates Tuning the system for performance Configuring printers Location "Creating and installing system backups" in Installation and migration "Users, Roles, and Passwords" in Security "Optional Software Products and Service Updates" in Installation and migration "Optional Software Products and Service Updates" in Installation and migration "Performance tuning" in Performance management Printers and printing
Installing AIX using the media device to install a partition without an HMC
In this procedure, you will use the system's built-in media device to perform a new and complete Base Operating System Installation on the standalone system. Things to consider
The information in this how-to scenario was tested using specific versions of AIX. The results you obtain might vary significantly depending on your version and level of AIX.
This information contains procedures to install the AIX operating system. For more information on concepts and considerations involved when performing a base operating system installation of AIX, or concepts and requirements involved when using the Network Installation Manager (NIM) to install and maintain AIX, refer to Installation and migration. At this point, the BOS Installation is complete, and the initial configuration of the system is complete.
386
387
2. To change the System Settings, which includes the method of installation and disk where you want to install, type 1 in the Choice field and press Enter.
Installation and Settings Either type 0 and press Enter to install with current settings, or type the number of the setting you want to change and press Enter. 1 System Settings: Method of Installation.............New and Complete Overwrite Disk Where You Want to Install.....hdisk0
3. Type 1 for New and Complete Overwrite in the Choice field and press Enter. The Change Disk(s) Where You Want to Install screen now displays.
Change Disk(s) Where You Want to Install Type one or more numbers for the disk(s) to be used for installation and press Enter. To cancel a choice, type the corresponding number and Press Enter. At least one bootable disk must be selected. The current choice is indicated by >>>. Name 1 2 3 >>> 0 66 77 88 99 hdisk0 hdisk1 hdisk2 Location Code 04-B0-00-2,0 04-B0-00-5,0 04-B0-00-6,0 Size(MB) 4296 4296 12288 VG Status none none none Bootable Yes Yes Yes
Continue with choices indicated above Disks not known to Base Operating System Installation Display More Disk Information Help ? Previous Menu
4. In the Change Disk(s) Where You Want to Install screen: a. Select hdisk0 by typing a 1 in the Choice field and press Enter. The disk will now be selected as indicated by >>>. To unselect the destination disk, type the number again and press Enter. b. To finish selecting disks, type a 0 in the Choice field and press Enter. The Installation and Settings screen displays with the selected disks listed under System Settings. 5. Change the Primary Language Environment Settings to English (United States). Use the following steps to change the Cultural Convention, Language, and Keyboard to English. a. Type 2 in the Choice field on the Installation and Settings screen to select the Primary Language Environment Settings option. b. Type the number corresponding to English (United States) as the Cultural Convention in the Choice field and press Enter. c. Select the appropriate keyboard and language options. 6. Verify that the selections are correct in the Overwrite Installation Summary screen, as follows:
388
Overwrite Installation Summary Disks: hdisk0 Cultural Convention: en_US Language: en_US Keyboard: en_US Desktop: CDE Enable System Backups to install any system: Optional Software being installed: >>> 1 88 99 Continue with Install Help ? Previous Menu
Yes
7. Press Enter to begin the BOS installation. The system automatically reboots after installation is complete.
389
You can use the alt_disk_install command to clone a system image to another disk, but you must use the -O option to remove references in the object data manager (ODM) and device (/dev) entries to the existing system. The -O flag specifies that the alt_disk_install command should call the devreset command to reset the device database. The cloned disk can now be booted as if it were a new system. For a full description of alternate disk installation, see alt_disk_install. 1. Boot the managed system as a Full System Partition so you have access to all the disks in the managed system. 2. Configure the system and install the necessary applications. 3. Run the alt_disk_install command to begin cloning the rootvg on hdisk0 to hdisk1, as follows:
# /usr/sbin/alt_disk_install -O -B -C hdisk1
The cloned disk (hdisk1) will be named altinst_rootvg by default. 4. Rename the cloned disk (hdisk1) to alt1 as follows:
# /usr/sbin/alt_disk_install -v alt1 hdisk1
Renaming the cloned disk allows you torepeat the operation with another disk. 5. Run the alt_disk_install command again to clone to another disk and rename the cloned disk, as follows:
# /usr/sbin/alt_disk_install -O -B -C hdisk2 # /usr/sbin/alt_disk_install -v alt2 hdisk2
6. Repeat steps 3 through 5 for all of the disks that you want to clone. 7. Use the HMC to partition the managed system with the newly cloned disks. Each partition you create will now have a rootvg with a boot image. 8. Boot the partition into SMS mode. Use the SMS MultiBoot menu to configure the first boot device to be the newly installed disk. 9. Exit the SMS menus and boot the system.
Configuring an initial partition as a NIM Master to use NIM to install the remaining partitions
You can set up an initial logical partition as a NIM master and server. The NIM environment allows you to manage installations for your other partitions. Before you begin this procedure, you should perform the following tasks: v Use the HMC to create the Master_LPAR partition profile. Leave the partition in the Ready state. v Verify that the Master_LPAR partition has a network adapter, enough hard-disk space for the NIM resources, and an assigned CD device. v Set the boot mode for the Master_LPAR partition to be Normal mode. v Use the HMC to create logical partitions and partition profiles for each NIM client. v Verify that each NIM client partition has a network adapter assigned. Set the boot mode for each partition to be SMS mode. After you have successfully created the partitions and partition profiles, leave the partitions in the Ready v If AIX is not currently installed on any of the disks in the system, you must install it. For more information, see Installing AIX using the media device to install a partition with an HMC on page 23. v Configure AIX for network communication on the Master_LPAR. v Activate the Master_LPAR partition profile on the HMC. For more information on activating partition profiles, see Activating a partition profile. You should consider the following aspects of the installation when you configure an initial partition as a NIM Master and using NIM to install the remaining partitions has the following advantages:
390
v NIM environment offers the most flexibility and customization options for installation and management. v NIM environment allows for multiple installations at the same time. v The nim_master_setup and nim_clients_setup scripts provide a way to set up the NIM environment. v Requires one LPAR with approximately 1.5 GB of disk space dedicated as the NIM master partition. In this procedure, you will set up an initial logical partition as a NIM master and server. This procedure refers to this initial logical partition as the Master_LPAR. 1. Run the oslevel command on the Master_LPAR. Output similar to the following displays:
5200
If the output from the oslevel command does not show the expected OS level, see Migrating AIX on page 366 for information about migrating the AIX operating system to the correct OS level. 2. Verify your network connection by running the netstat command. You can run this command with the -C flag to show routing table information. You can also use the -D flag to show the number of packets received, transmitted, and dropped in the communications subsystem. 3. Insert the AIX installation media. 4. Run the nim_master_setup command. For additional information on options for running this command, see nim_master_setup. 5. Run the following command to open the/export/nim/client.defs file with the vi editor:
# vi /export/nim/client.defs
6. Edit the client.defs file according to your environment. For more information on this file, see the instructions and examples in the client.defs file. When you are finished editing the client.defs file, save it and exit the vi editor. 7. Run the nim_clients_setup -c command. For additional information on options for running this command, see nim_clients_setup. Note: If you are adding new client machines that cannot be resolved on the name server, edit the /etc/hosts file to add the IP addresses and client host names. After you have defined the client machines, you should activate and install the partitions. For more information on activating partitions, see Activating a partition profile. After you activate and install the client partitions, you can perform any system management tasks.
Using a separate AIX system as a NIM Master to use NIM to install each partition
You can use a separate system running AIX as a NIM master and server. The NIM environment allows you to manage installations for your other partitions. Before you begin this procedure, you should perform the following tasks: v Use the HMC to create partitions and partition profiles for each NIM client partition that you want to install. Leave the partitions in the Ready state. v Verify each partition has a network adapter assigned. v Set the boot mode for each partition to SMS mode. You should consider the following aspects of the installation when you use a separate AIX system as a NIM Master to use NIM to install each partition has the following advantages: v You need not dedicate an LPAR as the NIM master. v NIM environment offers the most flexibility and customization options for installation and management. v NIM environment allows for multiple installations at the same time.
Installation and migration
391
v The nim_master_setup and nim_clients_setup scripts provide a way to set up the NIM environment. v Requires an available server running AIX that can be used as the NIM master. 1. Run the oslevel command on the Master_LPAR. Output similar to the following displays:
5200
If the output from the oslevel command does not show the expected OS level, see Migrating AIX on page 366 for information about migrating the AIX operating system to the correct OS level. 2. Verify your network connection by running the netstat command. You can run this command with the -C flag to show routing table information. You can also use the -D flag to show the number of packets received, transmitted, and dropped in the communications subsystem. 3. Insert the AIX installation media. 4. Run the nim_master_setup command. For additional information on options for running this command, see nim_master_setup. 5. Run the following command to open the/export/nim/client.defs file with the vi editor:
# vi /export/nim/client.defs
6. Edit the client.defs file according to your environment. For more information on this file, see the instructions and examples in the client.defs file. When you are finished editing the client.defs file, save it and exit the vi editor. 7. Run the nim_clients_setup -c command. For additional information on options for running this command, see nim_clients_setup. Note: If you are adding new client machines that cannot be resolved on the name server, edit the /etc/hosts file to add the IP addresses and client host names. After you have defined the client machines, you should activate and install the partitions. For more information on activating partitions, see Activating a partition profile. After you activate and install the client partitions, you can perform any system management tasks.
The output from the install_all_updates command is shown in the /var/adm/ras/ install_all_updates.log log file. The install_all_updates command checks whether your system is at the latest known technology level. If your system is not at the latest known technology level, your server is updated to the latest technology level of AIX. 4. After the update is complete, reboot the system by using the shutdown -Fr command. 5. Run the nim_update_all command to update any NIM resources created by the nim_master_setup command. The nim_update_all command uses the device /dev/cd0 by default. The output from the nim_update_all command is shown in the /var/adm/ras/nim.update log file. Output similar to the following displays:
############################## NIM update all ############################## # # During script execution, NIM client and resource updating times # may vary. To view the install log at any time during nim_update_all, # run the command: tail -f /var/adm/ras/nim.update in a separate screen. # # # # # #
392
############################################################################## NSORDER=local,bind Adding updates to lpp_res lpp_source....done Updating spot_res using updated lpp_source lpp_res....done Attempting to replace mksysb resource generic_sysb... Removing old mksysb resource generic_sysb....done Creating image.data file....done Checking /export/nim space requirement... Generating list of client objects in NIM environment...
A new mksysb is created that replaces the existing mksysb, unless you specify the -B flag. All clients in the environment are updated, unless you specify the -u flag.
In this example, the paging space is 12 LPs (logical partitions) in size. 2. Create a dump logical volume by running the smitty mklv. When you are prompted for the volume group, type rootvg. 3. In the Add a Logical Volume menu, fill in the Logical volume NAME and the Number of LOGICAL PARTITIONS fields. 4. Change the primary dump device by running the smitty dumpchgp. You are prompted to enter the path to the primary dump device. 5. Validate your dump devices by running the smitty dump command. 6. Select Show Current Dump Devices. The output will be similar to the following:
393
Before command completion, additional instructions may appear below. primary secondary copy directory forced copy flag always allow dump dump compression /dev/dumplv /dev/sysdumpnull /var/adm/ras TRUE FALSE OFF
Before command completion, additional instructions may appear below. primary secondary copy directory forced copy flag always allow dump dump compression /dev/hd6 /dev/sysdumpnull /var/adm/ras TRUE FALSE OFF
394
Host names cannot be reused between the Full System Partition and the logical partitions. To change the operating system host name, complete the following steps: 1. Run the lsrsrc command as follows:
/usr/sbin/rsct/bin/lsrsrc ManagementServer Hostname
If the partition is managed by multiple HMCs, multiple entries might exist because each HMC has its own entry. The output will be similar to the following:
resource 1: Hostname = "hmc1.mydomain.mycompany.com"
2. For each entry, use the rmrsrc to remove the host name shown. For example, run the following command:
/usr/sbin/rsct/bin/rmrsrc -s Hostname = "hmc1.mydomain.mycompany.com" ManagementServer
You can verify that all entries have been removed by running the lsrsrc command again. 3. Run the rmcctrl command as follows:
/usr/sbin/rsct/bin/rmcctrl -z
4. Change the host name of the partition. 5. Run the following command:
/usr/sbin/rsct/bin/rmcctrl -A
395
396
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this
Copyright IBM Corp. 2002, 2011
397
one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation Dept. LRAS/Bldg. 903 11501 Burnet Road Austin, TX 78758-3400 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows:
398
(your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp. _enter the year or years_. If you are viewing this information softcopy, the photographs and color illustrations may not appear.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at Copyright and trademark information at www.ibm.com/legal/copytrade.shtml. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. UNIX is a registered trademark of The Open Group in the United States and other countries.. Other product and service names might be trademarks of IBM or other companies.
Notices
399
400
A
accessing an unbootable system 89 accessing SMIT 326 activate operation 247 Activation Engine Overview 32 adapter_def resource 221 defining 221 adding BCMM management NIM environment 124 adding CEC management NIM environment 121 adding HMC management NIM environment 120 adding IVM management NIM environment 123 adding VIOS management NIM environment 122 additional topics dynamic host configuration protocol interacting with 116 advanced configuration 206 adding another network type 178 backing up the NIM database 186 booting diagnostics 183 booting in maintenance mode 181 creating additional interface attributes 151 defining /usr vs. non-/usr SPOTs 140 defining a heterogeneous network 177 defining an lpp_source on CD/DVD-ROM vs. Hard Disk 141 establishing a default route 179 establishing a static route 180 recovering the /etc/niminfo file 186 removing machines 187 Copyright IBM Corp. 2002, 2011
401
alternate disk installation (continued) examples 72 in a partitioned environment 389 mksysb installation 66 phased installation 67 using SMIT 72 Alternate Disk Installation 12 Alternate Disk Migration Installation 68 American Standard Code for Information Interchange applying optional software definition of 329 description 321 ASCII Installation Assistant 83 introduction to tasks 83 ASCII procedures 321 ASCII terminals setting communications options 317 setting display and keyboard options 56, 317 setting options 56 ATM networks installing to clients 130 ATM Networks 175 converting generic networks into 130 attributes if 151 if1 151 if2 151 other_net_type 177
83
B
backup disk space 315 backup image 315 backup installation changing installation modes 317 backup, of system 304 exclude files 307 introduction 308 mounting and unmounting file systems 20, 305 procedure list information about filesets in a system image 315 lsmksysb command 314 lssavevg command 314 prerequisites 20, 305 preview information about a backup 314 root volume group 20, 306 verifying backup 312 verifying system backups 315 view the backup log 315 basic configuration creating basic installation resources 117 basic host identification 206 basic operations and configuration 117, 165 adding a diskless or dataless client 136 adding a stand-alone client 120 adding a standalone client 125 clients and SPOT resources customizing 131 configuring the master 117 diskless and dataless clients configuring the master and creating resources 133 diskless or dataless machine initializing and booting 184 uninitializing 137 mksysb install 160 non-prompted install 159
basic operations and configuration (continued) rte install 157 binary compatibility 367 boot logs view 198 boot resource 224 booting diagnostics 183 over router 185 booting the system problems with 89 procedure 55, 317, 370 BOS installation cloning 21, 316 system backup, from 315 BOS maintenance mode accessing 89 BOS menus installation and setting window 39 installation summary window 39 welcome window 39 BOS run-time image source for 252 bos_inst operation 249 ATM adapters 130 paging space 174 using the boot_client attribute 254 using the force_push attribute 253 using the preserve_res attribute 254 using the set_bootlist attribute 254 bos.sysmgt.nim.master removing 214 bosboot troubleshooting 92 device problems 92 space problems 92 bosinst_data 225 defined 225 defining 225 overview 225 bosinst.data control_flow stanza descriptions 45 bosinst.data file 45 ACCEPT_LICENSES variable 48 ALL_DEVICES_KERNELS variable 48 ALT_DISK_INSTALL_BUNDLE variable 48 ALWAYS_ALLOW variable 53 BOSINST_DEBUG variable 47 BOSINST_LANG variable 52 bosinst.data target_iscsi_data stanza 51 BUNDLES variable 47 CONNECTION variable 51 CONSOLE variable 45 COPYDIR variable 53 CREATE_JFS2_FS variable 48 CULTURAL_CONVENTION variable 52 CUSTOMIZATION_FILE variable 47 description 79 DESKTOP variable 48 DUMPDEVICE variable 52 ERASE_ITERATIONS variable 49 ERASE_PATTERNS variable 49 ERROR_EXIT variable 46 EXISTING_SYSTEM_OVERWRITE variable 46 FIREFOX_BUNDLE variable 48 FORCECOPY variable 53 GRAPHICS_BUNDLE variable 48 HARDWARE_DUMP variable 49
402
bosinst.data file (continued) HDISKNAME variable 49 IMPORT_USER_VGS variable 48 INSTALL_DEVICES_AND_UPDATES variable 48 INSTALL_EDITION variable 46 INSTALL_METHOD variable 45 INSTALL_TYPE variable 47 INSTALL_X_IF_ADAPTER variable 46 KERBEROS_5S_BUNDLE variable 48 KEYBOARD variable 52 livedump stanza 53 LOCATION variable 49 MESSAGES variable 52 mksysb_migration_device 55 nonprompted BOS installation 46 PHYSICAL_LOCATION variable 49 PRIMARY variable 53 PROMPT variable 46 prompted mode, with 90 PVID variable 49 RECOVER_DEVICES variable 47 REMOVE_JAVA_118 variable 49 RM_INST_ROOTS variable 46 RUN_STARTUP variable 46 SAN_DISKID variable 51 SECONDARY variable 53 SECURE_BY_DEFAULT variable 48 SERVER_BUNDLE variable 48 SIZE_MB variable 49 SIZEGB variable 52 Specifies the edition selection 46 SYSTEM_MGMT_CLIENT_BUNDLE variable 48 TCB variable 47 TRUSTED_AIX variable 48 TRUSTED_AIX_LSPP variable 48 using 80 bosinst.data sample file 54 build date of filesets installed 325 bundles 322, 364 definition of 322 examples of 364 types of 364
C
CD or DVD creating backups CD or DVD 309 CD/DVD bootable 308 non-bootable 308 cdrecord 308 change characteristics 113 change operation 254 check operation 254 checking 113 chwpar operation 255 cleaning up failed software installation 22, 332 client determining control 116 diskless or dataless adding 136 operations 104 tasks performed from 206 client communication options management NFS defining 206
client machine verifying status of 129 client operations 206 clients dataless 108 initializing 110 diskless 108 initializing 110 optional resources 109 required resources 109 shared_root 241 standalone 108 managing software 108 network booting 108 standalone, adding 125 cloning backup, of system 21, 316 cloning using Alternate Disk Installation 12 commands nim_clients_setup 114 nim_master_setup 114 nimclient 206 committing service updates definition of 329 introduction 321 Common Criteria 42 communication between HMC and Partitions 381 communications ASCII terminals options 56 setting options for ASCII terminals 317 compatibility 367 concepts NIM 104 concurrency control 154 configuration assistant web browser, installing 83 web server, installing 83 Configuration Assistant configuring online documentation 83 documentation 83 configuration logs view 198 configuration menus using iSCSI 64 configuration tasks basic 117 configuration, system 83 access remote resources 83 add license passwords 83 back up the system 83 change language environment 83 configure printer 83 create user accounts 83 date and time 83 exit and log in 83 install optional software 83 introduction to 83 list of tasks 83 set root password 83 consolidation of multiple versions of the same operating system 380 control operations definition of 246 control status master or client 116 control_flow stanza 45
Index
403
Controlled Access Protection Profile and Evaluation Assurance Level 4+ 42 Create and Install a Software Bundle software bundle 7, 14 create backup 114 Creating AE Scripts 36 Creating AE Template File 34 creating clients 112 Creating EZNIM setup using different 270 creating software packages 363 cust operation 255 asynchronous behavior 214 customizing BOS installation 80 bosinst.data file 79
D
data recovery introduction 89 procedure 90 when system will not boot 89 dataless clients 108 initializing 110 managing software 111 shared_root 241 deactivate operation 256 deallocate operation 257 debug BOS installation 47 debug mode installing BOS 39 NIM 301 NIM BOS installation 302 using a bosinst.data file for NIM BOS installation default routes creating 179 define machine group 202 resource group 222 define operation 257 definition file KDC server sample 273 Kerberos slim client sample 274 devexports resource 225 defining 225 overview 225 diag operation 183, 257 diagnostics booting 183 loading from network for diskless and dataless machines 184 directories /dev 316 /etc/objrepos 315 /tmp/vgdata/rootvg 317 disk specifying for BOS installation CD-ROM, DVD-ROM or tape 57 system backup 317 disk space messages 92 planning for master machine 117 diskless and dataless managing software 111 diskless and dataless clients creating resources to support 133 migrating 201
303
diskless and dataless tasks booting diagnostics 183 diskless clients 108 initializing 110 managing software 111 resource boot 109 dump 109 home 109 paging 109 resolv_conf 109 root 109 shared_home 109 SPOT 109 tmp 109 resources optional 109 required 109 diskless or dataless client adding 136 initializing and booting 184 uninitializing 137 disks, hard (fixed) 57 displays setting options for ASCII terminals 56, 317 distributed resources 221 dkls_init operation 258 dtls_init operation 259 dump device verifying 394 dump devices creating and changing 393 in a partitioned environment 393 dump resource 226 defined 226 defining 226 overview 226 DVD-RAM creating backups DVD-RAM and UDF 311 dynamic host configuration protocol interacting with 116 dynamic logical partitioning 378
E
electronic license agreements 41 environment changing language 57 epkg command 355 error conditions 85, 274 error messages attempt to create bootable tape failed 92 check available disk space 92 error occurred during bosboot 92 format 92 hard disks not accessed 92 hard disks not configured 92 invalid or no boot device specified 92 NIM 274 no disks are available 92 not enough file space to create: /tmp/disk.image not enough file space to create: /tmp/unix 92 unable to expand file system /usr 92 error recovery 85, 274 exclude files from system backup 307 exclude_files 227 defined 227
92
404
exclude_files (continued) defining 227 overview 227 exporting resources number of hosts 214 eznim 268
F
fb_script 227 defined 227 defining 227 overview 227 FDDI router 185 file system messages 92 file systems / messages 92 root part 362 /tmp 315 free space in 20, 305 messages 92 /usr messages 92 troubleshooting when full 92 usr part 362 /usr/share 362 mounting and unmounting 20, 305 files /dev/ipldevice 92 /etc/exclude.rootvg 307 /etc/niminfo 186 /tmp/disk.image 92 /tmp/unix 92 /usr 242 bosinst.data 80 examples of 54 explanation of 79 prompted mode, with 90 examples bosinst.data 54 definition file for nimdef command script resource 271 image.data 80, 315 map 317 preserve.list 80 sample 271 filesets 322, 362 fix_bundle 228 defined 228 defining 228 overview 228 fix_query operation 259 fixed disks 57 fixes listing for SPOT 210 listing for standalone client 210 full system partition 378
graphical user interface Easy Install prerequisites 324 procedural overview 321 graphical user interfaces Installation Assistant introduction to tasks 83 group resource allocate 223 define 222 groups establishing 218 machine 218 defining 202 resource 219 GUIs 83
H
hard disks 57 location codes of 57 specifying for CD/DVD-ROM or tape installation specifying for system backup installation 317 unaccessible 92 unconfigured 92 hardware diagnostics diskless and dataless 183 Hardware Management Console (HMC) affinity logical partitions 378 communicating with partitions 381 managing remotely with AIX partition 379 managing remotely with client 379 managing systems with 378, 379 managing with an HMC client 379 Network Adapter Communication 381 heterogeneous networks defining 177 home resource 229 defined 229 defining 229 overview 229 host authentication 206 host authorization 207 host identification 206 host name naming 395 57
271
I
if attribute creating additional 151 if1 attribute 151 if2 attribute 151 image_data 229 defined 229 defining 229 overview 229 image.data file 80, 315 install_all SMIT fast path 326 install_all_updates command installation alternate disk 65 change method of 57
G
geninstall command 337, 362 Graphical Install menus 45
328
Index
405
installation (continued) verifying with lppchk operation 173 Installation Assistant 84 introduction to tasks 83 installation images mksysb configuration on backup tape 86 installation logs view 198 installation methods definition of 57 specifying 57 installation resources creating 117 installation screens (BOS) Change Disk(s) Where You Want to Install 317 specifying installation language 370 specifying system console 317, 370 System Backup Installation and Settings (BOS) 317 installation tasks advanced 202 installation to an iSCSI disk 63 installation windows (BOS) Change Disk(s) Where You Want to Install 57 Installing Base Operating System 59, 371 specifying installation language 57 specifying system console 57 installation, nonprompted specifying with the bosinst.data file 79 installing AIX considerations 23, 27, 382, 386 in a partitioned environment 23, 27, 382, 386, 390, 391 NIM 390, 391 procedures 23, 27, 382, 386 using the media to manually install a logical partition 23, 27, 382, 386 using the media to manually install a standalone system new and complete overwrite installation 1 installing and managing interim fixes 342 installing and managing software detached WPAR 216 installing BOS debug mode 39 new and complete overwrite 55 preservation 55 installing BOS from CD or DVD-ROM procedure specifying destination disk 57 installing BOS from CD or tape procedure booting (starting) the system 317 initiating the installation 317 installing BOS from CD-ROM procedure changing language environment 57 prerequisites for 55 installing BOS from CD/DVD-ROM procedure booting (starting) the system 55 initiating the installation 55 introduction to 55 installing BOS from CD/DVD-ROM or tape procedure booting (starting) the system 370 initiating the installation 370 introduction to 369, 370
installing BOS from DVD-ROM procedure prerequisites for 55 installing BOS from media or tape troubleshooting 92 installing BOS from system backup introduction to 315 procedure 317 resolving reported problems 86 source system 315 target system 315 troubleshooting 85 installing BOS using Web-based System Manager network installation 317 system backup 317 installing optional software applying 321, 329 cleaning up failed installation 22, 332 committing 321, 329 introduction to 321 prerequisites 324 procedural overview 321 procedure (graphical interface) 325 procedure (SMIT) 326 status messages 327 rejecting 321, 330 removing 321, 331 selection criteria 323 software licenses 323 software packaging 323 status messages (SMIT) 327 troubleshooting 22, 92, 332 installing software 114 Installing to an alternate disk 12 installp format creating software packages 363 installp_bundle 231 defined 231 defining 231 overview 231 InstallShield MultiPlatform 337 installing a package 337 silent installation 339, 341 uninstalling a package 338 interface attribute 151 creating additional 151 interim fix 341 interim fix management emgr command 342 interim fix control file 355 see also interim fix management 341 interim fixmanagement epkg command 355 introduction to NIM network objects definition of 104 IP address determining 176 iSCSI configuration menus 64 iSCSI disk installation 63 ISMP see InstallShield MultiPlatform 337 ISO9660 format 309
406
K
KDC server sample definition file 273 Kerberos host identification 206 NFS V4 host authentication 206 Kerberos slim client sample definition file 274 keyboards setting options for ASCII terminals
M
56, 317 machine diskless or dataless initializing and booting 184 uninitializing 137 machine groups defining 202, 218 operations 203, 204 machine operations defined 246 list of 246 machines 104 maint operation 211, 261 asynchronous behavior 214 maintain software in SPOT 211 maintain software on standalone clients 211 maint_boot operation 262 maintaining optional software applying 329 committing 329 concepts defined 329, 333 rejecting 330 removing 331 maintenance mode accessing (BOS) 89 maintenance mode recovery 64 maintenance mode to recover iSCSI parameters 64 maintenance updates automated downloads 333 management 341 managing clients 112 Managing NFS client communication options 206 Managing NFS client communication options using SMIT Managing NFS client communication options using the command line 208 managing software clients standalone 108 SPOT 209 standalone clients 209 map files 317 master activating 187 backing up NIM database 186 configuring 117 disabling push permissions 199 managing activate the master 187 back up NIM database 186 restore NIM database 187 removing master fileset 214 unconfiguring 139 master fileset removing 214 messages NIM error 274 NIM warning 274 system and error 92 migrating clients diskless and dataless 201 NIM SPOTs 201 Index
L
language environment changing 57 setting 57 license acceptance 48 license agreements 41 licensed programs 322 packaging of 323 selection criteria for installation 323 licenses, software function of 323 list characteristics 113 listing fixes installed on a SPOT 210 installed on a standalone client 210 listing information software in SPOT 209 software in standalone client 209 listing software updates installed on a SPOT 210 installed on a standalone client 210 locale 57 location codes, of the hard disk 57 logical partition consolidation of multiple versions of the same operating system 380 implementation 380 minimum resources 377 mixed production and test environments 380 overview 377 running AIX 378 server consolidation 380 logical volumes accessing 89 introduction 89 procedure 90 logs boot viewing 198 configuration viewing 198 installation view 198 lpp_source 232 copying software 212 defined 232 defining 234 maintaining software 212 overview 232 removing software 213 running the check operation 213 lppchk operation 260 lppmgr command 333 lppmgr operation 260
208
407
migrating installing AIX 5 migrating to new version procedure prerequisites for 369 migration installation definition of 39 mkcd command 308 mkinstallp command 363 mkisofs 308 mksysb 235 alternate disk installation 165 backup images on CD/DVD 308 cloning 21, 316 defined 235 defining 235 installation from 315 overview 235 resolving reported problems 86 source for BOS run-time image 252 system backup tapes 86 troubleshooting installation from 85 mksysb install performing 160 mksysb_migration_device 55 monitors setting options for ASCII terminals 56, 317 multibos utility 74
N
name resolution 115 naming your OS host 395 network heterogeneous defining 177 Network Adapter Communication Between Partitions and the HMC 381 network booting clients standalone 108 network objects managing creating interface attributes 151 establishing a route between networks 180 network types supported 175 networks ATM 130 defining 175 defining heterogeneous 177 NIM 175 New and Complete Overwrite BOS Installation using Graphical Install menus 45 new and complete overwrite installation 55 definition of 38 NFS client communication options management 206 NFS client communication options managing using SMIT 208 managing using the command line 208 NFS V4 host authentication 206 NFS V4 host authorization 207 NFS V4 host identification 206 NIM adding WPAR clients 129 alternate disk installation 165 client requests, tuning 138
NIM (continued) configuration basic 117 configure using EZNIM 14 dataless definition of 104 diskless definition of 104 error messages 274 exported Kerberos authentication 171 in a partitioned environment 390, 391 Kerberos 5 171 Kerberos authentication 170 machines 104 networks 175 nimesis daemon 138 operations basic 117 overview 103 resources definition of 217 response files and InstallShield MultiPlatform products 341 SPOTs migrating 201 standalone definition of 104 warning messages 274 NIM attributes 177 NIM clients defining 105 NIM concepts 104 NIM database backing up 186 restoring 187 NIM environment 104, 111 defining using the nimdef command 205 NIM eznim 268 NIM groups 218 NIM networks defining 175 IP address determining 176 routes 177 types supported 175 NIM object definitions name requirements 116 NIM objects definitions name requirements 116 NIM operations 183 activate 247 allocate 247 alternate disk installation 220 alternate disk migration installation 220 bos_inst 249 change 254 check 254 chwpar 255 cust 255 deactivate 256 deallocate 257 define 257 diag 257 diagnostics, booting 220
408
NIM operations (continued) diskless and dataless clients, adding dkls_init 258 dtls_init 259 fix_query 259 lppchk 260 lppmgr 260 lswpar 261 maint 261 maint_boot 262 maintenance mode, booting 220 reboot 262 remove 263 reset 263 resources 220 select 263 showlog 264 showres 264 software, customizing 220 software, removing 220 sync 265 sync_roots 266 syncwpar 266 takeover 267 unconfig 267 update 267 updateios 268 NIM output suppressing 215 NIM resources 217 NIM routes 177 NIM Service Handler 206 nim_script resource 236 nim_update_all in a partitioned environment 392 nimclient command 206 nimdef command NIM environment defining 205 sample definition file 271 NIMSH 206 non-prompted install performing a 159 nonprompted installation changing to prompted 317 nonprompted mode overriding 90 nonroot volume group definition of 304
220
O
operations activate 247 allocate 247 basic 117 BOS run-time image selecting source 252 bos_inst 249 change 254 check 254 chwpar 255 cust 255 deactivate 256 deallocate 257 define 257 diag 257
operations (continued) dkls_init 258 dtls_init 259 excluding a group member 204 fix_query 259 including a group member 204 list of 246 lppchk 260 lppmgr 260 lswpar 261 maint 261 maint_boot 262 NIM diag 183 machine 246 performed from client 206 on client machines 104 performing 246 reboot 262 remove 263 reset 263 select 263 showlog 264 showres 264 sync 265 sync_roots 266 syncwpar 266 takeover 267 types 246 unconfig 267 update 267, 268 optional software cleaning up failed installation of introduction 22, 332 definition of 322 options language environment 57 nonprompted installation specifying with the bosinst.data file 79 setting communications (ASCII) 56, 317 setting display (ASCII) 56, 317 setting monitor (ASCII) 56, 317 specifying installation disk (BOS) CD-ROM, DVD-ROM or tape 57 system backup 317 specifying installation language 57, 370 specifying installation method (BOS) 57 specifying system console 57, 317, 370 system configuration 83 other_net_type attribute 177 output, NIM suppressing 215 overview NIM 103, 104 overview of partitions managed system 378
P
package definition of 322 package formats installp 362 software filesets 362 packaging interim fixes 355 paging defined 236 Index
409
paging (continued) overview 236 paging resource 236 defining 236 partition security 380 partition scenarios Advanced Installation Options 393 partitions affinity 378 full system 378 implementation 380 logical 377 running AIX 378 using NIM 390, 391 port conflicts nimesis daemon 303 post_migration command 368 pre_migration command 368 prerequisites for setting up a NIM environment with NFS security using Kerberos 5 207 preservation installation 55 definition of 38 preserve_res 254 preserve.list file 80 problems, recovering from 85, 274 procedures accessing BOS maintenance 90 advanced configuration 206 adding another network type 178 backup up the NIM database 186 booting diagnostics 183 booting in maintenance mode 181 creating additional interface attributes 151 defining a heterogeneous network 177 defining an lpp_source on CD/DVD-ROM vs. Hard Disk 141 establishing a default route 179 establishing a static route 180 recovering the /etc/niminfo file 186 removing machines from the NIM environment 187 restoring the database and activating the master 187 unconfiguring the master 139 advanced installation adding new members 203 allocating a resource group 223 controlling the master or client 116 copying software to an lpp_source 212 defining a machine group 202 defining a resource group 222 defining default resource groups 223 excluding a group member 204 including a group member 204 listing software in a SPOT 209 listing software on a standalone client 209 listing software updates by keyword 210 maintaining software in an lpp_source 212 maintaining software on a SPOT 211 removing members 188 removing software from an lpp_source 213 resetting machines 200 running the NIM check operation 213 standalone clients and SPOT resources, managing software 209 using clients as resource servers 153 verifying installation with lppchk operation 173 viewing logs 198
procedures (continued) advanced installation, managing software rebuilding network boot images for a SPOT 201 basic configuration creating basic installation resources 117 basic operations and configuration adding a diskless or dataless client 136 adding a standalone client 125 clients and SPOT resources, customizing 131 configuring the master 117 creating resources to support diskless/dataless clients 133 diskless or dataless machine, initializing and booting 184 diskless or dataless machine, uninitializing 137 mksysb install, performing 160 non-prompted install 159 rte install, performing an 157 defining /usr vs. non-/usr SPOTs 140 identifying boot device 92 installing BOS from CD/DVD-ROM 55 installing BOS from CD/DVD-ROM or tape 369, 370 installing BOS from system backup 317 installing optional software 321 resizing /tmp 92 root volume group, backing up 20, 306 troubleshooting a mksysb installation 85, 86 troubleshooting full /usr file system 92 unlocking the root volume group 92 user volume group, backing up 312 verifying system backup 315 product identification, optional software 322 prompted installation 320 help information 320 prompted mode changing to (BOS) 90 push permissions master disabling 199
R
readme README.PARTITION_INSTALL 393 reboot operation 262 recover devices 47 recovery 85, 274 maintenance mode 64 rejecting optional software definition of 330 introduction 321 relocatable application execution 63 relocatable applications packaging 62 Relocatable Installation 60 relocatable installation utilities on AIX 61 remote management 379 remove operation 263 removing optional software definition of 331 introduction 321 reset operation 263 resolv_conf defined 237 defining 237 overview 237 resolv_conf resource 237
410
resource boot diskless/dataless 109 dump diskless/dataless 109 home diskless/dataless 109 paging diskless/dataless 109 resolv_conf diskless/dataless 109 root diskless/dataless 109 shared_home diskless/dataless 109 SPOT diskless/dataless 109 tmp diskless/dataless 109 resource group allocate 223 define 222 resource groups allocating resources 222 defining 219 defining default 223 resources 217 adapter_def 221 defining 221 AIX Version 4.3 or later spots boot 224 bosinst_data 225 defining 225 clients and SPOT customizing 131 devexports 225 defining 225 distributed 221 dump 226 defining 226 exclude_files 227 defining 227 exporting number of hosts 214 fb_script 227 defining 227 fix_bundle 228 defining 228 home 229 defining 229 image_data 229 defining 229 installp_bundle 231 defining 231 list of 217 lpp_source 232 defining 234 mksysb 235 defining 235 nim_script 236 operations list of 217 paging 236 defining 236 resolv_conf 237 defining 237 root 237
244
resources (continued) defining 238 savewpar 239 defining 239 script 238 defining 238 secattrs 240 defining 240 shared product object tree 242 shared_home 240 defining 241 SPOT 242 defining 244 tmp 246 defining 246 wpar_spec 245 defining 245 resources, NIM reducing space requirements 215 response files 339 response files and NIM 341 root shared_root 241 root directory creating file resources 222 root resource 237 defined 237 defining 238 root volume group (rootvg) backing up 20, 306 definition of 304 unlocking 92 router booting over 185 routes 177 creating a default 179 creating a static 180 RPM ISMP 362 rte source for BOS run-time image 252 rte install performing 157 run-time image 252
S
sample files 271 bosinst.data 54 nimdef command definition file 271 script resource 271 sample KDC server definition file 273 sample slim client definition file 274 savevg command 312 savewpar resource 239 defining 239 overview 239 screens Access a Root Volume Group (BOS) 90 Change Disk(s) Where You Want to Install (BOS) 317 Maintenance (BOS) 90 System Backup Installation and Settings 317 Volume Group Information (BOS) 90 Welcome to Base Operating System Installation and Maintenance (BOS) 90 script 238 Index
411
script (continued) defined 238 defining 238 overview 238 script resource sample file 271 secattrs resource 240 defining 240 overview 240 security Controlled Access Protection Profile and Evaluation Assurance Level 4+ 380 security evaluation technology see Controlled Access Protection Profile and Evaluation Assurance Level 4+ 42 select operation 263 service update management assistant 333 service updates committing 329 rejecting 330 removing 331 setting up a NIM environment with NFS security using Kerberos 5 prerequisites 207 shared product object tree 242 shared volume groups AUTO ON 315 shared_home defining 241 overview 240 shared_home resource 240 defined 240 showlog operation 264 showres operation 264 shutting down a partition using AIX 394 SMIT fast path alt_clone 72 alt_mksysb 72 assist 84 cleanup_software 336 commit 329 compare_report 335 eznim 268 fixtolist_compare 336 install_all 326 install_latest 326 install_update 84 installed_license 323 instofix_compare 335 instolist_compare 335 license_on_media 323 reject 330 remove 331 rename_software 336 service_software 333 update_all 326 update_by_fix 326 SMIT interfaces Custom Install path 326 Easy Install path 326 prerequisites 324 procedural overview 321 Installation Assistant 83 SMIT procedures installing optional software 321, 326 software listing for SPOT 209
software (continued) listing for standalone client 209 software bundles 322, 364 definition of 322, 364 examples of 364 software filesets definition of 322 software licenses function of 323 software packages definition of 322 software packaging root part 362 share part 362 user part 362 software products 323 applying 329 bundle, definition of 322 bundle, examples of 364 committing 329 fileset, definition of 322 identification of 322 licensed program, definition of 323 package, definition of 322 packaging of 323 rejecting 330 removing 331 selection criteria for installation 323 software service management 333 clean up software images 336 comparison reports 335 rename software images 336 software updates listing for SPOT 210 listing for standalone client 210 software, optional definition of 322 source system 315 SPOT defined 242 defining 244 maintaining software 211 managing software 209 overview 242 resources 141 source for BOS run-time image 252 updating 205 standalone client operations 206 standalone clients 108, 206 adding 125 maintaining software 211 managing software 108, 209 network booting 108 standalone machines determining control 116 standby BOS 76 stanza bosinst.data target_iscsi_data 51 starting 113 starting the system 55, 317, 370 static routes creating 180 stopping 113 suppressing NIM output 215 sync operation 265 sync_roots operation 266
412
synchronizing software 113 syncwpar operation 266 system booting (starting) 55, 317, 370 configuring 83 system backup 304 system backup to tape 20 system backup, BOS installation from 315 system bundles 364 system configuration 83 System Management Interface Tool 83 system messages 92 system settings changing during BOS installation 57 system, managed 378
T
takeover operation 267 tape creating bootable, troubleshooting 92 creating bootable,troubleshooting 92 tapeblksz 86 target disk specifying for CD/DVD-ROM or tape installation 57 specifying for system backup installation 317 target system 315 target_iscsi_data stanza 51 tasks bos, installing 220 configuring NIM environment 220 installation advanced 202 terminals (ASCII) setting communications options 56, 317 tmp resource 246 defined 246 defining 246 overview 246 troubleshooting 92 boot problems 89 introduction 89 procedure 90 cleaning up failed optional software installation introduction 22, 332 full /usr file system 92 installation from system backup (mksysb) 85 resolving reported problems 86 introduction 85, 274 network boot problem 299 client and server, establishing network communication 299 obtaining the boot image from the server 299 running the boot image on the client 300 nonprompted mode, overriding 90 producing debug output 301 producing debug output from a network boot image 302 BOS install program 302 prompted mode, changing to 90 troubleshooting procedures recovering /etc/niminfo file 186
unconfiguring master 139 Universal Disk Format 311 update operation 267 update_all install_all_updates command 328 SMIT fast path 326 updateios operation 268 updates, service explanation of 322 User Specified Installation Location (USIL) user volume group backing up 312 definition of 304 USIL 60 USIL connector ODM class object 63 Using Activation Engine 32 using Graphical Install menus 45 using the iSCSI configuration menus 64
60
V
Value 237 Virtual I/O Server using NIM installing 167, 169 migrating 155 volume groups accessing 89 introduction 89 procedure 90 backing up 20, 306, 312 nonroot 304 root 92, 304 user 304
W
warning messages NIM 274 Web-based System Manager 379 BOS installation 317 windows Change Disk(s) Where You Want to Install (BOS) Installing Base Operating System (BOS) 59, 371 WPAR 111, 112, 113, 114 detached installing and managing software 216 wpar_spec resource 245 defining 245 overview 245
57
U
unconfig operation 267 Index
413
414
Printed in USA