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:

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.

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.0PC1 makes changes to both the gateway, and version scripts necessary to print additional information about the current install level. In Portal 6.0, 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.0PC1, 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
Wed Sep 25 09:29:46 PDT 2002 Portal Server 6.0 Secure Remote Access
Thu Apr 1 14:38:05 PST 2004

# <install_dir>/SUNWps/bin/version
Thu Apr 1 14:29:46 PDT 2003 Portal Server 6.0
Thu Feb 26 14:30:18 PST 2004

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

'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.

Configuring the Gateway to Ignore HTTP Content-Length Headers

includes a fix for a bug whereby Portal Gateway threads lock up while trying to retrieve content from a remote server. This can happen if the response from the remote server includes a Content-length header that is incorrect (specifically, too high). This situation causes the gateway to wait for additional content that does not exist, and in turn generates exceptions that aggressively consume system resources. Ultimately, system performance may be degraded, or the gateway may hang.

The fix includes an additional platform.conf option to control the behaviour of the gateway when retrieving content. By default, an error is now returned when a remote server supplies insufficient content compared to that expected based on the Content-length header. However, the Gateway can be configured to ignore the Content-length header, and simply read all available data before rewriting it. To enable this behaviour, change the following entry in the /etc/opt/SUNWps/platform.conf.* file for the relevant instance:

gateway.rewriter.ignorecl=true

NOTE: Enabling this option may have an impact on overall gateway performance, to an extent that we have not yet been able to establish. Care should therefore be taken to test the impact of this option in staging before rolling it into production.

Enabling Delegated Administrator Support Through the Rewriter

This section covers the rewriter integration with Delegated Administrator that ships with Sun Messaging Server. The integration includes a fix for BugID #5032856 mentioned in the patch README in addition to a boilerplate rewriter ruleset to use for the integration. The ruleset is uploaded to the Identity Server as a part of the patch installation process, and needs to be mapped to the appropriate machine host in order to be affective. To map the new iDA ruleset, do the following:

1. Login in to the Identity Administration Console as amadmin
2. Select View: Service Management from the top view pane
3. Expand the link next to Gateway under the SRAP Configuration subheading in the left view pane
4. Select the appropriate profile that will be used to access Delegated Administrator from the right view pane
5. In the Domain-based RuleSets Mappings field, create a mapping for the Delegated Administrator Host
   
   EX: dahost.subdomain.domain.com|ida_ruleset
   
   
6. Select Add
7. Add Delegated Administrator server domain name to the Proxies for Domains and Subdomains field if it is not there already.
8. Select Save
9. Restart the Gateway

Attaching Localized Files Using Netmail Lite

Prior to 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 Management in the view panel
3. Expand the link next to Client Detection
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. Restart the servers

/etc/init.d/amserver startall

Disabling Gateway Statistics

The special URL https://<gateway>/statistics dumps a small amount of statistical data on the number of requests and data handled by that gateway instance since the last restart. However given that accessing this URL does not require any kind of authentication or valid session, you may wish to disable it. This is now possible by adding the following entry to the /etc/opt/SUNWps/platform.conf.instance file for that instance:

gateway.statistics.enabled=false

A restart of the gateway instance is required for this change to take affect.

Configuring the Maximum Limit of Netlet Rules

This patch introduces an option to configure the limit for netlet rules that can be started on the client machine. Before this patch the limit was hard coded to 30. By default this limit is still 30. To change this limit from 30 to some other value perform the following steps. Following example changes the limit to 50.

1. Change directory to /SUNWam/locale/
   where is the installation directory of Identity Server.
2. Open the file srapNetletServlet.properties
3. Add the following line to the file and save it.
   netlet.max.rules=50
4. Restart the server and the gateway.

Perform the above steps on all the platform servers.

NOTE: Different clients have different limits on the network ports that can be opened and if themaximum netlet rules limit exceeds the client limit, it will cause problems in starting the netlet on the client. For WINDOWS 98 this limit is 30 and therefore in case there are users using windows 98 as client machines DO NOT change this limit to be more than 30.

Back to top