iptool - Maintaining /etc/hosts
Bob Ess Before DNS and NIS, the /etc/hosts file was the method used for tracking hostnames and their associated IP addresses. In the early days of UNIX, before there were several thousands hosts to track, maintaining this file was relatively easy. A handful of hostnames and addresses was all that occupied the file. But as distributed computing grew up, this file grew larger and larger. Maintaining it correctly became more important as business came to rely on workstation network communications. Whether you have a small network or a WAN of thousands of machines, this file still plays an important role in the UNIX environment. Simply put, the file provides a one-to-one (or one-to-many) IP address to hostname key. On most, if not all, UNIX platforms, this file is what tells the workstation the value of its IP address during the boot process. When setting up DNS tables, this file is referenced by the h2n utility that is often used to create and update the DNS network tables. It is imperative that this file be accurate. If not, duplicate addresses can creep into the network and cause severe performance problems. Most large sites rely on NIS (Network Information Service) or DNS (Domain Name Service) to provide host to address resolution. These two facilities still rely on an accurate /etc/hosts file to maintain their tables. How these facilities operate is beyond the scope of this article. However, regardless of whether your site is using NIS, DNS, or the /etc/hosts file itself, keeping this file up to date and accurate is critical to maintaining a happy network. Maintenance Problems At large sites, there are usually several sys admins of various levels of expertise, one or two of whom are designated "keepers of the keys" when it comes to assigning IP addresses. This method works fine most of the time unless the keeper(s) is sick, on vacation, or just plain quits. Some sites use enterprise management software to help maintain the administrative flat files. These solutions, while effective, are highly complex and prohibitively expensive. Other sites use home-grown tools to help maintain their files. This is the spirit in which "iptool" was written. Our site has five administrators who could be changing the /etc/hosts at any one time; so, we needed a method that provided file-locking to keep from stepping on each others toes. Why automate? Manually maintaining the /etc/hosts file works effectively if just one or two admins are doing so in a fairly small shop. If you have dozens of segments with hundreds, perhaps thousands, of workstations, maintaining free and available addresses, assigning names, and knowing what is available or already on the net can be overwhelming. iptool does all of these things for you. Security Issues If you decide to run iptool as root, it will work just fine, however, you will lose the audit trail capability (i.e., who did what and when). In a large networked environment, this can be important - and not from a standpoint of being able to assign blame. By keeping a database of all transactions performed, you are maintaining a historical database of growth and resource allocation. We run sudo at our site. sudo allows non-root users to perform certain commands as root. It provides a complete audit trail as well. sudo is used with iptool to allow the user write access to the /etc/hosts file and root access to modify and push the NIS maps, all the while maintaining their UID during the process. It is this UID that is kept in the database as well as a log of their actions. Program Outline iptool is a Korn shell script (Listing 1) consisting of discrete shell functions that generate segment files, add a host and address, delete a host and address, show all free addresses for a given segment, sort and rebuild the /etc/hosts file and push out NIS maps, if needed. (Listings can be found at: ftp.mfi.com in /pub/sysadmin.) Program Flow By following the program listing, I will review important sections and point out areas where you likely need to make changes to allow iptool to play within your environment. Init Variables The only item you should have to change here would be the location of certain files and binaries. MASTERHOSTFILE will not likely change but SUDO may be in a public area other than /usr/local/bin. You may also want to keep your backup copies (ARCHIVE) in some other area than /etc/archive. I trap CNTRL-C's so that the tmp files are removed before the program exits. The program creates a lot of them and aborting out of the program without cleaning them up leaves a significant amount of trash in /tmp. Usage and CheckUID should be self explanatory. Again, not runnig as root allows an audit trail based on UID. LockHost and UnLockHost keep us from stepping all over each other. Usage is called anytime the incorrect number of arguments are used when the program is invoked. The first interesting function is GenFiles. This function does the following:
Once the above processes are finished, we then grep out the appropriate hosts for each segment and put them into a segment file. We end up with "n" number of files, named hosts.$segment (i.e., hosts.101.10.2), that include all of the valid hostnames and addresses for the segment. Now that we have the sorted segment files, we are ready to add, delete, or query for free IP addresses. AddIp AddIp contains four sanity checks before proceeding. First, it checks to see whether the address given on the command line already exists in the hosts file. If so, the program exits. The next check verifies that you have provided a unique hostname. If not, it aborts. Next, it checks to see whether the segment you provided in the IP address is valid for your network. Finally, a valid hostnumber check is performed. All of these checks are done in the AddIp function. Before this function is ever called, sanity checks are performed on the IPADDRESS and HOSTNAME as well. This is done to ensure that what we are telling the program to do is, in fact, what we want it to do. After the sanity checks are performed, a functional test is done to ensure that the chosen IP address is not actively configured on the network. Just because an address has not been formally assigned, does not mean it may not be in use somewhere. iptool will flag this condition if it exists. Also, if comments were provided on the command line, a COMMENTS string is built consisting of $USER, the date, and time. The host file is ready to be rebuilt, but first another check is done. DeleteIp The checks for deleting an IP address are not quite as extensive as for adding an IP address, because in order to delete an entity, you must provide an exact match. The program will not attempt to guess at it for you. DeleteIp provides only these two checks: Is the address in the host file, and does the address respond to pings? If the address is not in the host file, the program aborts. If the address responds to a ping, the program will not let you delete that hostname. If both of these checks pass, a simple grep -v is performed to create a temporary host file that has all entries but the one you want deleted. The host file can now be built. BuildHostFile First, a timestamped header is put at the top of the hosts file. Next, we check to see if we have done an "Add" action. If so, we add the entry to the temporary segment file. This file is then sorted. The HOSTDB file is updated to provide an audit trail of what has been added and deleted, by whom, and on what day and time. Finally, all of the segment files are cat'd into a tmp file. This file /tmp/hosts.tmp is uniq'd and sort'd and becomes our new host file. CleanUp A check is done to ensure that differences actually exist between the temporary host file and the current master. If so, we copy to the file to its final resting place and push out the NIS maps. CleanUp is also called when INTR's are caught. It removes all of the temporary files, of which there are quite a few, depending on the number of segments you have in your host file. ShowFreeIp Another function of this script is to provide the administrator a list of available IP addresses. This is done by invoking iptool with the -f switch and a segment number. A very simple check is then done using a counter to grep addresses against. Program Shortcomings The program, as written, requires 10 to 12 seconds to generate its temporary files using a host file of roughly 1000 entries. No doubt this program could be speeded up considerably using Perl or C. Nonetheless, performing any of the operation of iptool requires no more than a minute, including ping checks. Summary I have presented a simple method for maintaining the /etc/hosts file from the command line that all administrators can use. I have shown how to sort the hosts file, check for valid address, segments and hostnames, and how to rebuild the host file with proper address sequencing. By using this program, your host file insulates itself from "fat-finger" mistakes and protects you and your network by providing backup copies of the host file and doing preventative checks before adding or deleting a network entity. About the Author
Bob Ess is a Senior UNIX Systems Administrator, currently managing a UNIX support staff for Fujitsu Network Communications in Richardson, Texas. When not putting out fires, he spends as much time as possible with his lovely wife, Angel, and their two boys, Matthew and Gabriel. He can be reached via email at bob.ess@fnc.fujitsu.com.
|