[Cu-wireless] configuration database update

[David Young]

I have programmed a CGI script to serve a configuration database
to hosts on our network. I have written a small client, too. They are
simple and hackish.  I will refer you to this e-mail when, weeks hence,
someone complains that they are simple and hackish. =)

The architecture of the configuration database is this. I keep a database
file (man 3 gdbm) with configuration records for previously-registered
stations. A station's record is indexed by the station's least MAC number.
A station record requires certain fields, including:

  * station ID
  * list of MAC numbers for each Ethernet-like interface on the station
  * name, address, phone number of station owner
  * a record of at least one network interface, with its

      * name
      * MAC number
      * configuration status (unconfigured, DHCP configured, configured)

    and, if applicable, its

      * IP number
      * uplink/pod/customer network status
      * pod number

Also in the database is the last assigned pod number and the last assigned
station id.

The configuration server answers GET- and POST-type requests. It examines
request parameters to find all the MAC numbers, does a lexical sort on the
6-tuple of octets in the MAC number, and chooses the first of the sorted
MACs as a key on the database. If there is a record under that key, the
server will augment it with certain complete fields from the request.
(Record augmentation is not well-defined, yet.) If there is no record
in the database already, but the client has completed all the required
fields, the server will assign a station ID, produce a new record from
the request, store the new record, and send the new record to the client
as key=value pairs. However, if the client has not completed all the
required fields, the server will send fill a new record as best it can,
sending it back without a station ID, but with informational messages
and queries for the operator to answer. The server will NOT remember any
incomplete record. Its interaction with the client is stateless this way.

The configuration client sends an HTTP POST request to the server
with all its MAC numbers and with as much important information about
its configuration as it can glean from examining its interfaces. If
it receives a response from the server containing a station ID and no
operator queries, it records the configuration carried by the response in
some well-known location and quits. However, if it receives a response
containing operator queries, it displays any messages in the response,
first, it interrogates the operator, and it sends a new request.

So that the configuration requests/responses will eventually cease,
it is the responsibility of the server to produce a bounded number of
operator queries except under operator command.

Most the queries I define right now fill such fields as the interface type
(customer, uplink, pod) and pod number.

I've written the configuration server and client in Python because it's
what I know. Both the programs admit should easy implementations in PERL,
Ruby, or the scripting language of your choice.

Dave

-- 
David Young             OJC Technologies
dyoung at onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933