Chapter 12 - Routine Operations
When major elements of the network are in place, administrative duties consist mainly of managing services and users. Some services require little management, others more. This chapter briefly reviews the kinds of tasks involved in managing all services.
If you are not responsible for the tasks in this section, be sure to talk with the person who does perform them. You should exchange information regularly and coordinate any changes that can impact one another's work. Most importantly, ensure that backups are done on schedule.
The operations that you can anticipate performing to maintain your network include:
Monitoring servers Backing up and restoring services Maintaining security at the server console Optimizing network performance Managing server logs
Some of these operations are performed daily; others less frequently. The next section describes the daily operations.
The types of operations that take place on a regular basis include:
Checking the services running on the server Backing up the information kept on the server Maintaining security at the server console Managing the server's printers
You can enter the MNET command, which runs the VINES Network and Systems Management (VNSM) software, to monitor native VINES server operations. Table 12-1 describes the configuration and statistical information that the VNSM software can display.
You can also use the OPERATE and MSERVICE programs to view service status at the console of a native VINES server or at the workstation and examine information about server resources, such as disks. StreetTalk Explorer can also be run from a Windows 95 or Windows NT workstation to display service status of a native VINES workstation.
On a StreetTalk for Windows NT server, you can use Windows NT utilities (for example, the Performance Monitor, Event Manager, and the Services Manager) to monitor StreetTalk for Windows NT services. In addition, you can run the StreetTalk STCOMMS utility from the system prompt to display topology information. For more information, see the StreetTalk for Windows NT Administrator's Guide.
This information can help you evaluate the performance of your server. Look at this information about once a week to monitor disk usage. This information can help determine whether to move a file service from one server to another.
Pay special attention to mail if you purchased that option. Mail should not be used as a database to store information. If unread messages accumulate and users' mailboxes get too large, the system may display a memory failure error when you attempt a complete system backup.
Backing Up and Restoring Services
One key administrative task is to make backups regularly as protection against the possible loss of information on server disks. You are responsible for setting up a backup schedule for the servers in the network.
Having a current backup ensures minimal loss of data if you run into a problem. For example, if a user mistakenly deletes a file, you can restore an earlier version of the file from a backup. The user loses only the work done since the backup was made, not the entire file.
The optional Enterprise Backup and Restore (EBR) program can be used to back up native VINES servers. See the EBR Administrator's Guide for more information.
You must use the Microsoft backup utility or a third-party utility to backup and restore StreetTalk for Windows NT services and data. The StreetTalk for Windows NT Release Notice lists recommended third-party backup utilities.
Developing a Backup Strategy
An effective backup strategy has two primary considerations:
Providing adequate protection for the people who use the server. Your backup strategy must minimize the number of days' work that can be permanently lost if a disk is damaged. Following a schedule that is practical for you and for users. It is important that backups are done on a regular schedule.
When planning the backup schedule, avoid backing up the system when it's being used heavily. If a file is in use while being backed up, the contents of the file on the backup may not be consistent with the user's copy.
To ensure the integrity of the server's data on the backup medium, use one of these strategies:
Shut down server software to make the server unavailable to users. Schedule the backup to start automatically at a time when no one is using the server. For a service backup, temporarily stop that service.
It is not required that you shut down or stop any services during a backup.
Develop a backup strategy for the server so that you always have an up-to-date version of the system on one or more backups. Use a combination of complete system backups followed by one or more incremental backups.
Types of Backups
An effective backup strategy begins with a complete system backup. A complete system backup is a copy of all the data on the server. How often you create a complete backup depends on how the server is used:
Once a week is recommended for servers with moderate-to-heavy use. Once a month is the recommended minimum for any server. For a server with a large amount of information on its disks, a single complete backup can span several tapes or diskettes.
Use incremental system backups to supplement complete system backups. An incremental backup copies only the files changed since the last backup, whether it was a complete or incremental backup. For example, if you perform a complete backup weekly, keep it up-to-date with daily incremental backups. Incremental backups take less time than complete system backups and often use less media.
A service backup is a copy of an individual file service or mail service. As a rule, you use service backups only when you are deleting a file service from the server and want to archive it.
Worksheets
Figures 12-1, 12-2, and 12-3 are worksheets for scheduling the different types of backups available with VINES. You can do a full backup of all server data or an incremental backup of the data that has changed recently. You do not need to shut down the server to make a backup.
Using more than one set of backup tapes lets you retain the backups longer. When you schedule a monthly full backup, consider scheduling drive maintenance if required.
If you are responsible for making backups, you can use the worksheets in Appendix A.
Maintaining Security at the Server Console
You can prevent people from using the server console of a native VINES server by locking it. When the console is locked, no one can select a menu item without entering a password.
Managing Printers and Print Services
From a workstation, you can manage the server's printers, change paper form types, and control print jobs.
The print service lets you create a list of users who receive an alert message if the print service or printers fail.
Chapter 10 describes the print services.
Occasional server operations include:
Temporarily shutting down the software, and then either restarting it or rebooting the server. The procedures are quick and simple. Always give users advance notice of a shutdown. The REBOOT command lets you reboot a native VINES server from a network PC. Changing the console attached to the server, which requires that you specify its type. Restoring lost information on a server. Assigning information on the server's communications lines if you purchased serial communications options. You can change the information later, as needed. Controlling the information that enters and leaves your server's networks if your server is connected to serial lines or TCP/IP networks. Installing a new VINES or StreetTalk for Windows NT release or software option. Installing a patch on one or more servers. The VINES PATCH utility lets you install a software fix to one or more native VINES servers from a diskette, fixed, or network drive. Chapters 8 an 9 of the Banyan Server Operations Guide describe this program. Supplying information to the system whenever you add or change the network cards or disks in the server. Changing the system date, time, and time zones. Using the VINES Network and System Management (VNSM) software to optimize the performance of your network. Maintaining a log book and managing server logs. Giving your service representative access to your server if you experience a problem you cannot solve.
You can use VNSM software to identify performance trends and compare new statistics with past performance. Based on your evaluation you can make the following adjustments:
Replace a network communications card that is generating many errors. Move a service or a group. Stop unused or lightly used services. Reduce the number of users of a service or a server. Fine tune server resources (for example, file system cache, communications limits, or swap space). Move a LAN or workstations from one server to another to change the physical configuration.
See Monitoring and Optimizing Servers for more information.
You should keep a system log in a notebook by the server to record events such as backups taken, hardware or software added, or problems encountered. For each entry, include a date and time. Such a history is very helpful when diagnosing a problem.
You can use VINES Network and System Management (VNSM) and other VINES programs for troubleshooting problems on your servers or on your network.
For example, if the performance of your server is impaired, VNSM can tell you if the server is processing more traffic than its resources can handle or if it does not have enough memory for services to run efficiently.
You can use StreetTalk Explorer or the OPERATE program to produce a log report. Server logs contain information on system and service activity. This information can help you troubleshoot, determine the source of security violations, and measure the activity of users and servers. You can also use log files to keep track of changes to VINES Files (drive Z).
You use StreetTalk Explorer or the OPERATE program to control the type of information VINES logs. Server logs are ASCII files.
StreetTalk for Windows NT automatically creates log files for installed services in the \Program Files\Banyan\Data directory.
Logs can be viewed at the server console of a native VINES server or at a workstation. To view logs, you load them into any program that accepts such files.
Most services maintain two log files that range in size from 10 to 75 KB. The two log files are swapped so that when one log file is filled, the service flushes the contents of the other log file and begins writing to it. This allows the most recent logs to be retained. When you generate a log, the log file extraction program concatenates the two files and displays the contents in chronological order.
Log File Size Configuration
The normal log file scheme for VINES services consists of two log files, for example, SS0.log and SS1.log for SS (Server Service) as described above. Log data is first sent to SS0.log and, when SS0.log exceeds the maximum log file size specified by the service, the SS0.log file is closed, the SS1.log file is opened and emptied, and log data is sent to that file until it exceeds the same maximum log file size. Then the SS1.log is closed and the SS0.log is re-opened and emptied, and so on.
It is sometimes useful to be able to access all historical Security Service (VS) logs for previous dates. For example, you may want to have records of all login attempts that occurred on a specific Monday morning two months ago.
You may perform and archive backups once a week but this does not retain all log information if log file wrapping results in data loss before the next backup. At VINES 8.6, the logging mechanism lets the VS log files grow to an unlimited size and then creates a new log file each day regardless of size. This is achieved as follows.
If an ASCII text file named LOGSIZE exists in a given service's home directory, for example, /disk1/banyan/vs/LOGSIZE, when the service starts up, that file is scanned for a log file size in bytes. If there is a number in the LOGSIZE file greater than 0, that number is used to override the service's encoded default for maximum log file size in bytes. For example, if LOGSIZE contains 500000, the maximum log file size is 500,000 bytes (488 KB). If there is no LOGSIZE file or no number in the LOGSIZE file, the service's encoded default for maximum log file size and the standard alternating two log file scheme is used. If the LOGSIZE file exists and the ASCII value in the file is 0, the No-Size-Limit/Daily-Log scheme is invoked. Seven log files are created, for example, VS0.log through VS6.log that correspond to Sunday through Saturday, respectively. There is no size limit for any of the daily log files. With this mechanism in place for the VS service, the weekly backups will now contain all VS activity that was logged for the past week.
This feature is available to any VINES service.
This does not affect any previous system behavior because the LOGSIZE file does not exist for any service by default. This feature is available if you explicitly create the corresponding LOGSIZE files. To create the LOGSIZE files in service directories, you must have UNIX access.
To specify the kinds and volume of log messages that specific services will log, you set a log level.
Log Levels
A log level determines how much logging information will be written to disk. Levels range from 0 to 3, with level 3 being the most extensive. Log files are of fixed sizes so that a high log level (level 3) provides more information over a shorter time than a low log level (level 0).
Level 0 and 1 messages are always logged by a service, and include information on the following kinds of events:
Security Violations - Failed login attempts, failed file access attempts, and other access violations
Fatal Errors - Serious events such as a service shutting down
Media Events - Disk problems or other media-related errors
Communication Events - Lost sessions, failures to communicate with another service or client, or other communication difficulties
Level 2 and 3 messages can include debug messages, which are meaningful only to Banyan personnel.
Refer to Chapter 13 in the Banyan Server Operations Guide for the procedure used to set a log level.
New or Modified Programs on Drive Z
You can use Banyan server logs to identify and record all changes to VINES Files. Each time you generate a server log report (using a Banyan Management Tool), a consistency check is automatically run on all VINES program files. The server log includes the results of the consistency check. The VINES Files consistency report identifies all standard VINES client programs that are missing or that were modified.
The log reports the following changes:
A standard VINES file is missing or modified The name of a VINES client program was changed
The consistency checker reports on clients for each location (language version) that the server supports.
Planning Guidelines
When you use log files to track down an intermittent problem, it is important that you save the logs at some regular interval, or at intervals that match the time a process runs. Each log file rolls over at different intervals, depending on the type of log file and its log level. The size and topology also determine the frequency at which you generate a log file.
For example, for a large network, you might consider generating two or three log files during the hour or so it takes for an STDA master service to rebuild its database. For STDA satellite services, a log file covering a 24 hour period is sufficient.
For smaller networks, a log file covering 24 or 48 hours will suffice for troubleshooting any problems. Whether your network is large or small, experiment with the frequency at which you generate log files to ensure that you are gathering sufficient information.
Exit codes and service error messages also help you troubleshoot problems on a native VINES server.
Exit Codes
VINES displays a message on the screen and a concealed exit code that describes the error condition when an attempt to run the BAN, LOGIN, or LOGOUT programs fails. You can capture the exit code with a batch program to determine the probable cause of the error condition.
Service Messages
In the event of a VINES system problem or a problem that originates from another source, a VINES service (for example, StreetTalk) prints an error message on the 25th line of a workstation, at the DOS prompt, or in a log file.
The following examples are StreetTalk error messages:
STK1003 GROUP NAME TOO LONG
STK1006 NO MORE AVAILABLE MEMORY
An error code precedes each error message. The code has the following format:
STKnnnn
where STK is a prefix that identifies the StreetTalk service, and nnnn is a unique number that identifies the error message.
Using On-line Help
To access on-line help for a StreetTalk error message, type the VNSERR command from the DOS or OS/2 prompt. The VNSERR command has the following format:
VNSERR error-code
where error-code identifies the specific StreetTalk message. For example, to access help for the message STK1003, type:
VNSERR STK1003
The VNSERR command displays an explanation of the message.
To print the help text for all StreetTalk error messages to LPT1, type the following command:
VNSERR /P:STK
LPT1 must have been assigned with the SETPRINT command.
See the Command Reference for a complete description of the VNSERR command.
You now have an understanding of the major hardware and software components of a Banyan network, and how they work together. You have examined the major planning issues involved in setting up services and user access to them.
Keep these major tasks in mind as you begin managing your network:
1. Make sure that all of the hardware is properly installed, including servers, workstations, LAN cards, and cables. Meet with the person who installs servers at your site, and offer to help so that you can learn about the process.
2. Become an expert on VINES or StreetTalk for Windows NT and all the LANs you manage. The more you know about the LAN hardware, the better off you are if something goes wrong. Take Banyan education courses, if necessary.
3. Plan all of the organizations, groups, services, user names, profiles, security parameters, and other resources that you will create. Reread chapters or sections of this book as needed during the planning process. Then, read the other administrative references for detailed instructions on adding and managing network resources. Further Reading below lists these references.
4. Know your applications software, especially as it relates to file sharing on the network. Study the installation processes carefully.
5. Monitor the users and machines in your network. Gather all the information you can. Talk to beginning and advanced users. Order additional documentation for them, if necessary. Eventually, make some of them administrators or operators of print services, and share some of your administrative responsibilities with them.
6. In the beginning, you will spend some extra time getting things started. Later on, managing the network will take less time. Therefore, you should first concentrate on simply making things work, then shift your focus toward making improvements to a working system.
7. Run StreetTalk Explorer, the VNSM, REPORT, MSERVICE, and OPERATE programs or Windows NT programs (for StreetTalk for Windows NT servers) to evaluate network performance and to display system logs. If you monitor the system fairly closely, you can prevent any problems before they happen.
8. Make sure backups get done. Consider storing important files on tape at a secure location to prevent accidental loss (by fire, for example).
For more information on the topics discussed in this chapter, see the following books in the VINES documentation set:
Managing StreetTalk for Windows NT Services
Banyan Server Operations Guide
