Sun Java System Access Manager 7 2005Q4

Sun Java™ System Access Manager 7 2005Q4 Patch Release Notes

AM7.0patch1 Release Date: Dec/21/2005

Contents

Pre-Installation Considerations

This document applies to the following Access Manager 7.0 2005Q4 platforms and their respective patch IDs:

The Access Manager patches described in this document do not install Access Manager. Before you install a patch, Access Manager 7 2005Q4 must be installed on the server. For information, see the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX:
http://docs.sun.com/doc/819-2328

For a list of the Access Manager patches that are made obsolete by this patch and any patches that you must install before you install this patch, refer to the README file included with this patch.

Caution These patches (as with any other patches) should be tested on a staging or pre-deployment system before you put them into a production environment. Also, the patch installer might not update your customized JSP files properly, so you might need to make manual changes in these files in order for Access Manager to function properly.

Back to Top

Patch Installation Instructions

Before you install a patch, backup the following files:

where AccessManager-base is /etc/opt/SUNWam on Solaris systems and /etc/sun/identity on Linux systems.

To add or remove a patch use the patchadd and patchrm commands, which are provided with the Solaris OS.

patchadd Command

The following example installs a patch on a standalone machine:

# patchadd /var/spool/patch/120954-01

When the post patch script is executed, the following message will be printed (Except on a system that has only Access Manager SDK component installed):

After patch installation, please redeploy AM applications by following the release notes (120954-01/rel_notes.html#3). A draft amsilent file is created in /tmp directory.

This amsilent is based on $INSTALL_DIR/bin/amsamplesilent, but with some required parameters set according to the AM config files on this system.

The password parameter values in /tmp/amsilent contain default values. Please uncomment and modify the value of each password parameter, and carefully check and make sure the accuracy of other parameters in this file. Then run command

# cd $INSTALL_DIR/bin
# ./amconfig -s /tmp/amsilent

patchrm command

The following example removes a patch from a standalone system:

# patchrm 120954-01

When the post backout script is executed, a similar message will be printed (Except on a system that has only Access Manager SDK component installed):

After patch is removed, please redeploy AM applications by following the release notes (120954-01/rel_notes.html#3). A draft amsilent file is created in /tmp directory.

This amsilent is based on $INSTALL_DIR/bin/amsamplesilent, but with some required parameters set according to the AM config files on this system.

The password parameter values in /tmp/amsilent contain default values. Please uncomment and modify the value of each password parameter, and carefully check and make sure the accuracy of other parameters in this file. Then run command

# cd $INSTALL_DIR/bin
# ./amconfig -s /tmp/amsilent

For additional information and examples about the patchadd and patchrm commands, see the appropriate man pages.

Solaris 10 Zones

The Solaris 10 operating system introduced the new concept of "zones." Consequently, the patchadd command includes the new -G option, which adds a patch only to the global zone. By default, the patchadd command looks for the SUNW_PKG_ALLZONES variable in the pkginfo of packages to be patched. However, for all Access Manager packages, the SUNW_PKG_ALLZONES variable is not set, and the -G option is required if Access Manager 7 2005Q4 is installed in the global zone. If Access Manager is installed in a local zone, the patchadd -G option has no effect.

If you are installing Access Manager 7 2005Q4 patches on a Solaris machine, it is recommended that you use the -G option. For example:

# patchadd -G AM7.0_patch_dir

Similarly, if Access Manager is installed in the global zone, "-G" option is required to run command "patchrm".

# patchrm -G 120954-01

Linux Platform

The following example installs a patch on a standalone machine:

# ./installpatch

When the postpatch script is executed, messages that will be printed are similar to the messages on a Solaris platform.

However, the procedure to back out a patch on a Linux platform is different than on a Solaris platform. There is no generic script to back out a Linux patch. If a lower version of the patch was previously installed, you can simply re-install that version and then follow the postpatch instructions to redeploy the Access Manager applications by running the amconfig script.

If the patch is installed on the Access Manager 7 2005Q4 RTM release and you want to remove the patch and restore the system to the RTM state, you must reinstall the Access Manager RTM bits using the reinstallRTM script. The reinstallRTM script takes the path where the Access Manager RTM RPMs are stored and installs the RTM RPMs over the patched RPMs. For example:

# ./scripts/reinstallRTM path_of_AM7.0_RTM_RPM_directory

After you run the reinstallRTM script, redeploy the Access Manager applications by running the amconfig script.

Back to Top

Known Issues and Limitations

Caution If any of the files in the current installation are customized, back up those files before you install the patch. After you install the patch, compare the backed up files with the new files installed by this patch to identify the customizations. Merge the customizations with the new files and save them. For more information about how to handle customized files, read the following information.

Bug# 6254355: Access Manager patches do not redeploy Access Manager applications in postpatch scripts

Due to complexity of updating customized content of several WAR files deployed on a web container, the patch installer might not preserve some of the customized files, replacing them with non-customized versions. To help you identify and then manually update the customized contents of a WAR file, read the following quick guide.

There are multiple ways to modify WAR files:

$BASEDIR applies to /opt and $PRODUCT_DIR applies to SUNWam on Solaris systems. On Linux systems, $BASEDIR applies to /opt and $PRODUCT_DIR applies to /sun/identity.

The WAR files that get modified are:

The changeable content in a WAR file includes:

These files are in the following directories:

To update the WAR files:

# cd $BASEDIR/$PRODUCT_DIR
# jar -uvf amconsole.war <$path/$modified file>
# jar -uvf amservices.war <$path/$modified file>
# jar -uvf ampassword.war <$path/$modified file>

Here is an example:

# cd /opt/SUNWam
# jar -uvf amconsole.war index.html
# rm index.html

Workaround for Problem 6254355

The following workaround is for the issue described in problem 6254355. Follow these steps to make sure that all custom changes are properly preserved.

Note The steps below should preserve custom changes in most cases. However, if the changes are not preserved, use the technique described above.

  1. Make sure all your customized JSP files reside in the proper subdirectories under the $BASEDIR/$PRODUCT_DIR/web-src/ directory and that you have backed up all of your customized files.
  2. Install the patch.
  3. Check whether the patch installer made any changes to your customized JSP files in the $BASEDIR/$PRODUCT_DIR/web-src/... directories and manually add your original custom changes to the ones that got changed.
  4. Create a silent configuration file (for example, amsilent) based on the $BASEDIR/$PRODUCT_DIR/bin/amsamplesilent template file and then set the appropriate configuration variables in the file, including:
    •DEPLOY_LEVEL=21
    •DIRECTORY_MODE=5
    •Passwords for DS_DIRMGRPASSWD, ADMINPASSWD, and AMLDAPUSERPASSWD
    •Access Manager Web container variables.

    For more information about the Web container variables, see the amsamplesilent file in the /opt/SUNWam/bin directory on Solaris systems or the /opt/sun/identity/bin directory on Linux systems.
  5. Run the amconfig script as shown below. Before you run amconfig, Directory Server and the Access Manager web container must be running. For example, to run amconfig on a Solaris system with Access Manager installed in the default base installation directory:

# cd /opt/SUNWam/bin
# ./amconfig -s ./amsilent

For more information about running the amconfig script, see the Access Manager Administration Guide:
http://docs.sun.com/doc/819-2137

Bug# 6320475: com.iplanet.am.session.client.polling.enable on server side must not be true

The com.iplanet.am.session.client.polling.enable property in the AMConfig.properties file on the server side is set to false by default and should never be reset to true.

Debug files

All the debug files are created by default under the debug directory even when com.iplanet.services.debug.level property in the AMConfig.properties file is set to error. Before 7.0 Patch 1, a debug file is created only when the first debug message is logged to that file.

Bug# 6358751: AM70patch1 apply fails if the there are embedded spaces in the encryption key

The workaround is to use a new encryption key that includes no spaces. For detailed steps of changing the encryption key, please see Changing the Password Encryption Key for an Installation of Sun Java System Access Manager 6 2005Q1 Deployment Planning Guide.

Bug# 6361191: Trouble to deploy the war of Distributed Authentication on BEA WebLogic

The Distributed authentication war file generated by the DistAuth Make file throws 404 error, when deployed on BEA WebLogic. The reason is that WebLogic expects the war file name as the same as the deploy URI (It is not the case with the other servers, such as S1AS and S1WS).

The workaround is to modify the file Makefile.distAuthUI by changing the following line 

NEW_WAR_NAME=amauthdistui_deploy.war
to 
NEW_WAR_NAME=$(DISTAUTH_DEPLOY_URI).war

Back to Top

Copyright 2005 Sun Microsystems, Inc. All rights reserved.