sun.com | 1-800-123-4000 | How To Buy | My Sun | Worldwide Sites |  |  |  |  |

Java Enterprise System Portal Server 6 2005Q1/2005Q4 Patch 12 Release Notes

Table of Contents
Pre-installation considerations Installation instructions Additional post-install steps for non-root installs Patch backout support on the Linux platform Template modifications Tips for customizing templates Required fixes for Access Manager tuning | Required branding corrections Re-registering the Proxylet Service in the Access Manager console Changes in the behaviour of the Communication Express Calendar channel Additional requirements for UWC Address Book Channel proxy authentication Template updates needed for MS Address Book Access Configuring Portal Server to Work with a Load Balancer that Performs SSL Termination Configuring Portal Server in SSL Mode
#### Pre-installation considerations For a list of Portal 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 Portal Server 6.3. Portal Server 6.3 must be installed prior to patch installation. It is important that this patch, as with any other, be tested thoroughly on a staging or pre-deployment system prior to being put in to production. Additionally, special attention should be given to JSP files you may have customised that must be modified by the patch installer in order to fix defects, and/or for the product to continue functioning normally. If the system on which the patch is to be installed is being upgraded from Java Enterprise System Portal Server 6 2004Q2 to Java Enterprise System Portal Server 6 2005Q1, the patch should be installed before running the upgrade scripts, upgradePS04Q205Q1 and upgradeSRA-04Q2-05Q1. Back to top
#### Installation instructions If the Portal Server installation contains more than one node including any mixture of platform nodes, Portal proxy nodes, and gateway nodes, then this patch should be applied on the platform nodes first, followed by all remaining nodes. Running different release levels on different nodes is not supported. Each node must be upgraded to the same revision. In a terminal window, become root. Ensure that all Portal services are running on the node on which you are installing the patch. Solaris™ Use the patchadd command to apply the patch. # patchadd 118952-12 Linux: Use the update command included in the patch contents to freshen the installed Portal RPMs. # ./update On Portal Server nodes, use the deploy command to deploy the updated web application. # <PS_INSTALL_DIR>/SUNWps/bin/deploy redeploy On Portal Server nodes, restart all the webcontainer instances to complete the patch install. Back to top
> #### Additional post-install steps for non-root installs A small number of files in this patch are new since the original product release. Because there are no existing files on which the patchadd command can base the owner and group of these files, they must be added with owner and group of root and sys respectively. If the system on which this patch has been installed is running as a non-root user, it may be necessary to manually change the ownership of these files after the patch has been installed so that they match the rest of the environment. As of the current patch revision, the complete list of files added across all revisions of the patch is:
>     /etc/opt/SUNWps/desktop/default/tld/wireless_ab.tld
>     /etc/opt/SUNWps/desktop/default/tld/wireless_cal.tld
>     /etc/opt/SUNWps/desktop/default/tld/wireless_socs.tld
>     /etc/opt/SUNWps/desktop/default/tld/wireless_mail.tld
NB. It may be necessary to change the ownership of these files back to root:sys prior to installing a future revision of the patch in order to avoid attribute verification errors. This is an unfortunate and unavoidable consequence of the limited support for non-root installs in the patchadd command. Back to top
#### Patch backout support on the Linux platform In order to provide an equivalent level of backout on the Linux platform as that available on the Solaris platform, the upgrade script uses the --repackage option to the rpm command. This creates backup rpm files of the installed Portal software at that point, including any customisations that have been made. The remove script can be used to rollback if the patch needs to be backed out. However, due to an unavoidable rpm bug, this backout functionality does not function correctly if the Portal Server was installed in a location other than the default. Under these circumstances it is necessary to restore the original rpm files before running the remove script, and then recover any overwritten customisations manually. The repackage process stores the rollback rpm files in the /var/spool/backup/118952-12 directory, which will be created if necessary. You should avoid deleting this directory, even if you are forced to remove the patch. Back to top
#### Template modifications Every attempt is made by the patch installer to both preserve customized template information. However, since the contents of the files cannot be accurately predetermined, any modified template files are backed up in the same directory as their updated counterparts with the patch name postfixed to the template name. For example, when a patch is installed on the Solaris platform: /etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer/Netlet/display.template would be backed up to /etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer/Netlet/display.template.pre118952-12. Check the patch README.118952-12 file for the full list of files modified by this patch. Back to top
#### Tips for customizing templates Because the Portal Server itself is so customizable, you should follow some precautions to ensure that any customizations made to the Portal Server are preserved after a product upgrade. First, set up a customized template directory if you have not already done so. While this directory could be an entire subset of the default template directory, it is advisable to only copy over those template files that you will be customizing. This particular scheme would then use the default directory as a 'base' for all templates and would help insure that customized templates are not accidentally overwritten when the default templates are modified. NOTE: Files in the default template directory should never be customized. To create a customized template directory: Create a directory at the same level as the /etc/opt/SUNWps/desktop/default/ on Solaris, or /etc/opt/sun/portal/desktop/default on Linux, with a new name such as mytemplates. In that directory, only copy the templates you need to modify in their proper directories. The other templates will be retrieved as needed from the default directory using Portal's own filelookup mechanism. Edit the templates in the mytemplates directory according to your own preference. Log into the administration console. Select the appropriate services configuration screen. For example, select View: Services to administrate the desktop service globally. Alternately, select an organization, and then View: Services to administrate the desktop service for that organization only. Expand the link next to Desktop under the Portal Server Configuration subheading on the left view pane Modify the Desktop Type field located on the right view pane from default to mytemplates. Select Save As a general rule of thumb, avoid modifying templates that have only a functional purpose rather than a look and feel purpose. One example of a template that should not need modifications is the NetletProvider/display.template. This template contains only JavaScript necessary for the launching of the Netlet. The contents of the Netlet Pop-up window should instead be customized by modifying the associated .properties file. The reason for this is that there could be a functional change in the product that would overwrite a customization done specifically to that particular template file. This example also exhibits why it is important to only keep customized files in the customized template directory. Back to top
#### Required fixes for Access Manager tuning The perftune now uses the amtune script supplied with Access Manager. However, for this to function correctly on Solaris, an Access Manager patch is required. The patchids are 119259-01 (sparc) and 119260-01 (x86). Alternatively, the following changes can be applied manually. Edit /opt/SUNWam/bin/amtune/amtune-as8, changing the line: $ECHO $ASADMIN_PASSWORD > $ASADMIN_PASSFILE to: $ECHO "ASADMIN_PASSWORD=$ASADMIN_PASSWORD" > $ASADMIN_PASSFILE Edit /opt/SUNWam/bin/amtune/amtune-env, changing the line: ASADMIN=$CONTAINER_BASE_DIR/bin/asadmin to: ASADMIN=/opt/SUNWappserver/appserver/bin/asadmin Back to top
#### Required branding corrections A small number of updates to the Portal Server branding are missing from Java Enterprise System Portal Server 6 2005Q1. Should you wish to apply those updates manually to avoid confusion, you can do so as follows. Access the amconsole For default org select the Services drop down menu Select Portal Desktop In the right panel select Edit xml directly In the xml file, change the brandImage2BgColor attribute to white (#ffffff) from yellow (#FBE249) Click on OK and then Save Select the Service Configuration tab Select Portal Desktop in the left pane Click on Edit XML Directly on the right hand side Search for 2004Q2 and replace it with 2005Q1 in all the instances of productName Click on Identity Management tab Select Portal Desktop in the left pane Click on Edit XML Directly on the right side Search for 2004Q2 and replace it with 2005Q1 in all the instances of productName Back to top
#### Re-registering the Proxylet Service in the Access Manager console After a system is upgraded from Java Enterprise System Portal Server 6 2004Q2 to Java Enterprise System Portal Server 6 2005Q1, the link to invoke the Proxylet rules will not appear until the Proxylet Service is reregistered as follows: For the default org, select Services from the View drop down list Select the Proxylet service and click Delete Clicking the Add button, select the Proxylet service in the right hand frame and click OK Back to top
#### Changes in the behaviour of the Communication Express Calendar channel The Launch Calendar link now opens the Communication Express page rather than directly opening the Calendar tab. The user must now manually navigate from the mail tab to the calendar tab. Back to top
#### Additional requirements for UWC Address Book Channel proxy authentication The fix for Bug Id 6211569 (UWC address book channel does not work with proxy auth) also requires Universal Web Client patch 118540-12 or later. After installing this patch, you will need to perform the following steps: # /opt/SUWNuwc/sbin/patch-config /opt/SUNWuwc/install/patch/<patchid> # /opt/SUWNuwc/sbin/install-newconfig /opt/SUNWuwc/install/patch/<patchid> Uncomment the following line in <UWC-deploy-path>/WEB-INF/config/uwcauth.properties and add the uid (or list of uids) of the proxy admin: !uwcauth.admins=<list of comma seperated admins> Once both patches are installed, you will need to add additional attributes to the SUN-UWC-ADDRESS-BOOK SSOAdapter template as follows: Authenticate to the Identity Server Administration Console Select Service Configuration Select SSO Adapter Select Edit Properties... for the SUN-UWC-ADDRESS-BOOK SSO Adapter template Select New Default... Specify enableProxyAuth for Name Specify true for Value Select Create Select New Default... Specify proxyAdminUid for Name Specify the proxy authentication Admin user id for Value Select Create Select New Default... Specify proxyAdminPassword for Name Specify the proxy authentication Admin user password for Value Select Create Select New Default... Specify userAttribute for Name Specify uid for Value Select Create Back to top
#### Template updates needed for MS Address Book Access The fix for Bug Id 6229250 (MS Address Book is not accessible on Portal Desktop) requires the following changes to be made to the SUN-ONE-ADDRESS-BOOK SSO Adapter template: Authenticate to the Identity Server Administration Console Select Service Configuration Select SSO Adapter Select Edit Properties... for the SUN-ONE-ADDRESS-BOOK SSO Adapter template Select New Merge... Specify domain for Name Select Create Back to top
#### Configuring Portal Server to Work with a Load Balancer that Performs SSL Termination Some links on the Portal Server Desktop are generated using the server's port/host/protocol values. If a load balancer sitting in front of the Portal Server has been configured to perform SSL termination, there will be a port/protocol mismatch between LB and Portal Server. Due to which some links created on the desktop will be broken. To resolve this problem, the following properties needs to be added to the desktopconfig.properties file located at /etc/opt/SUNWps/desktop/desktopconfig.properties on a Solaris machine and at /etc/opt/sun/portal/desktop/desktopconfig.properties on Linux. lbHosts=<list of LB Host> lb.host1.protocol=<host1 protocol> lb.host1.port=<host1 port> Depending on the incoming request's host header, protocol and port are fetched from the properties file and passed on to form a link. Example: lbHosts=host1.com,host2.com lb.host1.com.protocol=https lb.host1.com.port=1443 lb.host2.com.protocol=https lb.host2.com.port=442 To enable switching of protocol and port depending on the client, its necessary to make the authlessanonymous desktop cache free. To do that, set the refreshTime property as zero for JSPTabContainer in authlessanonymous' desktop. Back to top
#### Configuring Portal Server in SSL Mode Prerequisite: Install web container, AM and PS in SSL mode. Make sure /etc/opt/SUNWps/PSConfig.properties file is present once the installation is complete. Configuration of SSL mode in Portal Server 2005Q1 is broken. To overcome the problem, install PS6.3.1P10 (11895x-10). Then, run psconfig from /<basedir>/SUNWps/lib to configure the Portal in SSL mode. For example: # cd /opt/SUNWps/lib # ./psconfig Back to top

Company Info | Contact | Terms of Use | Privacy | Copyright 1994-2005 Sun Microsystems