Features Overview
Features New to
- Support for Exchange 2000 SP3 Outlook Web Access
- Basic Authentication credential caching for more than one host
- New configurable option in the Gateway to ignore HTTP Content-Length headers
> patches provided on top of 6.0 release stream
> backports of important fixes provided in a future release stream
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.0. Portal Server 6.0 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
- Rewriter rules containing a '.' will now correctly rewrite content
- HTML entities in XML content are now correctly handled by the rewriter
- CSS content will now be rewritten once text/css is added to the Gateway profile
MIME mappings
- Netlet proxy now cleans up extraneous connections
Back to top
Installation Information
These installation instructions provide steps to install
For other document information about Sun Portal Server 6.0 software products,
visit:
http://docs.sun.com/db/coll/S1_PortalServer_60?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.0
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.0
- 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.0PC2, contains the entire delta between PS6.0 and PS6.0PC1
in addition to the new delta between PS6.0PC1 and PS6.0PC2.
PS6.0PC2 can be installed on PS6.0PC1 or on PS6.0.
Patch consolidations cannot be applied on differing
minor or major product versions. For instance, PS6.0PC1 cannot
be applied on PS6.1 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.0, this would be /usr/java1.3.1_04/jre.
|
# unzip rhino15R1.zip
# cp rhino/js.jar /usr/java1.3.1_04/jre/lib/ext/js.jar
# chmod 444 /usr/java1.3.1_04/jre/lib/ext/js.jar
|
|
-
Unzip the downloaded patch binary
-
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 |
| <install_dir>/SUNWps/locale/srapGateway.properties |
Gateway, Rewriter Proxy, Netlet Proxy |
Added additional error message |
/etc/init.d/gateway
<install_dir>/SUNWps/bin/version |
Gateway and Server node |
Modified scripts to print historical patch applications from the version files |
| /etc/opt/SUNWps/platform.conf.instances |
Gateway node |
Added additional Gateway option to control whether or not to read content using HTTP Content-Length headers supplied by remote servers |
| 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.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
To get the version information for the Portal Server node, from the node itself as root, type:
# <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
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
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 returned when a remote server supplies insufficient content compared
to that expected based on the Content-length header. However, the Gateway
can now 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.
Back to top
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:
- Login in to the Identity Administration Console as amadmin
- Select View: Service Management from the top view pane
- Expand the link next to Gateway under the SRAP Configuration subheading in the left view pane
- Select the appropriate profile that will be used to access Delegated Administrator from the right view pane
- In the Domain-based RuleSets Mappings field, create a mapping for the Delegated Administrator Host
EX: dahost.subdomain.domain.com|ida_ruleset
- Select Add
- Add Delegated Administrator server domain name to the Proxies for Domains and Subdomains field if it is not there
already.
- Select Save
- Restart the Gateway
Back to top
How to Attach 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:
- Login to the Identity Server administration console
- Select Service Management in the view panel
- Expand the link next to Client Detection
- Select the checkbox next to Client Detection Enabled
- Select Save
Add the necessary charsets:
- 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:
- 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.
- Change Encoding=Q to Encoding=B
- 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.
- Restart the servers
/etc/init.d/amserver startall
Back to top
|
