Life before hostcap

The situation: Our TCP/IP-based computer science department network currently consists of about 500 hosts, mainly UNIX workstations of various types. For the 20+ individual subnets, we use class C subnetting within our university's class B network. Our computer facility staff responsible for the network is divided into central staff who maintains the centralized services such as e-mail and netnews, and a number of staff members responsible for the various research groups and their subnets and computer facilities. For name service purposes we are using DNS and (with the exception of one subnet) NIS. All DNS and NIS related data so far have been maintained by the central technical staff. New hosts are added and existing ones removed or moved to a different subnet almost every day.

Life before hostcap: Before we introduced the host database, allocating a new hostname and IP address and entering it into the system roughly went like this:

Drawbacks: Manually inserting new hostnames and addresses into several files and keeping the files ``in sync'' is an inherently error-prone task; avoiding inconsistencies is quite difficult. In fact, newly installed hosts often would end up without a DNS record as our staff forgot to add it to the DNS tables; likewise, hostnames would show up in the ``trusted hosts'' netgroup long after they had been removed from the hosts NIS map. Furthermore, root permission was required to register new hosts with the system tables; and delays were inevitable as new hostnames and IP addresses were, basically, administered by a single member of staff.

(Not) knowing our hosts: Information about the hosts other than their names and IP addresses (e.g. OS version, hardware type, location) were not recorded by our staff, except for an occasional informal comment in the hosts map's source file (which was inaccessible for normal users).

As a result, with the number of machines growing, it became increasingly difficult for the technical staff to answer questions such as How many machines running Solaris 2.5 belong to the database systems research group? or How many SGIs are on the 5th floor?, and for the users to find out things like whether there exists a machine running a specific OS version. Likewise, it was impossible for the technical staff to write shell scripts or Perl scripts that performed some kind of administrative task (such as a software upgrade) for a subset of machines with specific characteristics, e.g. all machines running a particular OS release.

Hostcap: With the host database, all relevant information about all hosts in the local network is kept in a single, central place. The NIS and DNS tables are now generated automatically from the database; inconsistencies between the data files have become a thing of the past. Arbitrary host capabilities can be added to the host database, allowing the computer staff to accurately document our existing hosts. Portions of the host database are delegated to individual members of staff (who do not require root permission) to eliminate the bottle-neck caused by a single person doing all the work. Changes to hostnames and IP addresses become effective immediately. Using the new hostcap command and its query language, staff and users as well as administrative scripts can ask questions about hosts and easily select subsets of hosts with specific characteristics.

Top: hostcap overview  Next: A matter of format