IPADM Design Considerations (Mastering Perl/Tk)

start page | rating of books | rating of authors | reviews | copyrights

19.2. IPADM Design Considerations

The programs detailed in the remainder of this chapter work in unison to help manage Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) configuration files. Now, you don't have to know anything about DHCP or DNS, or managing IP networks for that matter; we're more concerned with how to manipulate these files remotely, rather than with their actual content.

Suppose we have a company, ACME Rocket Supply, Incorporated, which has a class B IP network, 192.168.0.0.[50] The site administrator has subnetted this address space by department; for instance, IP numbers 192.168.1.0 through 192.168.1.255 are assigned to the accounting department, while 192.168.2.0 through 192.168.2.255 are for purchasing. The administrator also decided to make each department responsible for managing its own computers and printers, and has delegated and trained several responsible persons. But he doesn't want his helpers to have direct access to the server machine. So he has written a Perl/Tk TCP/IP client, ipadm, for remote IP administration.

[50] This is actually a private address space that anyone can use, as long as the addresses remain on the internal network. We'll freely use any of the 65,536 IP numbers in the range 192.168.0.0 through 192.168.255.255 without fear of interfering with a valid address.

There are various DHCP and DNS programs, and ACME.com's network administrator chose not to limit his choices by writing ipadm for any particular flavors. Instead, he invented a metafile that describes an individual subnet, which can be sent to a filter to produce DHCP and DNS configuration files in whatever format is required. It's these metafiles (subnet definitions) that are remotely manipulated. Each subnet definition file consists of two sections, separated by a __NODES__ line. The following is a sample subnet description file:

Title = Subnet 128B, ACME Rubber Band Development
Domain = RubberBand.ACME.Com
Base_IP = 192.168.128.16
Subnet_Mask = 255.255.255.240
Gateway = 192.168.128.30
__NODES__
JetDirect3:192.168.128.17:00abcd00abcd:print::Network Print Server
Coyote:192.168.128.18:00abce00abce:Badguy:Mail.ACME.COM:SGI  1
Roadrunner:192.168.128.19:00abcf00abcf:Goodguy:Mail.ACME.COM:SGI  2

The first section lists characteristics of the subnet as a whole, while the second section defines every subnet node. (We'll learn more about each colon-separated field in a node definition in Section 19.3.2, "The Subnet Widget Edits a Subnet Description".) Using flat file databases is a common technique in the Unix world, so we'll call these files SDBs, for subnet databases.

All the SDB files are centrally located in a single directory on the DHCP/DNS server machine, and a forking TCP/IP daemon serves them to Perl/Tk clients. The daemon, ipadmd, and client, ipadm, communicate using four IPADM messages, all originated by the client:

get_subnet_list: Tells the daemon to return a list of all subnets. ipadmd does this by reading the Title line of each SDB file (Figure 19-2).
get_subnet_file: Tells the daemon to lock an SDB file for exclusive access and return its contents.
put_subnet_file: Tells the daemon to expect an updated version of an SDB file, which it uses to rewrite the master copy. ipadmd then releases its exclusive lock on the SDB file.
unl_subnet_file: Tells the daemon to simply release its exclusive lock on an SDB, as the client has canceled all changes.

These four messages and their responses make up the IPADM protocol. Once the protocol is defined, we know exactly what each component of the system can and cannot do. But a formal protocol definition needs to be much more comprehensive and define in detail the format of each command and response. We won't do that here. Instead, we'll look at the actual code. Suffice it to say, each message consists of a command line, zero or more lines of data, and a terminator. The command line, which may have arguments, ends with a newline, as do the data and terminator lines. The terminator, which we'll refer to simply as $EOF, is a funny string guaranteed to be unique; that is, it will never occur anywhere in a message. The message response includes a one-line command completion status, zero or more lines of data, and the terminator, $EOF.

Figure 19-2. ipadm displays the results of a get_subnet_list command

The daemon also maintains an SDBM file containing the last modification times of all the SDB files. Periodically, it uses this information to see which SDBs have recently changed and invokes the filter procedure to create updated versions of the DHCP/DNS configuration files. Of course, the filter must exclusively lock SDB files before it can do its work.


19. Interprocess Communication with Pipes and Sockets		19.3. The Perl/Tk IPADM Client, ipadm