a newbie question: how do i upgrade my bind 4.9.7 to latest version

Cricket Liu cricket at acmebw.com
Mon Aug 30 18:58:01 UTC 1999


>     Cricket> Okay, Jim, we're waiting.
>
> I thought you'd volunteered to compile a new FAQ? :-) ISTR a posting
> from you about this a while ago.

I volunteered to help with one, but since volunteering, I haven't heard
anything from the folks doing the compilation.

>     Cricket> I can hardly believe that it would cause more problems
>     Cricket> than it would solve.  By your reasoning, isn't providing
>     Cricket> a migration script like named-bootconf itself a bad idea?
>
> Yes and no. It's better than nothing, but I'm sure you'd agree that
> hostmasters should have some understanding of the zone{} statement
> instead of just blindly running a script. A little knowledge is a
> dangerous thing and all that.

Yes, definitely, and I think we'd both agree that named-bootconf is itself a
mixed blessing.  It's a great tool if you've got a named.boot file that's
hundreds of lines long and you don't want to convert it by hand or write
your own conversion utility.  Unfortunately, many folks don't take the time
to learn named.conf syntax after doing the conversion.

In that respect, named-bootconf is very similar to h2n.  At HP, we had lots
of administrators who never learned master file format because they had h2n
as a crutch.  I'll bet that somewhere, there's some administrator making all
his changes to his named.boot file and then using named-bootconf to filter
it into a new named.conf file each time.

>     Cricket> But if we provide a conversion script, shouldn't it do as
>     Cricket> complete a job as possible?
>
> But where do you draw the line for "complete"? Rejecting illegal
> names or bogus/missing glue records, zapping other common errors like
> NS and MX records which point at CNAMEs, multiple CNAMEs, syntax
> errors, etc, etc.

That's a good point, but I guess I'd say that the script should do as much
as it can automatically, without making assumptions about what the
administrator might want.  For example, leaving you with a zone data file
that produces a trivially correctable error message upon loading, even
though your original zone data file may have been squeaky clean, seems less
than good.  Not trying to guess whether or not you still want multiple CNAME
records seems perfectly reasonable, though.  You might be one of those
weirdos who really needs them.

>     Cricket> And if the clueless won't read the README, why do you
>     Cricket> assert that there's no substitute for a decent README in
>     Cricket> the distribution?
>
> Because we could all just tell them to read that README or FAQ instead
> of giving the same answers to the same questions. In fact, maybe the
> distribution could contain Something Obvious so everyone is told to
> read that FAQ before they post questions to the list. Some hope....

We certainly need some way to head off the FAQs.  We (Acme) are hoping to
revamp the Mr. DNS archive soon, both by adding our backlog of 1900+
"interesting" answers and replacing our lousy search engine with one that
supports boolean searches.  We hope that will help a little.  I'm tired of
telling people why http://314159265/ works.

>     Cricket> Why?  Say it stream edits the zone data files and
>     Cricket> prepends $TTL control statements.  If an administrator
>     Cricket> hasn't co'd the files, then he's no worse off than if the
>     Cricket> script hadn't done anything at all.
>
> True. But would does your proposed script cope with zone files that are
> or aren't under version control? Writing something that would work OK
> with the most common VC tools (and none!) will be awkward. Prepending
> $TTL directives is all very well, but that too could be troublesome,
> especially if it's done outside the check-out/in. [For instance, we
> check the zone files with the versions under the RCS tree just in case
> someone/something bypassed the co/ci and edited the zone file
> directly. Audit trails and all that. Not that we need a script to add
> $TTL directives anyway...]

Version control is certainly an issue, and one I hadn't thought about.

> I think that a script would be OK for the simplest (most clueless)
> setups, but it would need to be carefully identified as such. For
> instance "this tool won't work so well on zone files that are
> under version control and/or automatically produced (get your tool
> to generate $TTL)". I'm not sure how well such a message would be
> understood especially if the script was being run automagically for
> those who can't/won't read the most fundamental documentation. And if
> the script is for the clueless, the chances are the clueless won't use
> it. Someone had a great signature: "the more you try to make things
> idiot-proof, the world makes a bigger idiot". NB: I'm not insulting
> the people who pose naive questions, just making a point.

All good points.

Well, I hold off on doing anything just yet, and mull it over a little more.

cricket

Acme Byte & Wire
cricket at acmebw.com
www.acmebw.com

Attend our next DNS and BIND class!  See
www.acmebw.com/training.htm for the
schedule and to register for upcoming
classes.



More information about the bind-users mailing list