Re: A bunch of questions about commitinfo

[Greg A. Woods]

[ On Saturday, November 10, 2001 at 16:54:27 (+0100), Marc Haber wrote: ]
> Subject: Re: A bunch of questions about commitinfo
>
> 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".

What you need is a smarter generating script -- one that can perhaps be
data driven so that whatever manual tweaks you do for those zones is
done by the script instead.

However instead of a comment in the zone file I would use an explict
exception list -- either embedded in the script or kept in a separate
file.

Remember also you can physically separate into different files the
sections that need different handling and include them in the master
/etc/named.conf file using the "include" statement as I outlined.
You'll note the example script I posted only generates a fragment of the
file.

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

That could work, though it's quite a bit of magic for something that
should be quite simple and transparent in its functioning.....

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

I would always test all of the config all of the time.

> (loginfo)
> - 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?

I personally would _never_ tie the update of the live files into any
part of the CVS actions.  This is just way too magic and far too prone
to errors and worse screwups.

I.e. I would always require a separate, deliberate, action to update the
live production files and reload the production servers.

One simple example of why this separation is a good idea is that this
will allow you to make several commits at times when updating the live
production servers would be inappropriate or maybe even impossible
(eg. when they're not running! :-).

It's one thing to accidentally forget to reload the production servers,
and quite another to accidentally update something that shouldn't be
updated right at the moment.

Separating the commit and the load also gives you the ability to
separately delegate the responsibility of who does what too.  For
example you could institute a two-phase commit where someone higher up
the chain of command could validate the correctness of what's running in
the test servers and then push it out to the production servers if it's
OK, and at a time that's suitable for them to be updated.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>