A.7 Troubleshooting an Access Gateway Appliance Upgrade

A.7.1 After You Migrate from SLES 9 to SLES 11, the Health Status Indicates That the Embedded Service Provider Cannot Find the Keystores

If you failed to run the keystore cleanup script before migrating an Access Gateway Appliance from SLES 9 to SLES 11, the Embedded Service Provider of the Access Gateway cannot find its keystores. If you check the health status, the Embedded Service Provider displays a red status with the message that begins with the following:

The following error occurred during the embedded service provider configuration. Unable to read keystore: /opt/novell/devman/jcc/certs/esp/signing.keystore.

This message is followed by an exception.

The location of the keystores on the Administration Console for the Embedded Service Provider of the Access Gateway Appliance changed in Access Manager 3.0.1. The SLES 9 Access Gateway Appliance works with the keystores in either the old or the new location. However, the SLES 11 Access Gateway Appliance works only with the new location.

To run a script that moves the keystores to the new location:

  1. Back up your system.

    For instructions, see Backing Up the Access Manager Configuration in the Novell Access Manager 3.1 SP2 Administration Console Guide.

  2. Discover the device ID for the Embedded Service Provider of the Access Gateway Appliance.

    1. In the Administration Console, click Auditing > General Logging.

    2. In the Access Gateways section, view the IP address, then the ID number. The device ID for the Embedded Service Provider of Access Gateway begins with an idp-esp- prefix.

    3. Record all the device IDs for your Access Gateways.

  3. Log in to the primary Administration Console as root.

  4. Download the AM_31_SP2_LAG300_keystorePathScript.sh script from Novell Downloads.

  5. Enter the following command:

    AM_31_SP2_LAG300_keystorePathScript.sh

  6. Enter the IP address of your Administration Console machine.

  7. Enter the name of the Access Manager administrator.

  8. Enter the password for the administrator.

  9. Type the entry number for the device ID, then press Enter.

    The device ID is displayed with the name of the Access Gateway in parentheses.

  10. In the Administration Console, restart the Embedded Service Provider:

    1. Click Devices > Access Gateways.

    2. Select the Access Gateway.

    3. Click Actions > Service Provider > Restart Service Provider.

  11. Repeat Step 5 through Step 11 for each Access Gateway in the cluster that was first installed with Access Manager 3.0.

A.7.2 Embedded Service Provider Issues After Upgrading

After you upgrade to Access Manager 3.1 SP2, the health status might display ESP Halted or Server Not Responding errors. This issue might occur because both Tomcat 4 and Tomcat 5 RPMs are present in the system. To verify which versions are present, run the following command:

rpm -a | grep tomcat

If both the versions of Tomcat are found, then you need to kill the tomcat4 process manually:

  1. Log in as root.

  2. Specify the following command to stop JCC:

    /etc/init.d/novell-jcc stop

  3. Specify the following command to stop Tomcat 4:

    /etc/init.d/novell-tomcat4 stop

  4. Specify the following command to stop Tomcat 5:

    /etc/init.d/novell-tomcat5 stop

  5. Specify the following command to kill the Tomcat 4 process:

    rpm -e novell-tomcat4 --nodeps --noscripts

  6. Specify the following command to start Tomcat 5:

    /etc/init.d/novell-tomcat5 start

  7. Specify the following command to start JCC:

    /etc/init.d/novell-jcc start

    NOTE:You can verify that Tomcat 4 is removed by executing the following command:

    rpm -a | grep tomcat

A.7.3 Proxy Stops Responding after Trying to Upgrade with the Wrong Upgrade RPM

If you try to upgrade a SUSE Linux Enterprise Server (SLES) 9 Access Gateway Appliance with the SLES 11 RPMs, or a SLES 11 Access Gateway Appliance with the SLES 9 RPMs, the upgrade fails with an RPM level error. The error messages are logged in the /var/log/laguprade.log file. The Access Gateway Appliance goes into a non-responsive mode after the failed upgrade.

If this issue occurs, restart the machine and use the appropriate RPMs to upgrade your Access Gateway Appliance.

A.7.4 Pending Commands After an Upgrade

Occasionally during an upgrade, the response to an upgrade command is lost, even though the command succeeds. This results in a pending status for the command, and this status is never updated to success.

To clear a pending command:

  1. In the Administration Console, click Access Manager > Access Gateway.

  2. Click the Commands link.

  3. Select the pending command, then click Delete.

  4. Click Close.

A.7.5 After You Upgrade to Version 3.1, the New Alerts for Auditing Do Not Appear

If you upgrade your Linux Access Gateways from 3.0 SP4 to 3.1, the three new alerts for auditing (Failure in Audit, Stopping Services, Failure in Audit, Will lose events, but continuing services, and Failure in Audit, Server is offline) are not available. This issue is resolved in version 3.1 IR1 and later.

To solve this problem when the Access Gateway is not a member of a cluster, you need to trigger a reimport. For instructions on triggering the reimport, see “Triggering an Import Retry”.

If the Access Gateway is a member of a cluster, complete the following steps:

  1. Remove a member from the cluster.

  2. Verify whether the Access Gateway has the new alerts.

    In the Administration Console, click Devices > Access Gateways > Edit > Alerts > default.

  3. (Conditional) If the Access Gateway has the new alerts, add it to the cluster, then assign it to be the primary cluster member.

  4. (Conditional) If the Access Gateway does not have the new alerts, delete the Access Gateway from the Administration Console, reinstall the Access Gateway, add it to the cluster, then assign it to be the primary cluster member.

A.7.6 After Upgrading, the Access Gateway Health Status Indicates That It Is Waiting for a Policy Response

After upgrading to 3.1.2, you might see that the Linux Access Gateway health status is red and the following error message is displayed:

X Policy configure requests awaiting response

This indicates that the Embedded Service Provider (ESP) is waiting for the new timeout values from the Identity Server. To work around this issue, change a few configuration values for the Identity Server, apply the changes, then restart the server.

A.7.7 Upgrading the Access Gateway Appliance Randomly Stops the Embedded Service Provider

After upgrading, the Embedded Service Provider sometimes stops at the end of the upgrade process. When this happens, restart the Access Gateway. In the Administration Console, click Devices > Access Gateways, select the Access Gateway, then click Restart.