Netscape Messaging Server Concepts and Features

Netscape Messaging Server introduces new concepts and features different from those included in Netscape Mail. The following sections describe these concepts and features, as well as the Netscape Messaging Server installation and configuration procedures.

Server Root Concept

Netscape Messaging Server introduces the concept of a server root, a directory which contains a complete installation of Netscape Messaging Server 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 instance per server root, and only one server root per logical host--hence, one instance per logical host.

Dependence on a Configuration Directory Server

At time of installation, Netscape Messaging Server requires that a configuration directory server be available to it, because during the installation, Netscape Messaging Server contacts the configuration directory server and populates it with configuration information. After initial installation, Netscape Messaging Server 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 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, you can make Netscape Directory Server highly available by also installing and configuring Sun Cluster HA for Netscape LDAP. For more information about Sun Cluster HA for Netscape LDAP, see "Netscape Directory Server (LDAP)".

Fault Monitoring Behavior

Netscape Messaging Server 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 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.