Automating Your Network Maintenance
Arthur Donkers In this rapidly changing era of online media and Internet, it is vital to maintain a consistent and reliable network configuration. This article discusses number of programs a network administrator can use to automate the process of adding and removing users and systems from the network configuration databases. Introduction Each time a network administrator adds a node to the network a certain number of jobs come back. This is also true when adding users to your network environment, either as interactive ones or "fake" users for dial-in network access. As you probably have experienced when doing the same job over and over again, you tend to let things slip a bit and become somewhat careless (at least I do!). So, I've written a few Perl programs to help automate these jobs. When you want to add or remove a host or user, you just have to edit one or two files, and the software does the rest (almost) automagically. Because of the variety in networks and dial-up access, I have split up the software into three parts. The first part takes care of the UUCP connections. These are used by people who want to access their mail while away from the office. The second part is used for LAN access, the "normal" way of accessing the services on the network. The last part is common to the first two, and is used in both cases. Note that these programs are still experimental and should be adapted to your own specific environment and needs. The Setup I used the following networking packages: Taylor UUCP (version 1.06.1) Sendmail 8.6.12 Cnews (Cleanup Release, April 1995) You can find these at a number of sites on the Internet -- an archie or WAIS search will point you to a spot closest to you. I run this software on a SPARCstation with Solaris 2.4. The Taylor UUCP packages replace the stock Solaris UUCP, as does the Sendmail software. This machine does not run NIS or NIS+ as there are no NIS clients on the network. If you want to expand the software in this article to support NIS(+), please feel free to do so. If you send me these extensions, I can add them to the package. This SPARCstation is the central network server. It runs the stock named, the name resolver, and our mail and news server software. People can contact this machine over the LAN to retrieve their mail and read their USEnet news. For those who are connected through a UUCP dial-up link, it batches all the outgoing traffic into UUCP batches. Almost all network maintenance is done on this machine, so all software will run on this machine as well. If your setup differs from this one, you can split up the software and divide it over the different machines on your network. The Basic Structure The basic structure of this software is simple. Adding and removing hosts is done by a cron job that runs every hour. Both the UUCP and LAN parts have their own cron job. The host to be added or removed is put in a special file that will be read by this cron job. This file is called /etc/maintsite.uucp for UUCP connections and /etc/maintsite.lan for LAN connections. After reading this file, the cron job deletes it, so it will not run into it on the next round. The format for these two files is not exactly the same, but there are similarities. Adding a host or user is done by preceding it with a "+" sign. If a site should be removed, it is preceded by a "-" sign. Below is a simple example for adding a UUCP host. Example of /etc/maintsite.uucp file:
+cheops
A maintsite.lan file will contain more information because it needs to know the IP address of the host to be added. Example of /etc/maintsite.lan file:
+sphinx 193.23.45.78
The UUCP Connection While discussing the UUCP part of the software, most of the third or common part will be covered as well. This common part can also be used in the LAN (i.e., TCP/IP) part. The complete Perl program for UUCP hosts is shown in Listing 1. As said before, I use Taylor UUCP on this system. One of the nice features of Taylor UUCP is that it can support a number of different UUCP configuration formats. It has its native, and most flexible, Taylor format, which is a descriptive configuration that offers the most features. For compatibility reasons, it supports the well-known HDB format, and for true die-hards, it also supports the V2 style. When building Taylor UUCP you can specify which formats you would like to have supported. You can have more than one format supported, but that definitely complicates things. As an added bonus, Taylor UUCP comes with a special program, called uuconv, which enables you to convert HDB or V2 style config files into Taylor ones and vice versa. Because of its flexibility, I use Taylor format config files. However, you can easily change the software to HDB style, either by using the uuconv program, or by changing the templates I use. Adding Hosts to the UUCP config Adding a host to the UUCP network setup is done in several steps. To keep things simple, only dial-in UUCP connections are supported. People on the road are constantly on the move so they cannot be reached at a fixed phone number. The first step is to add the machine to the list of well-known UUCP hosts. These are trusted hosts that are allowed to dial-in and transfer data. The list of these machines is kept in a config file called sys in the Taylor config directory. This config directory is mostly located in a subdirectory called conf in the home directory of the UUCP user. This conf file is the equivalent of the Systems file in HDB. Adding a host to this file is done by adding a number of configuration lines describing the characteristics of this host. Most of these characteristics are equal among the different hosts, the sole difference being the name of UUCP machine. To add a host, simply fill out a template file that is concatenated to the existing sys file. The %s% tokens in this template will be replaced by the actual name of the UUCP machine. To be able to delete a host later, the part added will be delimited by special comment lines that determine the beginning and end of a host section. The template is shown in Listing 2. As you can see, a number of %s% tokens are present, and the beginning and ending of this host section are marked with START and END. Before a change is made to the sys file, a backup is saved. Experience has taught me that one backup sometimes is not enough -- if you make the same mistake twice you have lost the original. So, a history is kept of a maximum of three old sys files. The remote system is allowed to send and receive mail and news, plus it may upload or download files through the UUCP public storage in /usr/spool/uucppublic. The remote system is never called (see the time configuration line). Finally, the username the remote system uses for dialing in is called uu%s%. As shown in Listing 1, adding a host is done in the function addhost. It will first scan the active sys file to see if the host is already present. If so, it will issue a warning mail to root and exit. If not, it makes a backup of the sys file, opens the template, and adds the host to the bottom of the sys file. The function also replaces the %s% tokens with the name of the new system. Before the new system can dial-in, it must be added to the /etc/passwd file. A UUCP connection is made by logging in and starting a special UUCP shell called uucico (UUCP Copy In Copy Out). So, for each user the following line is added to the /etc/passwd file:
uu%s%:*:UID:GID:Dial in UUCP account for %s%:/usr/spool/uucppublic:/usr/local/lib/uucico
In this line, %s% is replaced by the name of the system already added. The UID and GID are a unique User ID number and the Group ID of the UUCP group. The function adduser in Listing 1 will take care of this. It will first read the /etc/group file to determine the GID of the UUCP group. If found, it will add the user uu%s% to the group file. It will open the /etc/passwd file and determine the first unused UID. It will then add the line to the file. The account is default disabled, as there is a "*" in the password field, and the network or system operator should give this account a secret password for security reasons. When these two functions are completed succesfully, the remote system is able to dial in. However, it still needs to be fed data, that is, mail and news. The next thing to do is tell the news and mail software that they can batch outgoing data for this new system. Adding Hosts to the News Configuration For CNews the configuration is stored in a number of files in the home directory of the news user. This also applies to INN, but the files and formats are different. The main configuration file for CNews is sys. This file contains the names and setting for systems exchanging news, and defines which newsgroups are exchanged with a system. Listing 3 contains an example of this sys file. To add a host to this file, simply add a line describing the newsgroups for this system. While this line is added, the %s% tokens are replaced with the actual name of the system. In Listing 1, this action is done in the function addnews. This function is also called when a host needs to be added to the LAN configuration. To ensure the system will batch outgoing news through UUCP, the system needs to be added to another configuration file, batchparms. This file describes the parameters with which the batches are created. Listing 4 contains an example. batchparms tells the maximum size of one batch file, whether it should be compressed, and how the batches are sent to the remote system. In this case the viauux setting makes the batches go out via UUCP. Systems are added by appending a line describing the system name and a default setting for the batch parameters. This is done in function addnewsuucp in Listing 1. Adding Hosts to the mail Configuration Adding a host to UUCP for mail is also simple. The sendmail.cf I use assumes that the names of all UUCP hosts are contained in a file called /etc/mail/sendmail.uunames, and when a UUCP host is added, its name is appended to this file. This change is automatically reflected when sendmail is started to send mail to a host. All of these actions are done by the function addmailuucp in Listing 1. The sendmail documentation describes how to adapt your sendmail.cf file to read the names of UUCP hosts from a file. Previous implementations of the sendmail program called the uunames program directly and read the output. In version 8, this has been abandoned due to security reasons. Once all actions have completed succesfully, a mail is sent to root, informing it of a succesful addition. Removing Hosts When a host needs to be removed, the inverse of the actions described above are performed. Furthermore, these actions are performed in the reverse order. There is one catch however. When a UUCP host is about to be removed, the system might still have a number of batches waiting to be transmitted. These batches need to be sent before the host can be deleted from the UUCP configuration, or else some mail could be lost. So, removing a host from the UUCP configuration is a two-stage process. First of all, the host is removed from both the mail and news configuration to prevent new batches from being created. This is done by the deluucpmailnews function in Listing 1. For mail, the system name is removed from the /etc/mail/sendmail.uunames file. For news, its associated lines from the sys and batchparms files are removed. Once this has been done, the system must wait until the pending batches have been sent, or until the maximum waiting time has expired. If the batches are still pending after 24 hours, they are removed anyway. If there are no pending batches, the function deluucp is called, and the host is removed from the UUCP sys file. If there are pending batches, the name of the system is stored in a file called /etc/pending.uucp. This file is scanned each time the job is started by cron. If the job detects that all batches have been sent, it deletes the host. If after 24 hours the batches are still pending, they are removed from the queue, and the host is removed from the UUCP configuration, including the /etc/passwd and /etc/group file. Once the host is completely removed, mail is sent to root informing it of the successful deletion. The LAN Connection In a networking environment, it is common for hosts to be connected and disconnected from the LAN (Local Area Network), and adding a host to a UUCP setup can be relatively complicated. It involves editing a number of (not related) config files that are scattered around the filesystem. Managing the LAN configuration is a better structured process. Only a limited number of related config files needs to be edited, with only one exception. The program used to perform these functions is shown in Listing 1. It is the same program used for the UUCP connection. When the program is started, it will determine its own name. Depending on this name, the program will either go for the UUCP configuration or the LAN configuration. Adding Hosts to the named Adding hosts to the LAN configuration involves a number of simple steps. The host must be assigned an IP address, but fortunately that address is already included in the maintsite.lan file. First, you need to add this IP address to the named configuration files. This is the daemon that will resolve all IP address translation queries. These configuration files are stored in the directory specified in the /etc/named.boot file. This file is read by the named when it is started and contains pointers to other configuration files. An example of this named.boot file is shown in Listing 5. If a host is added to the network, it must also be added to the forward and reverse mapping files. The forward mapping (translating a name into an address) is done by the named.reseau file, and the reverse mapping (translating an address into a hostname) is done by the named.rev file. These two files are kept very simple, and they include .data files that contain the lists of hosts and IP addresses. When a host is added, its information is added to one of these .data files. An example of the named.reseau.data is shown in Listing 6, and an example of named.rev.data is shown in Listing 7. So, you add a host simply by appending the information to both of these files. As shown in Listing 2, this is done by the function addnamed. After the information is added to the configuration, the named program must be notified of the change. This is done by sending it a HUP signal. After receiving this signal the program will reread its configuration file and the new data will be available. One problem remains to be solved. The new system may not be directly accessible, but connected to the LAN via a router. The only thing this program can do is check the active routing tables in the kernel and test if the machine can be reached directly. If not, a mail message is sent to root, so he or she can adapt the routing information in the kernel. If you are using some sort of security software, you need to add the name and/or IP address of this new host to those config files as well. An example is the tcp_wrappers package that is used by the inetd program to control which hosts may connect to the system. The configuration of tcp wrappers is stored in two files, /etc/hosts.allow and /etc/hosts.deny. These files control which hosts are allowed and denied access, respectively. These actions are performed by the function addsecurity in Listing 1. If you are using another package, you can change this function to suit your needs. Adding Hosts to the mail Configuration There is no need to change the mail configuration when adding a host to the LAN. As sendmail is configured to use named, it will automatically detect when a new host is added to the configuration. Adding Hosts to the news Configuration Apart from adding the host to the sys file as described in the UUCP configuration, you also need to add the name of the new host to another file, nntp_access. This file controls which hosts may access the news spool through NNTP. An example of this file is shown in Listing 8, and this action is performed by the function addnewslan in Listing 1. Next, the host is added to the basic network configuration and services. A mail is sent to root notifying it of this successful addition. If your network needs more adaptations you can add functions to the program to perform them. Removing Hosts Removing hosts is just as simple as adding them. The actions described above for adding them are reversed and executed in reverse order. I assume the host has already been physically disconnected from the network before removing it, so no more links are open to the host. First, the host is removed from the nntp_access file so it can no longer access the news spool. This is done by function delnewslan in Listing 1. Then, the information is removed from the named configuration and the named program is notified by the HUP signal. When both of these tasks are completed successfully, root is notified of the successful deletion. Root must check the routing information by hand, to make sure no excess routes are left lingering in the kernel. Conclusions The program presented in this article is an experimental one and is not suited for use in a production environment. You will need to tune it and add more errorhandling to deal with user and system errors. This program does show you the techniques involved and how to apply them in your own programs, and combining all of these simple steps into one program can save a lot of manual work and creeping errors.
About the Author
Arthur Donkers graduated from the Delft Universiy of Technology with a degree in Electrical Engineering and a major in Computer Architecture. Since then he has worked for a number of major software houses in the Netherlands and participated in several major projects. His primary field of interest in these projects has been, and still is, datacommunications, especially the integration of multivendor networksystems. For the last four years he has worked as an independant consultant for his own company, Le Reseau (french for "The Network").
|