Configuration Notes

The following dependencies and restrictions apply to Netscape Messaging Server 4.1 on Sun Cluster 2.2.

About the Configuration Directory Server

At time of installation, Netscape Messaging Server 4.1 requires that a configuration directory server be available to it, because during the installation, Netscape Messaging Server 4.1 contacts the configuration directory server and populates it with configuration information. After initial installation, Netscape Messaging Server 4.1 copies the configuration data back to its local cache, after which the external configuration directory server is no longer strictly relied upon. If the configuration directory server becomes unavailable, Netscape Messaging Server 4.1 will emit warning messages stating that it is starting up with configuration data from its own local cache. These messages are expected and harmless.

If you choose to install the Netscape Directory Server to serve Netscape Messaging Server 4.1, you can make it highly available by also installing and configuring Sun Cluster HA for Netscape LDAP. For more information about Sun Cluster HA for Netscape LDAP, see the Sun Cluster 2.2 Software Installation Guide.

Configuration Restrictions

Sun Cluster HA for Netscape imposes the following restrictions on Netscape Messaging Server 4.1:

• When you install Netscape Messaging Server 4.1, the listener daemons popd, smtpd, imapd, mshttpd, and stored must be configured as active, and must be configured on their default ports. If not, the startup and fault monitoring programs will perceive the daemons as inactive, and will take action based on the current configuration parameters. Further, if these two conditions are not met, the Netscape Messaging Server 4.1 instance will not start successfully. See "Fault Monitoring Behavior" for more information.

• You can configure only one Netscape Messaging Server 4.1 instance per server root, and only one server root per logical host--hence, one Netscape Messaging Server 4.1 instance per logical host.

• The Netscape Messaging Server 4.1 Multiplexor feature is not supported with Sun Cluster 2.2. Because the Multiplexor requires services located outside the server root, the Multiplexor cannot be probed or failed over by Sun Cluster HA for Netscape.

• Though Netscape Messaging Server 4.1 supports SSL-enabled listening for some of its protocols, the separate ports using SSL are not fault probed by Sun Cluster HA for Netscape. Basic restart and failover is supported, however, for any Netscape Messaging Server 4.1 instances listening on SSL-enabled ports.

• Netscape Messaging Server 4.1 supports SMTP plug-ins--shared libraries that you can install and configure to be used by Netscape Messaging Server 4.1 for customized SMTP processing. If you configure Netscape Messaging Server 4.1 to use SMTP plug-ins, then be sure to protect the shared libraries with Sun Cluster. Do this by placing the libraries on the shared disk, preferably within the Netscape Messaging Server 4.1 server root tree, or by placing the libraries on local disks on each potential master node.

• Netscape Messaging Server 4.1 supports sophisticated access control on a service-by-service basis for its TCP-based services (IMAP, POP, HTTP, and SMTP). You can enable this feature by creating filters to screen access to servers. However, if you create filters, do so with care so that you do not prevent root on any potential master from connecting to any of the Netscape Messaging Server 4.1 protocol servers. If root is prevented from connecting to any of the protocol servers, the data service probe that tests protocol service availability will fail, triggering Sun Cluster HA for Netscape to take action based on the current configuration parameters. This behavior will continue indefinitely until the filter in question is removed or the probe terminated. Make sure that root access is enabled from all nodes that are potential masters of the protocol servers.

Choosing an Install Location for Netscape Binaries

The Netscape Messaging Server 4.1 binaries and data directories can be installed on either the shared disk or on the local disk of each cluster node.

Installing the binaries and data directories on the shared disk eases administration and consumes less disk space, but increases down time during application upgrades, because the application must be brought down for the duration of the binary upgrade.

Installing the data directories on the shared disk and the binaries locally on each node preserves high availability during failover, and also reduces downtime during future upgrades of the application. You can upgrade the binaries on a node that is not currently hosting the application, switch the application over to that node, then upgrade the binaries on the original node. The application remains available except for during the brief switchover period.