Wandering Thoughts archives

How systems get created in the real world

From my previous entry on our DHCP portal, I may have left you with the impression that it sprang into existence one day, fully formed and ready to go. I regret to inform people that this was not at all the case; instead, our DHCP portal is the end stage of a long chain of evolutionary steps.

It goes like this:

• in the beginning, there were not even Points of Contact; there was just a general computing support organization. Users contacted us directly to get their machines on the laptop network, and we edited the DHCP config files by hand. We had a large section of our support website devoted to how to find out your machine's Ethernet address.

• when the Points of Contact model came in, users now contacted their Point of Contact, who worked with them to handle things like getting their Ethernet address and then emailed us the details. We still hand edited the information into the DHCP config files.

• users strongly advocated for something that had better out of hours service and was faster. The Points of Contact already had access to the DHCP server so they could troubleshoot things for their users; as a quick fix, we decided that it would be simple enough to write a script to add entries and let them run it via sudo, which would at least get us out of the loop. As a bonus, we could use the same script most of the time and stop having to hand-edit the DHCP config files ourselves.

  The script is very, very cautious because it is directly editing the DHCP configuration files and restarting the DHCP server; it verifies all its parameters, does locking, and so on.

• we realized that we could use an existing authenticated local documents area on our internal https server to host a simple web form and CGI that asked the user for all of the necessary information (getting the user's identity itself from the HTTP authentication), then ssh'd off to the DHCP server to run the script (via sudo) to actually add the entry.

  The script's paranoia meant that we didn't have to worry too much about the CGI getting things wrong. (The CGI still did validation itself, if only because it could give the users much better error messages.)

• we cannibalized that CGI to run on another system that had direct access to the laptop network, so that it could just pluck the Ethernet address from the ARP cache instead of having to ask the user for it. Everything else was just cloned for the new system, including both the Apache configuration (clunky HTTP Basic authentication over https and all) and the ssh-based access to the DHCP server to run the script.

And that was how our DHCP portal came into existence, at the end of all of these incremental steps. The result is not as clean as if we had started from scratch with what we wanted, but if we had tried to do that we might not have gotten there at all.

The result is not perfect. For example, the script on the DHCP server was originally written for sysadmins who were nervous about it failing, so it has quite verbose output that's completely unsuitable for showing to users; as a result, sometimes all the CGIs can say is 'something went wrong, try submitting your information again'. (Fortunately ssh will pass the exit status back or the CGIs would be even less informative.)

This is something that I find typical for systems in the real world. Almost nothing ever appears from nowhere; things are almost always the end product of a long series of small changes and adaptations and tweaks, cannibalizations of earlier projects and programs, things adopted to different purposes, and so on. The result is imperfect and sometimes the cracks show, with little bits of obsolete functionality and odd gaps and limitations.