[NCLUG] Are you running a local nameserver?

Bob Proulx bob at proulx.com
Tue Nov 6 19:26:58 MST 2007


John L. Bass wrote:
> It may be counterproductive for everyone to run off and make this change,
> which will show up as a Distro update in the near future. The general
> rules that distribution rules use for updates, is that if the user has
> NOT updated the file, then simply replace with the updated config file.

If people upgrade their packages to one containing the new root hints
file in a reasonable timeframe then I think that is a defensible
position.  People living on the bleeding edge packages would get this
update in a few days and that would be more than sufficient.  Do
nothing and let it flow through.  But people running long term support
stable systems might go a long time before seeing this update.  In
that case I think they should go ahead and be proactive about it.

In any case, since distro package managers always handle configuration
files sanely this shouldn't be a problem, right?  :-) :-)

I know that rpm based distros have historically had problems handling
configuration file changes but most people have learned to work around
them well enough so that I would not expect this to be a problem for
them.  People using rpm packages know to walk through the
configuration files and make adjustments as needed after an upgrade.
Regardless this should not block future package upgrades.  They should
continue to upgrade just fine.  And of course dpkg handles these
configuration file changes okay so this is not a problem there.

> If however, the user modifies a configuration file, then it generally will
> NOT be updated when the package changess.

That has not been my experience.  Mine on rpm has been that the old
file will be moved to .rpmsave and the new file installed in it's
place.  Of course it is %config versus %config(noreplace) versus other
handling in the package spec file that determines this behavior.  On
dpkg systems the config file handling will prompt the user as to which
file is desired.  In this case whichever one the user chooses will
work fine.

> For Debian users this will result in the package install scripts
> prompting to accept the change or aborting.

It certainly will not abort!  Debian users will be prompted with a
question to keep the current file, install the new file, or see the
diff between them in order to be able to help decide which to do.
This is a reason why keeping files diffs to a minimum is very useful.
Look at the diff, see that there are no changes outside of the
datestamp in the comment field, accept the new file simply to wash the
new file comments through.  This update as described should have no
changes other than comment differences, specifically the datestamp
included in a comment in the file.  Darn that or it could be
completely transparent.

If there were a way to predict what comment timestamp (and other
comments) would be in the future Sid package then that one could be
installed now and then in the future when that package was installed
dpkg would see that there were no differences and would not prompt the
user at all.  But this upgrade process is very much the normal thing
that happens on package upgrades on Debian.  It is actually very easy
and the framework supports it nicely.

> I haven't checked Redhat/Fedora reciently, but generally they
> quietly install the new config file as .rpmnew if the user modified
> the file.

I just looked at Red Hat packages a moment ago and I could not find a
root hints file in the package at all, making me think they must use
the compiled in defaults.

> The Debian maintainer for Bind 9 says the fix will be in the next upload.

I saw a message from LaMont[1].  Good for Debian Sid users.  But that
does not include Debian Stable users unless it is released as a
security upgrade.  This does not feel like a security issue so I would
expect not but it might be released through that channel anyway.  It
would be a safe upgrade.

> He also says there isn't any problem performance wise until at least two
> of the IP's have changed, so there isn't any problem other than a log
> entry at boot. He say's this happens about every 4 years, and never has
> been a problem.

Agreed.  I remember the last time this happened and it was not a
problem.

Bob

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449148



More information about the NCLUG mailing list