Re: DNS servers
> overall, your argument is just a recapitulation of DJB's old favourite
> "your way of doing things is completely wrong, you must throw it all
> away and change to my One True Way". that may be enough to convince DJB
> groupies, but it's not enough to convince me. in fact, it pisses me off
> and makes me extremely reluctant to even experiment with his software.
Whereas yours is entirely the usual "BIND RULES DJB SUX0RS!" variety.
Anti-zealotry is just as idiotic as straight zealotry.
> > > if djb actually gave a damn about providing a viable replacement for
> > > bind then he'd climb down off his pedestal and implement native
> > > support for bind-style configuration and zone files in djbdns. not
> > > a translator, not a converter, but native support for the existing
> > > files.
Why should he support something he disagrees with in entirety? Why
complicate the application he provides with what amounts to idiotic
cruft -- there are myriad scripts already provided by the community to
help you convert your BIND zones to tinydns-data format. This is assuming,
of course, that you don't simply transfer them using axfr.
Google is, and always shall be, your friend.
> what's wrong with habit? there are benefits to habit - the better you
> know something, the less likely you are to make a mistake with it.
There's lots of problems with habits. Especially the bad sort, the kind
where you use buggy, exploit-ridden software, much like BIND 4 and 8. Or
say, older versions of Sendmail (or apparently even more recent versions
of Sendmail). I know lots of Windows admins who continue to use IIS and
FrontPage-enabled servers "out of habit" because they can't be bothered
to switch to something that doesn't suck an inordinate amount of ass.
> it's also a question of documentation. Bind's format is well
> documented, with numerous books and HOWTOs published over the years.
> this documentation makes it easier to train new staff.
This point is pretty useless, considering how straight-forward djb-ware
is once you get your head around the underlying philosophy of it. Which
doesn't take more than a few minutes if you've admin'd various flavors
of UNIX and therefore have a feel for what's likely to go where --
because it probably makes sense for it to be there.
I think I've seen two or three books that concern Postfix (which you
mention using below). So what? The Postfix docs pretty much blow, if you
ask me, but I use Postfix over qmail -- partially because I'm lazy, and
partially because Postfix is just so darn easy to configure and use on a
Debian machine. Actually, I guess that amounts to the same thing,
doesn't it?
Postfix is also secure, fast, and operates in a relatively sane manner.
I find value in it, so I use it. I haven't been bothered enough by
anything it does to want to change. QED.
> while there's nothing "special"(*) about bind's zonefile format, there's
> also nothing wrong with it. there was no need to throw it out and
> re-invent it....especially when the re-invention is no easier to
> manipulate with scripts and is much harder for a human to read.
The BIND zone files suck. That's all there is to it. The tinydns format
was indeed slightly hard to read and understand for the first fifteen
minutes I screwed with it. And then - much like when I first started
writing Perl - it clicked. The fact that it's concise doesn't make it
hard to read; in fact, for me, it makes it that much more legible. It
makes it easier to write scripts which generate legible data files.
> (*) actually, the "special" thing about it is that it has existed for
> years, it is the de-facto standard, and that there are thousands of bind
> servers out there which use the format. these things are important,
> whether djb thinks they are or not.
De facto standard in Bizarro World, perhaps. And again, there are plenty
of scripts out there which will convert your BIND zone files to tinydns
format. There is zero reason to change what amounts to UI, when that added
"functionality" is completely unnecessary in the application itself. If
you're a UNIX systems administrator, you should know how to manipulate
text files.
> > > nobody with more than a handful of domains is going to throw everything
> > > away and convert to a new nameserver program that they know nothing
> > > about...and haven't been able to test adequately because it can't
> > > (won't!) read their hundreds or thousands of existing zone files.
Funny. The first day at the job I have now, I converted several hundred
domains from a Windows DNS box to djbdns. It wasn't difficult. And here you
are complaining about having to "throw everything away". This example
strikes very true in my opinion -- I moved from something that was
buggy, annoying, and broken, to something that was not.
You seem to be under the impression that moving to something new
requires you turn your old system into a bitpile of /dev/urandom output.
If you don't keep your old stuff around in the happenstance that you
misconfigure something, that's not the application's fault. It's yours,
for not being a good admin.
> no, it is NOT there already! i don't want to convert hundreds of
> zonefiles, i want to use my existing ones. i've already got tools and
> procedures in place for managing DNS updates, i have no intention of
> throwing everything away and starting from scratch.
Then don't. Use what you like. Why exactly are you bitching about this
to us when you appear to be perfectly happy using maradns (below) or
BIND? If you're happy with these things, why are you ragging on an
application that many people find incredibly useful and -- more than
anything else -- _sane_?
As I said above, anti-zealotry is just as lame as straight zealotry.
> djb never wants to understand this point, but this is crucially
> important. existing procedures and tools have value.
djb is a mathematician and a professor. The fact that he's uncomprising
when he believes something to be Correct isn't exactly what I'd term a
character flaw. This translates perfectly well into his software, and
it's all the better for it.
The fact that his applications use a UNIX philosophy and are therefore
in my -- and many other's -- opinion sane also revolves around the fact
that when he thinks something is Incorrect, he moves on and reimplements
it. I do the same thing too -- when I have a legacy application, script,
document, I'll generally end up just re-writing it instead of adding
more pathetic cruft to it, just because it "works".
It isn't good enough that things just "work". They should work
_correctly_, and you appear to not want to expend the effort in helping
make that change in your own environments.
> this is exactly the same problem as with qmail - if you want to switch
> from, say, sendmail to qmail, you have to throw away the entire
> configuration of your mail server and start again from scratch. that is
> why qmail failed as a viable replacement for sendmail, and that is why
> djbdns is failing as a replacment for bind. (postfix succeeded where
> qmail failed because it provided a migration path).
Postfix owes its entire existance to the fact that it was meant to be a
Sendmail replacement. Because of this, your argument is fatally flawed.
Postfix was a reaction to crappy software while letting people keep
their old habits -- as you so very much wish to do -- or easily migrate
away from their old bad habits into having new, better ones.
qmail is meant to be something New that worked in a manner sane to the
developer. And, apparently, sane to a large portion of people running
mailservers as well. Pretty wacky, that.
Your assertation that qmail has "failed" is woefully inaccurate and
suggests you have a less than realistic worldview.
If I was moving from, say, Sendmail to Exchange, I wonder -- would I
have to convert all of my domains to a new format? Or Postfix to exim,
or... etc... Your analogy is broken anyway you look at it.
> precisely my point. i wasn't forced to change, so i didn't - i waited
> until a program (vmailer aka postfix) came along that provided all the
> benefits (and more) of qmail, that also had backwards compatibility with
> my old sendmail stuff.
Yeah, that's exactly what Postfix and qmail needs.
sendmail.cf and M4.
> when postfix came out, though, i switched them all (including the qmail
> boxes) over to postfix within 6 months....and i was able to do this
> because postfix provided a migration path that allowed me to do a staged
> transition with backwards compatibility and minimal downtime AND (most
> importantly!) the ability to easily revert back to sendmail if anything
> went wrong. first i installed postfix as a (faster, more secure) bare
> replacment for sendmail, without using any of it's extra features...when
> that proved successful, i was able to start using more and more of
> postfix's features.
How long have you been a sysadmin? Generally speaking, when you feed a
new piece of software into something that has rollover capabilties --
eg, mail, DNS, webserving, whatever -- you put the new stuff in the
background _anyway_. And if you're going to be using two different
applications which have different configuration formats, all of that
stuff should be living in an androgynous format anyway. Like a plaintext
file which offers itself for easy updating and conversion. Or, as I do, a
relational database. The database gets updated, the configs then get
pulled and parsed from that information. Once it's living in a form that
is not application-specific, the majority of your "concerns" go away.
The REALLY nifty thing is that once you've got all your stuff in the
above database -- just about all the scripts to generate your junk for
you are already written. Unless you're like me and insist and writing
them yourself. Because, y'know, that's sort of your job.
> i intend to do exactly the same with dns, i'll wait until there's a
> decent replacement for bind that has native support for my existing
> zonefiles. if dbjdns implements that, then djbdns may well be that
> program. if not, then i'll have to wait longer for a replacement.
Well, good for you. When your nose starts bleeding from being up there
on that pedestal where you're using software you admit sucks (below),
be sure to spam us with any new revelations you might have.
> the point here is that evolutionary change via a staged migration path
> is far safer and far more likely to succeed than revolutionary change
> that requires throwing out the old and starting from scratch.
I really do not see your point. Your major complaints appear to be that
tinydns does not use your stupid BIND zone files, when it has already
been stated -- by myself and many others -- that you can easily convert
from BIND to djbdns without any downtime save for switching IPs. Your
arguements are invalid because I've _DONE_ this a number of times,
painlessly, and with no downtime.
> > > the successor program will also be free software, with a real free
> > > software license rather than djb's non-free license.
It's his software. He wrote it. He can do what he wants with it. If you
don't like it -- don't use it. Continuing to whine about it isn't going
to do anything except annoy those of us who have already accepted the
fact that he doesn't care to license it differently and still find value
in using it.
> the many thousands of free software packages which don't have that
> problem would seem to prove him wrong.
Actually, maybe you haven't noticed, but when you install, say, Postfix
on a Debian machine? And then you go install it on a Red Hat machine? Or
a SuSe machine? Or a FreeBSD machine? Yeah. All the configs, spools,
files/directories/whatever tend to live in different places based on where
that distro/OS feels they should.
Distrofication, you could call it.
> yes, i've read it. i think he's wrong. he claims that it's more
> important for the configuration and directory structure of programs to
> be 100% identical from one system to another than it is for programs on
> the same system to conform to the same policy. he's obviously not a
> systems integrator. most people couldn't care less about the
> configuration details of systems that they don't even use - they just
> want all the software on *their* system to operate in a consistent
> manner.
Well, if all UNIX-like operating systems followed the FHS, I'd say you
had a leg to stand on. But they don't, and neither do you. I was
initially annoyed with djbdns for putting more crap in slash until I
started running it on a multi-homed gateway box which had a number of
instances of dnscache and tinydns running for each interface. And wow.
Then it started making lots of sense.
At Cisco, they called this "scalability". Other people in the real world
call it "common sense".
I currently run two instances of tinydns on a webserver which is
eventually going to get a mate -- and at that point the secondary DNS
server will be migrated to the new box. Because tinydns binds itself to
an interface and because modern UNIX's have this crazy thing called "IP
aliasing" or "virtual IPs", I can have the current machine serving both
primary and secondary until I toss another box into the mix. This is
essentially pointless, I admit, and also a waste of resources -- but
boy, controlling those processes and later, when I migrate one of them?
So easy.
Not to mention that both servers _use the exact same data file_. It's
crazy only having to generate a single config for as many DNS servers as
I might care to use.
And hm, how should I get said data file to those theoretical servers?
Well, I suppose I could do it like I do at work and just use
passphraseless/key'd ssh logins to rsync the files.
It's weird, this whole "UNIX toolbox" mentality.
> > > it would also help in testing and/or migrating to djb's software if he
> > > tossed out his bizarre systems administration ideas and used plain-text
> > > config files like everyone/everything else rather than magic filenames
> > > inside a hard-coded directory tree to configure things. IMO, he's a
> > > good programmer but a lousy systems admin.
> he also uses magic filenames within directories, and he uses them
> extensively.
Which part of it isn't plaintext? The data file certainly is. And if
you're going to argue that doing an `ls' in a directory -- which is
logically placed -- is more difficult than editing a configuration file,
you're full of it.
If you're also going to argue that having a script do 'touch', 'rm', and
the like is also more difficult than opening a config file, parsing it,
saving it, checking to make sure it saved correctly, you're equally full
of it or a masochist.
> > > he should toss out the crappy ucspi-tcp and daemontools too - he may
> > > like them, but they're basically just a needless reinvention of
> > > inetd & tcpwrappers that provide no advantages but are significantly
> > > uglier to configure and use.
Yeah, reinventing software, making it more portable, easier to automate,
configure... Hm. That's "innovation", right? I think I've heard of that.
Maybe you should install dict and check it out. It's wacky!
> no, i just don't like djb's needless re-inventions of the wheel and i'm
> not particularly keen on change merely for the sake of change. i've
> changed the software i use many times over the years, but only when the
> benefits of changing significantly outweigh the disadvantages. there
> aren't any significant benefits of daemontools or ucspi-tcp over inetd
> and tcpwrappers.
If the wheel falls off the cart, maybe it needs to be re-thought. You're
too entrenched in your crappy habits, it seems.
> both maradns and dbdns make reasonable caching-only servers. for me,
> maradns wins because of it's license and it's lack of djb weirdness.
Strange that djb's "weirdness" is a major selling point for myself and
the more UNIX-philo-centric people I know.
> maradns isn't particularly good software, but a) it's GPL, b) it doesn't
> have djb's weird configuration style and c) it's adequate for the task i
> want to use it for. i still won't use it as an authoritative server
> because it isn't backwards compatible with bind zonefiles and its CSV1
> zonefile format sucks.
So.. you're using software that sucks. But because it's got a more
trendy license, you use it. Your second reason I have no issue with. If
you're more comfortable with it, hey, more power to you. The fact that
you admit it's inferior negates both points B and C, however.
While I'm all for people not using or doing things for moral reasons --
I respect my vegan friends for these reasons, even if it does make them
a pain to go to lunch with -- you don't see to have that entirely in
mind.
Software is not made better or worse simply because of its license.
Software can be judged on its own merit. Whether or not you feel you
have a moral or ethical reason to use that software due to its licensing
is something else entirely. I hate using Microsoft products not because
they're so expensive, but because they're horrible applications.
> > > it's as if he reinvents stuff that works perfectly well just to make
> > > people conform to his strange ideas about how systems should be
> > > configured - throw everything out and implement DJB's One True the.
Again, this is called innovation. It's when you see that things don't
work how they should, and you go do it a better way. The fact that you
don't agree with it is fine. The fact that you call people who DO find
it useful "groupies" makes me wonder at your own maturity. djb wrote
soemthing that makes sense to us. I guess everyone who uses Apache is
just a groupie, then?
The same can be said for idiotic Linux vs BSD wars. You use what makes
sense, what works best for the situation; you don't use something
because it has a SUPRA L33T COOL VALUE!!!1
What really pisses ME off is how people try to insist I use things just
because they're `cutting edge' and are therefore so much "kewler" than
what's currently standard. This is idiotic. I use applications that
work. That's it.
If it doesn't work, it has zero value to me. "Work", however, has a
number of connotations:
Is it easy to maintain?
Is it easy to automate?
Is it secure?
Can I easily replicate it if the machine it's currently living
on falls into a pit and is eaten by Cthulu and his dancing harem of
tenor sax playing gerbils?
> aside from bind, there are replacements for all of those programs which
> solve their problems while still providing backwards compatibility.
Yet again, there is backwards compatibility. It's called converting your
precious zone files to a less stupid format.
What all of this seems to come down to is that the "djb One True Way"
you continue to refer to rubs you the wrong way. Well, that's perfectly
fine. However, the fact that YOU act like djb has some sort of
obligation to do things he doesn't agree with simply because you don't
like how his software works is both insulting and counter-productive.
It seems to me, having used djb software for going on two years, that he
doesn't suffer fools -- and neither does his software.
The same could be, and has been, said for UNIX itself.
--
bda
Cyberpunk is dead. Long live cyberpunk.
http://mirrorshades.org
Reply to: