Setup Check
James W. Meritt Although there may be one system administrator who is held responsible for every system, it is highly unlikely on any large network that one administrator will personally install everything. Other members of the IS team, the individuals who own the separate system, even "knowledgeable" passersby can install things. So, I developed a program to check the setup and operability of a system. This script can run on a UNIX system to verify which programs have been installed. The program, called setup.chk, (Listing 1) is individualized by making the assignments used by this program. Before using the program, you should first set some variables that provide the following:
When these requirements have been established, you can begin testing. As the program examines your system, the results will appear on the screen in a readable format at what should be a readable speed. The sleep commands between items can be adjusted if need be. The program begins with a simple display to show the machine name and software revision information. This information is displayed at the beginning for two reasons: (a) The output may be directed to a file, and the identification at the top would help distinguish it from other files; and (b) If the system is wrong here, there really isn't a reason to continue. This information is followed by a quick check of the date and time. Again, if the output is directed to a file, this will be important identification information. Because some applications are very time dependent, the time should be as accurate as possible. Next, the script looks up the system's own name on the nameserver. This ensures both that the system being checked has an operating nameserver and that it is appropriately registered. It then performs a check of disk space. A new installation should have plenty of room to work on it. After a while, you should recognize what "normal" disk utilization looks like. The system also checks to make sure that specified directories are present. These directories are taken from the default root path on a Solaris system, but should be tailored to comply with the directory layout of the individual organization. The next checks performed by the script, use the program STROBE, which is a network security tool that locates and describes all listening TCP ports on a (remote) host. Here the program scans up to the highest value specified in the /etc/services file. As the system scans, watch to ensure that the services desired, and only the services desired, appear. The program next does a check of the system mount table and the one read from NIS, the automounter, and the overall operation of the network doing the automatic mounts. The program does a directory listing of every directory that should be mounted. After confirming the presence of the defaultrouter file, the checking program attempts to confirm that the system can reach the default gateway. It then ensures that there is a default route in the route tables. It checks that the load is within the usual parameters for your organization. To verify that the system can send and receive email, the script also operates the mailer verbosely to check the capabilities for sending and receiving email. The capabilities for ftp to and from the system are also checked. The program first checks to see whether the ftp command is available, then it checks whether the system is set up (in its network services files) to receive ftp. The program then examines the system logs for hardware errors. The errors that it checks for are in the file system.error, which is shown in Listing 2. The script also displays swap space. You need to know what should be there. Then the program checks that the system has access to the manual pages. Not all systems have this access, or even need to, so you should be aware of the requirements for your particular system. If interactive users are going to be on the system, the man pages should probably be available. Next, the program displays the system specification file. You should be able to scan through this briefly to make sure it is what you intend. To confirm the viability of all the default shells mentioned both in the password file for every user and read via NIS, the script displays a long listing of each one. These should be present, big, and executable. The script does not examine each for usability beyond that. The program checks the printer situation with lpstat, making sure that a printer is actually designated for use. Again, you must be aware of what is needed for the particular system. Printing is not allowed from some systems. For example, if there are only remote users, you may not want them to print remotely. To confirm the environmental variables, setup.chk displays them all. Simply watch for something unusual as they page out. Next, the script prints out the /etc/default/login. For assured operation, you should read this (it should be short) and ensure that the values are correct. setup.chk then prints out the hosts file. To ensure that the necessary entries are in /etc/hosts, look for the system's own address, the nameserver, and the systems that must be reachable if the nameserver is ever down. Next, read the display and ensure that the necessary entries, and ONLY the necessary entries, are in /.rhosts. Systems mentioned in this file can reach this system through the network unchallenged, so be very, very careful what - if any - entries are in this file. There are a number of checks that follow confirming the actions of the installation of root configuration and setup files. The checks compare the system defaults to the ones in the standard distribution and alert you to any differences. Watch for things that are organization or system specific. The script then says what the permissions for some standard files should be and prints out what they are. Watch this for any variance. If the root mail is forwarded, the program will print out where it is forwarded to. The script also prints out the message of the day. This message will be seen by everyone logging on and should identify the system, organization, and anything else you want everyone to see. Finally, the script runs the Computer Oracle and Password System (C.O.P.S.) security package, looking for security "holes" that may be present. The setup.chk program still requires the system administrator to look at each system, but it goes through all the things that the administrator would usually look at in a programmed order, missing, or forgetting nothing. It has proven to be an excellent debugging aid when used after a system "just quit working." By searching through everything that would stop a system from proper operation, the script has identified problems without a lot of frustration and guesswork. The script, as written, is a very general-purpose one that can and should be tailored for your individual organization. Some of the specific requirements have been mentioned in the discussion above, but to recap:
About the Author
Jim Meritt is currently working for Wang Government Systems, Inc as a Senior Security Analyst, and has been involved with Unix systems and networking for more than a decade. His email address is: JWMeritt@AOL.com.
|