Configuring the administration server


his document describes the forms in the Admin Preferences and Global Settings categories of the administration server's Server Manager.

Removing a server from your system

You can remove a server from your system using the Server Administration page. Be sure that you don't need the server anymore before you remove it--this process cannot be undone!

Some NT servers have an uninstall program that you can use to remove a server and it's administration server. Check with your product documentation.
To remove a server from your machine,

  1. Shut down the server by clicking the on/off icon to the left of the server name in the Server Administration page.
  2. Click the Remove Server link in the Server Administration page.
  3. Select the server you want to remove from the drop-down list.
  4. Check whether you want to remove the administration server binaries (programs), including the administration server's configuration files.

    Do not remove the administration binaries if there are other servers installed in the same directory. Checking this option permanently deletes the administration server programs from the computer, and then you won't be able to configure your remaining servers.

    1. Verify that you want to remove the server or the administration binaries by checking the Yes boxes, and then click OK.
      The administration server deletes the server's configuration files, Server Manager forms, and the directory <server_root>/<servertype>-<id> and its subdirectories.

Configuring the system user and port number

Network settings affect the way the administration server runs. You can change the system user account that runs the administration server. This is a user account you set up with your computer's operating system. (By default, the user is nobody on Unix and LocalSystem on Windows NT.)

You can also change the port number that the administration server listens to. The port number can be any number between 1 and 65535, but it is typically a random number greater than 1024. For security reasons, consider changing the port number regularly.

NT
You can also change the password that the server uses when the service starts. Make sure that the user account has a password and has both administrative and "log on as a service" permissions. You should change the permissions using the Windows NT User Manager program located in the Administrative Tools group for your desktop.

To configure administration server network settings:

  1. Choose Admin Preferences|Network Settings.
  2. In the Admin server user field, type the system user account you want to run the administration server.
    If the administration server runs on NT, type the administration server user password. Retype the password in the Password (again) field for verification. Leaving the password field blank leaves the administration server user unchanged.

    1. Type the port number you want the administration server to use. Click OK.
      Restart the server for the settings to take effect.

Changing the superuser settings

You can configure superuser access for your administration server. These settings affect only the superuser account. That is, if your administration server uses distributed administration, you need to set up access control for the administrators you allow. The following settings apply only to the superuser for the administration server.

  1. Choose Admin Preferences|Superuser Access Control.
  2. In the Hostnames to allow field, type the hostnames of computers you want to use when configuring your administration server. You can list multiple hosts by separating them with commas. You can also use wildcard patterns to match multiple computers. For example, you could type *.mozilla.com to allow all hosts from the mozilla.com domain.
  3. In the IP addresses to allow field, type the IP addresses of computers you want to use when configuring your administration server. You can separate IP addresses by using commas. You can also type wildcard patterns, such as 198.95.*. Using hostnames is more flexible; if a system's IP address changes, you won't need to update the server. Using IP addresses is more reliable; if a DNS lookup fails for the connected client, hostname restriction can't be used.
  4. In the Authentication user name field, type the name you want to assign as the "superuser" server administrator. (This is the name you entered during installation.) This user name can be used only to log in to the administration server. This information is stored in the admpw file.
  5. Type the password of the user you previously specified.The password can have up to 8 characters and can include any character other than control characters. If you leave the password field blank, the password remains unchanged. Click OK.

    If you use Netscape Directory Server to manage users and groups, you need to update the superuser entry in the directory before you change the username or password in this form! If you don't update the directory first, you won't be able to access the Users & Groups forms in the administration server. To fix this, you'll need to either access the administration server with an administrator account that does have access to the directory, or you'll need to update the directory using the Netscape Directory Server's administration server or configuration files.

Configuring distributed administration

With version 2.x administration servers, an administrator could configure all aspects of a server because there was only one user name to use when logging in (the superuser). Distributed administration in 3.x servers lets multiple administrators change specific parts of the server. With distributed administration you have three levels of users:

The superuser password file

The superuser's username and password are kept in a file called <server_root>/admin-serv/config/admpw. If you forget the username, you can view this file, but the password is encrypted and unreadable. The file has the format user:password.

If you forget the password, you can edit the admpw file and simply delete the encrypted password. You can then go to the Server Manager forms and specify a new password. Because you can do this, it is very important that you keep the server computer in a secure place and restrict access to its file system. On Unix systems, consider changing the file ownership so that it's writable only by root or whatever system user runs the administration server daemon. On NT systems, restrict the file ownership to the user account the administration server uses.

Enabling distributed administration

To enable distributed administration:

  1. If you need to create a group, choose Users & Groups|New Group. Create an "administrators" group in the LDAP directory and add the users you want to let configure the administration server or any of the servers installed in its server root.
  2. Choose System Settings|Distributed Admin.
  3. Check Yes to activate distributed administration.
  4. Type the name of the administrator group. This is set to "Administrators" by default, but it can be any group found in the user database (local or LDAP server).
  5. Check Yes to allow end-user access to the user database. Doing this means users can access the administration server using the same URL that administrators do, except they only see a single form with their user information. End users can then change their own passwords or update any other information stored in their entry of the user database.
  6. Click OK.
    All users in the "administrators" group have full access to the administration server, but you can use access control to limit the servers and forms they can configure.

    Once you create an access-control list, the distributed administration group is added to that list. If you change the name of the "administrators" group, you must manually edit the access-control list to change the group it references.

Working with log files

Server log files can help you monitor your server's activity. You can use these logs to monitor your server and troubleshoot problems. Server logs are in a Common Logfile Format, a commonly supported format that provides a fixed amount of information about the server.

The error log file, located in admin/logs in the server root directory, lists all the errors the server has encountered.

The access log, located in admin/logs in the server root directory, records information about requests to the server and the responses from the server. You can specify what is included in the access log file from the Server Manager.

To configure logging options for the administration server:

  1. Choose Admin Preferences|Logging Options.
  2. Type a path to the directory where you want the administration server to store the access log file. You can type either an absolute path or a path relative to your server root directory. Leaving this field blank deactivates access logging.
  3. Type the path to the directory where you want the administration server to store the error log file. Leaving this field blank deactivates the error log.
  4. Type a path to the directory where you want the administration server to store the change log file. Leaving this field blank deactivates the change log. The change log lists details of the configuration changes made to the server.
  5. Click OK.

Viewing an access log file

You can view the server's active and archived access log files from the Server Manager.

To view an access log:

  1. Choose Admin Preferences|View Access Log.
  2. Choose the access log file you want to see. Active log files for resources and archived log files appear in the list.
  3. To limit how much of the access log to display, type the number of lines you want to see in the Number of entries field.
  4. If you'd like to filter the access log entries for a particular word, type the word in the Only show entries with field. Case is important; make sure the case for your entry matches the case of the word you're searching for. (For example, if you only want to see access log entries that contain "POST," type POST.) If you use this search feature, the Number of entries field determines how many entries to search, not how many will display.
  5. Click OK.
    The following is a sample of an access log in the Common Logfile Format:

    a.moz.com - [16/May/1997:21:18:26 -0800] "GET /admin-serv/icons/dot.gif HTTP/1.0" 200 2575
    
    a.moz.com - [17/May/1997:11:04:38 -0800] "GET /admin-serv/bin/frames?index+pref HTTP/1.0" 
    204 342
    
    a.moz.com - [20/May/1997:14:36:53 -0800] "GET /admin-serv/manual/ag/config.htm HTTP/1.0" 
    200 890
    
    arrow.a.com -[20/May/1997:14:36:53 -0800] "GET /admin-serv/manual/ag/so.gif HTTP/1.0" 401 
    571
    
     
    
    The last line of the access log file has several fields.

    Access Log Field

    Example

    Hostname or IP address of client

    user.mozilla.com. In this case, the hostname is shown because the server is using DNS lookups; if DNS cannot resolve the name or if DNS lookups are disabled, the client's IP address would appear.

    RFC 931 information

    - (RFC 931 identity--not implemented)

    Username

    john (username entered by the client for authentication)

    Date/time of request

    29/Mar/1998:4:36:53 -0800

    Request

    GET /help

    Protocol

    HTTP/1.0

    Status code

    401

    Bytes transferred

    571

Viewing the error log file

The error log file contains errors the server has encountered since the log file was created. It also contains informational messages about the server, such as when the server was started and who tried unsuccessfully to log in to the server.

To view the error log file from the Server Manager:

  1. Choose Admin Preferences|View Error Log.
  2. If you want to see more or less than 25 lines of the error log, use the Number of errors to view field to enter the number of lines you'd like to see.
  3. If you'd like to filter the error messages for a particular word, type the word in the Only show entries with field. Case is important; make sure the case for your entry matches the case of the word you're searching for. (For example, if you only want to see error messages that contain "warning," type warning.)
  4. Click OK.
    The following is an example of an error log:

    [13/May/1997:16:56:51] info: successful server startup
    
    [13/May/1997:16:56:51] info: Netscape-Administrator/3.0 97.117.0455
    
    [13/Mar/1997:19:08:52] security: for host user.mozilla.com trying to GET /admin-serv/bin/
    index, acl-state reports: access of /usr/suitespot/bin/admin/admin/bin/index denied by ACL 
    admin-serv directive 3
    
    [13/May/1997 20:05:43] failure: for host ceo.mozilla.com trying to POST /admin-serv/bin/
    distadm, cgi-parse-output reports: the CGI program /usr/suitespot/bin/admin/admin/bin/
    distadm did not produce a valid header (program terminated without a valid CGI header. 
    Check for core dump or other abnormal termination)
    
    In this example, the first two lines are informational messages--the server started up successfully. The third entry shows that the client user.mozilla.com tried to access the server but was denied access. The last log entry shows that the user ceo.mozilla.com tried to post a file incorrectly, probably by not using the Server Manager forms.

Using cron controls (Unix only)

You can configure several features of your Netscape SuiteSpot server to operate automatically and at specific times. The Netscape cron daemon checks the computer clock and spawns processes at certain times. (The these settings are stored in the ns-cron.conf file.)

To schedule tasks with Netscape cron, you need to start the Netscape cron control, which activates a daemon run by the administration server. A daemon is a process that is responsible for a particular system task. The daemon that controls scheduled tasks for your Netscape server can be activated and deactivated from the administration server. The tasks performed by the Netscape cron process depends on the various SuiteSpot servers. (On NT, the scheduling occurs within the individual servers.)

Some of the tasks that can be controlled by daemons include scheduling collection maintenance, auto-cataloging, and archiving log files. You need to restart cron control whenever you change the settings for scheduled tasks.

To restart, start, or stop the cron control:

  1. Choose Global Settings|Cron Control.
  2. Click Restart, Start, or Stop to change the cron controls.
    Any time you add a task to Netscape cron, you need to restart the daemon.

Configuring SNMP agents (Unix only)

You can monitor your server in real time by using the Simple Network Management Protocol (SNMP). SNMP is a protocol used to exchange data about network activity. With SNMP, data travels between a managed device and a network management station (NMS) where administrators remotely monitor and manage the network.

A managed device is anything that runs SNMP (for example, hosts, or routers). Your Netscape server is a managed device. An NMS is usually a powerful workstation with one or more network management applications installed. A network management application graphically shows information about managed devices (which devices are up or down, how many error messages have been received, and so on).

Every managed device contains an SNMP agent that gathers information regarding the network activity of the device. This agent is known as the subagent. Each Netscape server (except the Administrations server) has a subagent.

Another SNMP agent exchanges information between the subagent and NMS. This agent is called the master agent. A master agent runs on the same host machine as the subagents it talks to. You can have multiple subagents installed on a host machine. All of these subagents can communicate with the master agent.

Values for various variables that pertain to network management are kept on the managed device and reported to the NMS as necessary. Each variable is known as a managed object, which is anything the master agent can access and send to the NMS. All managed objects are defined in a management information base. The top level of the MIB hierarchy contains the most general information about the network. Each branch underneath is more specific and deals with separate network areas. The top level of the MIB tree is shown in Figure 2.1.

Top level of the MIB tree

Figure 2.1 shows the internet object identifier has four subtrees: directory (1), mgmt (2), experimental (3), and private (4). The private (4) subtree contains the enterprises (1) node. Each subtree in the enterprises (1) node is assigned to an individual enterprise, which is an organization that has registered its own specific MIB extensions. An enterprise can then create product-specific subtrees under its subtree. MIBs created by companies are located under the enterprises (1) node. The Netscape MIBs are located under the enterprises (1) node.

How does SNMP work?

SNMP exchanges network information in the form of protocol data units (PDUs). PDUs contain information about various variables stored on the managed device. These variables, also known as managed objects, have values and titles that are reported to the NMS as necessary. Figure 2.2 shows the flow of information between a managed device (in this case, your Netscape server), SNMP master agent, and NMS.

Interaction between Netscape server, SNMP agents, and NMS

Communication between the NMS, SNMP agents, and managed device can take place in one of two forms:

NMS-initiated communication: NMS-initiated communication is the most common type of communication between an NMS and a managed device. In this type of communication, the NMS either requests information from the managed device or changes the value of a variable stored on the managed device.

These are the steps that make up an NMS-initiated SNMP session:

  1. The NMS searches the MIB to determine which managed devices and objects need to be monitored.
  2. The NMS sends a PDU to the managed device subagent through the master agent. This PDU either requests information from the managed device or tells the subagent to change the values for variables stored on the managed device.
  3. The subagent for the managed device receives the PDU from the master agent.
  4. If the PDU from the NMS is a request for information about variables, the subagent gives information to the master agent and the master agent sends it back to the NMS in the form of another PDU. The NMS then displays the information textually or graphically.

If the PDU requests the setting of variable values, the subagent sets these values.

Managed device-initiated communication: This type of communication occurs when the managed device needs to inform the NMS of an event that has occurred. A managed device such as a terminal would initiate communication with an NMS to inform the NMS of a shut down or start up. Communication initiated by a managed device is also known as a "trap".

These are the steps that make up a managed device-initiated SNMP session:

  1. An event occurs on the managed device.
  2. The subagent informs the master agent of the event.
  3. The master agent sends a PDU to the NMS to inform the NMS of the event.
  4. The NMS displays the information textually or graphically.
    For information on setting up and configuring your server to use SNMP, see "Setting up SNMP" on page 48.

The Netscape MIBs

Each Netscape server has its own MIB (management information base). The administration server's MIB is a file called netscape-main.mib. This file defines the object identifier that is shared by all Netscape servers and lists each of the object identifiers for all of the servers currently supported by Netscape. The MIBs for all other individual servers contain definitions for variables that pertain to network management for that particular server. For information about the variables in your individual Netscape server's MIB, see the documentation for that server.

The shared object identifier defined in the netscape-main.mib file is:
netscape OBJECT IDENTIFIER : := { enterprises 1450 }.

Using the Netscape MIBs and network management software, such as HP OpenView, you can monitor your Netscape servers like all other devices on your network.

All Netscape MIBs for your server are located in the
<server root>/plugins/snmp directory.

Setting up SNMP

Before you can use the Netscape MIB to monitor your Netscape server, you need to first install a master agent (unless your SNMP daemon supports SMUX). If you're not sure whether your SNMP daemon supports SMUX, see its documentation. You then need to enable an SNMP subagent. Your Netscape Administration Server for Unix comes with an SNMP master agent. All other Netscape servers come with a subagent.

Note
You should be a system administrator or have in-depth system knowledge before installing the SNMP agents.

If you are already using an SNMP daemon and want to continue using it, you need to install a proxy SNMP agent before restarting the original SNMP daemon. If you are working on the AIX platform, go to the section Installing subagents on AIX.

If an SNMP agent is running on your system and you want to continue using the native SNMP daemon, follow the steps in these sections:

Installing the SNMP master agent

You need to install the master SNMP agent before you can enable the SNMP subagent. Master agent operation is defined in an agent configuration file named CONFIG. You can edit the CONFIG file using the Server Manager, or you can edit the file manually.

Manually installing the SNMP master agent

To install the master SNMP agent manually:

  1. Log in as superuser.
  2. Check to see if there is an SNMP daemon (snmpd) running on port 161.
    If there isn't an SNMP daemon running, go to Step 4.

    If an SNMP daemon is running, make sure you know how to restart it and which MIB trees it supports.

    1. If an SNMP daemon is running, kill its process.
    2. Edit the CONFIG file, located in plugins/snmp/magt in the server root directory.

    Here is an example of a CONFIG file:

    COMMUNITY public
    ALLOW ALL OPERATIONS

    MANAGER <your_manager_station_name>
    SEND ALL TRAPS TO PORT 162
    WITH COMMUNITY public

    The CONFIG file defines the community and the manager that master agent will work with. The manager value should be a valid system name or an IP address. You can also define initial values for sysContact and sysLocation, as well as transport mappings for SNMP. For more information about these values, see "A sample CONFIG file."

A sample CONFIG file
In addition to setting the community with which the master agent works and the managers receive traps, you can edit the CONFIG file to add initial values for sysContact and sysLocation, which specify the sysContact and sysLocation MIB-II variables. Note that the strings for sysContact and sysLocation in the example CONFIG file are enclosed in quotes. Any string that contains spaces, line breaks, tabs, and so on must be in quotes. You can also specify the value in hexadecimal notation.

Here is an example of a CONFIG file:

COMMUNITY          public
ALLOW ALL OPERATIONS

MANAGER nms2
SEND ALL TRAPS TO PORT 162
WITH COMMUNITY public

INITIAL sysLocation "Server room
501 East Middlefield Road
Mountain View, CA 94043
USA"

INITIAL sysContact "John Doe
email: <jdoe@netscape.com>"

Installing the SNMP master agent using the Server Manager

You can not use the Server Manager to install and start the master SNMP agent unless the server is running as root.

To install the master SNMP agent using the Server Manager:

  1. Log in as root.
  2. Check whether an SNMP daemon (snmpd) is running on port 161.
    If no SNMP daemon is running, go to Step 4.

    If an SNMP daemon is running, make sure you know how to restart it and which MIB trees it supports.

    1. If an SNMP daemon is running, kill its process.
    2. In the Server Manager, choose Global Settings|SNMP Master Agent Trap. The Manager Entries form appears.
    3. Type the name of the system that is running your network management software.
    4. Type the port number at which your network management system listens for traps. (The well-known port is 162.) For more information on traps, see Configuring trap destinations.
    5. Type the community string you want to use in the trap. For more information on community strings, see Configuring the community string.
    6. Click OK.
    7. In the Server Manager, choose Global Settings|SNMP Master Agent Community. The Community Strings form appears.
    8. Type the community string for the master agent.
    9. Choose an operation for the community.
    10. Click OK.

Starting the SNMP master agent

Once you have installed the SNMP master agent, you can start it manually or by using the Server Manager.

Manually starting the SNMP master agent

To start the master agent manually, type the following at the command prompt:

# magt CONFIG INIT&

Note
The INIT file is a nonvolatile file that contains information from the MIB-II system group, including system location and contact information. If INIT doesn't already exist, starting the master agent for the first time will create it. An invalid manager name in the CONFIG file will cause the master agent start-up to fail.
After installing the master agent, if you want to continue using the native SNMP daemon, follow the steps in the section "Using the proxy SNMP agent."

After starting the master agent on your system, if you do not want to continue using the native SNMP daemon, you can enable the subagent. For more information on enabling the subagent, see the documentation for your Netscape server.

You can start a master agent on a nonstandard port in one of two ways:

Starting the SNMP master agent using the Server Manager

To start the SNMP master agent using the server manager,

  1. Log in as root.
  2. In the Server Manager, choose Global Settings|SNMP Master Agent Control. The SNMP Master Agent Control form appears.
  3. Click the Start button.
    You can also stop and restart the SNMP master agent from the SNMP Master Agent Control form.

Using the proxy SNMP agent

If you already have an SNMP master agent running and want to use the native SNMP daemon, you need to install a proxy SNMP agent, start the proxy SNMP agent, and then run the native daemon on a different port other than the one the master agent is running on. To use the proxy SNMP agent, follow the steps outlined in the next three sections, "Installing the proxy SNMP agent," "Starting the proxy SNMP agent," and "Restarting the native SNMP daemon."

Installing the proxy SNMP agent

To install the SNMP proxy agent, edit the CONFIG file (you can give this file a different name), located in plugins/snmp/sagt in the server root directory, so that it includes the port that the SNMP daemon will listen to. It also needs to include the MIB trees and traps that the proxy SNMP agent will forward.

Here is an example CONFIG file:

AGENT AT PORT 1161 WITH COMMUNITY public
SUBTREES 1.3.6.1.2.1.1,
1.3.6.1.2.1.2,
1.3.6.1.2.1.3,
1.3.6.1.2.1.4,
1.3.6.1.2.1.5,
1.3.6.1.2.1.6,
1.3.6.1.2.1.7,
1.3.6.1.2.1.8
FORWARD ALL TRAPS;

Starting the proxy SNMP agent

Once you have installed the proxy SNMP agent, you need to start it. To start the proxy SNMP agent, at the command prompt, type:

# sagt -c CONFIG&

Restarting the native SNMP daemon

After starting the proxy SNMP agent, you need to restart the native SNMP daemon at the port you specified in the CONFIG file. To restart the native SNMP daemon, at the command prompt, type

# snmpd -P <port number specified in the CONFIG file>

For example, on the Solaris platform, using the port in the previously mentioned example CONFIG file, you'd type:

# snmpd -P 1161

Now you need to enable the subagent. For more information on enabling the subagent, see the documentation for your Netscape server.

Installing subagents on AIX

If your SNMP daemon is running on AIX, it supports SMUX. For this reason, you don't need to install a master agent. However, you do need to change the AIX SNMP daemon configuration.

AIX uses several configuration files to screen its communications. One of them, snmpd.conf, needs to be changed so that the SNMP daemon accepts the incoming messages from the SMUX subagent. For more information, see the online manual page for snmpd.conf. You need to add a line to define each subagent.

For example, you might add this line to the snmpd.conf:

smux 1.3.6.1.4.1.1.1450.1 "" <IP_address> <net_mask>
IP_address is the IP address of the host the subagent is running on, and net_mask is the network mask of that host.

Note
Do not use the loopback address 127.0.0.1; use the real IP address instead.
For more information on enabling the subagent, see the documentation for your other Netscape server. If you need more information, see your related system documentation for details.

Configuring the community string

A community string is a password that an SNMP agent uses for authentication, which means that a network management station would have to send the special password with each message it sent to the agent. The agent can then verify whether the network management station is authorized to get information. Community strings are not concealed when sent in SNMP packets; strings are sent in ASCII text. The master agent uses the community string for authentication.

You can configure the community string for the SNMP master agent from the Server Manager. You also define which SNMP-related operations a particular community can perform. From the Server Manager, you can also view, edit, and remove the communities you have already configured.

Adding a community string

To add community strings,

  1. In the Server Manager, choose Global Settings|SNMP Master Agent Community. The Community Strings form appears.
  2. Type the community string for the master agent.
  3. Choose an operation for the community.
  4. Click OK.

Editing a community string

To edit a community string,

  1. In the Server Manager, choose Global Settings|SNMP Master Agent Community. The Community Strings form appears.
  2. Click the Edit button next to the name of the community string that you want to edit.
  3. Edit the information.
  4. Click OK.

Removing a community string

To remove a community string,

  1. In the Server Manager, choose Global Settings|SNMP Master Agent Community. The Community Strings form appears.
  2. Click the Remove button next to the name of the community string that you want to remove.
  3. Click OK.

Configuring trap destinations

An SNMP trap is a message the SNMP agent sends to a network management station. For example, an SNMP agent would send a trap when an interface's status has changed from up to down. The SNMP agent must know the address of the network management station so it knows where to send traps; you can configure this trap destination for the SNMP master agent from the Server Manager. You can also view, edit, and remove the trap destinations you have already configured. When you configure trap destinations using the Server Manager, you are actually editing the CONFIG file.

Adding a trap destination

To add trap destinations,

  1. In the Server Manager, choose Global Settings|SNMP Master Agent Trap. The Manager Entries form appears.
  2. Type the name of the system that is running your network management software.
  3. Type the port number at which your network management system listens for traps. (The well-known port is 162.)
  4. Type the community string you want to use in the trap.
  5. Click OK.

Editing a trap destination

To edit a trap destination,

  1. In the Server Manager, choose Global Settings|SNMP Master Agent Trap. The Manager Entries form appears.
  2. Click the Edit button next to the name of the manager station entry that you want to edit.
  3. Edit the information.
  4. Click OK.

Removing a trap destination

To remove a trap destination,

  1. In the Server Manager, choose Global Settings|SNMP Master Agent Trap. The Manager Entries form appears.
  2. Click the Remove button next to the name of the manager station entry that you want to remove.
  3. Click OK.


Copyright 1997 Netscape Communications Corporation. All rights reserved.