Before performing the following steps, you should:
Ensure that the following requirements are met for the control workstation:
/usr/lpp/ssp/bin /usr/sbin /usr/bin /usr/lpp/ssp/kerberos/bin
The following is an example of root user path in the .profile:
PATH=/usr/lpp/ssp/bin:/usr/sbin:/usr/lpp/ssp/kerberos/bin
Ensure that the following requirements are met for the boot/install servers:
Note that you should not reconfigure your system in any way during the migration process. For example, do not add a frame, switch, node, or any other piece of hardware to your system until after the migration process has completed. In addition, you should not add or delete any host names or IP addresses until after the migration process has completed. This will help to ensure a successful migration. For more information on reconfiguring your system, refer to Chapter 6, Reconfiguring the RS/6000 SP system.
As of PSSP 3.1, job management functions previously provided by the PSSP Resource Manager have been added to the LoadLeveler product. The switch table management for user space parallel jobs previously provided by the PSSP Resource Manager has been moved to a new PSSP file set ssp.st, Job Switch Resource Table Services. Depending on how you currently use the Resource Manager, see the PSSP: Administration Guide for more information on how maintain the same functionality.
The Resource Manager daemons have been removed from PSSP 3.1. The ssp.jm and ssp.clients file sets still contain the commands and library necessary to support back-level system partitions from the control workstation. The ssp.jm file set is no longer automatically installed by pssp_script. If you want to support back-level system partitions, you need to install the ssp.jm file set on the control workstation. Previous releases of the Resource Manager will not be automatically removed from the nodes being migrated. To regain file system space and prevent incompatibilities, it is recommended that the ssp.jm file set be deinstalled from all nodes.
The PSSP Job Switch Resource Table Services provide a way to load, unload, clean, and query Job Switch Resource Tables. The ssp.st file set is installed by pssp_script. LoadLeveler uses these services when scheduling and starting user space jobs.
When migrating your system, IBM strongly suggests that you should continue using whatever authentication method you presently have. After your migration is complete, you can then change your authentication method. Refer to Chapter 5, Reconfiguring security for information on changing your security settings. If you have PSSP 3.1 installed with DCE, see the exception recommended in Step 5.1: Migrating a PSSP 3.1 system configured with DCE.
PSSP 3.1 supported a limited implementation of DCE at DCE 2.2 or later. If your system was set up to use this implementation, your security attributes would look similar to the following:
splstdata -p List System Partition Information ... auth_install k4 auth_root_rcmd k4 auth_methods k5:k4:std
If your system is configured as shown in the preceding example, there are additional node migration considerations that you must take into account. PSSP supports migration of a PSSP 3.1.1 DCE implementation to |PSSP 3.4 using a BOS Node Upgrade. (See BOS node upgrade.) However, once the migration is complete, you must take additional steps before you can perform a mksysb install of a |PSSP 3.4 node. For example, if you are installing a new node or reinstalling a migrated node.
|PSSP 3.2 or later requires that if auth_methods includes k5, DCE must be installed on the node before psspfb_script sets the authentication methods during the install process. If you choose to migrate using a mksysb install of nodes, this same rule applies. This requirement also existed for PSSP 3.1, so you may have already implemented a process to do mksysb installs.
If you want to maintain your PSSP 3.1 k5 security settings with |PSSP 3.4, you will need to add code to your |/tftpboot/script.cust file to do a mksysb install of a |node. This file is documented in Step 61: Perform additional node customization and in Appendix E, User-supplied node customization scripts. The new code in script.cust will need to mount the directory containing DCE and install your required DCE clients.
Alternatively, you can use PSSP to install DCE during the mksysb install of the node. This is done by issuing the spsetauth -i command to change the auth_install security attribute to include DCE. You will need to ensure that DCE is at 3.1 or later on the control workstation and that your AIX lppsource contains the DCE file sets. |See mksysb install of nodes for detailed instructions.
|PSSP 3.4 provides the ability to remove the dependency PSSP has on |the rsh and rcp commands issued as root by enabling the use |of a secure remote command method. It is the administrator's |responsibility to choose the secure remote command software and install it on |the control workstation.
|All nodes must be at PSSP 3.2 or later and RRA must be |enabled before the secure remote command method can be enabled.
|Refer to RS/6000 SP: Planning, Volume 2, Control |Workstation and Software Environment for additional |information.
|Boot/install server nodes, other than the control workstation, |require rsh and rcp capabilities to use NIM services. |It is up to the administrator to add the authorization methods necessary for |boot/install activities.
|If additional files must be copied to the nodes during the installation |process with secure remote command and restricted root remote commands |enabled, the firstboot.cmds sample file gives examples of how |to enable the copy from the control workstation to the nodes in the restricted |access environment and secure remote command enabled environment.
|The LoadLeveler Central Manager node must be migrated to PSSP |3.4 before migrating any other LoadLeveler nodes. Refer to |Installation Memo for IBM LoadLeveler, GI10-0642, and IBM |LoadLeveler for AIX 5L: Using and Administering for additional |information on migration considerations.
Some of the subsystems managed by the Syspar Controller (syspar_ctrl) allocate port numbers from the range 10000 to 10100, inclusive. Therefore, if any customer subsystem, such as DB2, uses port numbers in this range, such port numbers must be reserved in /etc/services. For details, refer to Appendix G, Reserving ports.
|PSSP 3.4 has prerequisites for several runtime files from the |VisualAge C++ product. If you have this product installed, you may need |to update it to the current service levels either before or during your |migration. See Step 13: Copy the PSSP images for PSSP 3.4 for detailed information.
You should archive the SDR at its current level by issuing the SDRArchive command:
SDRArchive append_string
where append_string is the name you want to use for this archive. If you specified the append_string, it is appended to the name of the backup file /spdata/sys1/sdr/archives/backup.JulianDate.HHMM.append_string.
|As of PSSP 3.2, the SDR is NLS enabled and allows non-ASCII |data to reside in the SDR if that is how you have your site environment set |up. See Step 30: Enter site environment information for more information on setting up your site |environment. However, if you are migrating your control workstation |from PSSP 2.4 or PSSP 3.1 to PSSP 3.4, you must ensure |that only ASCII data resides in the SDR and that the locale on your machine is |set to en_US or En_US, otherwise the migration will |fail. Only the en_US and En_US locales are supported |for PSSP 2.4 and PSSP 3.1. You must remove all non-ASCII |data from the SDR and set your locale to en_US or En_US |before migrating from PSSP 2.4 or PSSP 3.1 to PSSP |3.4.
|PSSP provides an SDRScan utility to determine whether |non-ASCII data is present in your SDR. SDRScan was shipped in |the ssp.basic file set with PSSP 2.4 PTF Set 27 (APAR |IY23244) and with PSSP 3.1.1 PTF Set 21 (APAR IY23701). |If this utility is installed on your system at |/usr/lpp/ssp/bin/SDRScan, you can run the command to determine if you |have non-ASCII data in your SDR:
|SDRScan
|All SDR objects containing non-ASCII data will be written to |standard output.
|If the SDRScan utility is not available on your system and |you think you may have non-ASCII data in your SDR, you will need to manually |determine the presence of this data. You can do this by running the |SDRGetObjects command for the classes you suspect may have non-ASCII |data and visually inspect the results:
|SDRGetObjects class_name
|All non-ASCII data must be removed from the SDR. The method |to do this will depend on the attributes and classes that contain the |non-ASCII data. You will need to use the appropriate PSSP commands to |modify the data.
|When migrating from PSSP 2.4 or PSSP 3.1 to PSSP |3.4, you must also have the default locale on your control workstation |set to en_US or En_US. You can verify this by viewing |the LANG stanza in the /etc/environment file and ensuring it is set |to one of these values.
Before you migrate your system, you should always make a backup of your existing system. The following list provides you with a basic set of instructions for backing up your system:
mksysb -i /dev/rmt0
You should keep backup copies of critical files and file systems that have configuration data in them. For example, you should back up the /spdata file system. Use the tar command to save critical files and use the backup command to save file systems.
For AIX 4.1 and later systems, you may choose to back up the volume group by issuing the savevg command. For example, to save the spdatavg volume group, you could issue the following command:
savevg -f /dev/rmt0 -i spdatavg
You may want to export your nonroot volume groups immediately prior to the AIX migration. This will undefine the volume group from the system during the AIX migration. For example, you may want to export the spdatavg volume group by issuing the following commands:
umount /spdata (unmount the file system) varyoffvg spdatavg (vary off volume group) exportvg spdatavg (export volume group)
Once the AIX migration is complete, you will need to import any volume group that you previously exported. For example, to import the spdatavg volume group, issue the following command:
importvg -y spdatavg -V major # hdisk
Whether you made the backup to a file or a tape, verify that the file exists on the medium.
After backing up the control workstation in the last step, you should make a backup of your nodes. The following list provides you with a basic set of instructions for backing up your nodes.
mksysb -i /dev/rmt0