Pre-installation Considerations
For a list of Access Manager patches that are obsoleted by
this patch, and any patches you must install prior to installing this patch,
refer to the included patch README. This patch is not a standalone installation
and does not include Access Manager 6.2. Access
Manager 6.2 must be installed prior to patch installation. Please note that this
document is applicable to all Access Manager 6.2 supported platforms with following patch IDs:
- Solaris Operating System (Solaris OS) on SPARC® based system - 115766
- Solaris OS on x86 platforms - 120091
- Linux systems - 119409
It is important that this patch, as with any other patch, be tested thoroughly on a
staging or pre-deployment system prior to being put into production.
Additionally, special care should be taken in regards to some customized JSP
files. Due to the nature and complexity of some modifications, the patch
installer might fail to update some of those files properly, so manual changes
might be required in order for the product to continue functioning normally.
Back to top
Patch Installation Instructions
Backup following files:
- amamAdminConsole.xml
- amAuth.xml
- amAuthSafeWord.xml
- amProviderConfig.xml
- amAdminCLI.properties
- amAdminModuleMsgs.properties
- amAuth.properties
- amAuthSafeWord.properties
- amAuthUI.properties
- amProviderConfig.properties
- AMConfig.properties
- Login.jsp
- membership.jsp
- new_org.jsp
For the Solaris 8 and 9 releases, refer to the man pages for instructions on using the patchadd and patchrm commands provided with the Solaris OS. Any other special or non-generic installation instructions should be described below as special instructions. The following example installs a patch to a standalone machine:
# patchadd /var/spool/patch/115766-11
When the post patch script is executed, it will ask one to three questions about the server instance path. If Access Manager is running on Web Server, you will be asked this question:
What is the path of the WS 6.1 instance [/opt/SUNWwbsvr/https-hostname.domainname] ?
If Access Manager is running on Application Server, the following question will be asked:
What is the path of Application Server instance [/var/opt/SUNWappserver7/domains/domain1/server1] ?
When Access Manager is running on Application Server, if the Access Manager applications are redeployed multiple times, the application root path can vary. In this case, you will be asked to input the correct path to the deployment directory of application /amserver and /amconsole:
What is the path of the deployment directory of /amserver [/var/opt/SUNWappserver7/domains/domain1/server1/applications/j2ee-modules/amserver_1] ?
What is the path of the deployment directory of /amconsole [/var/opt/SUNWappserver7/domains/domain1/server1/applications/j2ee-modules/amconsole_1] ?
Besides the above, there are two more questions to be asked:
What is the dn of the Directory Manager [cn=Directory Manager]
What is the password for the Directory Manager []
Restart Access Manager after the patch is installed successfully.
The following example removes a patch from a standalone system:
# patchrm 115766-11
For additional examples please see the appropriate man pages.
Back to top
Known Problems and Limitations
This section describes known problems while applying the patch and associated
workarounds for Access Manager.
- If any of the files are customized in the current installation,
back up those customized files. Compare the contents of the backed up files
with the contents of the new files installed by this patch to identify the
customizations done. Merge the customizations with the new files and save them.
Please carefully read the following step 2 and 3 for more info on how to deal with customized files.
-
Bug# 6254355: 6.2 patches should redeploy AM applications in postpatch scripts
Due to complexity of updating customized content of several WAR files deployed
on a web container, the patch installer might fail to preserve some of customized
files replacing them with non-customized versions.
- Please read this quick guide, which will help you identify and manually update customized content of a WAR file.
There are multiple ways to modify WAR files:
- Edit files under $BASEDIR/$PRODUCT_DIR/web-src/applications/.
- Modify the JSPs associated with the Access Manager custom admin console,auth modules, services, etc.
- Modify resource bundles/property files in the WAR file.
Note: $BASEDIR generally 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:
$BASEDIR/$PRODUCT_DIR/amconsole.war
$BASEDIR/$PRODUCT_DIR/ampassword.war
$BASEDIR/$PRODUCT_DIR/amservices.war
Changeable content in a WAR file:
- Properties files ($BASEDIR/$PRODUCT_DIR/locale/*.properties)
- Tag library descriptors $BASEDIR/$PRODUCT_DIR/web-src/applications/WEB-INF/*.tld)
- The web.xml file and the files used to construct it (WEB-INF/web.xml and WEB-INF/*.xml)
- Application specific files :
- JSP files (*.jsp)
- images(*.gif)
- stylesheets - background colors,font size etc.,(*.css)
from the following directories:
$BASEDIR/$PRODUCT_DIR/web-src/applications/console/
$BASEDIR/$PRODUCT_DIR/web-src/services/
$BASEDIR/$PRODUCT_DIR/web-src/password/
How 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
- The following workaround is for the issue described in 6254355.
These are the steps to follow in order to make sure all custom changes are properly preserved.
Note: The steps below should be able to preserve custom changes in most cases. In a
case where the changes are not preserved, use the technique explained in step 1.
1. Make sure all your customized JSP files reside in proper subdirectories under
$BASEDIR/$PRODUCT_DIR/web-src/ and you have made a backup of all your
customized files.
2. Install the patch.
3. Check whether the patch installer made any changes to your customized JSP files in
$BASEDIR/$PRODUCT_DIR/web-src/... directories and add your original custom
changes manually to the ones that got changed.
4. Create the amsilent file based on $BASEDIR/$PRODUCT_DIR/bin/amsamplesilent template file and
also set the appropriate configuration variables, including:
- DEPLOY_LEVEL=21
- DIRECTORY_MODE=5
- Passwords for DS_DIRMGRPASSWD, ADMINPASSWD, and AMLDAPUSERPASSWD
- Access Manager Web container variables. For more details 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/817-7647
-
In a case where auth JSP files have been customized, special care should be
taken. Starting with Access Manager 6.2 Patch4, the 'goto' functionality for suborganizations
could be broken:
Bugs# 6237056/6294941: Applying patch 04 breaks 'goto' functionality in Access Manager 6.2
It is advisable to backup all customized JSP files in
<install_dir>/SUNWam/web-src/services/config/auth/default/ directory
before applying the patch.
After patch installation complete, note the differences
(diff utility can help
you identify those) between backed up JSP files and the
new ones installed/modified by the patch. When it comes to updating multiple JSP
files in the above directory, the current patch installer might fail to properly
identify and update several manually customized JSP files. In order to make sure
the 'goto' functionality is not broken in those files, the hidden 'goto' parameter:
<input type="hidden" name="goto" value="<%= request.getParameter("goto") %>">
should be added to all JSP files that use <auth:form> tags. For example:
<auth:form name="Login" method="post" defaultCommandChild="DefaultLoginURL" >
<script language="javascript">
if (elmCount != null) {
for (var i = 0; i < elmCount; i++) {
document.write("<input name=\"IDToken" + i + "\" type=\"hidden\">");
}
document.write("<input name=\"IDButton" + "\" type=\"hidden\">");
}
</script>
<input type="hidden" name="goto" value="<%= request.getParameter("goto") %>">
</auth:form>
- Bug# 5013729: Policy state is made inconsistent after the Policy Service is deleted.
A new option "--cleanpolicyrules" is supported while removing services using amadmin.
Here is an example:
# amadmin --runasdn "admindn" --password password -r ServiceName --cleanpolicyrules
If the option "--cleanpolicyrules" is passed while removing the service, policy rules
defined for the <ServiceName> are removed along with the service.
- Bug# 5060050: Unable to upgrade Portal in Access Manager/Portal Server separated configuration.
To set propertiesViewBeanURL in a service configuration, do the following:
- Create an XML file that contains:
<!DOCTYPE Requests
PUBLIC "-//iPlanet//Sun Java System Access Manager Admin CLI DTD//EN"
"jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<Requests>
<SchemaRootNodeRequests serviceName="$SERVICE_NAME">
<SetPropertiesViewBeanURL url="$NEW_URL" />
</SchemaRootNodeRequests>
</Requests>
Please replace $SERVICE_NAME with the service name of the service configuration; and replace $NEW_URL with the URL for the propertiesViewBeanURL of this service.
- Execute the amadmin command line tool:
#cd $BASEDIR/$PRODUCT_DIR/bin
# ./amadmin -u amadmin -w password --data xml-file
where $BASEDIR/$PRODUCT_DIR is the directory where Access Manager is installed, password is the password of the amadmin user,
and xml-file is the XML file that you have created in step 1.
-
Bug# 6175850: 6.2 Patch: Server Error on federating again after terminate federation
The workaround is that the user either logs out or restarts the browser.
-
Bug# 5107381: Cert auth no longer searches recursively to locate users
Change the 'People Container for All Users:' attribute value in the 'Core' auth service configuration, under default org from "ou=People,ROOT_SUFFIX" to "ROOT_SUFFIX"
For example: ROOT_SUFFIX=dc=red,dc=iplanet,dc=com
Bug# 6276972: Delay in Access Manager 6.3 failover to secondary LDAP directory Add the following VM option to the server.xml file for the specific web
container and restart the web container: <JVMOPTIONS>-Dnetworkaddress.cache.ttl=0</JVMOPTIONS>
<JVMOPTIONS>-Dsun.net.inetaddr.ttl=0</JVMOPTIONS>
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.
Back to top
|