The DNS/DHCP database management system, dns_dhcp, is designed to support a small organization in managing network addresses and host names. It is assumed that the organization uses BIND and ISC dhcpd for IP name resolution and DHCP service. Dynamic DNS is explicitly not used.
dns_dhcp maintains a database of hosts and generates new configuration files for both BIND and dhcpd whenever an entry is added, removed or updated. This works reasonably well in a small group where the network topology changes infrequently.
The code for dns_dhcp is written completely in Python. The source code is found in svn+ssh://plato.cgl.ucsf.edu/usr/local/src/svn/local/trunk/dns_dhcp.The web interface is password protected using Apache basic authentication.
The server configuration files are not regenerated immediately upon database update. Instead, a monitor process checks the database version every ten minutes; if the database changed, configuration files are generated and both the DNS and DHCP servers are restarted. The monitor process is invoked from periodic, the locally written cluster-wide cron daemon, whose configuration file is found in /usr/local/etc/periodic/periodic.conf. New configuration files are generated in a temporary directory in /usr/tmp and are installed using the rdist program.
dns_dhcp is targeted for a small organization, and manages a small number of records (thousands, not millions). Therefore, we chose to store the data in XML format files under RCS. An advantage of using a plain file is that there is no dependency on a separate database package. Using XML makes the data parsable by a wide variety of applications. Using RCS enables us to keep a history of modifications. In addition, RCS locking is used to serialize update requests to avoid data corruption.Currently, the database is stored in /usr/local/www/rbvi/shared/dns_dhcp. In the same directory, there is also a version file containing the serial number of the last database that was used to generate DNS and DHCP configuration files.
dns_dhcp is accessed strictly via a CGI script (file /usr/local/www/rbvi/preview/cgi-bin/secure/dns_dhcp_registration.py, URL https://www.rbvi.ucsf.edu/cgi-bin/secure/dns_dhcp_registration.py) on an SSL-secured and password-protected web site. dns_dhcp is only accessible after the user login name and password have been authenticated by the web server. Authorization is determined by comparing the authenticated user name with the names in Login records and Admin records. The user is associated with groups from all Login records whose name matches the login name; the user is considered an administrator if there is an Admin record whose name matches the login name. Administrators may add, remove and edit all data types; regular users may only edit Group, Contact, Alias and Host records which match one of their groups.Authentication Setup
Authentication relies standard web server mechanisms. For example, the Apache web server provides a variety of authentication mechanisms ranging from basic to MD5 digests. Users must have a Kerberos account and be part of the compbio web group to authenticate.Authorization Setup
Authorization must be bootstrapped because only an administrator may add new users and administrators. The very first administrator must be added to the database by hand. This means writing some XML records that complies with the dns_dhcp schema.
A single CGI script handles all management requests. The default page contains a search form and links for adding records. To update or remove a record, the user must first find it via the search form, and then use the Update or Remove links on that page. To add a record, the user can click the appropriate link from the default page. All editing requests are first authenticated, authorized and checked for data consistency before being executed.
Server configuration files need to be regenerated when the database content changes. However, there are many occasions where multiple changes need to be made, and recreating configuration files and restarting servers for each change is inefficient. Instead, a monitor process is used to check for database updates regularly. When a change is detected, new configuration files are generated; checked for syntax errors; copied to installation locations, possibly on a different host; and servers restarted.