iPlanet Portal Server Service Pack 3a |
Release Notes for iPlanet Portal Server 3.0
Updated October 11, 2001
These release notes contain important information available at the time of the release of iPlanetTM Portal Server Service Pack 3a. Installing this product will update the iPlanet Portal Server 3.0 software to include Service Pack 1, Service Pack 2, and Service Pack 3a. New features and enhancements, installation notes, known problems, and other late-breaking issues are addressed here. Read this document before you begin using iPlanet Portal Server 3.0 with Service Pack 3a.These release notes are available on the CD as well as on the iPlanet documentation web site: http://docs.iplanet.com/docs/manuals/. Check the web site prior to installing and setting up the software and then periodically thereafter to view the most up-to-date release notes and manuals.
These release notes contain the following sections:
What's New in iPlanet Portal Server 3.0, Service Pack 1, Service Pack 2, and Service Pack 3a
Software and Hardware Requirements
Service Pack 3a Installation Notes
Known Problems and Limitations
Bugs Fixed in Service Pack 1, Service Pack 2, and Service Pack 3a
Understanding the Typographic Conventions
The following tables describes the typographic conventions used in this release note.
Shell Prompts in Command Line Interface Examples
The following table shows the default system prompt and superuser prompt for the C shell, Bourne shell, and Korn shell.
Sample Machine Names
The Following table lists the machine names used in code examples and the types of iPlanet Portal Server components to which they correspond.
iPlanet Portal Server server component acting as the profile server
iPlanet Portal Server server component not being used as the profile server in multiple server installations
What's New in iPlanet Portal Server 3.0, Service Pack 1, Service Pack 2, and Service Pack 3a
The following product enhancements to iPlanet Portal Server 3.0 are included in the Service Pack 3a software release:
Gateway Performance Enhancements
Web Server Performance Tuning Parameters
Configuring Multiple Instances of iPlanet Portal Server
Configuring iPlanet Portal Server to Run as User Non-Root
Configuring iPlanet Portal Server to Run as User Nobody
Installing and Enabling Multiple Locales for a Domain
Supporting SSL for Authentication in an Open Portal
Redirecting the User Using the goto Parameter
Getting and Setting User Properties
Using an E-mail Address as the User's Profile ID
Changing Membership Login Password
Reloading Templates without a Server Restart
Setting Up Full-width Channels
URL Scraping with No Gateway Installed
Configuring Restart of the HTTP Proxy
Enabling Access to HTTP Requests and Responses
Running Applications on a Non-iPlanet Portal Server
Using Novell File Systems with NetFile and NetFile Lite
Defining Systems and Shares at the Domain and User Levels from the Administration Console
Alphabetized Shares on Windows NT System
Addition of smb.conf Parameter to smbclient Command
NetFile Usability Enhancements
Using a Load Balancer in Open Portal Mode
Loading Multiple Attributes in One Profile Request
Short-Circuiting for Session and Logging Requests
Running Desktop Applications on a Macintosh Client
Enabling Secure FTP Using a Netlet Connection
Rewriting Javascript Functions Parameters in Javascript
Rewriting JavaScript Variables in JavaScript
Rewriting JavaScript Function Parameters Function
Rewriting Applet/Object Parameter Values List
Gateway Performance Enhancements
The following changes have been made to the iPlanet Portal Server product as a result of enhancing the performance of the gateway.
Support of Netscape Security Service (NSS) on the Gateway Component
Support of Netscape Security Service (NSS) on the Gateway Component
Service Pack 3a introduces support for NSS (JSS) on the gateway component. This new implementation of SSL increases the number of HTTPS operations that can be sustained by the gateway component.Certificates installed for the previous SSL library are automatically converted to the format required by NSS when Service Pack 3a is installed, however, certificate management for the gateway component is different from previous releases of the iPlanet Portal Server product. For more information on gateway certificate management see, Web Server Performance Tuning Parameters."
Attribute Additions
A new attribute ips.gateway.trust_all_server_cert has been added.As a new line entry in the /etc/opt/SUNWips/platform.conf file ips.gateway.trust_all_server_certs offers a true/false statement for the gateway to allow or deny unknown certificate authorities (CAs).
The default value of this attribute is false.
This will also include CAs that the gateway component does not already know about.The value may be changed to true. Set the value to true you want the gateway component to trust all CAs which present signed certificates to the gateway component during an SSL handshake.
Typically, the Root CA certificate should be added to gateway certificate database so the gateway component can identify the certificate that is being presented. However, if a site presents a self-signed certificate, setting the ips.gateway.trust_all_server_cert attribute to true allows the iPlanet Portal Server gateway component to communicate with the site presenting the unknown certificate.
See Certificate Management" for instructions on installing a Root CA certificate.
Two cases in which the ips.gateway.trust_all_server_cert attribute would be set to true include:
The iPlanet Portal Server gateway component uses SSL to communicate with a gateway proxy, on which a self-signed certificate is installed.
The following error is generated if the gateway does not recognize the certificate that is being presented, and the ips.gateway.trust_all_server_cert attribute is set to false.The iPlanet Portal Server gateway component uses SSL to communicate with an iPlanet Portal Server server, on which a self-signed certificate is installed.
Attributes Removed in Service Pack 3a
As part of the gateway performance enhancements incorporated in Service Pack 3a, the following settings in the iPlanet Portal Server administration console are no longer used.Although, these settings appear in Administration Console on the Manage Gateway Profile page, they do not function. The information in the section "IP address validation" in Chapter 8 "Configuring the Gateway" in the Administration Guide no longer applies.
Gateway Component Performance Tuning Parameters
For better performance under load, increase the value of "Maximum Thread Pool Size". The default value is 200, and should be increased to 500.Increase this value through the Portal Admin Console:
Select Gateway Management.
Select Manage Gateway Profile.
Change the value in the field for Maximum Thread Pool Size to 500.
Restart the gateway component for the changes to take effect.
Certificate Management
In Service Pack 3a, the SSL certificate management for the gateway component is different from previous releases due to the replacement of the previous SSL library with the new SSL library.As a result, the information on SSL certificates for the gateway component presented in Chapter 11 of the iPlanet Portal Server Administration Guide, and in Appendix A of the iPlanet Portal Server Installation Guide has changed. The following information replaces the existing documentation on SSL certificates for the gateway.
Note Previous documentation on certificates for the iPlanet Portal Server server component still applies.
General Information on SSL Certificates for the Gateway Component
In Service Pack 3a, the certadmin script in <installation_directory>/SUNWips/bin/ is a script that wraps around the ipscertutil command for convenience and consistency with previous certificate administration. The certadmin script should satisfy the conventional needs of certificate administration. For any additional functionality, use the ipscertutil command directly. For example, use ipscertutil to delete a certificate from certificate database. The command ipscertutil -H lists usage.Certificate related files are located in /etc/opt/SUNWips/cert. Three of the five certificate files, cert7.db, key3.db and secmod.db, are binary files and contain the data for certificates, keys, and cryptographic modules. These files can be manipulated implicitly by using the certadmin script.
The three certificate related binary files have the same formats as the database files used by iPlanet Web Server and are located in <installation_directory>/netscape/server4/alias. If necessary, they can be shared between the iPlanet Portal Server server and gateway components or the gateway proxy.
The other two files are hidden text files: .jsspass and .nickname. The .nickname file stores the names of the token and certificate that gateway currently uses, in the form of token_name:certificate_name. If using the default token (the token on default internal software encryption module), omit the token name. In most cases, the .nickname file only has the certificate name stored in it.
The .jsspass file contains the password for the encryption module that iPlanet Portal Server gateway currently uses. The default module is the internal software module.
During the installation of the iPlanet Portal Server gateway component, a self-signed SSL certificate is created and installed. If necessary, use the certadmin script to do additional certificate administration.
Generating a Self-signed SSL Certificate for the Gateway Component
As root, run the certadmin script. The following example assumes that /opt is the installation directory.
The Certificate Administration menu is displayed.
Enter 1 on the menu to generate a self-signed certificate.
The Certificate Administration script asks you if you want to keep the existing database files.
Do you want to keep the existing certificate database files? [y]/n
Choose whether to keep the existing certificate database files.
The token name (default being empty) and certificate name will be stored in the .nickname file under /etc/opt/SUNWips/cert.
If you answer y, the script prompts you to enter certain organization-specific information, token name and certificate name.
If you answer n to the question "Do you want to keep the existing certificate database files?" the original certificate directory will be backed up, and the scripts will ask you for organization-specific information, token name, certificate name as shown above, and asks for a passphrase. A passphrase needs to be set because a new set of certificate, key and encryption module database files will be created. The passphrase will be stored in the .jsspass file under /etc/opt/SUNWips/cert.
Enter the organization-specific information, certificate name and, if needed, token name and passphrase.
To restart the gateway component, assuming /opt is the installation directory, enter the following commands.
Restart the gateway component for the certificate to take effect.
- A self-signed certificate is generated and the prompt returns.
# /opt/SUNWips/bin/ipsgateway stop
# /opt/SUNWips/bin/ispgateway start
Obtaining and Installing an SSL certificate for the Gateway from a Certificate Authority (CA)
During the installation of the gateway component of the Portal Server product, a self-signed certificate is created and installed. At any point after installation, you can install SSL certificates signed by vendors who provide official certificate authority (CA) services, or by your corporate CA.There are three main steps involved in this task.
Generating a Certificate Signing Request (CSR)
Generating a Certificate Signing Request (CSR)
The Certificate Administration menu is displayed.
Type 2 on the menu to generate a certificate signing request (CSR).
The script prompts you to type certain organization specific information, web master's email and phone number, and token name.
Fill in the information.
A CSR is generated and stored in the file /tmp/csr.<hostname> and is printed out to the screen which you can copy and paste.
Note Do not leave the web master's email and phone number blank. The information is necessary for getting a valid CSR.
Ordering a Certificate from the Chosen CA Using the CSR
The following example omits the actual certificate data.
-----BEGIN CERTIFICATE----- The certificate itself ----END CERTIFICATE-----
- Include both the "BEGIN CERTIFICATE" and "END CERTIFICATE" lines with the certificate in the file.
Installing the Certificate from the CA
Using the certadmin script, install the certificate from the CA in your local database files in /etc/opt/SUNWips/cert.
As root, run the certadmin script. The example assumes that /opt is the default location.
Type 4 on the menu to install your certificate from the CA.
- The Certificate Administration menu is displayed.
Answer the questions respectively.
- The script asks you to enter certificate file name, certificate name and token name.
What is the name (including path) of file that contains the certificate?
Please enter the token name you used when creating CSR for this certificate []
Restart the gateway component, for the certificate to take effect. The following commands assume that /opt is the default installation directory.
- The certificate will be installed in /etc/opt/SUNWips/cert, and the screen prompt returns.
# /opt/SUNWips/bin/ipsgateway stop
# /opt/SUNWips/bin/ispgateway start
Adding a Root CA Certificate
Importing a root CA certificate into the gateway's certificate database when the gateway is an SSL client allows the gateway component to communicate with an internet or an intranet HTTPS site if the site presents a server certificate signed by a CA that is unknown to the gateway certificate database. The SSL handshake will fail if the gateway component does not recognize the server's CA certificate.To allow a successful handshake, import the certificate authority's root certificate into gateway's certificate database so that the CA becomes known to the gateway which in this case is an SSL client.
To import a root CA certificate into the gateway component's certificate database:
As root, run the certadmin script. The example assumes that /opt is the default location.
If the gateway component is set up to communicate with an https site that presents a self-signed certificate, allowing the gateway component to trust any unknown CAs can be a useful approach. However, for a serious deployment, this approach should be used with caution. See Gateway Performance Enhancements: Attribute Additions" for more information on configuring the gateway component to trust all server certificates.
Choose option 3 on the certificate administration menu.
- The Certificate Administration menu is displayed.
Enter the name of the file that contains the root certificate, and enter the name for the certificate.
Most well-known public CAs are already included in the certificate database. The following is the list of all the public CAs included by default and their trust attributes. For information on modifying the trust attributes of a public CA see Modifying Trust Attributes of a Certificate".
Viewing the Public CA list
To view the list of Public CAs as shown above:
As root, run the certadmin script. The example assumes that /opt is the default location.
The Certificate Administration menu is displayed.
Choose option 6 on the certificate administration menu.
Modifying Trust Attributes of a Certificate
In general, the trust attributes of a certificate gives information about whether the certificate is a regular server certificate (also called user certificate) as opposed to a root certificate, whether the certificate (in the case of a root certificate) can be trusted as the issuer of a server or client certificate.There are three available trust categories for each certificate, expressed in this order: "SSL, email, object signing". In the context of the gateway component, only the first category is useful. In each category position, zero or more of the following attribute codes are used.
The possible attribute values and the meaning of each value are listed below, which help to further explain the usage of trust attributes.
The attribute codes for the categories are separated by commas, and the entire set of attributes is enclosed by quotation marks. For example, the self-signed certificate generated and installed during the gateway installation is marked "u,u,u" which means it is a server certificate (user certificate) as opposed to a root CA certificate.
Viewing Trust Attributes
All certificates and their corresponding trust attributes can be viewed by using the certificate administration script.To view the trust attributes of a certificate:
As root, run the certadmin script. The example assumes that /opt is the default location.
The Certificate Administration menu is displayed.
Choose option 7 on the certificate administration menu.
Setting the Trust Attribute for a Certificate
One case in which the trust attributes of a certificate need to be modified is if client authentication is used with the gateway. An example of client authentication is PDC (Personal Digital Certificate) as described in Chapter 6 of Administration Guide. The CA that issues the PDCs must be trusted by the gateway, for example, the CA certificate should be marked "T" for SSL.To set the trust attribute for a certificate:
As root, run the certadmin script. The example assumes that /opt is the default location.
The Certificate Administration menu is displayed.
Choose option 5 on the certificate administration menu.
The certificate trust attribute will be changed, and in the previous example about PDC, the client certificates signed by that CA will be recognized by the gateway.Enter the name of the certificate. For example, Thawte Personal Freemail C.
Please enter the name of the certificate:
Thawte Personal Freemail CAEnter the trust attribute for the certificate. For example, CT,CT,CT (in this case, it is the fault new value, you just need to hit return)
Please enter the trust attribute you want the certificate to have [CT,CT,CT]
Web Server Performance Tuning Parameters
Table 6 describes web server parameter settings that will improve the performance of the gateway component. These configuration files are located in:
- install_directory/netscape/server4/https-server_name/config
Open Portal Mode
If the portal does not contain sensitive information (deploying public information and allowing access to free applications), then by using the Open Portal mode (without a gateway), the portal server can respond faster to access requests by a large number of users than if a gateway is installed (Secure Portal mode).The gateway, which provides encryption services and URL rewriting, is not required when the iPlanet Portal Server is operating in Open Portal mode.
Running iPlanet Portal Server without the gateway is referred to as Open Portal mode. The main difference between an open portal and a secure portal are the services presented by the open portal typically reside within the DMZ and not within the secured intranet.
Note Using the iPlanet Portal Server without the gateway (Open Portal mode) may improve the individual response of the portal for a large number of simultaneous users.
The Secure Portal
The iPlanet Portal Server 3.0 product was targeted towards customers deploying highly secure portals or remote access portals. These types of portals have a major emphasis on security and protection and privacy of intranet resources. The iPlanet Portal Server architecture is well suited to this type of portal. The URL Rewriting, URL Access Policy, and Netlet features of the gateway allow users to securely access intranet resources from the Internet without exposing these resources to the public Internet. The gateway, residing in the DMZ, provides a single secure access point to all intranet URLs and applications. All other iPlanet Portal Server services such as Session, Authentication, Desktop, Channels, and Profile database reside behind the DMZ in the secured intranet. Communication from the client browser to the gateway is encrypted using HTTP over SSL. Communication from the gateway to the server and intranet resources may be either http or https.
The Open Portal
The iPlanet Portal Server 3.0 Service Pack 3a product enables the features necessary for iPlanet Portal Server to be deployed without the services of the gateway.The Service Pack 3a installation provides the option of installing the iPlanet Portal Server product in open-portal mode. For instructions on installing the iPlanet Portal Server software in open-portal mode, see the section, Clean installation" under Installation Instructions."
Configuring iPlanet Portal Server 3.0 to Run SSL in Open Portal Mode
The typical public portal runs in the clear or using http. It may however be desirable to deploy a portal using HTTP over SSL (https). The Portal server may be configured to run https services during installation or manually changed from http to https after installation.See the iPlanet Portal Server 3.0 Administration Guide for more information on using SSL.
Note This type of open portal does not require the services of the gateway.
Users access the server directly as if the server was configured for http, but use https://server.domain instead of http://server.domain.
The following features are not available when running without the gateway or in Open Portal mode:
One iPlanet Portal Server installation may be configured to support both open and secure portal.
For example, a company may want to create a portal which resides within the intranet:
When users access the portal from the intranet, log in to the server directly using http
When accessing the portal from the internet use https through the gateway
Updating an Existing Gateway/Server Installation to Open Portal Mode
Install iPlanet Portal Server 3.0 Service Pack 3a on the portal server, then do the following:
To shut down the gateway only, use the ipsgateway stop command:
# /opt/SUNWips/bin/ipsgateway stop To completely remove the gateway on a different computer from the portal server, remove the SUNWwtgwd and SUNWwtsd packages using the pkgrm command.
To completely remove the gateway, and the gateway and portal server are on the same machine, remove only the SUNWwtgwd package using the pkgrm command.
Logging Into the Open Portal
To log in to the Open Portal use the following rules:
Note Users should always use the fully qualified name of the server.
If the server name is my.sun.com and the server is running http use the following URL:
or
- http://my.sun.com if the default http port 80 is configured.
- http://my.sun.com:port where port is the non-default port number. For example,
- http://my.sun.com:8080
If the server name is my.sun.com and the server is running https use the following URL:
or
- https://my.sun.com:port
- https://my.sun.com if port 443 is used.
Multi-hosting in Open Portal Mode
Service Pack 3a includes functionality which allows the server to access multiple instances of iPlanet Portal Server from a single server installation.Access to the iPlanet Portal Server is through either:
http://server:port
To log in to a different domain on the Portal, use the following URL:https://server:port (if the server was configured to HTTPS)
- Where server is the Portal server name, and port is the Portal server port.
- http://server:port/login/domain_name
- Where domain_name is a Portal domain name.
URL to Domain Mapping
If the existing installation of portal server contains multiple servers and multiple domains, a URL to domain mapping allows the portal server to find the domain automatically without the need to provide the domain name in the URL.The following example describes how to map a URL to a specific domain:
If the iPlanet Portal Server installation has one server (server1), and two domains (domain1 and domain2), the following URL to domain mapping is needed:
To map a URL to a domain, do the following in the Administration console:
Logon as Super Administrator.
Repeat these steps for the second domain.Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
Select one of the domains.
In the Domain, Role and Users page:
Domain URL Mapping List
The domain URL list for domain1 must contain the following URLs:
Add the following two lines to obj.conf (as shown in bold text in the following example).
The obj.conf is located at:
The following is another example:
- /opt/netscape/server4/https-server1/config/obj.conf
- Where domain 1 and domain 2 are the iPlanet Portal Server domain names.
If there are three servers (server1, server2, and server3) and two domains (domain1 and domain2), the following are the URL to domain mappings:
To map a URL to a domain, do the following in the Administration console:
- http://server1:port ---> go to domain 1
- http://server2:port ---> go to domain 2
- http://server3:port ---> go to domain 2
Logon as Super Administrator.
Repeat these steps for the second domain.Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
Select one of the domains.
In the Domain, Role and Users page:
Domain URL Mapping List
The domain URL list for domain1 must contain the following URLs:
The domain URL list for domain2 must contain the following URLs:
Configuring Multiple Instances of iPlanet Portal Server
This configuration supports running multiple instances of the iPlanet Portal Server 3.0 on different ports, giving the user just one virtual server to interact with.Running multiple instances of iPlanet Portal Server 3.0 servers, each with its own copy of iPlanetTM Web Server on the same physical machine, changes the context of iPlanet Portal Server 3.0 to have multiple web servers and JVMs on the same machine.
It is possible to configure the various instances to implement SSL, giving a user the flexibility of switching to SSL mode for security on any of the iPlanet Portal Server instances. So when running in open portal mode, iPlanet Portal Server instances can talk over SSL.
Note Using the create command will only configure new iPlanet Portal Server instances using the HTTP protocol.
Installing Multiple Server Instances
To create multiple instances of the iPlanet Portal Server installation on different ports, do the following:
Install iPlanet Portal Server 3.0 Service Pack 3a on the Portal server, then do the following steps.
This is an interactive option where the administrator can continue to enter unique port numbers, not already in use, where the multiple instances are to be created. Enter a blank line (Return) when finished.
As root, in a terminal window enter the following commands:
- See the Service Pack 3a Installation Notes in this document.
Note In the following instructions and examples, /opt is the default installation directory.
# cd /opt/SUNWips/bin
# ./ipsserver create
Tip From the command line, enter: To determine if the port desired is available and unused.
This process takes approximately 5 minutes depending on the machine architecture. The script output looks like the following example. (Where the bold text is user input).
If any of the above instances already exist then the following message will be displayed before being prompted to overwrite:
Warning:: server instance already exists:siroe.iplanet.com-8081
Select Return when menu is completed.
This will start all the portal server instances, including the original installation.Stop and restart all the Portal Server instances:
# /opt/SUNWips/bin/ipsserver startall
In the iPlanet Portal Server Administration Console, do the following:
- To start the different server instances separately, use the individual ipsserver scripts in the /opt/SUNWips/bin directory.
- To start the server instance running on 8081, for example:
- /opt/SUNWips/bin/ipsserver.siroe.iplanet.com@8081 start
- The original server can still be started by:
- /opt/SUNWips/bin/ipsserver start
Logon as Super Administrator.
Stop and restart all the Portal Server instances:Select the Server Management link from the left frame.
Select the Manage Server Profile link in the right frame.
Change the Server List attribute.
Select the Submit button, at the bottom of the page, and save the changes.
- Add the new server instances to the Server List:
- http://ipsserver.siroe.iplanet.com:8081
- http://ipsserver.siroe.iplanet.com:8082
Select the Continue button on the Profile Successfully Updated page.
# /opt/SUNWips/bin/ipsserver startall
These instances can be directly accessed through the web browser, as follows:
If the machine name is siroe.iplanet.com, and two port numbers 8081 and 8082 were configured as shown in the Step 2 example, and the install directory was /opt, the following files will be listed:
- http://siroe.iplanet.com:8080
- http://siroe.iplanet.com:8081
- http://siroe.iplanet.com:8082
- /opt/SUNWips/bin/ipsserver.siroe.iplanet.com@8080
- /opt/SUNWips/bin/ipsserver.siroe.iplanet.com@8081
- /opt/SUNWips/bin/ipsserver.siroe.iplanet.com@8082
Updated Command Options
The following command options have been updated, and new commands added. The following examples assume that the commands are being run from the directory in which they reside:
Changing the Profile Server to SSL in an Open Portal Environment
This section discusses how to change the profile server's protocol to HTTPS. This is also the server which has the profile service running on it. See the following instructions.
Note In the following instructions and examples, /opt is the default installation directory.
In a terminal window, become root, and type the following command:
# /opt/SUNWips/bin/ipsserver start In the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
From the admin console, select Server Management.Select the Server Management link from the left frame.
Select the Manage Server Profile link in the right frame.
Change the Platform Server List attribute.
Select the Submit button, at the bottom of the page, and save the changes.
- Change the protocol of the URL for the original server to be https.
- https://ipsserver.siroe.iplanet.com:8080
Select the Continue button on the Profile Successfully Updated page.
Select Manage Naming profile.
In a terminal window, go to the /etc/opt/SUNWips directory.In the Profile URL, change the protocol to https.
- https://ipsserver.siroe.iplanet.com@8080/profileservice
In the Logging URL, change the protocol to https.
- The profile URL would be changed to https if the original server is running the profile service as well. If the profile service is running on a different machine, the protocol should be the same as the server running the profile service.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- https://ipsserver.siroe.iplanet.com:8080/loggingservice
Select the Continue button on the Profile Successfully Updated page.
Make the following changes to the platform.conf file of the server that will be configured for SSL, The file maybe any of the files listed above.
- The directory will contain platform.conf files of the type:
- /etc/opt/SUNWips/platform.conf.siroe.iplanet.com
- /etc/opt/SUNWips/platform.conf.siroe.iplanet.com@8081
- /etc/opt/SUNWips/platform.conf.siroe.iplanet.com@8082
- In this example the original server will be configured for SSL,
- From a terminal window, use a text editor to edit the platform.conf file:
- /etc/opt/SUNWips/platform.conf
- Edit the following entries as shown in bold text in the following example:
ips.server.protocol=https
From a terminal window, use a text editor to edit the magnus.conf file:
- /opt/netscape/server4/https-siroe/config/magnus.conf
Stop and restart all the Portal Servers:
- The Security option must be turned on, for the server to talk over SSL.
- Edit the entry as shown in bold text:
# /opt/SUNWips/bin/ipsserver startall
Changing the Created Multiple Instance Servers to SSL in an Open Portal Environment
The section discuses how to change the protocol to HTTPS of any of the other created multiple instances. Make these changes for the server where SSL is required. Make sure that the key pair file password and the trust database password entered for any of the certificate installation is the same between all the iPlanet Portal Server created multiple servers which are being configured to talk over SSL and that password must be the SSL passphrase entered during the iPlanet Portal Server server installation.
Note In the following instructions and examples, /opt is the default installation directory.
If the instance running on port 8081 is to be secure, for example, do the following:
Stop and restart all the Portal Servers:
# /opt/SUNWips/bin/ipsserver startall In the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
In a terminal window, open the /etc/opt/SUNWips directory.Select the Server Management link from the left frame.
Select the Manage Server Profile link in the right frame.
Change the Platform Server List attribute.
Select the Submit button, at the bottom of the page, and save the changes.
- Change the protocol of the URL for the instance server to be https.
- https://ipsserver.siroe.iplanet.com:8081
Select the Continue button on the Profile Successfully Updated page.
Make the following changes to the platform.conf file of the server that will be configured for SSL.
- The directory will contain platform.conf files of the type:
- /etc/opt/SUNWips/platform.conf.siroe.iplanet.com
- /etc/opt/SUNWips/platform.conf.siroe.iplanet.com@8081
- /etc/opt/SUNWips/platform.conf.siroe.iplanet.com@8082
Note If the original server running the profile server has been changed to talk over SSL, then the protocol in ips.naming.url also needs to be changed to https.
- From a terminal window, use a text editor to edit the platform.conf file for the instance server:
- /etc/opt/SUNWips/platform.conf.siroe.iplanet.com@8081
- Edit the following entries, as shown in bold text, in the following example:
ips.server.protocol=https
The Security option must be turned on, for the server to talk over SSL.
Stop and restart all the Portal Servers:
- From a terminal window, use a text editor to edit the magnus.conf file:
- /opt/netscape/server4/https-siroe@port/config/magnus.conf
- Edit the following entries, as shown in bold text, in the following example:
# /opt/SUNWips/bin/ipsserver startall To confirm that the configured server is talking SSL protocol, directly access it at:
- https://siroe.iplanet.com:8081
Configuring iPlanet Portal Server to Run as User Non-Root
This procedure configures User Non-Root on an iPlanet Portal Server 3.0 server. For the examples shown, the server and gateway are installed on the same system. If installing the gateway on a separate system, perform the same steps on the gateway computer, where appropriate. If User Non-Root was installed in Service Pack 2, and is being upgraded to Service Pack 3a, see the Upgrading a User Non-Root Installation to Service Pack 3a section.
Note A root-started gateway can run with a non-root user started server.
Note Authentication helpers must be run as root.
The following information is included in this procedure:
Installation Examples
Installing iPlanet Portal Server Server Component
Configuring User Non-Root on the Server ComponentInstalling iPlanet Portal Server Gateway Component
Configuring User Non-Root on the Gateway Component
Upgrading a User Non-Root Installation to Service Pack 3a
Server Error Messages
Installation Examples
When installing the iPlanet Portal Server 3.0 server, select a non-default install. If specifying a non-root userid, enter an unused port number above 1024 for the directory server (default is 389); these examples use port 8389, as all the other iPlanet Portal Server ports are in the 8000's. If a root password is not being implemented, change the super administrator's userid from the default root. If converting the gateway specify a different port, these examples use port 8443, instead of the default 443. Select a non-default install for the gateway to do this. A sample server and gateway install sessions appears below.
Note In the following instructions and examples, /opt is the default installation directory.
Installing iPlanet Portal Server Server Component
See the iPlanet Portal Server 3.0 Installation Guide for more information on installing the iPlanet Portal Server server software.
Tip Non-default entries are shown in bold text.
Installing iPlanet Portal Server Gateway Component
See the iPlanet Portal Server 3.0 Installation Guide for more information on installing the iPlanet Portal Server gateway software.
Tip Non-default entries are shown in bold text.
Configuring User Non-Root on the Server Component
Perform all steps as root, except as noted.
See the Installation Instructions for more information on installing Service Pack 3a.
After installing the iPlanet Portal Server software do the following:
As root, in a terminal window:
Note In the following examples for non-root user, substitute userid for the qualified name of a user.
As root, in a terminal window, do the following:
Edit the following file, to change the localuser to user login name (Userid), as shown in bold text:
- The userid is the name of the user, and MyGroupid is the name of the group the user belongs to. If the user, Jim, belongs to the staff group, then it would be written as:
Edit the following file, to change the User to user login name (Userid), as shown in bold text:
- /opt/netscape/directory4/slapd-Servername/config/slapd.conf
If the LDAP Directory Server process is also to run as a user other than root, edit the following file, to change the configuration.nsSuiteSpotUser to user login name (Userid), as shown in bold text:
- /opt/netscape/server4/https-servername/config/magnus.conf
As root, in a terminal window, do the following:
- /opt/netscape/directory4/admin-serv/config/local.conf (partial example)
# chown -R Userid:MyGroupid /etc/opt/SUNWips
# chown -R Userid:MyGroupid /var/opt/SUNWipsEdit the following file, to comment out line 410, check_root_user, as shown in bold text:
Rename the following files to prevent the iPlanet Portal Server server from automatically being started by root upon reboot:
- /opt/SUNWips/bin/ipsserver (lines 408 through 429)
# mv /etc/rc3.d/S42ipsserver /etc/rc3.d/XS42ipsserver
# mv /etc/rc3.d/K42ipsserver /etc/rc3.d/XK42ipsserverStart the iPlanet Portal Server server component. From a terminal window, as the non-root user, do the following:
% /opt/SUNWips/bin/ipsserver start
Configuring User Non-Root on the Gateway Component
Edit the following file, to comment out lines 172 through 176, as shown in bold text:
Edit the following file, to add ips.gateway.user=Userid, as shown in bold text:
- /opt/SUNWips/bin/ipsgateway (lines 170 through 182)
Rename the following files to prevent the iPlanet Portal Server gateway from automatically being started by root upon reboot:
- /etc/opt/SUNWips/platform.conf
Note Must be a valid userid on the iPlanet Portal Server gateway component. If ips.gateway.user does not match the userid for which the procedure has been applied, permission problems will result.
# mv /etc/rc3.d/S90ipsgateway /etc/rc3.d/XS90ipsgateway
# mv /etc/rc3.d/K90ipsgateway /etc/rc3.d/XK90ipsgatewayStart the iPlanet Portal Server server and gateway components. From a terminal window, as the non-root user, do the following:
% /opt/SUNWips/bin/ipsserver start
% /opt/SUNWips/bin/ipsgateway start
Special Case Configurations
When the iPlanet Portal Server server and gateway components are installed on the same system, both the server and gateway must be configured to run as user non-root.
Upgrading a User Non-Root Installation to Service Pack 3a
To upgrade Non-Root userid installation from Service Pack 2 to Service Pack 3a requires that all the user names be reset to root for the upgrade to work. Once Service Pack 3a has been installed the user will have to re-configure the server and gateway to run as Non-Root. Failure to do all these steps will result in loss of data.The following list is a brief summary of the steps required to upgrade to Service Pack 3a:
Stop all services for the iPlanet Portal Server 3.0 server and gateway.
If the gateway is running on a separate computer from the server, do the following:
- See Stopping the Server Component Processes."
Edit the gateway /etc/opt/SUNWips/platform.conf file, as shown in bold text:
Edit the following file, to uncomment line 410 (remove the #), check_root_user, as shown in bold text:
- Remove ips.gateway.user=userid
Edit the following file, to change the configuration.nsSuiteSpotUser to root, as shown in bold text:
- /opt/SUNWips/bin/ipsserver (lines 408 through 429)
In a terminal window, do the following:
- /opt/netscape/directory4/admin-serv/config/local.conf (partial example)
# chown -R root:root /etc/opt/SUNWips
# chown -R root:root /var/opt/SUNWips
# chown -R root:root /opt/netscape
# chown -R root:root /opt/SUNWips
- /opt/netscape/server4/http-Servername/config/magnus.conf.
Edit the following file, to change the localuser to root, as shown in bold text:
- Change name of the user login name (Userid) to root, as shown in bold text.
Install the Service Pack 3a upgrade. See Upgrading to Service Pack 3a" for the iPlanet Portal Server 3.0.
- /opt/netscape/directory4/slapd-Servername/config/slapd.conf
Reconfigure both the server and gateway to run as non-root. See Configuring User Non-Root on the Server Component" and Configuring User Non-Root on the Gateway Component".
Restore all backed up data, create all server instances, and all special configurations.
Special Case Configurations
When the iPlanet Portal Server server and gateway are installed on the same system, both the server and gateway must be configured to run as non-root.
Non-Root Error Messages
Running as a non-root user, there will be error messages on the server and gateway. These messages are expected, and workarounds are offered when appropriate.
Server Error Messages
Because a non-root user may not set the maximum file descriptors to a value larger than 1024. The ipsserver script attempts to set it to 10240.
/opt/SUNWips/bin/ipsserver: ulimit: exceeds allowable limit Failure to start the doSKey. This error is not common.
starting auth helpers ... ld.so.1: /opt/SUNWips/bin/doSKey: fatal: libskey.so: open failed: No such file or directory
When running as a non-root user, if a locally-administered UNIX userid is to be authenticated, then:
# chown root:sys /opt/SUNWips/bin/doUnix
# chmod 4555 /opt/SUNWips/bin/doUnix
Gateway Error Messages
Configuring iPlanet Portal Server to Run as User Nobody
To configure user nobody on an iPlanet Portal Server 3.0 server, in the following examples, the server and gateway are installed on the same system. If installing the gateway on a separate system, perform the same steps on that system.Specifying nobody as the owner of the iPlanet Portal Server files is a special case, as nobody has an impossible resultant (encrypted) password. The user must be root to manipulate and execute files nobody owns.
When the iPlanet Portal Server server is to run as nobody, the server can be configured to listen on port 8080, the default web server port. The LDAP server can also run on the default port 389, and the gateway on the default SSL port 443.
Note The Netfile and Netfile Lite applications cannot use NFS protocol when running as nobody.
Note Authentication helpers must be run as root. When the server component is started or restarted, it must be done as root.
If user nobody was installed in Service Pack 2, and is being upgraded to Service Pack 3a, see the Upgrading User Nobody to Service Pack 3a section.
The following information is included in this procedure:
Installation Examples
Installing iPlanet Portal Server Server Component
Configuring the Server Component to Run as User NobodyInstalling iPlanet Portal Server Gateway Component
Installation Examples
When installing the iPlanet Portal Server 3.0 server, select a non-default install. The following procedures are install examples for both the server and the gateway components.
Installing iPlanet Portal Server Server Component
See the iPlanet Portal Server 3.0 Installation Guide for more information on installing the iPlanet Portal Server servercomponent.
Tip Non-default entries are shown in bold text.
Installing iPlanet Portal Server Gateway Component
See the iPlanet Portal Server 3.0 Installation Guide for more information on installing the iPlanet Portal Server gateway.
Tip Non-default entries are shown in bold text.
Configuring the Server Component to Run as User Nobody
Perform all steps as root, except as noted.
See the Installation Instructions for more information on installing Service Pack 3a.
After installing the iPlanet Portal Server software do the following:
As root, in a terminal window, do the following:
Edit the following file. In this example servername would be siroe; use the servername that applies to your setup:
As root, in a terminal window, do the following:
- Change the user root to the name of the user nobody, as shown in bold text.
# chown -R nobody:nobody /opt/netscape
# chown -R nobody:nobody /opt/SUNWipsEdit the following file, to change the localuser to nobody, as shown in bold text:
Edit the following file, to change the User to nobody, as shown in bold text:
- /opt/netscape/directory4/slapd-servername/config/slapd.conf
If the LDAP Directory Server process is also to run as a user other than root, edit the following file, to change the configuration.nsSuiteSpotUser to nobody, as shown in bold text:
- /opt/netscape/server4/https-servername/config/magnus.conf
As root, in a terminal window:
- /opt/netscape/directory4/admin-serv/config/local.conf
# chown -R nobody:nobody /etc/opt/SUNWips
# chown -R nobody:nobody /var/opt/SUNWipsTo set the http and netlet proxies on the server to run as nobody, edit the /etc/opt/SUNWips/platform.conf file, as shown in bold text:
ips.httpproxy.user=nobody
Start the iPlanet Portal Proxy server. From a terminal window, as root, do the following:
# /opt/SUNWips/bin/ipshttpd stop
# /opt/SUNWips/bin/ipsnetletd stop
# /opt/SUNWips/bin/ipshttpd start
# /opt/SUNWips/bin/ipsnetletd start
Configuring the Gateway Component to Run as User Nobody
The following steps are for configuring user nobody on the gateway, when the gateway is not installed on the same system as the server.
Note When the gateway component is started or restarted, it must be done as root.
See the Installation Instructions for more information on installing Service Pack 3a.
After installing the iPlanet Portal Server software do the following on the gateway:
As root, in a terminal window, do the following:
When the gateway is configured as user nobody, do the following to workaround an invalid session condition when the gateway does a restart:
# chmod 666 /dev/random
# chown -R nobody:nobody /etc/opt/SUNWips
# chown -R nobody:nobody /var/opt/SUNWips
# chown -R nobody:nobody /opt/SUNWipsEdit the /etc/opt/SUNWips/platform.conf file, as shown in bold text:
ips.gateway.user=nobody
# chmod 4555 /etc/init.d/ipsgateway
Special Case Configurations
When the iPlanet Portal Server server and gateway are installed on the same system, both the server and gateway must be configured to run as user nobody.
Upgrading User Nobody to Service Pack 3a
To upgrade user nobody from Service Pack 2 to Service Pack 3a requires that all the user names be reset to root for the upgrade to work. Once Service Pack 3a has been installed the user will have to re-configure the server and gateway to run as nobody. Failure to do all these steps will result in loss of data.The following list is a brief summary of the steps required to upgrade to Service Pack 3a:
Stop all services for the iPlanet Portal Server 3.0 server and gateway.
If the gateway is running on a separate computer from the server, do the following:
Edit the gateway /etc/opt/SUNWips/platform.conf file, as shown in bold text:
Edit the following file, to change the configuration.nsSuiteSpotUser to root, as shown in bold text:
In a terminal window, do the following:
- Remove ips.gateway.user=nobody
# chown -R root:root /etc/opt/SUNWips
# chown -R root:root /var/opt/SUNWips
# chown -R root:root /opt/SUNWips
In a terminal window:
- /opt/netscape/directory4/admin-serv/config/local.conf
# chown -R root:root /etc/opt/SUNWips
# chown -R root:root /var/opt/SUNWips
# chown -R root:root /opt/netscape
# chown -R root:root /opt/SUNWipsEdit the following file, to change the localuser to root, as shown in bold text:
- Change the user nobody to the name of the user root, as shown in bold text.
Edit the following file, to change the User nobody to root, as shown in bold text:
- /opt/netscape/directory4/slapd-servername/config/slapd.conf
Install the Service Pack 3a upgrade. See Upgrading to Service Pack 3a" for the iPlanet Portal Server 3.0.
- /opt/netscape/server4/https-servername/config/magnus.conf
Reconfigure both the server and gateway to run as nobody. See Configuring User Non-Root on the Server Component" and Configuring User Non-Root on the Gateway Component."
Restore all backed up data, create all server instances, and all special configurations.
Installing and Enabling Multiple Locales for a Domain
This feature provides support for multiple locales per installation. That is, the administrator can specify the locale for domains, roles, and users. For example, one iPS installation with three locale packages installed allows the admin to set up three domains, one for each locale. Users registering in domain1 will use locale 1, users registering in domain2 will use locale2 and so on.Every time you install a new locale, you must run the ipsadmin command to update the iwtPlatform attribute. The iwtPlatform-availableLocales attribute lists all the locales available for the user. For instance:
Although the value for this attribute may look like en_US or ja_JA, users only see the common name, for instance, English (United States), of the available locale.
To specify the locale for domains:
Login in to the administration console and select Manage Domains.
Select the domain which you are administering.
Select Platform and Show Advanced Options.
Specify the languages you wish to make available for this domain.
Supporting SSL for Authentication in an Open Portal
In a portal setup without the gateway, this feature provides support for SSL (HTTPS) server for user registration although the sites run without SSL (HTTP). That is, a portal configured to return all content on the desktop using http can still support user registration or login through https.The iPlanet Portal Server will support this configuration by running two instances of iPlanet Portal Server; one instance running http and the other instance running https.
See Configuring Multiple Instances of iPlanet Portal Server for detailed information on setting up two instances of iPlanet Portal Server.
After setting up the server instances, convert the second instance of the server to SSL. See Configuring Multiple Instances of iPlanet Portal Server." After configuring the second instance, update the user profiles to redirect to the non-SSL server (instance) after initial authentication. To do this:
To ensure that all unauthenticated sessions on the non-SSL server (instance) are redirected to the SSL server (instance), edit the platform.conf file in /etc/opt/SUNWips/ directory:
Here servername refers to the host name of the SSL server instance and port refers to the port where the server instance is running.
If using multiple iPlanet Portal Server server instances, edit the platform.conf file associated with each instance.
All registrations and login will be directed to the https server, and all desktop redirects will be sent to the http server.
Edit, the following file, as shown in bold text:
In the administration console set the user profile to point to the non-SSL port on the open portal. Do the following instructions:
- /etc/opt/SUNWips/desktop/customized_template/iwtLoginProvider/display.html
- <FORM ACTION="https://siroe.iplanet.com:8081/login/Membership" onSubmit="return checkBlank()" MET
HOD=GET NAME="userid_form" ENCTYPE="application/x-www-form-urlencoded">
- and
- <FONT FACE="[tag:iwtDesktop-fontFace1]" SIZE="-1"><A HREF="https://siroe.iplanet.com:8081/login/Membership?arg
=newsession&page=1&Submit=New%20User">Sign Me Up</A></FONT>
Log in to the administration console and select Manage Domains.
Select your domain and select User (under Profiles).
Change User's Default URL from /DesktopServlet to:
Select the Submit button, at the bottom of the page, and save the changes.
- http://servername:port/DesktopServlet
Select the Continue button on the Profile Successfully Updated page.
Anonymous Authentication
The zero-page auth module is specifically intended for supporting open portal installations, where just the iPlanet Portal Server server is installed without a gateway, although anonymous authentication may be used with a secure portal.In a typical anonymous installation, the anonymous authentication module would be the only authentication type enabled. When the URL http://server:port/login/mydomain is specified, the user's browser displays the anonymous user desktop. No other user input is required, other than specifying the URL.
There is also a feature where a list of userid's that may login to the anonymous user's desktop can be specified. The list may be entered or modified through the administration console.
Managing Anonymous Username
If userid is in the List of Anonymous Usernames, then access to the anonymous user's desktop is granted, with the session assigned to the specified userid. If the userid is not in the List of Anonymous Usernames, then the anonymous desktop is still displayed, but the session is assigned to the userid specified in the Default Anonymous Username.
Modifying Default Anonymous Usernames
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
In the Domain, Role and Users page:In the Authentication Menu:
Select Show Advanced Options at the bottom of the page.
In the List Anonymous User Names, change default value "anonymous" to the desired userid.
Select the Continue button on the Profile Successfully Updated page.Select the Submit button at the bottom of the page to commit these changes to the profile server.
Setting the Default Anonymous Username
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Domain, Role and Users page:
In the Authentication Menu:
Select Show Advanced Options at the bottom of the page.
In the Default Anonymous User Name, change the default userid "anonymous," to the desired userid.
Select the Continue button on the Profile Successfully Updated page.Select the Submit button at the bottom of the page to commit these changes to the profile server.
Redirecting the User Using the goto Parameter
The goto parameter enables applications to instruct auth to redirect the user to a URL other than the default URL stored in the user's profile upon login or logout.When a user authenticates, the application can prompt the user to specify the URL to which the user will be redirected to instead of sending the user to the default desktop URL stored in the user's profile.
The goto parameter allows the calling application to specify where the user will be redirected upon successful login. For example, if an application wanted the user to be redirected to my.sun.com after successful authentication, the login link will be the following:
http://sun.domain:port/login?goto=http://my.sun.com
An api developer can include the goto parameter used in conjunction with the logout URL to specify where the user should be redirected upon logout. If the application wanted to redirect the user to nasdaq.com after logging out, the logout link will be the following:
http://sun.domain:port/logout?goto=http://sun.com
To demonstrate the goto parameter, open a browser and in the Location field, enter:
The goto parameter is valid for this auth session only and it will not change the default URL stored in the user's profile.
Setting Persistent Cookies
This enhancement enables setting persistent cookies. That is, when a user closes the browser or when the user's session expires, the user will not be required to re-authenticate.Persistent Cookie Mode is set by the user by selecting the Remember My Username and Password checkbox using the Login Channel. If the Persistent Cookie Mode is enabled:
However, if the user explicitly logs out, login is required on the next visit.
To set persistent cookie for a domain:
Log in to the administration console and select Manage Domains.
To demonstrate the persistent cookie mode, open a browser and in the Location field, enter:Select your domain and select Profiles and Authentication.
Select Show Advanced Options in the Profile:Auth page.
Specify the maximum age of the cookie in the Persistent Cookie MaxAge Value text box.
Select the Enable Persistent Cookie Mode check box.
- Specify the cookie expiry time in seconds.
- This will enable the persistent cookie mode for users in this domain.
http://server.domain:port/login/domain?iPSPCookie=yes
If the value for the parameter iPSPCookie is yes, then the persistent cookie mode is enabled.
Extending Authentication
No authentication is required if a valid session is present. That is, if a user wanted to switch from anonymous user to a registered user, it was impossible to authenticate the user using another authentication module such as the Membership module since an anonymous user has a valid session. In Service Pack 3a this has been corrected.When a registered user authenticates from the anonymous desktop, the application will get the information about the user and present the user's desktop from the user's profile. When a new user registers from the anonymous desktop, the user's current session (from the anonymous desktop) is destroyed before calling the auth module in the URL for the user's default desktop. This allows a user with a valid iPlanet Portal Server session to directly go to a login module without sending a logout URL. For example, a login channel will send the following URL to allow an anonymous user to register with the membership module:
http://server.domain:port/login/Membership?domain=/<mydomain>&arg=newsession
Here, the arg=newsession parameter instructs the authentication module to destroy the current session before calling the authentication module in the URL.
Setting the Default URL
This feature allows setting up the user's default URL in the pluggable interface in addition to the user's profile. This method doesn't change the default URL in the user's profile. When the user authenticates successfully, the user will be redirected to this URL. A new method called setDefaultURL in the pluggable authentication API allows the authentication modules to set the user's default redirect URL on successful authentication. This method does not change the user's attribute in the user profile. This method will override the goto parameter. See Redirecting the User Using the goto Parameter," in the initial auth URL.
public void setDefaultURL(java.lang.String url) throws LoginException
Getting and Setting User Properties
This feature allows the authentication module to set and get user properties from the user session. Two new methods called setUserSessionProperty and getUserSessionProperty in the pluggable auth API enables authentication modules to get and set properties in the user session. This allows authentication modules to communicate with channels, applications, or other authentication modules by setting session properties. For example, a custom authentication module may add the user password to the session, so that an application may retrieve this property, for single sign on at a later time.
public void setUserSessionProperty(java.lang.String name, java.lang.String value) throws LoginException
Using an E-mail Address as the User's Profile ID
This feature provides the ability to use an E-mail address on the certificate as the user's profile ID.To use the E-mail address as profile ID:
Log in to the administration console and select Manage Domains.
Select your domain and select Profiles and Authentication.
Select email address from what field in cert to use to access user info in profile.
Select the Submit button.
- This allows the administrator to specify what to use to access the user's profile id. If email address is selected, the cert auth module will search for the field emailAddr in the certificate's user subject dn field for the attribute tag emailaddr and use its value to access the user's profile id.
- The tag emailAddr is stored in the iwtAuthCert.properties file and it can be replaced with a different value depending on the site and/or certificate issuer.
Login Channel
The Portal Server 3.0 currently contains a membership authentication module which is useful for open portal installations. Combined with an anonymous user, unregistered users can view static content in a portal, and registered users can log in and view personalized content. The addition of a login channel on the desktop provides a simple way for registered users to access the portal while allowing non-registered users to still view static content and provides a simple mechanism to register with the portal and receive personalized pages.The login channel also provides an option to the user to enable persistent cookies. Persistent cookie support is a feature of the authentication system which puts the user's login information into a cookie so that the user can be automatically logged in for subsequent sessions. The channel provides a check box that allows the user to enable persistent cookie support for their login, based on whether or not this domain allows for this option.
The user interface for the login channel does not have an edit page, as there are no user editable preferences.
JavaServer Pages Provider
The JavaServer PagesTM Provider (JSPProvider) feature allows providers for desktop channels to be written using JavaServer Pages (JSP).Support for JSP-based channels is provided through a class called JSPProvider. A JSP Provider-based channel has, in addition to the regular attributes that other channels have, the following configured attributes:
contentPage - the JSP that is used to generate the channel content using the getContent method
There are several options for handling the processing of an edit form for a JSP-based provider. Typically, processing of the edit form consists of Java code that checks validity of the form entry and updates user preferences for the channel. The result is either a display of the desktop (in the case of success) or a display of the edit page, possibly with some error information for the user (in the case of a failure). To handle the processing of an edit form, the JSP-based provider has the following options:editPage - the JSP that is used to generate the edit page content using the getEdit method
processPage - the JSP that is used to process the results of an edit page using the processEdit method
The contentPage JSP generates the HTML content for the channel. The generated HTML must contain only those tags that are appropriate for display within a channel.
The editPage JSP generates the internal content for the edit form that is displayed when the user clicks the Edit button for the channel. This page is optional, and if not specified, the isEditable method for the provider returns false. As with the contentPage JSP, the JSP has access to iPlanet Portal Server platform services.
The contentPage and editPage JSPs can be used in various combinations. For example, a JSP can be used to generate the content while the edit page can be generated using Java code in the provider class.
Define a processPage JSP. If defined, this JSP is invoked via a POST request and the JSP can process the results, either using a script or a bean or other Java class. The JSP must produce a redirect in the response. This redirect then becomes the return value for the provider's processEdit method.
The JSPProvider extends the ProfileProviderAdapter class to support other attributes for the channel by using the profile service.Extend the JSPProvider class and implement the processEdit method. The processPage attribute is left blank.
When specifying a JSP in one of the JSP attributes, the path name is interpreted relative to the desktop template directory for the user using the same algorithm as for other desktop templates including the locale setting.
The system searches for the following JSP files:
For more information on implementing JSP-based channels, see the javadocs that are shipped with Service Pack 3a.
- /etc/opt/SUNWips/desktop/SunBlue_de_DE/myChan/chan.jsp
- /etc/opt/SUNWips/desktop/SunBlue_de_DE/chan.jsp
- /etc/opt/SUNWips/desktop/SunBlue/myChan/chan.jsp
- /etc/opt/SUNWips/desktop/SunBlue/chan.jsp
- /etc/opt/SUNWips/desktop/default_de_DE/myChan/chan.jsp
- /etc/opt/SUNWips/desktop/default_de_DE/chan.jsp
- /etc/opt/SUNWips/desktop/default/myChan/chan.jsp
- /etc/opt/SUNWips/desktop/default/chan.jsp
Tabbed Desktop
Service Pack 3a offers tab functionality to the user desktop. The desktop can use the tabs feature to organize content. Tabs are not active by default, and must be turned on for any given domain. The Tab Provider is enabled by the super administrator through the Administrator's console, and tabs are then configured, or removed in a chosen domain. Tabbed desktop pages can be individually modified to configure the desktop in a personalized way, as shown in the following procedures.
Configuring the Tab Desktop in the Administration Console
This procedure presumes that Tab Desktop is not configured in a particular domain. To enable the Tab Desktop, do the following in the iPlanet Portal Server Administration Console:
Log on as Super Administrator.
Select the Manage Domains link from the left frame.
Select a domain in the right frame.
Expand the Applications link in the right frame.
Select Show Advanced Options at the bottom of the Profile: Desktop page.
In the Profile: Desktop page, scroll down to the Channels Field.
If the iwtTabProvider is shown in the Available Channels window then do the following:
Highlight iwtTabProvider in the Available Channels window.
If the iwtTabProvider is not shown in the Available Channels window then do the following:Select the arrow pointing to the right, and the iwtTabProvider should then appear in the Selected Channels field.
In the New Channel Name window, enter a new channel name, iwtTabProvider.
Scroll down the page and confirm that the Active Channel List Module contains a Tab Channel List entry. The Tab Channel List Module must be selected. See the following example:In the Provider Class Name window, enter a new provider class:
Select Add.
- com.iplanet.portalserver.providers.tab.TabProvider
iwtTabProvider will now be shown in the Available Channels window.
Highlight iwtTabProvider in the Available Channels window.
Select the arrow, and the iwtTabProvider should then appear in the Selected Channels field.
In the Start Tab field, enter a tab name. The first tab default name is My Front Page.
- com.iplanet.portalserver.desktop.util.channellist.TabChannelList
In the Available Tabs field, edit the default tab conditions that the tab will contain. The following string is an example. Change the name, providers, and description to create a custom tab:
- This Tab will always be present on every desktop in the domain, and is not user configured.
In the Tab Pattern field, enter in a string, the name of a tab content template, and the providers to be included. See Step 12.
- name=new tab|channels=iwtTabProvider;iwtUserInfoProvider;
iwtIPInfoProvider;iwtSampleRss|desc=new tab description|
removable=true|renamable=true
In the Make From Scratch Tab field, enter a suitable heading title, and all the content providers that will appear on the Edit Tab Provider page. See the following string as an example:
In the Maximum Number of Tabs field, enter a number.
- name=Make From Scratch ...|channels=iwtTabProvider;iwtUserInfoProvider;
iwtBookmarkProvider;iwtIPInfoProvider|desc=Design a tab from the ground up|
removable=true|renamable=true
Select the Submit button, at the bottom of the page, and save the changes.
- This will be the total number of tabs that may be on the desktop. 4 is a default value.
Select the Continue button on the Profile Successfully Updated page.
Configuring the Tab Provider on the Desktop
Any user can configure the tabs on the desktop. The tab's channel edit page allows a user to create, rename, or remove tabs from their desktop. Additionally a user can select which tab should be present on the initial desktop page.
As a user, log in to the iPlanet Portal Server desktop.
In the Edit Tab Provider page, the user can use a pre-defined tab content template by topic, or by choosing each channel for the new tab manually.In the desktop, select the Edit button, on the right of the tab banner.
Creating Customized Tabs
In the Edit Tab Provider page, do the following:
In the Tab Name field, enter the name of the tab being created.
In the Channels page, do the following:In the Tab Topics field, select the radio button for Make From Scratch.
Select Finished at the bottom of the page.
Select the desired channels, to customize the desktop page.
The desktop screen will return back to the User Desktop Page.
Select Finished at the bottom of the page.
- Thin and thick channels are determined by the administrator, when configuring Desktop Pages and layout in the administration console.
Creating Default Content Tabs
In the Edit Tab Provider page, do the following:
In the Tab Name field, enter the name of the tab being created.
The desktop screen will return back to the User Desktop Page.In the Tab Topics field, select the radio button of a pre-made Tab Content Provider.
Select Finished at the bottom of the page.
Changing Membership Login Password
To change the membership login password, the user must choose the Edit icon from the User Information channel menubar.In the Membership Password area are fields for:
The user enters the original password, and the new and confirm passwords must match for the change to be successful. Password checking is subject to the same rules as the membership authentication module.
The user must have authenticated via Membership for changes to the Membership password.
Reloading Templates without a Server Restart
When the desktop accesses templates to generate content, it reads them from disk and caches them. All subsequent requests for the template are served from the cache.The desktop periodically checks to see if the disk files have been updated. If the disk file is newer than the cache, the template is re-cached based on the updated disk file.
The length of time between checking to see if the disk files have been updated is the template scan interval. This interval may be changed in the iPlanet Portal Server Administration Console. Changing the template scan interval causes the desktop to immediately check for changes to the disk files and then wait for the new interval value before re-checking again.
To change the template scan interval, do the following in the iPlanet Portal Server Administration Console:
Log on as Super Administrator.
Select the Management Platform Settings link from the left frame.
Expand the Applications link in the right frame.
In the Component Profile: Desktop page, scroll down to the Template Scan Interval Field.
Select the Submit button, at the bottom of the page, and save the changes.
- This field can be edited. The default value for the template scan interval is 900 seconds, or 15 minutes.
Select the Continue button on the Profile Successfully Updated page.
Enabling Anonymous Desktop
The following is the recommended procedure for enabling an anonymous desktop using the Anonymous Authentication Module and Login Channel delivered with Service Pack 3a.
Configuring Anonymous Authentication
To enable the Anonymous Desktop, in the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
In the Domain, Role and Users page:In the Authentication Menu:
Select Anonymous and de-select all other authentication modules
Select the Continue button on the Profile Successfully Updated page.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- The portal server is now defaulted to the Anonymous authentication module in all cases and will display the anonymous desktop by default.
Select Show Advanced Options at the bottom of the page.
In the Non Interactive Modules, add Membership.
Select the Continue button on the Profile Successfully Updated page.
Select Enable Persistent Cookie Mode.
- This will enable users to use the login channel to use Membership authentication instead of having to use the provided membership login page.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
Customizing Templates for Anonymous Desktop
To customize a user logout from the desktop redirect to the anonymous user desktop, do the following:
Edit the /etc/opt/SUNWips/desktop/default/iwtDesktop/menubar.html as shown in the code example, in bold text.
To customize the Help page for the anonymous desktop, do the following:
- Change the HREF for the Log Out link to:
- This will set the logout from the desktop to be redirected to the anonymous desktop in all cases.
Logon as Super Administrator.
Select the Anonymous User Desktop.
Select the Manage Domains link from the left frame.
Select the domain.
Select the Continue button on the Profile Successfully Updated page.Scroll down and select Show Advanced Options.
Modify the value for Front Page Help.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- The value in Front Page Help is assumed to be relative from the directory:
- /opt/SUNWips/public_html/docs/en_US/online_help
Enabling Anonymous Desktop for Other Domains
To create an anonymous user for any other domain, do the following steps:
Copy /var/opt/SUNWips/iwtAnonymousUser.xml-orig file to a temporary location (/tmp)
# cp /var/opt/SUNWips/iwtAnonymousUser.xml-orig /tmp/iwtAnonymousUser.xml-orig Edit the /tmp/iwtAnonymousUser.xml-orig file as shown in the example, in bold text.
Use the ./ipsadmin command to load the new anonymous user profile to the profile service. Type the following commands in a terminal window:
- Change the string INST_DEFAULT_DOMAIN to the name of the other domain.
userConfigurable="true" > <Val>/INST_DEFAULT_DOMAIN/defaultRole</Val> </iwt:Att>
# cd /opt/SUNWips/bin
# ipsadmin create user /other_domain/anonymous /tmp/iwtAnonymousUser.xml-origTo access the authentication menu for the new domain in the browser location, type:
http://your_server/login?domain=/other_domain
Disabling the Anonymous Desktop
To disable the Anonymous Desktop, in the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
Select the domain.
In the Domain, Role and Users page:
In the Authentication Menu:
De-select the Anonymous auth module.
Select the Continue button on the Profile Successfully Updated page.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- There must be at least one auth module entry selected in the field after de-selecting any module.
Modifying the Login Channel
The login channel can be modified to work with other authentication modules, other than the default login channel shipped with Service Pack 3a. A sample template is available to illustrate how the login channel can be changed to work with the Unix authentication module, rather than the Membership authentication module.To enable Unix authentication for the login channel, do the following:
Note When replacing files to modify the operation of the desktop, make copies of the files being replaced, first, so that they can be reinstated at any later date.
As root, in a terminal window, make a copy of the following file:
The login channel will now use Unix authentication.
# cd /etc/opt/SUNWips/desktop/default/iwtLoginProvider
# cp display.html display_iwtAuthMembership.htmlReplace the display.html file with the following file:
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
Select the domain to add the Unix authentication.
In the Domain, Role and Users page:
In the Non Interactive Modules field:
Select the Continue button on the Profile Successfully Updated page.
Viewing the contents of the template file, display_iwtAuthUnix.html, will give the user an example of how other templates could be created to enable other authentication modules for the login channel. View the contents of the built-in login page for a given authentication method to get an example of the correct parameters to include in the display.html template.
Using Form Control
A method has been added to the provider API which allows a channel to return either a complete HTML edit form, or a subset of a complete HTML page in response to a request for the edit page.
Provider API
Several changes are required in the Provider API to support form control.Integer constants have been added to the Provider interface that return values from the getEditType() method. These integer constants define the form type, return type, from the getEditType() method:
New methods are added to query and set the form type.
- public static final int provider.EDIT_SUBSET ;
- public static final int provider.EDIT_COMPLETE ;
The desktop uses the getEditType() method so it can expect either a complete or subset HTML form to be returned when calling channel.getEdit().
- public int getEditType();
The desktop servlet is expecting some particularities as edit forms are posted, so some restrictions apply on what can be returned from getEdit() when the edit type is equal to EDIT_COMPLETE:
This method returns a complete, valid, HTML form
The following parameters must be present in the submitted form:The form is an encoding type of application/x-www-form-urlencoded
The form must contain the correct parameters for instructing the desktop to process the page, as defined in editTemplate.html.
The form action must be /DesktopServlet. When returning a complete HTML form, a channel must submit valid actions to the desktop as defined in the Desktop URL javadocs.
Provider Attributes
For channels that extend the ProfileProviderAdapter class, a new attribute can be defined in the profile component:
The default value will be different for each provider. Variations to this might include turning off write permission for OWNER, if one or the other edit type was not implemented.
The iPlanet Portal Server default channels all return Provider.EDIT_SUBSET. Modifying the -editType attribute will cause a malfunction. A new channel must return Provider.EDIT_SUBSET, or Provider.EDIT_COMPLETE depending on how the getEdit() method is implemented.
Locking a Channel's Position
This feature enables an administrator to lock a channel's position. When a channel's position is locked, the user cannot move the channel from its position on the desktop. The purpose of locking a channel is to force the user to see particular content.With this enhancement, a channel can be locked, which means the user will not be able to change the position on the desktop.
The Layout page that allows the user to arrange channels on the desktop will not list a locked channel.
Log in to the administration console and select Manage Domain.
To unlock a channel's position, do the following:Select the domain and select Profiles and Policy.
Deselect the Movable check box for the channel to lock the channel's position.
Deselect the Removable check box, so the channel may not be removed from the desktop.
- If you select the Movable check box, the channels can be moved around in the desktop.
Select the Submit button.
- Selecting the Removable check box will allow the user to remove the channel from the desktop.
Log in to the administration console and select Manage Domain.
Select the domain and select Profiles and Policy.
Select the Movable check box for the channel to unlock the channel's position.
(Optional) Select the Removable check box so the channel can be removed from the desktop.
- If you select the Movable check box, the channels can be moved around in the desktop.
Setting Up Full-width Channels
Full-width channels have content that spans the full-width of the desktop, either at the top or bottom. A full-width channel can be simple static images or forms that need to be submitted.To configure full width channels:
Log in to the administration console and select Manage Domains.
Select your domain and select Applications and Desktop.
Select the channel you wish to modify and select the Edit Channel button.
Select the Show Advanced Options button.
Setting Up Frameless Channels
This feature enables setting up unframed channels in the desktop. The standard channel is displayed with a title, some set of controls, and inside a frame that appears similar to a window. The controls consist of icons linking to functions such as remove, edit, minimize etc. With this enhancement, you can set up a channel without a frame (that is, without the title and the controls).To configure frame-less channels:
Log in to the administration console and select Manage Domains.
Select your domain and select Applications and Desktop.
Select the channel you want to present without a border from the list of available channels.
Select the Edit Channel button and select Show Advanced Options.
Deselect the Framed? check box (if it is selected) to make the channel frame-less.
Select the Submit button.
- If the Framed? check box is selected, the channel will be displayed with a title and controls.
Note The channel will be displayed with a border. If you wish to modify the border of the channel, edit the hasBorder attribute in the Policy page.
Selecting the Locale
This feature allows users to choose their locale from a list of available locales on the platform. The provider displays a list of languages to the user, allows them to select one, and then stores the selection in the user profile. The user must re-login to get the new locale.
Log in to the desktop and select Edit to proceed to the Edit User Information screen.
Select the language from the list of available languages pull-down menu.
URL Scraping with No Gateway Installed
Some rewriting facilities from the Gateway Component Profile are used when configuring parameters for URL scraping. These parameters include:
Rewrite HTML attributes
When the Open Portal mode is installed the selections on the Gateway Component Profile page are not greyed out even though most selections are disabled because there is no gateway running.Rewrite HTML attributes containing JavaScript
Rewrite JavaScript function parameters
Rewrite JavaScript variables in URLs
Rewrite JavaScript variables functions
Rewrite JavaScript function parameters in HTML
To view this and observe the impact, in the Administration console, do the following to access the Gateway Component Profile page:
Logon as Super Administrator.
Select the Gateway Management link from the left frame.
Forwarding Cookies
This feature allows the URL scraper to forward cookies which were passed in the HTTP request to the desktop. That is, the URL scraper will send cookies when it makes a connection to the target site to retrieve the content it is scraping. The URL scraper will also send set-cookie requests to the browser. That is, it will get all cookies from set-cookie headers and add them to the HTTP response to the client browser.By default, no cookies are forwarded. For the affected domain, role, or user, the list of cookies to forward must be set from the administration console. To forward cookies:
Log in to the administration console and select Manage Domains.
Select your domain and select Profiles and Policy.
Change the entries in the allow and deny lists for the Cookies To Forward privilege for the channel.
- A "*" entry allows or denies all cookies. Other entries are compared using a prefix match.
Configuring Restart of the HTTP Proxy
To automatically configure a restart of the http proxy whenever rebooting the system server, use the command line interface on the iPlanet Portal Server server to do the following:
Note If using more than one server, repeat these steps for each server.
As root, in a terminal window, do the following:
# cd /opt/SUNWips/bin
# cp ipshttpd /etc/rc3.d/K55ipshttpd
# cp ipshttpd /etc/rc3.d/S55ipshttpd
# chmod 500 /etc/rc3.d/K55ipshttpd
# chmod 500 /etc/rc3.d/S55ipshttpdThis will autostart the http proxy when the machine is rebooted.
This will not autostart the http proxy when iPlanet Portal Server 3.0 is restarted using ipsserver start.
Enabling Access to HTTP Requests and Responses
This feature allows a provider to get access to the HTTP request and response headers. This is desirable for single sign-on, setting cookies, getting parameters for the HTTP headers, and for inserting data into the headers.The following are three new methods in the Content Provider interface:
These methods in the ProviderAdapter and ProfileProviderAdapter will call the old versions of the getContent, getEdit, and processEdit methods. The HttpServletRequest and Responses objects passed to the new methods have the following indicated behaviors:
Table 7 HttpServletRequest and Responses
Gateway Logging
When gateway logging is enabled, logging traffic between the gateway and the portal server can impact portal performance. In Service Pack 3a, gateway default logging is disabled. To enable gateway logging do the following:
Note In the following instructions and examples, /opt is the default installation directory.
Logon as Super Administrator.
Select the Gateway Management link from the left frame.
Select the Manage Gateway Profile link in the right frame.
In the Component Profile: Gateway page, do the following:
Scroll to the end of the page and select the Show Advanced Options button.
Select the Continue button on the Profile Successfully Updated page.Scroll to near the bottom of the page to the Logging Enabled check box, and select the box to enable the gateway logging.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
# /opt/SUNWips/bin/ipsgateway start
Running Applications on a Non-iPlanet Portal Server
This section explains how to run applications written using the iPlanet Portal Server APIs on a non-iPlanet Portal Server server. The application may be either a standalone java application (with some limitations) or a servlet application running on the iPlanet Web Server server.
Note iPlanet Portal Server 3.0 public APIs are supported only on Solaris operating systems.
Setting Up a Non-iPlanet Portal Server 3.0 Server
Note In the following instructions and examples, /opt is the default installation directory.
Create the following directories on the non-iPlanet Portal Server server host.
Copy /etc/opt/SUNWips/platform.conf to the same location on the non-iPlanet Portal Server server.
- /opt/SUNWips
- /opt/SUNWips/lib
- /opt/SUNWips/locale
- /etc/opt/SUNWips
In order to receive notifications, the application's run time environment must support servlets.
Copy from /opt/SUNWips/lib the following files:
- Modify the ips.notification.url parameter in the platform.conf to be the fully qualified domain name of the server the application will be running on. See the example (in bold text):
Copy from /opt/SUNWips/locale the following files:
- to the same location on the non-iPlanet Portal Server server.
iwtPll.properties
If the client application will be running under iPlanet Web Server, update the classpath on the iPlanet Web Server:
- to the same location on the non-iPlanet Portal Server server.
- iws_server_root/https-your_server/config/jvm12.conf
Update the following iPlanet Web Server file:
- In the classpath, include:
- iws_server_root/https-your_server/config/rules.properties
Update the following iPlanet Web Server file:
- by adding the following line:
- /notificationservice=notificationservice
- iws_server_root/https-your_server/config/servlets.properties
Restart the iPlanet Web Server server after updating these files.
- by adding the following line:
- servlet.notificationservice.code=com.iplanet.portalserver.pll.client.PLLNotificationServlet
Applications Not Running Under iPlanet Web Server
The iPlanet Portal Server session and profile APIs have a notification feature which allows the application to listen for profile and session state changes. If the application is running as a standalone application the following conditions are in effect:
Cannot receive session or profile notifications
The client side cache will not be updated when attributes change in the profile. Only after the user logs out and logs back in will the application see the changes
After the user session times out on the iPlanet Portal Server session server, the user will still have a valid session until the cache refresh timer is reached
Tip Reduce the cache seconds attribute in the session profile in the iPlanet Portal Server 3.0 Administration Console.
Running Client Applications Using SSL
If the iPlanet Portal Server 3.0 server is configured to use SSL, then the iPlanet Portal Server APIs will also be using SSL. The application must also use SSL to communicate with the iPlanet Portal Server services.The iPlanet Web Server, when installed, is not properly configured to support outgoing SSL connections by servlets.
Note In the following instructions and examples, /opt is the default installation directory.
In order to enable SSL connections by servlets, do the following:
Copy from /opt/SUNWips/lib the following files:
Update the classpath on the iPlanet Web Server:
- to the same location on the non-iPlanet Portal Server server.
- iws_server_root/https-your_server/config/jvm12.conf
Copy the following file to the iws_server_root/bin/https/lib directory:
- In the classpath, include:
Restart the iPlanet Web Server after updating these files.
- /opt/SUNWips/lib/solaris/sparc/libjssl.so
Running Applications Through the iPlanet Portal Server Gateway (Secure Portal)
When using the iPlanet Portal Server gateway, the gateway must be configured to forward the iPlanet Portal Server cookies to the application host. If the URL of the server the application is running on is not added to this attribute, the iPlanet Portal Server cookie will not be forwarded, and the application will have an invalid user session. By default the gateway will only forward the cookie to the iPlanet Portal Server server.
Note In the following instructions and examples, /opt is the default installation directory.
In the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
Restart the gateway:Select the Gateway Management link from the left frame.
Select the Manage Gateway Profile link in the right frame.
Scroll down to the Forward Cookie URL List attribute.
Enter the URL of the server the application is running on in this field, for example:
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- http://auth.iplanet.com:8080
Select the Continue button on the Profile Successfully Updated page.
# /opt/SUNWips/bin/ipsgateway start
Running Applications Without the iPlanet Portal Server Gateway (Open Portal)
When running the application without the gateway, access the application using a fully qualified domain name (FQDN). If a fully qualified domain name is not used, the iPlanet Portal Server cookie will not be forwarded to the application, and the user session will be invalid.
Using Novell File Systems with NetFile and NetFile Lite
Service Pack 3a offers File Transfer Protocol (FTP) support for Novell file systems through the NetFile and NetFile Lite applications. The following procedures describe how Novell systems are added to the NetFile and NetFile Lite Network Neighborhood.
Adding a Novel File System to NetFile
Start Netfile by selecting the Netfile link in the Applications channel of the iPlanet Portal Server desktop.
NetFile users can now perform Netfile functions as for any other host type.Enter the fully qualified system name.
Choose AUTO DETECT or NETWARE as the system type, and select OK.
Add a share by double clicking on the system in the Network Neighborhood.
Enter your Netware username and password and select a directory to mount.
Double click on the share under the system name in the Network Neighborhood to browse the directory
Adding a Novell File System to NetFile Lite
Start Netfile Lite by clicking on the Netfile Lite link in the Applications channel of the Portal desktop.
Netfile functions can now be performed by using the checkboxes next to the file names and selecting an action using a button at the bottom of the page.Fill in the form field for System Name and select the Machine Type as AutoDetect or NETWARE.
Fill in the next form fields for User Name, Password, Directory to mount, and select Enter.
Defining Systems and Shares at the Domain and User Levels from the Administration Console
Service Pack 3a offers the ability to define Systems and Shares for NetFile and Netfile Lite at the domain, role and user levels. By setting the common host data attribute in the administration console, administrators can define systems and shares to be displayed in the end user's Network Neighborhood.The following NetFile profile attributes have changed to allow administrators to define systems and shares.
The iwtNetFile-hostlist attribute can no longer be edited from the administration console.
See the following sections for instructions on defining systems and shares.The iwtNetFile-commonhostdata attribute is a new attribute that has been created for NetFile. It allows administrators to predefine systems and shares for the user.
Defining Systems and Shares at the Domain Level
Defining Systems and Shares at the Domain Level
Log in to the iPlanet Portal Server administration console as the Super Administrator.
To view the defined systems or shares in NetFile, the end user must perform the following steps:In the Portal Server Domains page, select the desired domain.
Expand the key next to Applications.
Modify the common host data attribute in the prepopulated Host list/type and share information field.
- To modify the common host data attribute, use the following format to enter (in one string with no spaces) the name, domain, type, and share information:
- name=fully_qualified_host_name|domain=domain_ name|type=host_type|share=share_directory
NAME is the remote host name
DOMAIN is the NT/WIN domain. The domain field can be "NULL" if inapplicable.
TYPE can be NT or WIN or NFS or FTP or NETWARE.
SHARE the host data can have one or more shares or directories listed.
For each entry, select Add to add the host and share to the list.
- Some examples are:
When finished, select Submit from the bottom of the page.
Log in to the iPlanet Portal Server desktop.
Start NetFile or NetFile Lite application.
Defining Systems and Shares at the Role Level
Log in to the iPlanet Portal Server administration console as the Super Administrator.
To view the defined systems or shares in NetFile, the end-user must perform the following steps:Expand the key next to Applications and select NetFile.
Modify the common host data attribute in the prepopulated Host list/type and share information field.
- To modify the common host data attribute, use the following format to enter the name, domain, type, and share information:
- name=fully_qualified_host_name|domain=domain_ name|type=host_type|share=share_directory
NAME is the remote host name
DOMAIN is the NT/WIN domain. The domain field can be "NULL" if inapplicable.
TYPE can be NT or WIN or NFS or FTP or NETWARE.
SHARE the hostdata can have one or more shares or directories listed.
For each entry, select add to add the system and share to the list.
- Some examples are:
When finished, select Submit from the bottom of the page.
Note End users are not able to delete defined hosts and shareseven if they remove them and choose to save their session upon exit.
Login to the iPlanet Portal Server desktop.
Start NetFile or NetFile Lite application.
Defining Systems and Shares at the User Level
Log in to the iPlanet Portal Server administration console.
To view the defined systems or shares in NetFile, the end-user must perform the following steps:Expand the key next to Applications and select NetFile.
Modify the common host data attribute in the prepopulated Host list/type and share information field by entering the common host data in the following format:
- To modify the common host data attribute, use the following format to enter the name, domain, type, and share information:
- name=fully_qualified_host_name|domain=domain_ name|type=host_type|share=share_directory
NAME is the remote host name
DOMAIN is the NT/WIN domain. The domain field can be "NULL" if inapplicable.
TYPE can be NT or WIN or NFS or FTP or NETWARE.
SHARE the hostdata can have one or more shares or directories listed.
For each entry, select add to add the system and share to the list.
- Some examples are:
When finished, select Submit from the bottom of the page.
Note End users are not able to delete defined hosts and shareseven if they remove them and choose to save their session upon exit.
Login to the iPlanet Portal Server desktop.
Start NetFile or NetFile Lite application.
Defining Hidden Shares
Administrators and desktop users can define NT hidden shares for use in NetFile. The Common Host Data attribute allows administrators to define NT hidden shares through the administration console. The procedure for defining hidden shares through the administration console is the same as that for defining regular shares. See Defining Systems and Shares at the Domain and User Levels from the Administration Console."Desktop users can add hidden NT shares the same way they would add a regular share as long as they use the correct user name and password for the hidden share.
Alphabetized Shares on Windows NT System
Windows NT shares in NetFile are alphabetized. Because all shares on a Windows NT system are automatically displayed when a user double-clicks a system name, alphabetizing the list of shares makes it easier to locate the desired share.
Addition of smb.conf Parameter to smbclient Command
The smb.conf parameter has been added to the smbclient command. The smb.conf parameter allows NetFile to display ISO8859-1 character sets in file names and provides a way for administrators to configure the NetFile application to take advantage of other smbclient features.An example smb.conf file which could be used for the Portal Server follows:
An accompanying map file, which would need to be in /opt/samba/lib/users.map, might look like:
For more information about Samba-specific configurations, refer to the samba website at:
- http://samba.org/samba
NetFile Usability Enhancements
The Service Pack 3a product offers the following NetFile enhancements that make NetFile easier to use.
NetFile files can be opened by double-clicking the file name.
Multiple files can be selected for download.
The maximum file size for uploading files with the NetFile application has been increased to 500MB. NetFile Lite still has a maximum file size of less than 5 MB.
Using a Load Balancer in Open Portal Mode
With Service Pack 3a, iPlanet Portal Server supports using a load balancer in open portal mode.In order for the iPlanet Portal Server server to work with a load balancer in open mode, the load balancer must support persistent connections, sometimes referred to as sticky sessions based on cookies. If the load balancer supports persistence based on a cookie name and value this feature must be enabled.
If the iPlanet Portal Server environment includes a load balancer, and a URL scraper channel that references material from a server, other than the iPlanet Portal Server server, that material is looked up from the server on which it sits. For example, server names in an image's URL are visible in the browser's page information window, and the browser will access those images without using the load balancer.
For this feature to work correctly, the load balancer must be able to recognize the cookie on the first reply from portal. It should then continue to send all requests with that cookie name and value to that same server. Some cookie persistence algorithms will not recognize the cookie on the reply, but on the post or get to the server. This type of cookie persistence will not work since the first and second request can end up on different servers.
If the load balancer does not support this type of cookie persistence algorithm, but it supports load balancing to specific servers based on the presence of a cookie name and value, then edit the appropriate platform.conf file to configure cookie values on each server.
Each server defines a special cookie that the load balancer will be configured to recognize and always forward requests with that cookie to that specific server. Each portal server instance will set this cookie along with the usual portal session cookie.
Cookies can be used to establish session persistence between some load balancers and the iPlanet Portal Server servers.
To Use a Load Balancer in Open-Portal Mode:
Set up a load balancer to the servers.
As root, add the following lines to the platform.conf file.
In the administration console, add the load balancer cookie domain name to the Cookie Domain List.
- This step is only required if the load balancer being used supports load balancing to specific servers based on the presence of a cookie name and value. Refer to the documentation shipped with the load balancer to determine if this step is required.
ips.lbcookie.name=<iPSlbCookie> ips.lbcookie.value=<some_unique_server_string>
- This step is optional. If the load balancer domain name is the same as the domain name of the servers, this step is not necessary.
- To add the load balancer domain name to the server's Cookie Domain List:
Login to the administration console as the super administrator.
Add the load balancer name to Domain URLs list:Add the load balancer domain name to the Cookie Domain List and select Add.
Select Submit.
- For example, if the cookie domain is sun.com, add the domain name in the following way. Note the preceding ".":
In the administration console, select the desired domain.
Edit the URL for channels that reference their content from the iPlanet Portal Server 3.0 server.Add the load balancer name three times to Domain URLs list. The following example assumes that the load balancer domain name is sun.com. Add the load balancer URL in the following ways (shown in bold):
siroe.sun.com siroe.sun.com/sun.com siroe.sun.com/login 192.168.66.15 192.168.66.15/sun.com 192.168.66.15/login www.sun.com www.sun.com/sun.com www.sun.com/login
Note This step is not for channels that point to external content. It is useful for portal-related content that is displayed in channels.
In the administration console, select the desired domain.
Click the key next to Applications to expand the list choices, and select Desktop.
Edit the URL scraper channels that reference their content from the server. Change the attribute to a relative URL by removing the protocol, server and port number from the URL.
Select Submit.
- For example, if the URL scraper channel value is:
http://siroe.sun.com:8080/ipinfo.html
- Change the URL attribute so that the value is:
Loading Multiple Attributes in One Profile Request
This feature allows the desktop and other applications to load multiple attributes from multiple components in one operation. A new method called Profile.loadAttributes can be used to load multiple attributes in one profile request by passing in a set of attribute names that can contain wildcards for multiple profile components. The returned attribute values are cached in the profile object which allows a subsequent call to retrieve these attributes faster thereby improving overall iPlanet Portal Server performance.The parameter name is attributeNames. The value is a set of attribute names that can contain wildcard characters.
public void loadAttributes(Set attributeNames) throws ProfileException
Short-Circuiting for Session and Logging Requests
Short-circuiting for session and logging requests is a performance enhancement that reduces the number of HTTP requests for logging and session services, thereby improving the overall performance of the iPlanet Portal Server product.Short-circuiting works in the following way. If the logging client and the logging server are in the same JVM, the http connection is bypassed during client and server communication. Likewise, if the session client and the session server are in the same JVM, there is no http connection in order for them to communicate. Short-circuiting also eliminates XML parsing for session and logging requests, enhancing overall performance.
Running Desktop Applications on a Macintosh Client
Service Pack 3a supports the ability to run the NetFile, NetMail, and Netlet applications on Macintosh client computers.The NetFile and NetMail applications work on a Macintosh similar to the way they work on other supported platforms. However, the Netlet application, when used on a Macintosh, does not support the dynamic loading feature; if the Netlet is enabled, Macintosh clients automatically load the Netlet when the Netlet Channel is enabled on the desktop.
Table 8 lists the minimum system requirements for running the Netlet, NetMail, and NetFile applications on a Macintosh client.
Table 8 Minimum system requirements for running the Netlet, NetFile, and NetMail applications on a Macintosh client
Unlimited Netlet Connections
The Netlet now supports an unlimited number of connections per Netlet rule. This change is beneficial if an application running through the Netlet requires many connections per Netlet rule.
Netlet Windows
The Service Pack 3a product adds an interim status window when a Netlet connection is established. This window lets the user know when the Netlet is finished loading. The contents of this interim window can be changed by modifying the nc3 value in the following file:
To edit the message displayed in the status window when a static rule has been defined for the current user, see the following file example, and edit as shown in bold text:
- <install_dir>/SUNWips/locale/iwtNetletServlet.properties
The values in the following file are used when a Macintosh client attempts to use an automatic proxy configuration file, or when the Netlet cannot determine the Macintosh browser's proxy settings:
- iwtNetletProvider.properties
The following file shows values that are used when the Netlet is started from a link within the Netlet channel itself; as opposed to being launched following a successful login as is the case with a static rule. The nc4 value, and the contButton value are displayed in the intermediate status window:
- iwtNetletApplet.properties
- iwtNetletServlet.properties
Enabling Secure FTP Using a Netlet Connection
Service Pack 3a is designed to provide FTP service to a single FTP Server, with controlled end user accounts, which will make for secure remote FTP transfers from an end user system to a single location.Without having a username, an FTP URL is interpreted as an anonymous FTP connection.
Note You must define port 30021 as the client port for your Netlet FTP rule.
For example a secure FTP URL would be shown as:
Setting up the FTP service to a single FTP server can be done using a static Netlet rule added to a users' desktop. This enhancement does not support dynamic FTP using a Netlet connection.And an anonymous FTP URL shown as:
- ftp://username@localhost:30021
- ftp://localhost:30021
Setting up the Static Netlet Rule
The Netlet enhancement requires creating a Netlet rule which will listen for FTP requests.Create a static FTP Netlet rule for the Default Role as follows:
As root, login to the Portal console at:
Select Manage Domains and the domain to set the Netlet rule.
- http://server.domain.subdomain:port/console
Expand the key next to Applications.
Select form field below the Netlet Rules text area and add a Netlet rule similar to this:
Select add below the form field and then Submit at the bottom of the page
- ftp|null|false|30021|your_ftp_server.your_domain|21
Using the Netlet Proxy
The Netlet proxy is used for the following reasons:
To minimize the use of extra IP addresses and ports from the Gateway through an internal firewall in a significantly sized deployment environment.
To provide encryption for each transaction through the Netlet to the iPlanet Portal Server server from the gateway to the platform server. The Netlet proxy offers improved security benefits through data encryption but may increase the use of system resources.
Note If configuring the iPlanet Portal Server 3.0 to run as nobody with the netlet utility, see Configuring the Gateway Component to Run as User Nobody," before reading these instructions.
Figure 1 Netlet Proxy Implementation
Configuring the Netlet Proxy
In the iPlanet Portal Server Administration Console, do the following:
Logon as root.
Select the Gateway Management link from the left frame.
Select the Manage Gateway Profile link in the right frame.
In the Component Profile: Gateway page, do the following:
Scroll to the end of the page and select the Show Advanced Options button.
Select the Continue button on the Profile Successfully Updated page.Scroll to near the bottom of the page to the Netlet Proxy Enabled check box, and select the box to enable the netlet proxy.
In the Netlet Proxy Port, enter the desired (unused) port number to be used (for example: 8048).
Tip From the command line, enter: To determine if the port desired is available and unused.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
Configuring Restart of the Netlet Proxy
To configure a automatic restart of the Netlet proxy whenever rebooting the system server, use the command line interface on the iPlanet Portal Server server to do the following:
Note If using more than one iPlanet Portal Server server, repeat these steps for each server. Configure the Netlet Proxy in the iPlanet Portal Server Administration Console before starting the portal server and gateway. See Using the Netlet Proxy" for instructions.
This will automatically start the netlet proxy when the machine is rebooted.
This will not automatically start the netlet proxy when iPlanet Portal Server 3.0 is restarted using ipsserver start.
Using Automatic Proxy Configuration with the Netlet
In Service Pack 3a, the Netlet applet can be used with web browsers that are configured to use automatic proxy configuration (PAC) files. The automatic proxy configuration feature is supported in the Netscape Navigator and Internet Explorer browsers. For detailed information about atuomatic proxy configuration and PAC files, see the Netscape Developer's website.
Rewriting Javascript Functions Parameters in Javascript
The gateway will rewrite JavaScript variables or JavaScript functions according to any other existing rules specific to that variable, or that function, in the gateway profile.The gateway will try to rewrite the matched parameters. A matched parameter in JavaScript is either in the form of a JavaScript variable or a JavaScript function.
The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Function Parameters list. Each entry in the list has the following syntax:
java_script_function_name: [y|], [y|], ...
<script language="JavaScript"> func1("func2('url2');", 500, "var var3='url3'"); </script> </html> The gateway will try to rewrite func2 and var3.
If there is an entry var3 in Rewrite JavaScript Variables in URLs, then url3 will be rewritten
If there is an entry func2:y in Rewrite JavaScript Function Parameters list, then url2 will be rewritten
Rewriting JavaScript Variables in JavaScript
The entries in this list are the names of the JavaScript variables which are in turn expressed in JavaScript, and which will be rewritten by the gateway.The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Variables in JavaScript list.
If the list has the following entries:
and the rewriter's input is:
<script language="JavaScript"> var jsvarjs1 = "var var1 = 'url1';" + some_var; var jsvarjs2 = "func2('url2');" + some_var; </script> </html> The gateway will try to rewrite the right-hand sides of both jsvarjs1 and jsvarjs2.
If there is an entry var1 in Rewrite JavaScript Variables in URL, then url1 will be rewritten
If there is an entry func2:y in Rewrite JavaScript Function Parameters list, then url2 will be rewritten
Rewriting JavaScript Function Parameters Function
The gateway will wrap the matched parameters with a function called iplanet, which will do the actual rewriting when the browser interprets the page.The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Function Parameters Function list. Each entry is this list has the following syntax:
If the list has an entry:
- java_script_function_name: [y|], [y|], ...
<script language="JavaScript"> ... func1("http://" + some_func() + some_var); </script> </html> Then the output will become:
<html> <script language="JavaScript"> ... func1(iplanet("http://" + some_func() + some_var)); function iplanet(url) { ... } </script> </html> The iplanet function is the same as described in Chapter 8 of the iPlanet Portal Server 3.0 Administration Guide Rewriting JavaScript Variables Function.
Rewriting Applet/Object Parameter Values List
The Rewrite Applet/Object Parameter Values list can be edited by using the iPlanet Portal Server administration console's Gateway Profile page. Each entry in this list has this syntax:
object_of_applet/object_url applet_class/object_classid applet/object_parameter_name [url_pattern]
If url_pattern is omitted, the value of the applet/object parameter is examined as a single URL, and the gateway will rewrite accordingly.
If the gateway receives a request for the URL:If url_pattern is included, then the gateway will rewrite according to the pattern matching.
The url_pattern consists of *, or **, plus the separation character used in the original parameter value to separate multiple fields, one wild card (*) matches any field which is not to be rewritten, and two wild card (**) matches any field which is to be rewritten.
The separation character, for example, could be "," or "|".The last field to be rewritten does not have to be indicated by **, that is the url_pattern matches the start of the string in the parameter value, then the remainder of the value will be considered a URL to be rewritten.
http://some_server/some_dir/some.html
Then if the Rewrite Applet/Object Parameter Values List contains the following example entries, the corresponding URLs will be rewritten as noted in Table 9 below:
Choice Property Keys
This feature allows the user to see the visible changes in the locale of choice.When editing the profile, for channels created with the channel wizard in a non-English locale, the administrator will now see the choices translated in the chosen language of the locale.
File Lookup
In Service Pack 3a, a generic file path search utility for all data file types has been added to support the iPlanetTM Portal Server: Mobile Access Pack architecture.All components will use the use the same utility for file lookup, including:
This file lookup utility uses a combination of attributes to create a list of file paths to search.These attributes include:
For more information about the attributes, see "Appendix A" of the iPlanet Portal Server:Mobile Access Pack Programmer's Guide.
The following example asks for filename foo.template with the values:
The File Lookup utility will search the following paths in order and return the first file, with the given filename, that is encountered:
isPresentable() Method Added to the Provider API
In the Mobile Access Pack architecture, each channel is responsible for identifying itself as able to present content for a particular client type. Each channel has access to the client type via the session, and is therefore capable of making the decision as to whether it supports the output format for this client type.A channel determines if it is presentable by indexing the client data based on the client type stored in the iPlanet Portal Server 3.0 session. The channel can use any of the client data elements to determine whether it is presentable. For example, in the simplest case the channel may determine that it only supports clients where:
Each channel must be asked whether it supports the client type before output is gathered and returned to the user. So for each place in the desktop core where content is gathered, the channel generating the content must first be asked if it can produce this output format.
- contentType=text/html
An iPlanet Portal Server 3.0 channel can generate content from two methods:
The Provider.getContent() returns the main channel content. The Provider.getEdit() returns an edit page for the channel.
A channel will be able to signal the desktop that it supports output of the main content or the edit page separately for different devices.
A new Provider API method will answer whether the channel can return main channel content for the particular client:
The isPresentable() method is part of the Provider interface and is implemented in the ProviderAdapter.
- public boolean isPresentable();
Setting Session Time-out to the Maximum Value
The session time out unit of measurement is in minutes. In the Administration console, do the following to set the session time-out to the maximum possible value:
As Super Administrator, login to the iPlanet Portal Server administration console.
Select the name of the desired domain.
Select Session under Profiles.
Make value of Maximum Idle Time to the maximum value of: 153722867280912930.
Make value of Maximum Session Time to the maximum value of: 153722867280912930.
Deprecated Features in Future Releases
The following features and products will no longer be supported in future releases of the iPlanet Portal Server product.
Firewall software that is currently included with the iPlanet Portal Server product
Although the GraphOn client, Citrix software, and PCAnywhere Java client will no longer be included as third party software with the iPlanet Portal Server product, they will continue to work with the iPlanet Portal Server product and will be available from their respective websites.GraphOn server and client (client still available for download)
Citrix (available for download)
Software and Hardware Requirements
This section describes the system requirements for Service Pack 3a software. The system requirements depend on how the iPlanet Portal Server 3.0 product is used.
Table 10 describes the system requirements for developing a portal.
Table 11 describes the system requirements for deploying a portal.
Table 10 System Requirements for Developing a Portal
Each server component of iPlanet Portal Server 3.0 should have a minimum of 256 MB of memory.
If the installation directory is /opt, increase this partition to 1.5 GB
Required or recommended Solaris patches are located in ./patches/<solaris_version>/<solaris_version_patch_cluster>. For more information on installing the required or recommended patches, see Installing the Required Solaris Patches From the Download."
The gateway needs more than one network interface, if a firewall is installed on its machine.
Netscape Communicator v 4.06 or higher (except v4.6) or Microsoft Internet Explorer v4.0 or higher with SSL v3.0.
Table 11 System Requirements for Deploying a Portal
One GB of memory per two-CPU setup. Two GB in swap space for the portal server.
If the installation directory is /opt, increase this partition to 1.5 GB
Required or recommended Solaris patches are located in ./patches/<solaris_version>/<solaris_version_patch_cluster>. For more information on installing the required or recommended patches, see Installing the Required Solaris Patches From the Download."
The gateway needs more than one network interface, if a firewall is installed on its machine.
Netscape Communicator v 4.06 or higher (except v4.6) or Microsoft Internet Explorer v4.0 or higher with SSL v3.0.
The PATH environment for the administrative user must include /usr/sbin:/usr/bin.
Service Pack 3a Installation Notes
The iPlanet Portal Server 3.0 Service Pack 3a is a cumulative service pack. It includes all Service Pack 1, Service Pack 2, Service Pack 3a bug fixes and related hotpatch fixes. It can be used to install the iPlanet Portal Server product as a new install on a machine with no previous installations of the iPlanet Portal Server software, and to upgrade the following installations:
Software Dependencies for the Service Pack 3a Upgrade
The iPlanet Portal Server Service Pack 3a installation process provides the following dependency upgrades to the iPlanet Portal Server 3.0 product.
iPlanet Directory Server (iDS) 4.14
iPlanet Web Server (iWS) 4.1 SP7
JSS 2.1 which includes NSS 2.8.4
Note Certificates installed on the gateway component for the previous SSL library are automatically converted to the format required by NSS when Service Pack 3a is installed.
Accessing The Service Pack 3a (iPS3.0SP3-01) Software
The iPlanet Portal Server 3.0 Service Pack 3a (iPS3.0SP3-01) software can be accessed two ways:Refer to the following release note sections:
Contents of iPS3.0SP3-01.tar for a description of the software packages from the web
Contents of iPlanet Portal Server 3.0 Service Pack 3a CD-ROM for a description of the software packages on the CD-ROM
Contents of iPS3.0SP3-01.tar
The iPlanet Portal Server 3.0 Service Pack 3a (iPS3.0SP3-01) software can be downloaded from the iPlanet web page as a series of compressed files. Once assembled, the following directories and files are included in iPS3.0SP3-01.tar. For instructions on downloading and assembling the compressed files see Downloading Service Pack 3a Software From the iPlanet Web Page.
iPlanet Portal Server Service Pack 3a packages and scripts
Contents of iPlanet Portal Server 3.0 Service Pack 3a CD-ROM
The iPlanet Portal Server 3.0 Service Pack 3a software are available on a CD-ROM. The following directories and files are included in the CD-ROM package. For instructions on accessing the CD-ROM, see Accessing Service Pack 3a Software From the CD-ROM.
iPlanet Portal Server Service Pack 3a packages and scripts
Preparing for Installation
Before you begin installing Service Pack 3a, see the following sections for pre-installation tasks.
Installed Software Modules, Customizations, and Third Party Products
Downloading Service Pack 3a Software From the iPlanet Web Page
Accessing Service Pack 3a Software From the CD-ROM
Installing the Required Solaris Patches From the Download
Stopping the Server Component Processes
Stopping the Proxies and the Gateway Component's Processes
Saving the Certificates Used by the Server Component
Stopping the Third-party Software Processes and the Channels
Note When using the tar and ps commands called for in the following procedures, use the commands found in /usr/bin.
Installed Software Modules, Customizations, and Third Party Products
If iPlanet Portal Server 3.0 software has been previously installed and other modules have been configured to run on top of this software, it is important to read all release notes and updates that pertain to the added modules. It may be required to install patches and additional configuration steps. Also, any customizations must be backed up or documented before Service Pack 3a is installed, so the customizations can be implemented again after the upgrade.Third party software that was originally included as a separate CD with the iPlanet Portal Server product, is available for download from the iPlanet website, www.iplanet.com. The iPlanet website contains a third party download directory in which the third party software file, ThirdParty.tar.gz, is located.
Instructions for installing third party products shipped with iPlanet Portal Server 3.0 remain the same for the Service Pack 3a release as for the iPlanet Portal Server 3.0 release. See "Appendix B" in the iPlanet Portal Server Installation Guide for instructions on installing third party software shipped with the iPlanet Portal Server product.
Downloading Service Pack 3a Software From the iPlanet Web Page
The iPlanet Portal Server 3.0 Service Pack 3a software package is available from the iPlanet.com web page:
The software package has been split into twelve 20-Megabyte files to make the Service Pack 3a product easier to download. In addition to downloading the Service Pack 3a compressed files, download the checksums file and the assembleiPS3SP3 script for assembling the individual files into a single Service Pack 3a. The following instructions describe how to check the integrity of the files once they have been downloaded and how to assemble the files for installation.
- http://iplanet.com/downloads/patches
Note If the iPlanet Portal Server 3.0 installation contains individual gateway and platform servers, the Service Pack 3a package must be installed on both servers.
In a terminal window, become root.
Change directories to /opt and create a directory in which to download the Service Pack 3a files. For example
Download the following files into the directory created in Step 2.
iPS3.0SP3-01.tar.gz.aa
In /opt/ips_sp3, run the assembleiPS3SP3 script to verify that the files are all present and that the file data has not been corrupted.iPS3.0SP3-01.tar.gz.ai (On the ftp site, this file is named iPS3.0SP3-01.tar.gz.es)
# cd /opt/ips_sp3/
# ./assembleiPS3SP3
Run the gunzip command to extract the iPS3.0SP3-01.tar.gz file.
- If the script determines that the correct number of files are present and that their data has not been corrupted, a single tar file iPS3.0SP3-01.tar.gz is created, which contains all the Service Pack 3a packages.
Run the tar command to extract the contents of the iPS3.0SP3-01.tar file.
# /usr/bin/tar -xvf iPS3.0SP3-01.tar
Note Use the Solaris version of the tar command.
Installing the Required Solaris Patches From the Download
The iPlanet Portal Server product is shipped with Solaris patches that are required or recommended for the iPlanet Portal Server software. The directory /opt/ips_sp3/patches contains patch directories for each supported version of Solaris. Use the patches in the directory that corresponds to the version of Solaris on which you are installing the iPlanet Portal Server product. Solaris patches are periodically updated, and can be downloaded from www.sunsolve.sun.com.To install the required or recommended Solaris patches:
As root, change directories to the patch directory that corresponds to the version of the Solaris operating system on which the iPlanet Portal Server product is installed. For example, if the iPlanet Portal Server product is installed on Solaris 8:
# cd /opt/ips_sp3/patches/solaris8/solaris_2.8_patch_cluster Run the install_cluster installation script:
Accessing Service Pack 3a Software From the CD-ROM
To Access the Service Pack 3a Release Notes
As root, change directories to the document directory. The Service Pack 3a Release Notes are available in two document formats in this directory. Both formats can be copied to the hard disk, and accessed for future reference.
# cd /cdrom/cdrom0/docs/<document_format>/
Installing the Required Solaris Patches From the CD-ROM
As root, change directories to the patch directory that corresponds to the version of the Solaris operating system on which the iPlanet Portal Server product is installed. For example, if the iPlanet Portal Server product is to be installed on Solaris 8:
# cd /cdrom/cdrom0/patches/solaris8/solaris_2.8_patch_cluster Run the install_cluster installation script:
Stopping the Server Component Processes
Before upgrading or installing the Service Pack 3a software, stop the following services:
Directory server
Note The following instructions assume that the installation directory is /opt.
Issue the following command to see which directory server and web server processes are running. By viewing the processes that are currently running, you can reissue the command after stopping the processes to verify that have been stopped.
Stop the iPlanet Portal Server server component. This step stops the directory server and web server processes.
- In this example, the process id numbers correspond with the following processes.
If running iPlanet Portal Server 3.0 or iPlanet Portal Server Service Pack 1, start and stop the server component.
Verify that all directory server and web server processes are stopped. The processes that were running in Step 1 should no longer be displayed.
If running iPlanet Portal Server Service Pack 2, stop the server component.
# /etc/init.d/ipsserver stopall stopping auth helpers ... done. stopping web server ... done. stopping directory server ... done.
# /usr/bin/ps -eo pid,args | grep /opt/netscape
Stopping the Proxies and the Gateway Component's Processes
Before upgrading to or installing Service Pack 3a, the following processes need to be stopped.
ipshttpd proxy process
Issue the following command to see which gateway processes are running. By viewing the processes that are currently running, you can reissue the command after stopping the processes to verify that have been stopped.
Stop the ipshttpd or ipsnetletd proxies that are running on the server component.
- In this example the process id numbers correspond with the following processes.
481 ipshttpd process 503 ipsnetletd process 741 gateway process
# /opt/SUNWips/bin/ipshttpd stop
# /opt/SUNWips/bin/ipsnetletd stopStop the iPlanet Portal Server gateway component.
Verify that the processes have been stopped. The processes that were running in Step 1 should no longer be displayed.
# /usr/bin/ps -eo pid,args|grep java
Stopping the Third-party Software Processes and the Channels
Before performing a clean installation of or upgrading to Service Pack 3a, stop all iPlanet Portal Server third-party software and channels that push data to the iPlanet Portal Server product.It is especially important to stop channels that push data to the iPlanet Portal Server product because some channels write into iPlanet Portal Server directories. For example, iSyndicate writes to /var/opt/SUNWips/debug which interferes with Service Pack 3a.
Consult the manuals for each channel and for third-party software for instructions on shutting down.
Saving the Certificates Used by the Server Component
If using certificates on the iPlanet Portal Server server component, save the certificates in a safe location before the upgrade process, and restore them after the upgrade is complete.The following procedure assumes that /opt is the installation directory.
As root, change directories to the certificate directory. In the following example, /opt is the base directory.
See Upgrading to Service Pack 3a" for instructions on upgrading the iPlanet Portal Server product to Service Pack 3a.
Create a tar file of the alias directory and copy it to a safe location. In the following example the compressed alias directory is copied to /usr/tmp.
# tar cf /usr/tmp/alias.tar alias
Installation Instructions
The Service Pack 3a installation script offers the choice of upgrading the existing version of the product or performing a clean installation of the product. Choosing the upgrade option upgrades the iPlanet Portal Server product to Service Pack 3a.Performing a clean installation removes all aspects of a previous iPlanet Portal Server software installation. A clean installation can be useful if an existing installation has problems that might be resolved by a fresh installation.
Note The Service Pack 3a software can also be installed as a new iPlanet Portal Server installation requiring no previous iPlanet Portal Server installations.
Sample Machine Names
The following table lists the machine names used in code examples and the types of iPlanet Portal Server components to which they correspond.
iPlanet Portal Server server component acting as the profile server
iPlanet Portal Server server component not being used as the profile server in multiple server installations
The installation procedures documented in this section are categorized based on the following types of installations. Select the installation procedures which best suit the type of installation you want to perform.
Upgrading to Service Pack 3a
Standard Upgrade
Clean installationUpgrading a User Non-Root Installation to Service Pack 3a
Upgrading User Nobody to Service Pack 3a
Open-portal Installation Using a Single Machine
Open-portal Installation Using Multiple Machines
Secure Portal Installation Using a Single Server (Followed by gateway component installation)
Secure Portal Installation Using Multiple Servers (Followed by gateway component installation)
Gateway Component Installation
Note If this is an upgrade of user non-root, or user nobody, go to the appropriate sections in these release notes.
Standard Upgrade
If the Samba software has been installed, this procedure removes it. The Samba software, along with other third party software originally shipped with the iPlanet Portal Server product, is contained in a file called ThirdParty.tar.gz and can be downloaded from the www.iplanet.com website. See "Appendix B" in the iPlanet Portal Server Installation Guide for instructions on installing the Samba software.To upgrade the iPlanet Portal Server software:
Backup the iPlanet Portal Server 3.0 installation.
If the iPlanet Portal Server processes are running, stop all iPlanet Portal Server processes.
- See Stopping the Server Component Processes.
Accessing the Install Script From the CD-ROM
As root, mount the Service Pack 3a CD-ROM.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.Change directories to /cdrom/cdrom0 and run the ipsinstall script.
# volcheck
# cd /cdrom/cdrom0
# ./ipsinstall
Accessing the Install Script From the Service Pack 3a Directory
As root, change directories to /opt/ips_sp3.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.
The iPlanet Portal Server 3.0 Service Pack 3a Install Script
The following examples are the install script prompts for this installation.
The installation script displays the Service Pack 3a license agreement.
The script displays the following status:
Accept the default values or enter the correct name and IP address information.
- Enter yes to accept the license agreement and continue with the installation.
Note If the installation script detects missing Solaris patches, a warning message is displayed. See Installing the Required Solaris Patches From the Download, or Accessing Service Pack 3a Software From the CD-ROM, for information on installing the necessary Solaris patches.
- The installation script attempts to determine name and IP address information about the machine on which you are installing. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the portal.
Enter 1 to upgrade an existing iPlanet Portal Server installation.
- The script displays the task menu.
Note If any of the iPlanet Portal Server processes are still running, the installation script displays a warning message and process information. If the processes detected by the script are related to the iPlanet Portal Server, abort the upgrade, and stop the processes before proceeding. See Stopping the Server Component Processes" and Stopping the Proxies and the Gateway Component's Processes" for instructions.
When the upgrade process is finished, your screen prompt is returned. Look in /var/sadm/install/logs/ipsinstall.<process.id>/install.log to verify that no errors in the upgrade have occurred.
If your previous iPlanet Portal Server installation was customized, see Restoring Customizations" for more information.
Restoring Customizations
If you performed customizations on your previous iPlanet Portal Server installation, the installation script saves these customizations in /var/sadm/install/logs/ipsinstall.<process_id>. Generally, the same steps used for the initial customizations development can be used when reinstating your customizations into Service Pack 3a installation. If you reinstate previous customizations, run the iPlanet Portal Server product to verify that your customizations still work. Certain customizations could be affected by changes in Service Pack 3a.
Tip By using the diff command to compare pre-Service Pack 3a files and the new Service Pack 3a files, changes can be viewed so that previous customizations can be reinstated.
See After Installation" for information on Restoring Certificates.
Clean installation
The instructions for performing a clean installation of the iPlanet Portal Server Service Pack 3a server and gateway components may be any of the following:
A new version of iPlanet Portal Server software can be installed on a new machine
If the Samba software has been installed, performing a clean installation in which the previous installation is removed also removes the Samba software. The Samba software, along with other third party software originally shipped with the iPlanet Portal Server product, is contained in a file called ThirdParty.tar.gz, which can be downloaded from the www.iplanet.com website. See "Appendix B" in the iPlanet Portal Server Installation Guide for instructions on installing the Samba software.A previous version of an iPlanet Portal Server software is installed
- If the Service Pack 3a is being installed on a machine where an existing version of iPlanet Portal Server software is already installed, the existing version will be removed completely and replaced by the new installation.
Open-portal Installation Using a Single Machine
In open-portal mode, the gateway, which provides encryption services and URL rewriting, is not required. For more information, see Open Portal Mode."To install the server component on a single machine:
Backup the iPlanet Portal Server 3.0 installation.
If the iPlanet Portal Server processes are running, stop all iPlanet Portal Server processes.
- See Stopping the Server Component Processes.
Accessing the Install Script From the CD-ROM
As root, mount the Service Pack 3a CD-ROM.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.Change directories to /cdrom/cdrom0 and run the ipsinstall script.
# volcheck
# cd /cdrom/cdrom0
# ./ipsinstall
Accessing the Install Script From the Service Pack 3a Directory
As root, change directories to /opt/ips_sp3.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.
The iPlanet Portal Server 3.0 Service Pack 3a Install Script
The following examples are the install script prompts for this installation.
The installation script displays the Service Pack 3a license agreement.
After the installation process has been completed, the script automatically starts the server component.
Accept the default values or enter the correct name and IP address information.
- Enter yes to accept the license agreement and continue with the installation.
Note If the installation script detects missing Solaris patches, a warning message is displayed. See Installing the Required Solaris Patches From the Download, or Accessing Service Pack 3a Software From the CD-ROM, for information on installing the necessary Solaris patches.
- The installation script attempts to determine name and IP address information about the machine on which you are installing. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
Choose 2 to perform a fresh installation of the iPlanet Portal Server components.
- The script displays the task menu.
The script displays the component menu.
- In the event that this installation is a new installation on a new machine the prompts in the install script will not state that a current installation will be removed.
Accept the default installation directory, or enter another directory in which to install.
- Choose 1 to install the server component.
1) iPlanet(TM) Portal Server 2) iPlanet(TM) Portal Server: Secure Remote Access Pack (Gateway) 3) Exit Choice? [3] 1
What directory to install in? [/opt] Choose y for an open-portal installation.
Will this be an open portal install? y/[n] Choose whether you want to use Secure Sockets Layer (SSL) to communicate with the server component. SSL provides encrypted communication to the server. For information about using SSL with the iPlanet Portal Server product, see the iPlanet Portal Server Administration Guide.
Are the servers using SSL protocol? y/[n] Choose n for a single server installation.
Is this a multiple server install? y/[n] Accept the default profile server port number or enter an available port number.
The profile server will run on siroe.iplanet.com
On what port will the profile server run? [8080]Press Return to accept the default for the role tree root, or enter another name.
What is the root of the profile role tree? [iplanet.com]
Accept the default or enter the correct name for the root user.
What is the user for the profile role tree? [root] Accept the default port number for the directory server, or enter an available port number.
On what port will the directory server run? [389] Accept the default administrator port number or enter an available port number.
What is the administrator port for the web server? [8088]
Enter and verify the passphrase.
- The installation script prompts you to enter and verify a passphrase. This passphrase is not the root user's password. It is used internally for SSL communication to the server and for access to the iPlanet Webserver administration console.
What is the passphrase (8 chars minimum) :
Re-enter passphrase :
Answer y to install the server. The installation script installs the server packages.
- The installation script displays the settings and asks if they are correct.
For information on configuring multiple-instances of the iPlanet Portal Server product on a single server machine, see Configuring Multiple Instances of iPlanet Portal Server."
Open-portal Installation Using Multiple Machines
In open-portal mode, the gateway, which provides encryption services and URL rewriting, is not required. For more information, see Open Portal Mode."
Note If installing the server component on multiple machines, designate only one machine as the profile server, and configure the other servers to reference that machine as the profile server.
To install the server component:
Backup the iPlanet Portal Server 3.0 installation.
If the iPlanet Portal Server processes are running, stop all iPlanet Portal Server processes.
- See Stopping the Server Component Processes.
Accessing the Install Script From the CD-ROM
As root, mount the Service Pack 3a CD-ROM.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.Change directories to /cdrom/cdrom0 and run the ipsinstall script.
# volcheck
# cd /cdrom/cdrom0
# ./ipsinstall
Accessing the Install Script From the Service Pack 3a Directory
As root, change directories to /opt/ips_sp3.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.
The iPlanet Portal Server 3.0 Service Pack 3a Install Script
The following examples are the install script prompts for this installation.
The installation script displays the Service Pack 3a license agreement.
After the installation process has been completed, the script automatically starts the server component. Repeat this procedure for each server component in a multiple-server environment.
Accept the default values or enter the correct name and IP address information.
- Enter yes to accept the license agreement and continue with the installation.
Note If the installation script detects missing Solaris patches, a warning message is displayed. See Installing the Required Solaris Patches From the Download, or Accessing Service Pack 3a Software From the CD-ROM, for information on installing the necessary Solaris patches.
- The installation script attempts to determine name and IP address information about the machine on which you are installing. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
Choose 2 to perform a fresh installation of the iPlanet Portal Server components.
- The script displays the task menu.
Choose 1 to install the server component.
- The script displays the following component menu.
1) iPlanet(TM) Portal Server 2) iPlanet(TM) Portal Server: Secure Remote Access Pack (Gateway) 3) Exit Choice? [3] 1 Accept the default installation directory, or enter another directory in which to install.
What directory to install in? [/opt] Choose y for an open-portal installation.
Will this be an open portal install? y/[n] y Choose whether you want to use Secure Sockets Layer (SSL) to communicate with the server component. SSL provides encrypted communication to the server. For information about using SSL with the iPlanet Portal Server product, see the iPlanet Portal Server Administration Guide.
Are the servers using SSL protocol? y/[n] Choose y for a multiple server installation.
Is this a multiple server install? y/[n] y Choose whether you want the local computer to be the profile server.
Enter y to make the local computer the profile server. If you have not already installed the profile server on another computer, you can choose y to make the local computer the profile server. Go to Step 11.
Enter n if you have already installed the profile server on another computer or if you will install the profile server on another computer. Continue with Step 10.
Should the local machine be the profile server? [y]/n
Enter the profile server information. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component. Go to Step 12.
- If the local machine is not the profile server, the installation script asks for information about the profile server.
Accept the default profile server port number or enter the correct number for the port.
- If the local machine is the profile server, the installation script asks for the profile server port number.
The profile server will run on siroe.iplanet.com
On what port will the profile server run? [8080]Press Return to accept the default for the role tree root, or enter another name.
What is the root of the profile role tree? [iplanet.com]
Accept the default root user name or enter the correct name for the root user.
What is the user for the profile role tree? [root] Accept the default port number for the directory server or enter an available port number.
On what port will the directory server run? [389]
If the local machine is not the profile server, go to Step 16.
Enter the server component information. Go to Step 17.If the local machine is the profile server, the installation script asks you the following set of questions about the server components of the Service Pack 3a product. Continue with Step 15.
Accept the default server port number for the machine on which you are installing or enter an available port number.
- If the local computer is the profile server and you specified multiple server components, the script repeats the set of questions until you have specified information for all the desired server components. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
- The script repeats the set of questions, allowing you to enter name and IP address information for each server component in a multiple server environment. Enter a "." after you have finished adding the information for all the server components.
On what port will the server run on this machine? [8080] Accept the default web server administrator port number or enter the correct port number.
What is the administrator port for the web server? [8088]
Enter and verify the passphrase.
- The installation script prompts you to enter and verify a passphrase. This passphrase is not the root user's password. It is used internally for SSL communication to the server and for access to the iPlanet Webserver administration console.
What is the passphrase (8 chars minimum) :
Re-enter passphrase :
Answer y to install the server. The installation script installs the server packages.
- The installation script displays the settings and asks if they are correct.
For information on configuring multiple-instances of the iPlanet Portal Server product on a single server machine, see Configuring Multiple Instances of iPlanet Portal Server."
Secure Portal Installation Using a Single Server
In secure mode, the gateway, which provides encryption services and URL rewriting, is required. For instructions on installing the gateway component, see Gateway Component Installation."
Note If installing a single server component, the machine on which you install must be the profile server.
To install the server component:
Backup the iPlanet Portal Server 3.0 installation.
If the iPlanet Portal Server processes are running, stop all iPlanet Portal Server processes.
- See Stopping the Server Component Processes.
Accessing the Install Script From the CD-ROM
As root, mount the Service Pack 3a CD-ROM.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.Change directories to /cdrom/cdrom0 and run the ipsinstall script.
# volcheck
# cd /cdrom/cdrom0
# ./ipsinstall
Accessing the Install Script From the Service Pack 3a Directory
As root, change directories to /opt/ips_sp3.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.
The iPlanet Portal Server 3.0 Service Pack 3a Install Script
The following examples are the install script prompts for this installation.
The installation script displays the Service Pack 3a license agreement.
If you chose not to have the script start the server component, start the server by using the following command:
Accept the default values or enter the correct name and IP address information.
- Enter yes to accept the license agreement and continue with the installation.
Note If the installation script detects missing Solaris patches, a warning message is displayed. See Installing the Required Solaris Patches From the Download, or Accessing Service Pack 3a Software From the CD-ROM, for information on installing the necessary Solaris patches.
- The installation script attempts to determine name and IP address information about the machine on which you are installing. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
Choose 2 to perform a fresh installation of the iPlanet Portal Server component.
- The script displays the task menu.
Choose 1 to install the server component.
- The script displays the component menu.
1) iPlanet(TM) Portal Server 2) iPlanet(TM) Portal Server: Secure Remote Access Pack (Gateway) 3) Exit Choice? [3] 1 Accept the default installation directory, or enter another directory in which to install.
What directory to install in? [/opt]
Note If installing the server and gateway components on the same machine, install both components in the same directory.
Enter n to perform a secure portal installation.
Will this be an open portal install? y/[n] Choose whether you want to use Secure Sockets Layer (SSL) to communicate with the server component. SSL provides encrypted communication to the server. For information about using SSL with the iPlanet Portal Server product, see the iPlanet Portal Server Administration Guide.
Are the servers using SSL protocol? y/[n] Choose n for a single server installation.
Is this a multiple server install? y/[n] Accept the default profile server port or enter the correct number for the profile server port.
The profile server will run on siroe.iplanet.com
On what port will the profile server run? [8080]Press Return to accept the default for the role tree root, or enter another name.
What is the root of the profile role tree? [iplanet.com]
Accept the default root user or enter the correct name for the root user.
What is the user for the profile role tree? [root] Accept the default port number for the directory server or enter an available number for the port.
On what port will the directory server run? [389] Accept the default port number for the gateway component or enter the correct port number.
On what port will the gateways run? [443] Choose whether the iPlanet Portal Server environment will use multiple gateways or a single gateway.
Is this a multiple gateway install? y/[n]
Enter the information for the gateway or gateways. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
- The installation script asks a set of questions about the gateway.
Note
- If you chose a multiple gateway installation in Step 14, the script repeats the set of questions so you can enter host and domain information for each gateway. Enter a "." when you are finished entering the information for all the gateways.
Choose whether the gateway should use a web proxy.
Should the gateway(s) use a web proxy? y/[n]
If you choose n, go to Step 18.
Enter the information for the web proxy.If you choose y, the installation script asks the following set of questions about the web proxy. Continue with Step 17.
On what hostname will the web proxy run? [sesta]
What is the sub-domain name for sesta ("." for none)? []
What is the domain name for sesta? [iplanet.com]
On what port will sesta run? [8080]
Note If you choose a web proxy name that is different from the name of the current machine, the script also asks for the IP address of the web proxy.
Accept the default administrator port for the web server or enter the correct port number.
What is the administrator port for the web server? [8088]
Enter and verify the passphrase.
- The installation script asks you to enter and verify a passphrase. This passphrase is not the root user's password. It is used internally for SSL communication to the server and for access to the iPlanet Webserver administration console.
What is the passphrase (8 chars minimum) :
Re-enter passphrase :Choose whether you want the script to start the server component after the installation is complete.
Start after installation completes? [y]/n
Answer y to install the server. The installation script installs the server packages.
- The installation script displays the settings and asks if they are correct.
Choose 3 to exit or 2 to install the gateway on the current machine. See Gateway Component Installation" for complete instructions on installing the gateway component.
- The installation script installs the following packages.
- When the installation is complete, the component menu is displayed.
Select which component to install:
1) Server
2) Gateway
3) Exit
Choice? [3]
For information on configuring multiple-instances of the iPlanet Portal Server product on a single server machine, see Configuring Multiple Instances of iPlanet Portal Server."
Secure Portal Installation Using Multiple Servers
In secure mode, the gateway, which provides encryption services and URL rewriting, is required. For instructions on installing the gateway component, see Gateway Component Installation."
Note If installing the server component on multiple machines, designate only one machine as the profile server, and configure the other servers to reference that machine as the profile server.
To install the server component:
Backup the iPlanet Portal Server 3.0 installation.
If the iPlanet Portal Server processes are running, stop all iPlanet Portal Server processes.
- See Stopping the Server Component Processes.
Accessing the Install Script From the CD-ROM
As root, mount the Service Pack 3a CD-ROM.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.Change directories to /cdrom/cdrom0 and run the ipsinstall script.
# volcheck
# cd /cdrom/cdrom0
# ./ipsinstall
Accessing the Install Script From the Service Pack 3a Directory
As root, change directories to /opt/ips_sp3.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.
The iPlanet Portal Server 3.0 Service Pack 3a Install Script
The following examples are the install script prompts for this installation.
The installation script displays the Service Pack 3a license agreement.
If you chose not to have the script start the server component, you can start the server component by using the following command:
Accept the default values or enter the correct name and IP address information.
- Enter yes to accept the license agreement and continue with the installation.
Note If the installation script detects missing Solaris patches, a warning message is displayed. See Installing the Required Solaris Patches From the Download, or Accessing Service Pack 3a Software From the CD-ROM, for information on installing the necessary Solaris patches.
- The installation script attempts to determine name and IP address information about the machine on which you are installing. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
Choose 2 to perform a fresh installation of the iPlanet Portal Server components.
- The script displays the task menu.
Choose 1 to install the server component.
- The script displays the component menu.
1) iPlanet(TM) Portal Server 2) iPlanet(TM) Portal Server: Secure Remote Access Pack (Gateway) 3) Exit Choice? [3] 1 Accept the default installation directory, or enter another directory in which to install.
What directory to install in? [/opt]
Note If installing the server and gateway components on the same machine, install both components in the same directory.
Enter n to perform a secure portal installation.
Will this be an open portal install? y/[n] Choose whether you want to use Secure Sockets Layer (SSL) to communicate with the server component. SSL provides encrypted communication to the server. For information about using SSL with the iPlanet Portal Server product, see the iPlanet Portal Server Administration Guide.
Are the servers using SSL protocol? y/[n] Choose y for a multiple server installation.
Is this a multiple server install? y/[n] y Choose whether you want the local computer to be the profile server.
Should the local machine be the profile server? [y]/n
Enter y to make the local computer the profile server. If you have not already installed the profile server on another computer, you can choose y to make the local computer the profile server. Go to Step 11.
Enter n if you have already installed the profile server on another computer. Continue with Step 10.
Enter the profile server information. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component. Go to Step 12.
- If the local machine is not the profile server, the installation script asks for information about the profile server.
Accept the default profile server port or enter an available number for the profile server port.
Press Return to accept the default for the role tree root, or enter another name.
- If the local machine is the profile server, the installation script asks the question:
The profile server will run on siroe.iplanet.com
On what port will the profile server run? [8080]
What is the root of the profile role tree? [iplanet.com]
Accept the default root user name or enter the correct name for the root user.
What is the user for the profile role tree? [root] Accept the default directory server port number or enter an available number for the directory server port.
On what port will the directory server run? [389]
If the local machine is not the profile server, go to Step 21.
Enter the server component information for the server components.If the local machine is the profile server, the script asks the following questions about the server components in the Service Pack 3a installation environment. Continue with Step 15.
Accept the default port number or enter the correct port number for the gateway or gateways.
- If the local computer is the profile server and you specified multiple server components, the script repeats the set of questions until you have specified information for all the desired server components. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
- The script repeats the set of questions, allowing you to enter name and IP address information for each server component in a multiple server environment. Enter a "." after you have finished adding the information for all the server components.
On what port will the gateways run? [443] Choose whether the iPlanet Portal Server environment will use multiple gateways or a single gateway.
Is this a multiple gateway install? y/[n] Enter the information for the gateway or gateways.
Choose whether the gateway should use a web proxy.
- The installation script asks the following set of questions about the gateway.
Note If you chose a multiple gateway installation in Step 17, the script repeats the set of questions so that host and domain information can be entered for each gateway. Enter a "." when you are finished entering the information for all the gateways.
Should the gateway(s) use a web proxy? y/[n]
If you choose n, go to Step 22.
Enter the information for the web proxy. Go to Step 22.If you choose y, the installation script asks the following set of questions about the web proxy. Continue with Step 20.
On what hostname will the web proxy run? [sesta]
What is the sub-domain name for sesta ("." for none)? []
What is the domain name for sesta? [iplanet.com]
On what port will sesta run? [8080]
Note If you choose a web proxy name that is different from the name of the current machine, the script also asks for the IP address of the web proxy.
Accept the default server port number for the machine on which you are installing or enter an available port number.
On what port will the server run on this machine? [8080] Accept the default administrator port for the web server or enter the correct port number.
What is the administrator port for the web server? [8088]
Enter and verify the passphrase.
- The installation script asks you to enter and verify a passphrase. This passphrase is not the root user's password. It is used internally for SSL communication to the server and for access to the iPlanet Webserver administration console.
What is the passphrase (8 chars minimum) :
Re-enter passphrase :Choose whether you want the script to start the server after the installation is complete.
Start after installation completes? [y]/n
Answer y to install the server component. The installation script installs the server packages.
- The installation script displays the settings and asks if they are correct.
Choose 3 to exit or 2 to install the gateway on the current machine. See Gateway Component Installation" for complete instructions on installing the gateway component.
- The installation script installs the following packages.
- When the installation is complete, the component menu is displayed.
Select which component to install:
1) Server
2) Gateway
3) Exit
Choice? [3]
Repeat this installation procedure on each server component in a multiple-server environment.
For information on configuring multiple-instances of the iPlanet Portal Server product on a single server machine, see Configuring Multiple Instances of iPlanet Portal Server."
Gateway Component Installation
To install the gateway component:
Backup the iPlanet Portal Server 3.0 installation.
If the iPlanet Portal Server processes are running, stop all iPlanet Portal Server processes.
- See Stopping the Server Component Processes.
Accessing the Install Script From the CD-ROM
As root, mount the Service Pack 3a CD-ROM.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.Change directories to /cdrom/cdrom0 and run the ipsinstall script.
# volcheck
# cd /cdrom/cdrom0
# ./ipsinstall
Accessing the Install Script From the Service Pack 3a Directory
As root, change directories to /opt/ips_sp3.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.
The iPlanet Portal Server 3.0 Service Pack 3a Install Script
The following examples are the install script prompts for this installation.
The installation script displays the Service Pack 3a license agreement.
If you chose not to have the script start the gateway component, you can start the server component by using the following command:
Accept the default values or enter the correct name and IP address information.
- Enter yes to accept the license agreement and continue with the installation.
Note If the installation script detects missing Solaris patches, a warning message is displayed. See Installing the Required Solaris Patches From the Download, or Accessing Service Pack 3a Software From the CD-ROM, for information on installing the necessary Solaris patches.
- The installation script attempts to determine name and IP address information about the machine on which you are installing. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
Choose one of the following options to perform a fresh installation of the iPlanet Portal Server components.
- The script displays the task menu.
Choose 2 if the Service Pack 3a server component is not already installed on the current machine.
Choose 3 if the Service Pack 3a server component is already installed on the current machine.
Choose 2 to install the gateway component.
- The script displays the component menu.
1) iPlanet(TM) Portal Server 2) iPlanet(TM) Portal Server: Secure Remote Access Pack (Gateway) 3) Exit Choice? [3] 2 Specify whether the sever component is using SSL. For information about using SSL with the iPlanet Portal Server product, see the iPlanet Portal Server Administration Guide.
Is the profile server using SSL protocol? y/[n] Specify whether the local machine is the profile server.
Should the local machine be the profile server? [y]/n
If you chose y, go to Step 8.
Enter profile server information. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component. Go to Step 9.If you chose n, the installation script asks the following questions about the profile server. Continue with Step 7.
Accept the default profile server port number, or enter the number for the profile server port.
The profile server will run on siroe.iplanet.com
What is the port for the profile server? [8080]Accept the default for the role tree root, or enter another name.
What is the root of the profile role tree? [iplanet.com]
Accept the default root user name or enter another name for the root user.
What is the user for the root of the role tree? [root] Accept the default information for the gateway component or enter the correct gateway information.
What is the sub-domain name for sesta ("." for none)? [] What is the domain name for sesta? [iplanet.com] On what port will sesta run? [443] Choose whether the gateway component has multiple network interfaces. If the machine on which the gateway is being installed has multiple network interfaces, the iPlanet Portal Server gateway component can be restricted to use only one interface.
Does this gateway have multiple network interfaces? y/[n]
If you answer n, go to Step 15.
Choose whether to limit the use of the gateway component to one network interface.If you answer y, continue with Step 13.
If you answer n, go to Step 15.
Accept the default IP address or enter the correct IP address for the network interface that the gateway component will use.If you answer y, continue with Step 14.
Limit use to one network interface? y/[n]
What is the ip address of that network interface? [192.168.01.03] Choose whether you want the firewall software to be installed on the gateway component. Install the firewall only if the gateway component has more than one network interface.
Enter and verify the passphrase.
- If installing on Solaris 2.6 and Solaris 7, the installation script asks the question:
Note This question is omitted if installing on Solaris 8 because the firewall included with the iPlanet Portal Server product is not supported on Solaris 8.
- The installation script asks you to enter and verify a passphrase. This passphrase is not the root user's password. It is used internally for SSL communication to the server and for access to the iPlanet Webserver administration console.
What is the passphrase (8 chars minimum) :
Re-enter passphrase :Choose whether you want the script to start the gateway after installation.
If the setting are correct, answer y to install the gateway component. The installation script installs the gateway packages.
- The installation script asks the question:
Start after installation completes? [y]/n
- The installation script displays the settings and asks if they are correct.
Enter the information for your organization.
- The installation script asks the following set of organization specific information for the self-signed certificate.
# /etc/init.d/ipsgateway start
Removing the Service Pack 3a Software
This procedure assumes that the Service Pack 3a packages were downloaded to /opt/ips_sp3.
Backup the iPlanet Portal Server 3.0 installation.
If the iPlanet Portal Server processes are running, stop all iPlanet Portal Server processes.
- See Stopping the Server Component Processes.
Accessing the Install Script From the CD-ROM
As root, mount the Service Pack 3a CD-ROM.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.Change directories to /cdrom/cdrom0 and run the ipsinstall script.
# volcheck
# cd /cdrom/cdrom0
# ./ipsinstall
Accessing the Install Script From the Service Pack 3a Directory
As root, change directories to /opt/ips_sp3.
The iPlanet Portal Server 3.0 Service Pack 3a install script will now run. See The iPlanet Portal Server 3.0 Service Pack 3a Install Script for an example of the prompts required to install this software.
The iPlanet Portal Server 3.0 Service Pack 3a Install Script
The following examples are the install script prompts for this software removal.
The installation script displays the Service Pack 3a license agreement.
Accept the default values or enter the correct name and IP address information.
- Enter yes to accept the license agreement and continue with the backout.
- The installation script attempts to determine name and IP address information about the machine on which you are installing. If the machine on which you are installing uses multiple IP addresses or multiple domains, verify that the IP address displayed by the script is the correct one for the iPlanet Portal Server component.
Enter 4 to remove the Service Pack 3a product.
- The script displays the task menu.
Select which component to remove.
1) iPlanet(TM) Portal Server 2) iPlanet(TM) Portal Server: Secure Remote Access Pack (Gateway) 3) Exit Choice? [3] 1
Choose y to remove the iPlanet Portal Server component.
- The script asks you to verify your choice.
Select which component to remove, or choose 3 to exit the script.
- The script proceeds with the removal process. When the component is removed, the script returns you to the component menu.
1) Server 2) Gateway 3) Exit Choice? [3] 1
Removing a Partial Installation
If the installation process gets interrupted and only some of the iPlanet Portal Server packages have been installed, the packages that were installed must be removed before attempting to reinstall or use the product.To remove a partial installation:
As root, change directories to the Solaris package database directory.
List the iPlanet Portal Server software directories.
Look for any of the following directories:
Remove any directories that match the list above. For example:
Change directories to /var/sadm/install/logs and list the iPlanet Portal Server software directories.
# cd /var/sadm/install/logs
# lsLook for any of the directories listed in Step 3.
Remove any directories that matched the list of iPlanet Portal Server software directories. For example:
Setting the Environment Variable IPS_ROOT
Set the environment variable IPS_ROOT to the iPlanet Portal Server 3.0 installation directory. The following example assumes that /opt is the installation directory.
Restoring Certificates
To restore server certificates after upgrading the iPlanet Portal Server:
As root, stop the iPlanet Portal Server server.
Change directories to the directory in which the certificates are to be restored. In the following example, /opt is the base directory.
Un-compress the alias.tar file created before the upgrade process. See Saving the Certificates Used by the Server Component."
# /usr/bin/tar xvf /usr/tmp/alias.tar Restart the iPlanet Portal Server server.
Open a browser window, and go to the iPlanet Web Server administration console. For example:
Login as admin.
- http://siroe:8088
Note The password for the web server administration console is the same passphrase entered during the iPlanet Portal Server installation.
Select Load configuration files.
In a terminal window, restart the iPlanet Portal Server server.
Known Problems and Limitations
Here are known problems with the iPlanet Portal Server 3.0 software that have not been fixed in Service Pack 3a, with workarounds where appropriate.
4383120
- The number of valid sessions (as indicated by the Valid Session number in the Manage User Session page) is inaccurate.
- For instance, when you log in to the administration console (either as super user or any user) and select Manage User Session, the Valid Session number is shown as 1. When you log in again from another browser, the Valid Session number does not increment to 2 to show that two valid sessions are in progress.
- The LDAP authentication module does not allow the admin to specify a search filter when configuring the server for user lookup in the directory. The text field, search filter for userId, refers to the attribute (by default, the uid attribute) to use in searching the directory. Then the attribute specified in the search filter for userId is used to create the search filter used in the lookup.
- For example, if you did not specify an attribute in the search filter for userId text field and left it blank, the default is uid. So, the search filter becomes (uid=jim), where jim is the username entered by the user. If the search filter for userId contained the value surname or sn, then the search filter would become (surname=jim).
4378030
- Desktop comes up blank if no channels are selected in the Administration Console and in the Desktop.
- Workaround:
- None.
4376634
- The setDomain method should attempt to retrieve a domain profile before setting the domain.
- Workaround:
- None
4379326
- The Administration console allows duplicate tab names if one attribute is different.
- Workaround:
- Verify that tab names are not duplicated.
- Contents of profilestyle.css can become visible in the Administration Console when adding a new user to a newly created domain.
- Workaround:
- None.
4355280
- Disabling the Netlet provider in the Administration console for a user causes error message: "Document contained no data".
- Workaround:
- Remove the provider from the channel list in the Administration console.
4358738
- When using Internet Explorer 5x on Windows 98, closing the Netlet window crashes the web browser.
- Workaround:
- None.
4447005
- Using bookmark provider with IE4 client on open portal gets a script error.
- Workaround:
- None. IE4 bug, not reproducible with IE5.X or Netscape Browsers.
4454833
- delAttribute permits deletion of a profile attribute without write permission.
- Workaround:
- None.
4457299
- Administrator can delete their own account.
- Workaround:
In a terminal window, become root.
At the prompt, enter the following string:
# echo '<iwt:Att name="iwtUser-role"><Val>/$DOMAIN/AdminRole</Val></iwt:Att>' | /opt/SUNWips/bin/ipsadmin create user /$DOMAIN/root/dev/stdin
- Where $DOMAIN is the default domain and AdminRole is the administrator's role.
- Descriptions for channels created with channel wizard cannot be localized.
- Workaround:
- To localize the description and title for a channel created with the channel wizard, do the following:
On each iPlanet Portal Server 3.0 server, create a file called:
- /opt/SUNWips/locale/channel_locale.properties
- where channel is the fully qualified name of the channel and locale is the name of the locale to be supported.
The fully qualified name of the channel is printed on the last page of the channel wizard, and it is also shown in the available channels list in the desktop profile
Within this file, create entries for the description and title, as follows:The locale is a language and country combination, for example, en_US
- description=This is the description
- title=This is the title
- The .properties file must use Java Unicode encoding, where multi-byte characters are represented as \xf9 XXXX where the Xs are hexidecimal digits.
- Files in this encoding can be created from files in a variety of native encoding using the java native2ascii program.
Note A separate .properties file is necessary for each locale to be supported.
- External bookmark URLs are not redirected.
- Prevention:
- Remove openURL from the Gateway profile "rewrite JavaScript function parameters".
- Workaround:
- Create a second bookmark channel to handle external sites.
- The bookmark provider can not be used for URLs which reference Internet URLs that the Gateway cannot or should not fetch.
- Installing the iPlanet Portal Server product over a previous installation that did not install correctly causes the installation log file to get very large.
- Workaround:
- After installation, remove the installation log file:
- /var/sadm/install/logs/ipsinstall.<process_id>/install.log.
- The command ipsadmin does not check for the syntax of boolean flags.
- Workaround:
- When creating an XML file, if the attribute type is boolean, add a true or false statement, as shown in bold in the following example:
desc="Trust Proxy Feature" type="boolean" idx="X-x1" userConfigurable="TRUE"> <Val>false</Val> <Rperm>ADMIN</Rperm><Rperm>OWNER</Rperm> <Wperm>ADMIN</Wperm> </iwt:Att>
4472975
- The ipsserver start command requires additional arguments if the server is running multiple instances. For more information see Configuring Multiple Instances of iPlanet Portal Server."
- Heavy loads for an extended duration cause components in the operating system to fail.
- Workaround:
- None.
- Log records should be written using iwtPlatform-locale not iwtUser-locale.
- Workaround:
- None.
4293370
- The hour glass occasionally keeps running after attempting to add a share in Netfile Java.
- Workaround:
- Select some other part of NetFile to clear up the hour glass.
4372826
- NetFile Lite does not check the size of a file before attempting to upload. If the file is greater than 5 MB, the upload fails.
- Workaround:
- None.
4463515
- Uploading tar files greater than the 5 MB limit in NetFile Lite, and tar files greater than the 500 MB limit in Netfile generates an incorrect error message.
- Workaround:
- None.
- The Netfile application allows users to access denied hosts if those hosts were added to the desktop before a deny rule was added in the iPlanet Portal Server administration console.
- Workaround:
- None.
4307367
- A race condition occurs if when replying to a message, selecting send and then immediately deleting the message.
- Workaround:
- Wait for the reply flag to be set (slow down) or delete the message again.
- IMAP password is displayed in clear text in source of edit.
- Workaround:
- None
- The editType attribute is missing in the following xml files:
- Workaround:
- Add the following code inside the component tags of iwtHelloWorld3Provider.xml:
- Add the following code inside the component tags of iwtQuotationProvider.xml:
Bugs Fixed in Service Pack 1, Service Pack 2, and Service Pack 3a
The following bugs have been fixed in iPlanet Portal Server 3.0 Service Pack 1, Service Pack 2, and Service Pack 3a.
Documentation Updates
The following information supplements the iPlanet Portal Server 3.0 Administration Guide.
Authentication Chaining
Authentication chaining provides a higher level of security for organizations by requiring users to authenticate against more than one authentication mechanism. For example, if the membership and Unix authentication modules are chained, desktop users would authenticate against both to access the desktop. If all authentication modules are chained, desktop users would authenticate against all to access the desktop.To set up authentication chaining, do the following.
Login to the iPlanet Portal Server administration console as Super Administrator.
Select the domain for which authentication chaining is to be used.
In the Authentication Chaining Modules field, enter the authentication modules to be chained, separated by spaces. For example
Select the Authentication Enabled checkbox to enable authentication chaining.
Select Submit. A message is displayed indicating that the profile was successfully updated.
Where to Go for More Information
For document information about the iPlanet Portal Server 3.0, visit:
- http://docs.iplanet.com/docs/manuals/portal.html
How to Report Problems
If you have problems with iPlanet Portal Server 3.0 Service Pack 3a, contact iPlanet customer support using one of the following mechanisms:
iPlanet online support web site at http://www.iplanet.com/support/online/
So that we can best assist you in resolving problems, please have the following information available when contacting iPlanet support:
The telephone dispatch number associated with your maintenance contract
- From this location, the CaseTracker and CaseView tools are available for logging problems.
Description of the problem, including the situation where the problem occurs and its impact on the operation
Machine type, operating system version, and product version, including any patches and other software that might be affecting the problem
For More Information
Useful iPlanet information can be found at the following Internet locations:
iPlanet release notes and other documentation --- http://docs.iplanet.com/docs/manuals/
iPlanet product status --- http://www.iplanet.com/support/technical_resources/
iPlanet developer information --- http://developer.iplanet.com/
iPlanet learning solutions --- http://www.iplanet.com/learning/index.html
iPlanet product data sheets --- http://www.iplanet.com/products/index.html
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.
Last Updated October 11, 2001