Product Overview

New Features

The following new concepts and features are introduced with Netscape Messaging Server 4.1.

Server Root Concept

Netscape Messaging Server 4.1 introduces the concept of a server root, a directory which contains a complete installation of Netscape Messaging Server 4.1 and configured instances for the installation, with one minor exception: the /etc/nsserver.cfg file resides outside of the server root and contains a list of all server roots on a node. Note, however, that Sun Cluster 2.2 allows only one Netscape Messaging Server 4.1 instance per server root, and only one server root per logical host--hence, one instance per logical host.

Dependence on a Configuration Directory Server

Netscape Messaging Server 4.1 depends upon a configuration directory server. For more information, see "About the Configuration Directory Server".

Fault Monitoring Behavior

Netscape Messaging Server 4.1 includes five separate daemons: smtpd, popd, imapd, mshttpd, and stored. These daemons can be stopped and started individually, and can fail individually.

Sun Cluster HA for Netscape fault monitoring checks that daemon processes exist and that protocol services are available. During process existing checking, the fault probe periodically verifies that a daemon exists. The fault probe interprets any daemon absence as an application failure, and takes action based on the current configuration parameters. During protocol probing, the fault probe periodically checks the daemon and takes action only in response to error codes indicating a timeout. The default timeout value set by Sun Cluster HA for Netscape is 660 seconds, to prevent inadvertent failovers in situations where a server is simply slow to respond.

Because this fault monitoring model relies on a fully active mail server, you must always turn off the Sun Cluster HA for Netscape data service (using hareg -n) before you perform any administrative tasks that require a daemon to stop. Otherwise the fault probe will take action. Turn on the data service (using hareg -y) only after completing the administrative task.

Sun Cluster HA for Netscape monitors the smtpd, popd, and imapd daemons with both process existence checking (using the local probe) and protocol probing (using both local and remote probes). Sun Cluster HA for Netscape monitors the mshttpd and stored daemons with only process existence checking (using the local probe). The mshttpd and stored daemons are never checked by a remote probe. Therefore, if an mshttpd process exists but is stalled, Sun Cluster HA for Netscape will take no action; once you notice that web mail clients are unable to connect, you must restart the mshttpd process manually.

Sun Cluster HA for Netscape does not monitor any SNMP subagents.

Use of User/Group Directory

Netscape Messaging Server 4.1 requires use of a user/group directory, which was optional with Netscape Mail 3.5. The user/group directory is an LDAP directory used by the messaging server to process email. You can install and start the messaging server before configuring the user/group directory, but the messaging server depends upon access to the user/group directory after installation. Because of this dependency, the directory server that services the user/group directory should be installed on the multihost disk or on another clustered server, so as to be highly available.

The configuration directory and user/group directory can be serviced by the same directory server instance or by different instances.

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.