Messaging Server Administrator's Guide: Monitoring and Maintaining Your Server


Category	Command-Line Utility
Management	configutil, imscripter, mboxutil, NscpMsg, processq
Recovery	deliver, reconstruct
Background and daily tasks	stored
Monitoring and reporting	counterutil, hashdir, mailq, quota, readership

Performing Daily Tasks

Probably the most important tasks you should perform on a daily basis are checking the postmaster account and monitoring the log files.

Checking the postmaster Account

The Messaging Server has a predefined administrative alias account set up for the postmaster. The postmaster account is defined in RFC822, which requires every email site to accept mail addressed to a user named postmaster and that mail sent to this account be delivered to a real person. All messages sent to postmaster@host.domain are sent to this account.

Typically, the postmaster account is where users should send email about their mail service. You might receive mail from local users about server response time, from other server administrators who are encountering problems sending mail to your server, and so on. You should check this account daily.

You can also configure the server to send certain error messages to the postmaster account. For example, when the MTA cannot route or deliver a message, you can be notified via email sent to the postmaster account. You can also send exception condition warnings (low disk space, poor server response) to the postmaster account. For more information about sending messages to the postmaster account, see Specifying Error Handling in Chapter 3 and Alarm Attributes in Appendix A.

Monitoring and Maintaining the Log Files

Netscape Messaging Server creates a separate set of log files for each of the major protocols, or services, it supports: SMTP, IMAP, and POP. You should monitor the log files on a routine basis--especially if you are having problems with the server. For information about searching and viewing log files, see Searching and Viewing Logs in Chapter 11.

Be aware that logging can impact server performance. The more verbose the logging you specify, the more disk space your log files will occupy. You should define effective but realistic log rotation, expiration, and backup policies for your server. For information about defining logging policies for your server, see Defining Log Rotation, Expiration, and Backup Policies in Chapter 11.

Setting Up the stored Utility

The stored utility performs automatic monitoring and maintenance tasks for the server, such as:

background and daily messaging tasks

low-level database consistency check and repair

deadlock detection and rollback of deadlocked database transactions

cleanup

expiration, expunging, and erasing of messages stored on disk

alarm setting

The stored utility automatically performs cleanup and expiration operations once a day at midnight. You can choose to run additional cleanup and expiration operations; for example, to run stored as a daemon once a day at 09:00 p.m., type the following command at the command line:

stored -d -h 21

For more information about stored, see stored in Appendix A and Using the stored Utility in Chapter 5.

Monitoring and Controlling Disk Usage

The server requires adequate disk space for processing and storing messages. You must never let the server run out of disk space. Consequently, you must monitor disk usage and take appropriate actions if available disk space becomes too low.

The message queue contains messages that cannot be routed or delivered immediately. The message store contains the messages delivered to local users. Both the queue and the store must have adequate disk space for the messages they contain. For example, if disk space reserved for the store falls too low, the server might start queueing messages destined for the store. If disk space reserved for the queue falls too low, the server might start rejecting messages. For general information about the message queue, see Managing the Message Queue in Chapter 3. For general information about the message store, see Chapter 5, Managing the Message Store.

Monitoring Disk Usage

You can monitor disk usage by configuring the disk space alarm attributes described in Table 10.2. You configure these attributes by using the configutil utility. You can specify how often the system should monitor disk space and under what circumstances the system should send a warning.

Table 10.2 Disk Space Alarm Attributes


Disk Space Attributes	Default Value
alarm.diskavail.msgalarmstatinterval	3600 seconds
alarm.diskavail.msgalarmthreshold	10%
alarm.diskavail.msgalarmwarninginterval	24 hours

For example, if you want the system to monitor disk space every 600 seconds, specify the following command:

configutil -o alarm.disavail.msgalarmstatinterval -v 600

If you want to receive a warning whenever available disk space falls below 20 %, specify the following command:

configutil -o alarm.diskavail.msgalarmthreshold -v 20

For more information about setting alarm attributes, see Appendix A, Command-line Utilities.

Controlling Disk Usage

You can control disk usage by setting user message quotas, specifying aging policies for messages stored on disk, limiting the size of messages the server will accept, and processing the message queue at frequent intervals. If these methods are not sufficient or are not acceptable to your users (or are not practical), you might want to consider adding disks to your system. For more information, see Specifying Alternate Paths for Queue Storage in Chapter 3 and Configuring Message Store Partitions in Chapter 5.

Message Quotas

If disk space is limited, you might want to set user message quotas for your system. Message quotas allow you to limit users to a fixed mailbox size. If a user exceeds the limit, the user can no longer retrieve mail until he or she deletes existing messages to free disk space. For information about specifying message quotas, see Configuring User Disk Quotas in Chapter 5.

You can use the quota utility to view reports and optionally fix mailbox quota usage. This utility generates a report listing quotas, giving their limits and usage. For more information about the quota utility, see Appendix A, Command-line Utilities.

Aging Policies

Another method for controlling disk space is to specify aging policies for messages in the message store. You can control how long messages are stored in one or more mailboxes. If you set aging policies, you should educate your users about these policies because the server will not send a warning message before it starts deleting messages from the store.

You can specify constraints for the following:

number of messages in the mailbox

total size of the mailbox

number of days that messages remain in the mailbox

number of days that messages exceeding a given size remain in the mailbox

For more information, see Specifying Aging Policies in Chapter 5.

Message Size Limits

You might want to limit the size of messages that your server will accept. If you limit message size, the server will automatically reject any messages that exceed the maximum message size. By limiting the size of messages, you'll save queue disk space and message store disk space. For more information about how to limit message size, see Limiting Message Size (SIZE) in Chapter 3.

Reserved Disk Space

You can specify a minimum amount of disk space that will remain unused for the message queue. If the minimum threshold is reached, the server will temporarily reject all messages until disk space is freed. The server returns an error (452) notifying the client of a temporary disk space shortage and asking the client to resend the message at a later time. For information about how to reserve free disk space, see Reserving Free Disk Space in Chapter 3.

Monitoring Server Response Time

In general, server response time is measured by the number of messages per second and the number of client connections per second your server can handle. There are many factors that affect server response time: number of users, peak traffic times, hardware and software configuration, network bandwidth, and so on.

The msgalarmproc utility provides a set of server response attributes you can use to monitor server response time for IMAP, POP, and SMTP services. These attributes are listed in Table 10.3. Response time is measured for how long it takes to make a connection to a service and to receive the service greeting. If response time exceeds a specified number of seconds, you will be notified via email. You set values for the server response attributes by using the configutil utility. For more information about the configutil utility and the msgalarmproc attributes, see Appendix A, Command-line Utilities.

Table 10.3 Server Response Attributes


Server Response Attributes	Default Value
alarm.serverresponse.msgalarmstatinterval	600 seconds
alarm.serverresponse.msgalarmthreshold	10 seconds
alarm.serverresponse.msgalarmwarninginterval	24 hours

To improve server response time, you can:

Run stored at off hours--not during peak hours for your business.

Defer queue processing to off hours.

Reduce the size of the queue.

Distribute the queue across multiple physical disks.

Distribute the message store across multiple physical disks.

Limit the size of user inboxes.

For more information about improving server response time, see Factors Affecting Messaging Server Performance later in this chapter.

Performing Recovery Tasks

If one or more mailboxes becomes corrupt, you can use the reconstruct utility to rebuild the mailboxes or the mailboxes database and repair any inconsistencies. For more information, see Repairing Mailboxes and the Mailboxes Database in Chapter 5.

For information about backing up and restoring the message store, contact your Netscape technical support person.

Factors Affecting Messaging Server Performance

This section describes factors that affect Messaging Server performance and contains tips to help you enhance the performance of Netscape Messaging Server 4.0 on Unix platforms. These tips are intended as general guidelines and suggestions only; the actual performance of your messaging server depends on many factors, including CPU power, disk space, usage patterns, network bandwidth, and so on.

Note: The tips in this document are for Netscape Messaging Server 4.0 only and might or might not apply to other versions of Netscape Messaging Server.

Factors that affect Netscape Messaging Server performance include the following:

Number of Users per Disk

Configuration of POP and IMAP Services

Configuration of SMTP Services

Configuration of Logging Services

Size of Mailboxes

Distribution of the Store and Queue Directories

MTA Thread Settings

Applications Co-Resident with the Messaging Server

Activity of the Administration Server

Activity of the Directory Server

Location of the Messaging Server and the Directory Server

Number of Address Lookups per Message

Ratio of Delivery to Outbound Sends

Use of RAID Technology

Memory, Disk, and CPU Requirements

Number of Users per Disk

As the number of users per disk increases, the I/O to that disk increases non-linearly due to the algorithms used by the OS to cache the directory index (it's faster to search memory than to search a hard drive). To improve disk access, you should distribute users across available disks.

To ease management of multiple disks, you can use RAID (Redundant Array of Inexpensive Disks) technology to distribute data across a series of physical disks. For more information, see Use of RAID Technology.

Configuration of POP and IMAP Services

How you configure your POP and IMAP services affects Messaging Server performance. You can configure the following:

the number of POP and IMAP processes

the number of POP and IMAP connections per process

the number of threads per POP and IMAP process

For details on configuring POP and IMAP services, see Chapter 2, Configuring IMAP and POP Services.

Number of POP and IMAP Processes. If you have a multiprocessor machine, you might want to configure multiple POP and IMAP processes to allow more connections to your server and perhaps less thread contention. There is a performance overhead, however, in allocating tasks among multiple processes and in switching from one process to another.

Number of POP and IMAP Connections Per Process. IMAP connections are generally very efficient compared to POP connections. Each reconnection during a POP session requires re-authentication of the user, whereas an IMAP connection requires only a single authentication because the connection remains open.

Scalability is most adversely affected, therefore, by the number of POP users "pinging" the server to see if they have new mail. Netscape Messaging Servers can service several dozen user requests per second. Consequently, 10,000 POP users checking mail once a day is easier to support than 1000 POP users checking mail every second during the day.

Connected processes do occupy memory on the server system, however. Because IMAP connections are persistent, the more IMAP users there are connected to the server, the fewer resources there are for new connections.

Number of Threads per POP or IMAP Process. Having more simultaneously executing threads means that more client requests can be handled without delay, so that a greater number of clients can be serviced quickly. However, there is a performance overhead to dispatching among threads, so there is a practical limit to the number of threads the server can make use of.

Configuration of SMTP Services

This section summarizes SMTP configuration options that affect system performance. Some of these options can improve server performance; other options provide valuable features but can impact server performance adversely. If you are having problems with server performance for whatever reasons, you might want to consider whether you need the features provided by some of these options. SMTP configuration options that can affect server performance include:

Limiting Dial-up Connections

Limiting the Size of Messages

Verifying Recipient Addresses

Enabling Host Name Resolution

Specifying Alternate Search Methods

Specifying "From" Address Rewrite Style

Using the Plug-in API

Limiting Dial-up Connections

You can improve server performance by limiting the number of dial-up connections to your server. If both client (in this case another MTA) and server support the ETRN command, when the client connects to the server to send a message, it can also initiate processing of the deferred queue for the client's domain. This feature is useful for sites that only have a dial-up connection to the Internet. For more information, see Enabling Requests for Deferred Queue Processing (ETRN) in Chapter 3.

Limiting the Size of Messages

The size of messages is a factor when considering the transmit time to actually "move" the message from the client to the server and the disk space available for storing messages. Users may negatively impact performance by sending extremely large documents over the network. You can limit the size of messages your server will accept. For more information, see Limiting Message Size (SIZE) in Chapter 3.

Verifying Recipient Addresses

You can specify an option to verify recipient addresses when a client connects to the server. Specifying this option has slight performance impact because the server must perform an LDAP lookup for each recipient while connected to the client. The benefit, however, is that bad recipients can be rejected immediately, allowing the sender to fix before sending (instead of getting a bounce message later). For more information, see Verifying Recipient Addresses in Chapter 3.

Enabling Host Name Resolution

If you enable this option, the Messaging Server will use DNS to map the client's IP address to the associated host name. The host name is then used in the process table, the log files, and in "Received" lines in message headers. This option requires DNS lookups, however, so enabling this option can impact performance adversely if your server handles a large volume of messages. For more information, see Performing Host Name Resolution in Chapter 3.

Specifying Alternate Search Methods

If you enable alternate search methods, you can expand the list of possible recipient matches. Be aware that enabling this option can impact server performance because of the increase in LDAP lookups. For more information, see Specifying Alternate Search Methods in Chapter 3.

Specifying "From" Address Rewrite Style

Rewriting the "From:" address increases the odds that replies to outgoing messages are processed correctly. However, this feature does incur some performance overhead. For more information on this option, see From Address Rewrite Style in Chapter 3.

Using the Plug-in API

If you are using the Messaging Server plug-in API, some CPU and memory resources will necessarily be diverted from the usual Messaging Server processing. However, you can use the plug-in API to provide valuable extensions to the Messaging Server capabilities. For more information, see Chapter 7, Working With SMTP Plug-Ins.

Configuration of Logging Services

Logging options can be expensive in terms of server performance and response time. You should carefully consider your logging requirements and log only those messages that you need to successfully monitor and maintain your server. For more information on logging policies, see Defining Log Rotation, Expiration, and Backup Policies in Chapter 11.

Size of Mailboxes

Users with mailboxes that contain an extremely large number of messages might encounter slow response times from the server. If so, you might want to set up user disk quotas or aging policies for user mailboxes. For more information about disk quotas and aging policies, see Chapter 5, Managing the Message Store.

You might also want to consider distributing mailboxes across disks. See Distributing the Store Across Disks.

Distribution of the Store and Queue Directories

The store directory contains the user mailboxes. The queue directory is a temporary directory where all mail manipulation and rewriting take place. To improve disk access, the store directory and the queue directory should reside on separate disks. If you have a fast RAID setup (see Use of RAID Technology), you should keep the store and the queue on separate disks, but on the same logical volume. You should also consider:

Mounting the Queue Directory on a Fast File System and Fast Disk

Distributing the Queue Across Disks

Distributing the Store Across Disks

To ease management of multiple disks, you can use RAID (Redundant Array of Inexpensive Disks) technology to distribute data across a series of physical disks. The disks appear as one logical volume, so disk management is simplified. For more information, see Use of RAID Technology.

Mounting the Queue Directory on a Fast File System and Fast Disk

Because the message queue directory is the most heavily used part of the system, you should mount the queue directory on a very fast file system, such as the Veritas file system (VsFS). Mounting the queue directory on a fast file system can significantly increase performance for SMTP accept rates. By maintaining the queue directory in its own file system, you can also monitor message queue performance separately from message store performance.

You should also consider disk performance. For example, newer I/O buses like Ultra2 SCSI and Fibre Channel can transfer large quantities of data rapidly--up to 80 MB per second. The faster the communication speed between disk and CPU, the better Messaging Server will perform.

Distributing the Queue Across Disks

If you have more than one disk available, you might want to distribute the queue across disks. By distributing the queue, you can reduce the load associated with delivering a message because the server can perform concurrent I/O operations. You can also use multiple queue directories to reduce the overhead associated with large number of files accumulating in a single queue. For more information about specifying alternate queues, see Specifying Alternate Paths for Queue Storage in Chapter 3.

Distributing the Store Across Disks

For improved mailbox access performance, you can distribute the message store across multiple disks. When distributing the message store, you should limit the number of mailboxes on any one disk.

Distributing mailboxes across disks does not change the SMTP access rate, but it will dramatically improve message delivery time. The number of mailboxes you allocate per disk depends on the following factors:

disk capacity

disk space allocated to each user

Note: Messaging Server 4.0 stores one copy of each message per file system. Therefore, if you have 5 disks, each disk will contain a copy of the message.

For more information about distributing the message store, see Configuring Message Store Partitions in Chapter 5.

MTA Thread Settings

You can use the configutil utility to modify the thread settings for various MTA components:

service.smtp.account-handler.minruncount
service.smtp.autoreply-handler.minruncount
service.smtp.error-handler.minruncount
service.smtp.mailbox-deliver.minruncount
service.smtp.prog-deliver.minruncount
service.smtp.smtp-accept.minruncount
service.smtp.smtp-deliver.minruncount
service.smtp.smtp-router.minruncount
service.smtp.unix-deliver.minruncount

For example, you might want to improve the SMTP acceptance rate and allow for more simultaneous inbound connections by increasing the number of threads allocated to the service.smtp.smtp-accept component as follows:

configutil -o service.smtp.smtp-accept.minruncount -v 300

As another example, you might want to improve the mailbox delivery rate by increasing the number of threads allocated to the service.smtp.mailbox-deliver component as follows:

configutil -o service.smtp.mailbox-deliver.minruncount -v 10

Be aware that threads use available memory. So, depending on the hardware configuration of the server machine, too many threads can impede server performance.

Applications Co-Resident with the Messaging Server

Be aware that other applications running on the same system as Netscape Messaging Server will compete for the same system resources (memory, disk space, and so on) as the Messaging Server. Depending on your messaging requirements, you might want to dedicate one or more machines to the messaging services.

Activity of the Administration Server

If the Netscape Administration Server is being used while Netscape Messaging Server is running, there will be less memory available to map incoming connection requests.

Activity of the Directory Server

If the Messaging Server is competing with numerous other LDAP clients (for example, other Netscape servers or a synchronization process with another LDAP based directory) for access to the Directory Server, Messaging Server performance will be affected. Under large stress loads (greater than 5000 local entries), you should replicate the directory services to more machines to increase accessibility of the service. You should also dedicate a directory machine to one or more Messaging Servers.

Location of the Messaging Server and the Directory Server

In general, for improved performance, you should keep the Messaging Server and the Directory Server on separate machines. Placing these servers on separate machines will prevent contention over system resources (CPU, RAM, and disk space).

If you do decide to place the servers on separate machines, you must also consider the network bandwidth between the two machines. For example, a 100 MB dedicated network should provide good performance. If possible, you should consider using full duplex on a switch/dedicated network to eliminate collisions.

Number of Address Lookups per Message

Be aware that if the average message is destined for a large number of recipients, there is a corresponding increase in the number of required LDAP lookups required to resolve the address. You might want to limit access to aliases that contain a large number of users; for example, you might not want all users to have access to the companyall alias.

Ratio of Delivery to Outbound Sends

Most customers have a higher number of messages received to messages sent per user (on the order of 4 to 1 or higher). Netscape messaging solutions are optimized for exactly these kind of environments. Because sending a message on the server is more "expensive" than receiving, any deviation from the expected ratio (for example, 1:1 sending and receiving) will affect the expected performance and scalability of your Messaging Server.

Use of RAID Technology

To ease management of multiple disks, you can use RAID (Redundant Array of Inexpensive Disks) technology to distribute data across a series of physical disks. With RAID technology, multiple disks appear as one logical volume, so disk management is simplified. You can have multiple logical volumes each consisting of several physical disks.

There are several levels of RAID technology. You should consider implementing a RAID-0+1 configuration. RAID 0 provides fast access to data through a technology called striping. A stripe is a disk segment varying in size from one sector up to several megabytes. Disk I/O is distributed across all stripes. RAID 1 implements disk mirroring for fault tolerance.

Memory, Disk, and CPU Requirements

As stated before, a well-configured server cannot perform well on a poorly-tuned system. During the initial planning stage, you need to estimate your memory, disk, CPU, and network bandwidth requirements for your business environment. These estimates depend on many factors, including how many users the server supports, average number of messages per user, geographic location of users, and so on.

Of course, your estimates will depend on usage patterns and mail configuration. For example, if you are a host providing resources to residential consumers, your estimates will differ from the estimates required for corporate use. In general, residential consumers use much less resources than corporate consumers, so you would allocate less memory, disk space, and processing power for each residential user.

If your original estimates did not plan for growth, if business conditions change, or if performance requirements change, you might need to reconfigure your hardware. For example, you might need to add disks to the system, add processors, and so on. Although deployment planning is beyond the scope of this section, you can use the tools described in System Monitoring Tools to monitor how your system is performing.

System Monitoring Tools

The following table lists system tools you can use to monitor your server environment. These tools are available on various Unix platforms. For more information about these tools, see the man pages delivered with your Unix system.

Table 10.4 General Unix Tools


Tool	Description
iostat	Provides information about disk I/O and CPU usage.
lsof	Provides information about open file descriptors. (Available in source from :ftp://vic.cc.purdue.edu/pub/tools/unix.)
lslk	Provides information about file system locks. (Available in source from :ftp://vic.cc.purdue.edu/pub/tools/unix.)
netstat	Provides statistics about network functions.
nslookup	Allows you to query DNS servers for information about hosts and domains; for example you can print a list of hosts in a particular domain; also provides an IP address-to-hostname mapping function (and vice versa).
ping	Allows you to query the status of a remote host or network gateway.
sar	Unix SysV performance monitoring tool. Useful for gathering system information over a longer period of time to use in long term planning, for example.
tcpdump	Public domain tools used in debugging and to monitor network traffic.
top	Provides quick, easy monitoring of processes and CPU activities. (This is a public domain tool that works on most Unix platforms.)
trace	Similar to truss on Solaris. Sometimes included by the vendor; otherwise, you can download this tool from an Internet site.
traceroute	Determines the path a packet takes throughout the Internet to reach its final destination.
vmstat	Provides statistics about process, virtual memory, disk, trap, and CPU activity.

Table 10.5 System Monitoring Tools - Sun Solaris


Tool	Description
lockstat	Provides information on OS and application locking. Available on Solaris 2.6 only.
mpstat	Provides statistics about each processor on the system
pmap	Provides breakdown on how much memory a process is using so you can see how much is shared and how much is private. (Located in /user/proc/bin.)
proctool	Monitors processes and threads. (Available from Sun's web site.)
snoop	Monitors network traffic; indispensable when debugging low-level packets.
SymbEL/Virtual Adrian	A very powerful system monitoring toolkit. Provides the functionality of the above listed tools and more. Can be used to tune the ncsize and ufs_ninode parameters and even has a mode to tune the operating system automatically.
truss	Provides information about which system calls a process makes.

Table 10.6 System Monitoring Tools - HP-UX


Tool	Description
glance	Provides detailed system information about open file descriptors, locks, threads, and so on.
gpm	Provides detailed system information about open file descriptors, locks, threads, and so on.
tusc	A system call trapper. Might not be available on all systems.
sysdef	Provides information about kernel parameters.
landiag	A tool for monitoring network statistics.
sam	System Administration Manager. A tool for general system administration.

Table 10.7 System Monitoring Tools - SGI Irix


Tool	Description
dkstat	Similar to iostat. Provides information about disk I/O and CPU use.
gmemusage (Irix 6.x)	X windows tool for viewing information about virtual memory.
netstat -C	Provides real-time, full-screen data.
osview	Provides full-screen information; combines functionality of vmstat, mpstat, and netstat.
par	Similar to truss on Solaris. Provides information about system calls made by a process.
Performance Copilot	An SGI add-in package.

Using SNMP

Netscape Messaging Server 4.0 supports the Simple Network Management Protocol (SNMP), version 1, and provides controls for configuring its SNMP subagent. Using SNMP and network management software, such as HP OpenView, you can monitor Messaging Server in real time as you do any other network device.

Under SNMP, data travels between a managed device and a network management station (NMS). A managed device is any device that runs SNMP; a server is a managed device. From the network management station, you can monitor the network remotely and exchange data between servers about network activity.

In Messaging Server, SNMP uses two agents to transfer information between the network management station and the managed device, the master agent and the subagent.

The master agent handles all communication between servers, through their subagents, and the network management station. The master agent is installed with the Administration Server, and is controlled through its user interface. For more information, see Managing Servers with Netscape Console.

The subagent for each server has access to its network information, which the subagent sends to the master agent when requested. The Messaging Server subagent is installed with Messaging Server and is controlled by the SMTP Settings form. For more information, see The Messaging Server Subagent.

Each server stores network information in the form of variables, or managed objects, which the network management station can query. The definitions for the server's managed objects are stored in the Management Information Base (MIB). For information about the Messaging Server MIB, see Appendix D, SNMP MIB.

Note: For more information about SNMP capabilities in Netscape Server products, see Managing Servers with Netscape Console.

For detailed information about the SNMP protocol, see RFC 1155 and RFC 1157.

Communication Between the NMS and the Managed Device

To exchange network information, SNMP uses protocol data units (PDUs), which contain information about the variables stored on the server. The network management station (NMS) and the server, or managed device, exchange PDUs in either of two ways:

In network management station-initiated communication, the management station queries the server for data. This accounts for most communication between the management station and a server. Messaging Server 4.0 supports querying server data only.

In a network management station-initiated session, the management station identifies which servers and variables to monitor by examining the MIB. Then, the management station sends a PDU to the master agent, which passes it to the subagent of the server. The subagent returns the data to the master agent, which sends it back in PDU form to the management station.

In managed-device-initiated communication, SNMP uses traps to send information about network events, such as shutdown and startup.

In a managed-device-initiated session, when a monitored event occurs, the subagent sends a trap to the master agent, which forwards it to the network management station. For information about traps, see MIB Traps in Appendix D, SNMP MIB.

Note: To send SNMP traps to the network management station, you must set the correct community and trap destination through the Administration Server. For more information, see Managing Servers with Netscape Console.

The Messaging Server Subagent

The Messaging Server's SNMP subagent, called ns-mailagt, gathers data about Messaging Server's network activity. You can configure some parts of the subagent through the SNMP Tab.

Before you can enable the Messaging Server subagent, you must start the master agent through the Administration Server user interface. The master agent handles communication between servers, through their subagents, and the network management station. The subagents of all installed Netscape servers communicate with the same master agent. For information about the master agent, see Managing Servers with Netscape Console.

Once the master agent is available, you can start the subagent. The subagent does several things:

It reads its configuration information, which is stored in Directory Server. This is the information you can set using the SNMP Tab.

It initializes the Messaging Server MIB, which contains variables that store network information.

It informs the master agent about the part of the MIB subtree that it monitors, and therefore what information it can provide. In this case, the Messaging Server subagent monitors, and can provide, only Messaging Server MIB data.

When the network management station sends a query, the master agent sends the request to the subagent through the SNMP Multiplexing (SMUX) protocol. The subagent queries the variables in the MIB and reports back to the master agent.

Periodically, the subagent checks the status of the Messaging Server. If it detects that the server has shut down, restarted, or failed to respond, it sends a trap to the network management station through the master agent. When the Administration Server terminates the subagent, the master agent unregisters the MIB, while the subagent performs any cleanup or logging and then exits.

For information about the Messaging Server MIB, see Appendix D, SNMP MIB. For information about the SMUX protocol, see RFC 1227.

SNMP Tab

You use the Messaging Server SNMP Settings form, which is part of Netscape Console, to set some options for the subagent, enable server statistics collection, and start or stop the subagent. After you modify the subagent, you must restart it before your changes can take effect.

To view and configure information subagent options, go to the SNMP Settings form.

In the Messaging Server Console, select the server for which you are setting subagent options.

Under Server Group, double-click the Configuration tab.

In the window on the right side of the page, click the SNMP tab.

You see the SNMP Settings form.

Using this form, you can perform the following tasks:

Configuring the Subagent

Starting and Stopping the Subagent

To verify the changes you make using the SNMP Settings form, see Verifying SNMP Configuration Changes.

Configuring the Subagent

To configure the SNMP subagent on your system and enable statistics reporting to the network management station, you use the SNMP Settings form, which is part of Netscape Console.

Note: Before you can modify the subagent, the Messaging Server installation you want to configure and the master agent must be running. The master agent is enabled through the Administration Server's SNMP Master Agent Control form. For more information, see Managing Servers with Netscape Console.

Follow these steps to configure the subagent.

Go to the SNMP Settings form. For directions, see SNMP Tab.

At the top of the SNMP Settings form, configure the fields as follows:

Master agent hostname. Use this field to enter the name of the host where the SNMP master agent resides. This must be a machine name, not an IP address. Default: localhost.

Master agent port number. Use this field to specify the port number the subagent uses to communicate with the master agent. Default: 199.

Organization name. Use this field to enter the name of the organization using Messaging Server. Usually this is a department or company name.

Server Description. Use this field to enter a text description that uniquely describes this Messaging Server installation, for example, the Messaging Server for Marketing.

Contact person info. Use this field to specify the person to contact about anything related to Messaging Server. Usually this is the server administrator. You can enter the name or email address of the contact, or both.

Server Location. Use this field to specify the location of this installation of Messaging Server. Usually this is a street address.

The information in these fields is stored in Netscape Directory Server for this installation.

Click Save.

A message appears reminding you to restart the subagent so that the settings can take effect. Before you can restart the subagent, you must enable statistics collection.