Content

1.       What’s new

This release enhances authentication and communication between NIM masters and NIM clients. The following security enhancements are included for Network Installation Management (NIM) secure (nimsh) communication:

 

Note: IBM recommends that you upgrade all NIM masters and NIM clients to the latest supported Security Service Pack or to the latest supported Service Pack that includes these NIM security enhancements. This ensures compatibility and access to the latest security updates.

2       Upgrading the NIM master and NIM clients

In environments that use NIM secure (nimsh) communication, follow this upgrade sequence:

2.1       Remove NIM security interim fixes (Optional)

2.2       Upgrade or migrate NIM clients

2.3       Upgrade the NIM master

2.4       Confirm that communication is restored

Note: Starting with these Security Service Pack (SP) levels, upgrading the NIM master before upgrading the NIM clients might temporarily disrupt secure nimsh communication because of updates to the secure nimsh protocol. Secure communication is automatically re-established after the clients are upgraded to compatible service levels.

Important: Upgrading NIM clients before you upgrade the NIM master is the recommended sequence to preserve uninterrupted nimsh communication; however, this sequence is not mandatory. If the NIM master is upgraded first, or if some clients remain at an earlier service level, secure nimsh communication with those clients is unavailable during the transition period. This does not have any other adverse effects. Secure communication can be restored at any time by reconfiguring the affected clients after both the NIM master and clients are running compatible service levels.

2.1      Remove NIM security interim fixes (Optional)

If a NIM security interim fix (iFix) is installed and the target Technology Level (TL) or SP includes the same fix, remove the interim fix registration before you start the update. 

This removes the iFix registration but keeps the updated files that are included in the iFix.

• To remove an iFix from a client, run the following command: 

  emgr -FR <ifix_label>

• To remove an iFix by using NIM script resource, complete the following steps:

               1. Create the script:

#!/bin/ksh
emgr -FR <ifix_label>

               2. Define the script resource:

nim -o define -t script \
-a server=master \
-a location=<script_path> \
<script_resource>

             3. Run the script resource:

nim -o cust \
-a script=<script_resource> \
<client_name>

2.2      Upgrade or migrate NIM clients

Upgrade all NIM clients to the most recent supported Technology Level (TL) or Security Service Pack (SP) before proceeding with the NIM master upgrade. For the recommended upgrade commands, see Recommended upgrade methods.

2.3      Upgrade the NIM master

Once all NIM clients have been upgraded, proceed with upgrading the NIM master.

If a NIM client is upgraded before the NIM master, the nimclient -c command that runs during the client's initial boot cannot complete successfully. To handle this condition, the client automatically creates a temporary cron job that retries nimclient -c every minute until the NIM master is upgraded and certificate registration completes successfully.

Once certificate registration is successful, the client automatically removes the cron job and re-establishes secure nimsh communication.

If the temporary cron job is removed before certificate registration is completed, run the following command on the client after the NIM master has been upgraded:

nimclient -c

2.4      Confirm that communication is restored

Secure NIM (nimsh) communication is automatically restored once the NIM master and all NIM clients are running compatible Service Pack levels. If communication remains unavailable, refer to  Troubleshooting. 

3       Verifying NIM secure communication

After you upgrade the NIM master, run one of the following commands to verify communication with each client.

nim -o lslpp <client_name>

nim -o showlog <client_name>

nimclient -l

nimclient -d

If the command completes successfully, secure NIM (nimsh) communication is established between the NIM master and the client.

4       Troubleshooting

If secure nimsh communication is not automatically restored after the NIM master and all NIM clients have been upgraded to compatible Security Service Pack levels, perform the following troubleshooting steps:

4.1      Refresh certificates

• On the NIM master, run the following command:

nimconfig -c

• On the NIM client, run the following command: 

nimclient -c

The "nimclient -c" command performs the following:

1. Generates a new Certificate Signing Request (CSR)

2. Sends the CSR to the NIM master

3. Retrieves the signed certificate

4. Re-establishes secure nimsh communication

4.2      Verify communication

After the commands complete successfully, run any of the following commands to verify the communication:

nim -o lslpp <client_name>
or
nim -o showlog <client_name>

4.3      Further checks

If communication is still not restored, check the following:

• Network connectivity between the NIM master and NIM client
• nimesis daemon status by running the command:

lssrc -s nimesis

• nimsh daemon status by running the command: 

lssrc -s nimsh

• Certificate configuration on both systems
• Firewall and network policies 
• DNS name resolution
• System time synchronization on both systems

5       High availability considerations 

After you upgrade both the primary and alternate NIM masters, refresh certificates on both High Availability (HA) masters[MC1] .

Refresh certificated on Secure nimsh:

nimclient -c

Refresh certificates on Traditional nimsh:

nimclient -c

6       nimadm Considerations

These Security Service Packs include the secure NIM (nimsh) communication enhancements. During the transition period IBM recommends customers use these Security Service Packs until all NIM masters and clients have been upgraded to compatible Security Service Pack levels.

The recommended upgrade sequence affects environments using nimadm. 

The nimadm command has the following requirements:

• NIM master operating system level must be equal to or greater than the migration target level. 

• The bos.alt_disk_install.rte file set in the SPOT must match the NIM master level.

If either requirement is not met, initialization fails.

The following example shows the error that is returned when the NIM master is at a lower level than the migration target:

0505-175 nimadm:
The operating system release of the NIM master is lower than the migration target.

Master: 7.3.4.0

Target: 7.3.4.2

Note: Do not use nimadm during the transition period. Because the NIM master must remain at an earlier Service Pack level until all NIM clients are upgraded, nimadm is not supported until all systems reach compatible Service Pack levels.

For supported upgrade methods during the transition period, see  Recommended upgrade methods.

7       Recommended upgrade methods

Use one of the following methods to apply TL or SP updates:

7.1      NIM alt_disk_install

Installs the update to an alternate disk. After installation, the system reboots from the updated disk. The original disk is preserved and can be used as a fallback if needed.

Run the following command: 

nim -o alt_disk_install \
-a source=rootvg \
-a disk=hdisk1 \
-a lpp_source=<lpp_source> \
-a fixes=update_all \
-a boot_client=yes \
-a installp_flags="-acNgXY" \
<client_name>

7.2      AIX Live Update

AIX Live Update applies Technology Level and Service Pack updates to the running system with minimal downtime. No alternate disk is required.

Note: Test Live Kernel Update (LKU) functionality in a nonproduction environment before using it on production systems. 

Note: Because LKU applies the update on the running rootvg and communication may be interrupted after the NIM binaries are updated, a communication error or non 0 return is expected at the end of the operation. Check the FAQ for more information.

To apply the update, run the following command:

nim -o cust \
-a live_update=yes \
-a live_update_data=<resource> \
-a lpp_source=<lpp_source> \
-a filesets=update_all \
<client_name>

To preview the update without applying changes, run the following command:

nim -o cust \
-a live_update=yes \
-a installp_flags="-p" \
-a live_update_data=<resource> \
-a lpp_source=<lpp_source> \
-a filesets=update_all \
<client_name>

7.3      Operating system migrations

For operating system release migrations, such as migrating from AIX 7.2 to AIX 7.3, you can only go TO pre-update levels before the NIM master is updated and after the NIM server is updated you can only go TO compatible levels via the “bos_inst” method. 
For the NIMADM method you can only go FROM pre-update TO pre-update levels before the NIM master and only FROM compatible TO compatible levels after the NIM master is updated. 

8       Communication during the transition period

The transition period begins when you start upgrading NIM clients and ends when the NIM master and all NIM clients are running compatible Service Pack levels.

8.1 Clients upgraded before the NIM master

An earlier-level NIM master might be unable to communicate with upgraded clients until the master is upgraded. Secure communication is automatically restored after the NIM master upgrade is completed.

8.2 NIM master upgraded before all clients

Communication between the NIM master and clients running earlier service levels might be temporarily interrupted. As a result, operations that require communication with the NIM master can experience delays. For example, commands such as shutdown -Fr might take longer to complete while the client attempts to establish communication with the NIM master during shutdown.

Note: To minimize service disruption, IBM recommends upgrading all NIM clients to the latest supported service level before upgrading the NIM master. 

If you must upgrade the NIM master before all NIM clients are upgraded, avoid running operations that require communication between the NIM client and the NIM master, including nimclient commands, until both systems are running compatible service levels.

If a client must be operated independently during the transition period, you can temporarily remove the /etc/niminfo file from the client and stop the “nimsh” service (stopsrc -s nimsh). Removing this file prevents NIM client operations from attempting to communicate with the NIM master.

Before removing the file, ensure that the client no longer requires communication with the NIM master. After the NIM master has been upgraded, reinitialize the client using the appropriate NIM client initialization procedure to restore normal NIM management.

9       Frequently asked questions

For answers to common questions about this release, see the NIM security FAQ on IBM Support: https://www.ibm.com/support/pages/node/7282482