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

Table of Contents
Features Overview Pre-installation Considerations Installation Information Template Modifications Required Tips for Customizing Templates Checking the Current Product Install Level | Maintaining Netlet Connections During Periods of Network Inactivity Configuring Auth Level Checking in the Gateway Rewriting ID Attribute Values Contained in Form Data Rewriting JavaScript Object Property Values How to Attach Localized Files Using Netmail Lite
#### Features Overview ##### Features New to NetFile upload performance enhancements ##### Features Inherited from Portal Server 6.1 Patch Consolidation 1 Active Netlet keep-alive Netlet window closure upon explicit Portal logout Gateway Auth level checking support Support for ID match in addition to name match when rewriting form data Support for rewriting URLs in JS object properties New product version handling For a list of Portal patches that are obsoleted by refer to the included patch is not a standalone installation and does not include Portal Server 6.1. Portal Server 6.1 must be installed prior to upgrading to or installing . can be installed on top of previous patches as it is cumulative. Refer to the section titled New Portal Patching Methodology for additional information. Back to top
#### Pre-installation Considerations In addition to the profile and flatfile changes listed in the Template Modifications Required section of the this document, there are also internal changes made that may directly affect how you use, test, or evaluate the product. Most of these behavioral changes tend to be directly related to the rewriter component, but there are other parts of the product that may be affected, as well. As such, it is important that this patch, as with any other, be test thoroughly on a development or QA system prior to being put in to production. Additionally, because of the nature of Portal 6x distribution and the customization requirements for the product, special attention should be given to JSP files that must be modified by the patch installer in order to fix defects, and/or for the product to continue functioning normally. Noticeable Behavioral Changes after Installing Dynamic rewriter functions will no longer be inserted twice when web pages contain inlined JavaScript. Patch will now correctly deploy and backout when Portal is installed on SunONE App Server. Rewriter Proxy will no longer fetch content from domains that are not explicitly specified in the `Proxies for Domains and SubDomains` list of the Gateway profile. Back to top
#### Installation Information These installation instructions provide steps to install For other document information about Sun Portal Server 6.1 software products, visit: http://docs.sun.com/db/coll/S1_PortalServer_61?q=portal For Portal Server software packages, visit: http://www.sun.com/downloads System Requirements This section describes the system requirements for
System Requirements for Portal
Component | Description
Operating Environment | updates Portal Server 6.1 software, and runs in the Solaris™ 8 and Solaris™ 9 operating environments.
Memory | Each Portal component should have a minimum of 1GB of main memory. This minimum requirement applies to proof of concepts (POCs), demo/test environments, and production systems alike.
OS Patches | No OS patches besides those required by the Portal Server base install are needed by
Installation Overview Please familiarize yourself completelly with the release notes prior to attempting either installation of, or upgrade to, The following directories and files are included in `` : NOTE: The release notes are now stored in the patch directory itself so that they are able to be included with the rest of the patch on SunSolve. Installation Instructions NOTES: If the Portal Server installation contains both a server node and one or more platform nodes, then `` must be applied on the server node first, then each additional platform node as well. The patch must also be applied to any installed gateway nodes following completion of application to the Server and platform nodes. must have the following releases applied prior to patch installation: Portal Server 6.1 Portal Server 6.x Patch Consolidations are cumulative. That means that any later patch consolidation for the same minor version (dot release) will contain prior patch consolidations for the same minor version. For example, PS6.1PC2, contains the entire delta between PS6.1 and PS6.1PC1 in addition to the new delta between PS6.1PC1 and PS6.1PC2. PS6.1PC2 can be installed on PS6.1PC1 or on PS6.1. Patch consolidations cannot be applied on differing minor or major product versions. For instance, PS6.1PC1 cannot be applied on PS6.0 or iPS3.0. Running different release levels on different nodes is highly discouraged and not supported by Sun. Each node must be upgraded to the same revision in the order previously outlined. In addition to the required Solaris patches, Mozilla.org's Rhino JavaScript engine is also required if you have a Gateway node in place and would like end users to be able to use automatic proxy configuration files in conjunction with the Portal Server Netlet functionality. Rhino 1.5R1, which has been tested and certified for use by Portal Server Quality Assurance, is available for download at http://www.mozilla.org/rhino/, or from the third party product distribution. STEPS: In a terminal window, become root. Download and install Rhino Version 1.5R1 on the server node if needed for automatic proxy configuration support by the Netlet. Rhino must be installed to the JRE being used by the Portal. In 6.1, this would be `/usr/java1.3.1_06/jre`.
# unzip rhino15R1.zip # cp rhino/js.jar /usr/java1.3.1_06/jre/lib/ext/js.jar # chmod 444 /usr/java1.3.1_06/jre/lib/ext/js.jar
Unzip the downloaded patch binary
# unzip PS6.1PC1.zip
Be sure the server and platform nodes on which you are currently installing are running and use the Solaris[tm] patchadd command to apply the patch.
# root@ps-server: /etc/init.d/amserver startall
starting auth helpers ... done. checking for directory server ... directory server already running done starting web server ... iPlanet-WebServer-Enterprise/6.0SP5 B10/31/2002 16:22 [LS ls1] http://ps-server.int.sun.com, port 80 ready to accept requests startup: server started successfully iPlanet-WebServer-Enterprise/6.0SP5 B10/31/2002 16:22 [LS ls1] http://ps-server.int.sun.com, port 8088 ready to accept requests startup: server started successfully done.
# root@ps-server: patchadd

- Apply the patch using `patchadd` to other installed nodes on separate machines including any Portal proxies or Gateway nodes.

Back to top

#### Template Modifications Required

Every attempt is made by the patch installer to both preserve customized template information and automate the update of that 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, `/etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer \ /Netlet/display.template` might be backed up to `/etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer/ \ /Netlet/display.template.pre
` . The backup files are also copied back to their original location upon patch removal. To help avoid potential content-related customization problems, refer to the Tips for Customizing Templates section of this document. The following template files, `.properties` files, jsps, xml files, and platform files are modified by this patch consolidation:

Template and Flatfile Modifications Made by
Name | Component | Change
N / A
Name | Component | Change
Template and Flatfile Modifications Inherited from Portal 6.1 Patch Consolidation 1:
Name | Component | Change
`/etc/opt/SUNWps/desktop/default \ /Login/display_AuthLDAP.html` `/etc/opt/SUNWps/desktop/default \ /LoginProvider/display_AuthLDAP.html` | Server and Platform | Fixed typo in the FORM NAME attribute value. Changed from `login_form2` to `userid_form` so that JavaScript form verification will now work.
`/etc/opt/SUNWps/desktop \ /default/JSPLayoutContainer/layout1.jsp` `/etc/opt/SUNWps/desktop/ \ default/JSPLayoutContainer/layout2.jsp` `/etc/opt/SUNWps/desktop/default \ /JSPLayoutContainer/layout3.jsp` | Server and Platform | Added logic for JSPs to check whether channels are movable or not before displayting the channels on the layout page.
`/etc/opt/SUNWps/desktop \ /default/JSPTabContainer/tabs.jsp` | Server and Platform |
`/etc/opt/SUNWps/desktop \ /default/JSPTabContainerProvider/tabs.jsp` | Server and Platform | Added a return statement to the onClick handler to reduce the number of requests made when a tab is selected.
`/etc/opt/SUNWps/desktop/default \ /JSPEditContainer/doedit.jsp` `/etc/opt/SUNWps/desktop/default \ /JSPEditContainer/edit.jsp` `/etc/opt/SUNWps/desktop \ /default/TabJSPEditContainer/doedit.jsp` `/etc/opt/SUNWps/desktop \ /default/TemplateEditContainer/editTemplate.template` | Server and Platform | Adds necessary logic to correctly handle cases where InvalidEditFormDataExceptions would previously result in serious desktop errors, instead of displaying the appropriate error message provided in the exception handling.
`/etc/opt/SUNWps/desktop/default \ /MyFrontPageTabPanelContainer/Netlet/display.template` | Server and Platform | Added two additional assignments to add the Netlet popup window to the list of detached windows so that it will be automatically closed on exit without having to code any JavaScript event handlers on the Portal desktop logout link.
`/etc/init.d/gateway` | Gateway | Modified script to display new versioning logic, and also to not spawn multiple Gateway instances as a result of additional backed up platform.conf files stored in the /etc/opt/SUNWps directory.
`<install_dir>/SUNWps/bin/deploy` | Server and Platform | Modified script so that entire directory structures that may contain other deployed web applications are not incedentally removed as a part of redeploing the Portal Server Web Application.
Name | Component | Change

Back to top

#### Tips for Customizing Templates

Because the Portal Server itself is so customizable, you should follow some precautions to insure 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 should never be customized.

To create a customized template directory:

Create a directory at the same level as the `/etc/opt/SUNWps/desktop/default/` directory 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. Fox 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

#### Checking the Current Product Install Level

Portal Server 6.1PC1 makes changes to both the gateway, and version scripts necessary to print additional information about the current install level. In previous versions of Portal 6, this information had to be gathered from a variety of sources including the package versions, patchadd -p output, or from a flatfile that was not updated by patches themselves. Beginning with 6.1PC1, Portal patches will now update the version files when they are installed and again when they are backed out.

To get the version information for the Gateway node, from node itself as root, type:

> `# /etc/init.d/gateway version
> Thu Jun 19 14:29:46 PDT 2003 Portal Server Secure Remote Access 6.1
> Thu Feb 26 14:38:05 PST 2004
> `

To get the version information for the Portal Server node, from the node itself as root, type:

> `# <install_dir>/SUNWps/bin/version
> Thu Jun 19 14:29:46 PDT 2003 Portal Server 6.1
> Thu Feb 26 14:30:18 PST 2004
> `

To get the version information for the Identity Server node, from the node itself as root, type:

> `# /etc/init.d/amserver version
> Sun One Identity Server 6.0-sp1`

NOTE: If no version information is displayed, you may need to comment out the following line in the amserver script.

> `'version')
> #check_amserver_script
> echo `/usr/bin/cat -s $VERSIONFILE`
> ;;
> `

An RFE has been filed to modify the Identity Server version information to match that which is available in Portal Server. The First line of the version output contains the major version information that may also include the product build date. Each remaining line of output represents a patch that has been applied to the major version. The comma separated list in order includes the actual patchID (currently a Solaris patch ID), the patch name, and the patch install date. All of this information is important for supportability purposes and to help Portal administrators in product maintainance. Back to top

#### Maintaining Netlet Connections During Periods of Network Inactivity

In Portal Server 6.0 and 6.1, the Netlet Keepalive feature did not work as expected. The feature would force the Netlet session to terminate immediately when the interval was reached. This feature has been changed in Portal Server 6.1PC1 to send dummy packets during periods of no network activity to keep connections alive that may otherwise close as a result of infrastructure products like proxies and firewalls timing out the network connections. Specified in seconds, this value is generally set to something greater than 60 seconds, but less than half the value of the destop idle timer, to reduce security implications of abandoned sessions.

The Netlet KeepAlive Interval can be set using the Identity Server Administration Console. To change the Netlet Keep Alive Interval, do the following:

1. Log in to the amconsole
2. Select the Service Configuration Tab
3. Netlet the link next to Netlet Service From the SRAP Configuration subheading
4. Change the value for Keep Alive Interval on the right hand view pane
5. Select Save

Setting the value to 0 will disable the feature. Back to top

#### Configuring Auth Level Checking in the Gateway

Authentication Level checking is a new feature that allows you to restrict the authentication methods used when accessing the portal via the gateway to a subset that you consider sufficiently secure. For example, you may allow users to authenticate using LDAP, Safeword, NT and Certificate authentication when accessing the portal directly, but wish to insist upon either Safeword or Certificate authentication when accessing via the gateway.

Every Authentication Service in Identity Server has an "Authentication Level". This is an arbitrary positive integer of your choice, and is 0 by default for all. By specifying a higher value for more trusted authentication services, you can restrict gateway access to those with an "Authentication Level" above a certain threshold.

Using the above example, you would set the Authentication Level for Safeword and Certificate authentication to 5 as follows:

1. Log in to the amconsole
2. Select the Service Configuration Tab
3. Expand the link next to Safeword
4. From the righthand viewpane, change the value for Authentication Level to 5
5. Repeat steps 3 and 4 for Certificate
6. Select Save
7. On the Gateway node, edit the platform.conf file for the instance(s) you wish to enfoce the new authentication policy
8. Change the value for gateway.min_auth_level to 5
9. Restart any modified gateway instances

Back to top

#### Rewriting ID Attribute Values Contained in Form Data

Prior to Portal Server 6.1 PC1, form data that needed to be rewritten could only be matched using the `NAME` attribute. The `NAME` attribute may also be complemented or superceded entirely by an `ID` attribute values in some web applications. To rewrite form data that contains `ID` attirbute values, simply specify the ID value in the name field of the rule entry. For example, to rewrite the following form data:

> `<input type="hidden" id="FORM1" value="/form2.html">`

the rule:

> `<Form source="*" name="FORM1">`

would need to be added to the `HTMLRules` section of the appropriate ruleset. Back to top

#### Rewriting JavaScript Object Property Values

JavaScript Object properties can now be rewritten as `EXPRESSION` rule types. For example, to rewrite a JavaScript object property similar to one used by an SAP application:

> `<html>
> <body BGCOLOR="#FFFFFF" TEXT="#000000">
> <script>
> ur_system = {doc : window.document , mimepath :"/irj/portalapps/com.sap.portal.themes.lafservice/themes/portal/sap_standard/common/"};
> </SCRIPT>
> </body>
> </html>
> `

The following rule would need to be added to the `JSRules` section of the appropriate ruleset:

> `<Variable TYPE="EXPRESSION"> mimepath </Variable>`

Back to top

#### How to Attach Localized Files Using Netmail Lite

Prior to 6.1 Patch Consolidation 1, Japanese files could not be attached from the Compose Message window of NetMail Lite when the `Attach File` button is selected. A blank page would be displayed instead. 6.1 Patch Consolidation 1 solves this problem by obtaining the charset using the Portal client detection module. In order to take advantage of the fix then, client detection must be enabled, and the proper character set needs to be set for the japanese locale.

Enable the client detection module in the Portal Server:

1. Login to the Identity Server administration console
2. Select `Service Configuration`
3. Expand the link next to `Client Detection` under the Identity Server Configuration section in the lefthand viewpane
4. Select the checkbox next to `Client Detection Enabled`
5. Select Save

Add the necessary charsets:

1. From the Client Detection view pane, modity the Client Types Field to include localized charsets `clientType=MSIE|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=genericHTML|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=NSCP_UNIX|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=MSIE6|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=NSCP_WIN32|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=NSCP6|userAgent=Mozilla/5.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR`
   NOTE: The leading `\` preceeding `charset=UTF-8` represents a line wrap and is included in this document for readability purposes only. In the Client Type field, this character should not be present, nor the whitespace padding around it.

Modify the charset properties in the psNetMailServlet properties file:

1. Edit <install_dir>/SUNWps/web-src/WEB-INF/classes/psNetMailServlet_<locale>.properties
   NOTE: Replace install_dir and locale with the appropriate values. Locale in this case might be ja, and install_dir might be the default /opt.
2. Change Encoding=Q to Encoding=B
3. Change iwtNetMail-charset from ISO-8859-1 to the appropriate value indicated in the Client Types Field above. For example, for Japanese locale, this should be changed to ISO-2022-JP.
4. Redeploy the portal web service by using deploy:
   <install_dir>/SUNWps/bin/deploy -redeploy -is_admin_password "<passwd>"

Back to top

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