On Thu, Aug 22, 2002 at 10:26:45AM -0700, Marc Singer wrote: > On Thu, Aug 22, 2002 at 08:44:04AM -0400, Matt Zimmerman wrote: > > No less appropriate than your one-line dismissal of a reasonable and > > tactful response. > > So let me get this straight. You equate "shut up" with a request for > concrete examples. How unfortunate.
You are expecting others to do your homework for you. If you take a casual look around your system, it should be clear why things are done the way they are. > > In the particular case of BIND, it is entirely reasonable to move the > > entire configuration somewhere else (such as into a chroot) and remove > > /etc/bind and its contents. It would be confusing to have them reappear > > when BIND is upgraded. > > The idea is that db.root is a different kind of file. Most of the time, > configuration files reflect the personality of the user's machine. > db.root contains information about the root name servers. I would > differentiate the presence of this information on a user's machine with > the application of that information. It has a closer relationship to > terminfo files or the POSIX timezone files than the global bash rc file. It sounds like you are arguing that DNS zone files should not be considered configuration files. If you read section 11.7.1 of the policy manual, it is clear that DNS zone files meet the policy manual's definition of configuration files. > > > As far as I can tell there is no way to pass --force-confmiss to dpkg > > > when using apt-get. Perhaps this is the only real omission. > > > > man 5 apt.conf, search for 'dpkg', 6th match. > > That's a global change. Someone else pointed out that it can be > passed with -o. I pointed you to the documentation for the configuration option. You are complaining that it is a global configuration option, and in the same paragraph explaining how to set it for a particular invocation. This does not make sense to me. > > The conffile system does nothing to break BIND's access to root > > nameservers; this only happens if an administrator explicitly removes > > db.root. If this was an accident, they need to reinstall with > > --force-confmiss. If not, then their change is preserved as it should > > be. What purpose would be served by making db.root not a conffile? > > Albeit, this isn't a grave consideration, but one that make repairing a > broken name server a little easier. Because --force-confmiss isn't a very > desirable switch to use, because there is no compelling reason to keep > db.root a configuration file, and because making this change would make > restoring a missing db.root simple it seems that real question is qhy > not?. If you want a db.root that is easy to restore, file a wishlist bug asking the maintainer to include a copy of the default db.root in /usr/share/doc/bind9/examples. -- - mdz
