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,
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.
<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:
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.
*.mozilla.com
to allow all hosts from the mozilla.com domain.
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.
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:
<server_root>/admin-serv/config/admpw
. This is the user name (and password) you specified during installation. This user has full access to all features in the administration server and sees all forms in the administration server except the Users & Groups forms, which depend on the superuser having a valid account in an LDAP server such as Netscape Directory Server. If you use the local database, superuser will always have access to the Users & Groups forms.
<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.
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:
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:
POST
.) If you use this search feature, the Number of entries field determines how many entries to search, not how many will display.
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
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:
warning
.)
[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:
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
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
If the PDU requests the setting of variable values, the subagent sets these
values.
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.
CONFIG
. You can edit the CONFIG
file using the Server Manager, or you can edit the file manually.
If an SNMP daemon is running, make sure you know how to restart it and
which MIB trees it supports.
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
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:
If an SNMP daemon is running, make sure you know how to restart it and
which MIB trees it supports.
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
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."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 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:
CONFIG
file, specify a transport mapping for each interface over which the master agent listens for SNMP requests from managers. Transport mappings allow the master agent to accept connections at the standard port and at a nonstandard port. The master agent can also accept SNMP traffic at a nonstandard port. The maximum number of concurrent SNMP is limited by your target system's limits on the number of open sockets or file descriptors per process. Here is an example of a transport mapping entry:
TRANSPORT extraordinary SNMP
OVER UDP SOCKET
AT PORT 11161
NoteAfter editing the
CONFIG
file manually, you should start the master agent
manually by typing the following at the command prompt:
#
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>"
/etc/services
file to allow the master agent to accept connections at the standard port as well as a nonstandard port.
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>
# snmpd -P 1161
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,
Editing a community string
To edit a community string,
Removing a community string
To remove a community string,
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,
Editing a trap destination
To edit a trap destination,
Removing a trap destination
To remove a trap destination,