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
- 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
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.