tinydns on Debian, Sanity Intact
tinydns is nice. But it has some wacky ideas about filesystem layout. This is a headache for sysadmins. D.J.B. calls this a feature, not a bug. Nobody wins.
So I wrote a shell script to install tinydns from source, with some nice changes and additions.
Example: /etc/init.d/tinydns start. None of this /service mumbo-jumbo.
Doesn’t that just make you feel all warm and fuzzy inside?
Important note
Dan Bernstein considers any installation of his software with files moved from their default locations to be a broken installation. Any deviation from the way he intended the software to operate is a bug.
Under his definition, this script will give you a broken installation of tinydns.
It just might be a bit easier on your brain, though.
download link goes here
Rationale (this is long)
In the beginning there was Bind. Bind sucked. But bind was part of every server Unix and Linux distribution. Moreover, Bind was the first DNS server, and for a long time, the only one. People used it despite its sickeningly bad security record and somewhat obtuse configuration and data files. It wasn’t good software by most definitions, but it was out there.
(Pause to discuss parallels with sendmail)
Then, Dan Bernstein wrote tinydns (part of his djbdns package). It’s fast, it’s lightweight, and it’s secure. It’s a breeze to configure and automate. It’s everything a DNS server should be.
Dan has set some interesting terms for distribution of his software (check out the “May we distribute binaries?” section). I will not question his choice of license: it’s his software, and he can do with it as he pleases. What follows is simply my commentary.
Dan encourages cross-platform compatibility. On his page of that name, he tells how he is fed up with all the various Unices calling the same thing by different names. In the end, he states his opinion that “Breaking cross-platform compatibility for the sake of cross-package similarity is a horrible idea.”
In my opinion, he has things completely backward. Breaking cross-package similarity for the sake of cross-platform similarity is a horrible idea.
I’m going to invent a word. A software package’s “worldview” is the combination of the interface it presents to the user/administrator and the interface it expects the OS and other packages to present to it. A worldview includes details such as: expected paths for configuration and data files; where init scripts should go and what arguments they expect (up/down? start/stop?); what commands should exist for users to work with (one big command like openssl or mdadm? a lot of little ones like raidtools or mysql?). A worldview is everything POSIX doesn’t specify but humans need to know. A system’s worldview is one of the major things differentiating it from others.
Let’s also invent some users. There are a lot of system administrators that only work with one or two machines. There are also many sysadmins who have to manage hundreds or thousands of systems with incredible OS and configuration diversity. In between, there are many folks who deal with maybe a couple of dozen machines, a couple of dozen major software packages, and three or four operating systems. I am concerned with the latter group, as it seems to me those with less to contend with can deal with a bit of irregularity, and those with more to contend with are screwed anyway. (I have absolutely no data to back up anything in this paragraph, it’s just the way I feel the world works)
If every package has its own unique (and presumably “best”) worldview - its own unique set of paths, configuration file syntax, method of starting and stopping itself, and expectation of how other software ought to operate - and that worldview is consistent across operating systems, then the sysadmin tasked with maintaining twenty software packages must learn twenty different worldviews. Furthermore, applications and operating systems are stratified; different software packages are run on different systems. A department may run a webserver package on a Debian system, a scientific computation package on a big Sun box, and an MTA on an old Redhat server. In this case, what the sysadmin learns of the webserver’s worldview, or the scientific program’s worldview, or the MTA’s worldview, is white elephant knowledge that cannot usefully be transferred anywhere else. When a new package arrives, the administrator must learn its new worldview. If the department were to combine the web and mail systems onto one machine, the administrator may be better off, but migrations like that happen more rarely than new installations of new software.
In the opposite case, suppose every operating system suggests or enforces similarity between packages - each operating system has its own worldview. For our hypothetical department, this makes maintenance easier. Certainly, the sysadmin must learn each operating system’s worldview, but there are only three of those. Once thesysadmin is familiar with each OS, this knowledge can easily be applied to new packages. Even migrations aren’t as bad as they appear: practically speaking, the main differences between Unices these days are paths and APIs. APIs are something for the package author to worry about; by definition, that problem has been solved before the migration. Paths may cause some problems, but nothing a decent find-and-replace can’t fix. The actual content of a package’s files (configuration and data) should stay the same between operating systems, since it’s the same software.
Clearly, the system administrator who has to cope with a few operating systems and many software packages, is much better off in the case of cross-package similarity on a per-OS basis than in the case of cross-platform similarity on a per-package basis (which D.J.B. espouses). I believe this segment represents most system administrators in the real world, though I maintain I have no real data to support this belief.
Finally, I would like to make an appeal to universality. What if everyone wrote software the way D.J.B. does? What would happen if every author believed they alone knew the “best” way to set up a Unix system, and thus every package had its own worldview?
Chaos. A thousand different systems to start and maintain daemons. A thousand different paths for configuration files. Heck, a thousand different paths for binaries (Dan, are you listening? Nobody else on earth thinks it’s a good idea to put binaries in /var). Any system with more than one software package quickly becomes completely unmaintainable.
But what if every single operating system vendor, every last stinking one of them, had its own different and mutually incompatible worldview. Wait… isn’t that more or less how things are right now? The situation isn’t exactly dire. So there are, what, fifty different worldviews out there? The average system administrator will likely have to deal with a handful on a regular basis. Not perfect, but not the end of the world. The selection of operating system, then, is equivalent to a selection of worldview—a choice that must be made only very infrequently. And each system is self-consistent, with clear rules and patterns of behavior. Much better than the other situation.
In conclusion, cross-platform similarity with no regard to cross-package similarity within an operating system will only increase confusion for sysadmins.