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, when a patch is installed on the Solaris platform: /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

and subsequent patch consolidations make changes to both the gateway, and version scripts necessary to print additional information about the current install level. In previous versions of Portal, 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. 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
Fri May 7 18:45:51 PDT 2004
Mon Apr 26 14:38:05 PST 2004

# <install_dir>/SUNWps/bin/version
Fri May 7 18:45:51 PDT 2004 Sun Java(tm) System Portal Server 6.3
Mon Apr 26 14:30:18 PST 2004

# /etc/init.d/amserver version
Sun Java System Identity Server version 2004Q2

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 Network Socket Timeout Between the Gateway and the Netlet Proxy

This patch includes a new option to configure a fixed timeout for the network socket that is opened between the Gateway and Netlet Proxy if the Netlet Proxy is in use. This option was included to reduce socket depletion resulting from sockets on the Netlet Proxy node remaining indefinitely in an ESTABLISHED state.

For example, prior to this fix, if a Telnet session was opened via the Netlet and there was no activity for 2-4 minutes, the Telnet session would timeout as a result of the idle timout being reached. However, the socket opened between Gateway and Netlet Proxy would remain in an ESTABLISHED state. The same behavior would result from a user explicitly exiting the Telnet session as well.

The new option included with this patch gives portal administrators the ability to explicitly set a timeout for how long the abandoned socket should remain open. The default value of this timeout is 10 minutes. So, if there is no activity between the Gateway and Netlet Proxy socket for 10 minutes, the socket will be closed. If this value needs to be changed, an entry for gateway.netletproxy.socket.timeout can be added to the platform.conf file on the Gateway with the new value specifi ed in milliseconds.

Example:
To change the value to five minutes, the following step should be performed on the Gateway instance(s) which require modification.

1. Change directory to /etc/opt/SUNWps on a Solaris machine, or /etc/opt/sun on a Linux machine
2. Backup the platform.conf.<gateway_instance> file; where gateway_instance is the instance you want to configure this option for.
3. Edit the platform.conf.<gateway_instance> file and add the following entry:
   
   gateway.netletproxy.socket.timeout=300000
   
   
4. Restart the gateway Instance

NOTE: If the socket timeout is set too high, the socket depletion could be significant enough to cause Netlet connections to hang.

Configuring Portal Server to Work with a Load Balancer that Performs SSL Termination

Some links on the Portal Server Desktop are generated using the configured 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 protocol mismatch, and some links created on the desktop will be broken. To resolve this problem, an additional entry, called lbProtocol 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.

Example:
If the load balancer is performing SSL termination, it's protocol will be https so the new property entry will look like:

lbProtocol=https

Configuring Portal Server & Gateway when PS and IS are on seperate machines behind a load balancer

If PS (Portal Server) and IS (Identity Server) are installed on seperate machines and either of these machines are behind a load balancer then the following needs to be done :

If IS is behind a load balancer, then the URL of the load balancer needs to be added to the Platform Profile list in IS Admin Console and a property called "gateway.ignoreServerList" needs to be set to "true" in the platform.conf file of the Gateway instance.

If PS is behind a load balancer, then the URL of the load balancer needs to be added to the Gateway Profile Portal Server list under the IS Admin Console for the gateway instance.

The above steps are needed only when PS and IS are on seperate machines and either PS or IS is behind a load balancer.

Back to top

Eliminating the Specific Portal Server Requirement During Gateway Failover

The Gateway currently requires a specific Portal Server to be available when the Gateway starts up. The Portal Server which the Gateway uses is defined in the Gateway's platform.conf file in an entry called gateway.dsame.agent.0. This entry's value creates a single point of failure for each Gateway instance that will prevent it from properly restarting should the specified Portal Server be temporarily unavailable.

To rememdy this problem, multiple entries can be created in each gateway instance platform.conf file in order of preference. For instance, to define two Portal Servers to use during Gateway startup edit the /etc/opt/SUNWps/platform.conf.<gateway_instance> file and change:

gateway.dsame.agent.0=http://host1:80/portal/RemoteConfigServlet

to:

gateway.dsame.agent.0=http://host1:80/portal/RemoteConfigServlet
gateway.dsame.agent.1=http://host2:80/portal/RemoteConfigServlet

You will also need to add the additional hosts to the /opt/SUNWam/lib/AMCOnfig.properties file.

Change:

com.iplanet.am.naming.url=http://host1:80/amserver/namingservice

to:

com.iplanet.am.naming.url=http://host1:80/amserver/namingservice http://host2:80/amserver/namingservice

And:

com.iplanet.am.notification.url=http://host1:80/amserver/notificationservice

to:

com.iplanet.am.notification.url=http://host1:80/amserver/notificationservice http://host2:80/amserver/notificationservice

This change will take effect the next time the Gateway instance is started.