[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A bunch of questions about commitinfo

From: Marc Haber
Subject: Re: A bunch of questions about commitinfo
Date: Sat, 10 Nov 2001 16:54:27 +0100
User-agent: Mutt/1.2.5i

On Fri, Nov 09, 2001 at 02:08:39PM -0500, Greg A. Woods wrote:
> [ On Friday, November 9, 2001 at 11:17:47 (+0100), Marc Haber wrote: ]
> > Subject: Re: A bunch of questions about commitinfo
> >
> > Drilling people doesn't work :-(
> Well, no, it doesn't always -- but if you have other checks and balances
> such as peer pressure it can encourage people to be more careful!  ;-)

I have lost all faith in that, regarding a few of my colleagues.

> > What I am planning is generating a named.conf fragment in the
> > commitinfo script, so that in case of new zones being added to the
> > repository the corresponding zone entry in the named.conf file can be
> > generated automatically. Also, I'd like to automatically add
> > allow-query clauses to named.conf for every zone that is loaded
> > automatically.
> Don't even try to do it that way.
> Don't ever version any generated files -- only version the sources to
> the programs which do the work.


> I.e. always automatically generate _all_ of the named.conf include file
> for all of the zones that will be installed into the running
> configuration (then test it along with the zone files themselves, of
> course) and just version the sources for the script that generates it.

I would have to have special mechanisms for zone files that need
special care in the name.conf file, for example having them in a
non-generated part of the server config and suppress generating the
automatic zone statement with a comment like "; named.conf manually".

Or, even better, generate an automatic zone statement if none is given
in the zone file itself, and if a zone statement is in comment lines
in the zone file, copy it to the name server config. I like that idea.
What do you think?

<example deleted>

So it would probably be the best idea to split the job into two:

- learn which zones have changed
- generate a named.conf containing only these zones [1]
- start test named
- if named barfs on any zones, reject commit
- if named likes the zones, accept commit.

[1] or would it probably be a good idea to test the entire config all
the time?

- ssh out to the name servers themselves, starting a script that
  - does cvs update
  - generates new named.conf
  - reloads the name servers

What do you think about that scheme?


Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."    Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29

reply via email to

[Prev in Thread] Current Thread [Next in Thread]