Re: dpkg should prompt re missing conffiles [was Re: When bind9 reinstalls, no db.root]
On 24-Aug-02, 09:48 (CDT), Oliver Elphick wrote: > On Thu, 2002-08-22 at 21:40, Steve Greenland wrote: > > While I'll grant you that "dangerous" is probably not the correct > > adjective, the current behaviour is correct. Debian policy is that > > packages don't override admin modifications to configuration files. > > Removing a file is a modification. End of story. > > The problem is not that it doesn't override, which would not be > desirable, but that it doesn't flag a missing conffile during > upgrading. Deletion of a file should be regarded as a change, and > should merit a question about whether the default package file should be > installed. It does. But you are asked about replacing only if *both* of the following are true: A. You've modified the conffile. B. The maintainer has modified the conffile. If only A is true, the conffile is left alone with no question. If only B is true, then the conffile is replaced with no question. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
dpkg should prompt re missing conffiles [was Re: When bind9 reinstalls, no db.root]
On Thu, 2002-08-22 at 21:40, Steve Greenland wrote: > While I'll grant you that "dangerous" is probably not the correct > adjective, the current behaviour is correct. Debian policy is that > packages don't override admin modifications to configuration files. > Removing a file is a modification. End of story. The problem is not that it doesn't override, which would not be desirable, but that it doesn't flag a missing conffile during upgrading. Deletion of a file should be regarded as a change, and should merit a question about whether the default package file should be installed. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "For yourselves know perfectly that the day of the Lord so cometh as a thief in the night. For when they shall say, Peace and safety; then sudden destruction cometh upon them, as travail upon a woman with child; and they shall not escape." I Thessalonians 5:2,3
Re: When bind9 reinstalls, no db.root
On Wed, 2002-08-21 at 16:08, Marc Singer wrote: > Without a single example, I don't see how installing a configuration > file where there is none can have *any* affect on the system. Off the top of my head, try "ls -ld /etc/cron.* /etc/*.d" That should give you a very incomplete list of directories in which it might happen. signature.asc Description: This is a digitally signed message part
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: > 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. Fortunately it is still possible and legal to run dpkg directly. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: When bind9 reinstalls, no db.root
On Thu, 22 Aug 2002, Steve Greenland wrote: > apt-get --option Dpkg::Options=--force-confmiss apt-get \ -o Dpkg::Options::=--force-confmiss \ -o Dpkg::Options::=--force-somethingelse \ Note the trailing ::
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 01:49:39PM -0700, Blars Blarson wrote: > In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > >because there is no compelling reason > >to keep db.root a configuration file > > > But there IS a compelling reason to keep db.root a configuration file: > alternic > > I don't use them, but debian shouldn't trash files that a sysadmin needs > to change to use them just because they arn't recomended. > > (See http://www.alternic.org/ for info on alternic. While I have my > problems with the way icann runs the DNS, alternic doesn't show signs > of being run better, just differently.) Perhaps the file is poorly named db.root -> db.internic-root
Re: When bind9 reinstalls, no db.root
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >because there is no compelling reason >to keep db.root a configuration file But there IS a compelling reason to keep db.root a configuration file: alternic I don't use them, but debian shouldn't trash files that a sysadmin needs to change to use them just because they arn't recomended. (See http://www.alternic.org/ for info on alternic. While I have my problems with the way icann runs the DNS, alternic doesn't show signs of being run better, just differently.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Re: When bind9 reinstalls, no db.root
On 22-Aug-02, 11:12 (CDT), Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > On Wed, Aug 21, 2002 at 11:38:36PM -0700, Marc Singer wrote: > > The trouble with removing db.root is that it may not be obvious how to > > recover when it is missing. > > the questions to replace/diff/keep a modified conffile, why dont they apply > to missing conffiles, too? Because you only get that question if the distributed version of the conffile is changed also. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: When bind9 reinstalls, no db.root
On 21-Aug-02, 19:16 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: > > It does appear that there are a couple of good examples. In fact, > this is not one of them since what you ought to ship is a cron.allow > that blocks everything, right? No, because that is not the expected, traditional behaviour in cron. If I included an empty cron.allow, I'd be inundated by bug reports about how crontab didn't work. > As far as I can tell, there aren't many 'dangerous' examples. A > package may install a crontab file in cron.d that is deleted by the > user. Apparently, apache2 performs directory scanning for > configuration files, too. Examples such as BASH are definitely *not* > dangerous since the default file contains a single, innocuous > directive. While I'll grant you that "dangerous" is probably not the correct adjective, the current behaviour is correct. Debian policy is that packages don't override admin modifications to configuration files. Removing a file is a modification. End of story. > As I wrote in another message, given that there is an override switch > in dpkg, that switch would be helpful if available in apt-get. apt-get --option Dpkg::Options=--force-confmiss Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: When bind9 reinstalls, no db.root
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
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 08:44:04AM -0400, Matt Zimmerman wrote: > On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: > > > This terse reply is obviously inappropriate. If you are annoyed, stop > > writing. > > 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. > > > I was asking for real examples in order to discuss how the case of bind > > and db.root is *not* a member of that set and how there may be a genuine > > problem with the handling of installing over missing configuration files. > > Are you saying that you think that the situation with this particular > conffile is different enough, and that there are enough other similar > conffiles, that it justifies different handling by dpkg? If so, I think > that I would disagree. > > 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. > > > 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. > > > Still, breaking bind's access to root name servers is particularly > > troublesome because it may tend to break all net access. It may be > > worthwhile to remove db.root from the list of configuration files. > > Especially, because this list isn't something anyone should need to > > change. > > 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?.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 11:38:36PM -0700, Marc Singer wrote: > The trouble with removing db.root is that it may not be obvious how to > recover when it is missing. the questions to replace/diff/keep a modified conffile, why dont they apply to missing conffiles, too? Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: > This terse reply is obviously inappropriate. If you are annoyed, stop > writing. No less appropriate than your one-line dismissal of a reasonable and tactful response. > I was asking for real examples in order to discuss how the case of bind > and db.root is *not* a member of that set and how there may be a genuine > problem with the handling of installing over missing configuration files. Are you saying that you think that the situation with this particular conffile is different enough, and that there are enough other similar conffiles, that it justifies different handling by dpkg? If so, I think that I would disagree. 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. > 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. > Still, breaking bind's access to root name servers is particularly > troublesome because it may tend to break all net access. It may be > worthwhile to remove db.root from the list of configuration files. > Especially, because this list isn't something anyone should need to > change. 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? -- - mdz
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 01:08:53PM -0700, Marc Singer wrote: > Without a single example, I don't see how installing a configuration > file where there is none can have *any* affect on the system. Removing /etc/snmp/snmpd.conf causes snmpd to _NOT_ start. Reinstalling the conffile would reenable snmpd, which is - given the history of snmp-related security-problems - dangerous. Regards, David -- Afrika kommt nach Europa. Das ist der Kontinentaldrift. Da kann man auch mit einem neuen Asylgesetz nichts dagegen machen. Das sollte mal wer denen von der FPÖ erklären! -- Dieter Nuhr (www.nuhr.de) in der Wiener Remise, 2002-08-02 pgpmc4wfwv0wW.pgp Description: PGP signature
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:19:49PM -0400, Scott K. Ellis wrote:
> > Still, breaking bind's access to root name servers is particularly
> > troublesome because it may tend to break all net access. It may be
> > worthwhile to remove db.root from the list of configuration files.
> > Especially, because this list isn't something anyone should need to
> > change.
>
> I beg to disagree. Changing db.root is the primary way to use an alternate
> DNS root (either for an all-internal DNS, or to utilize an alternate DNS
> root than NetSol's). Just because you can't see why something might be
> configured differently doesn't mean other people can't.
One can change the database reference in named.conf to do this. The
difference is that db.root references 'the' root servers. You can
choose which ones you want to use in the zone file:
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.alternative_root";
};
The trouble with removing db.root is that it may not be obvious how to
recover when it is missing.
Re: When bind9 reinstalls, no db.root
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 22 Aug 2002, Arthur de Jong wrote:
> > For example...
>
> Logcheck has a number of files under /etc/logcheck/ignore.d... that are
> marked as configuration files. Removing a configuration files means that
> more information is present in the log summary. (automaticly) Replacing
> these configuration files would result in unwanted behaviour.
Oh I just thought of a better one: a lot of packages have configfiles in
/etc/cron.{daily,monthly,weekly}. Removind a configfile is clearly not the
same as having a default in this case.
Bluntly overwriting the db.root file is also not a good idea since some
people use alternative root nameservers. If you screwed up your package
configuration you should do:
apt-get --purge remove bind9
apt-get install bind9
(maybe apt-get --purge --reinstall install bind9 would be nice)
You either replace you whole configuration or just your binaries. I don't
think tat changing dpkg to do vodoo for you is a good idea.
- -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
iD8DBQE9ZKg+VYan35+NCKcRAoRDAKDpCk9sGyA1IhYEOx4uYSNfaivl3gCdHu+d
8wFw7M3PKUaMpmIiSTbEz3s=
=8G62
-END PGP SIGNATURE-
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 01:18:35AM -0700, Marc Singer wrote: > On Thu, Aug 22, 2002 at 08:47:46AM +0100, Colin Watson wrote: > > On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: > > > 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. > > > > Sure there is: it's something like -o DPkg::Options=--force-confmiss. > > OK. You got me. Is there any hope that's you'll at least cede that > that's not as straightforward as we *could* be? Yep, certainly. -- Colin Watson [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Aug 2002, Marc Singer wrote: > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > > Sounds like you want dpkg --force-confmiss. > > > > > > I wouldn't expect that since the documentation states: > > > > > > confmiss: Always install a missing configuration > > > file. This is dangerous, since it means not pre- > > > serving a change (removing) made to the file. > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > For example... Logcheck has a number of files under /etc/logcheck/ignore.d... that are marked as configuration files. Removing a configuration files means that more information is present in the log summary. (automaticly) Replacing these configuration files would result in unwanted behaviour. - -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE9ZKQgVYan35+NCKcRAoZSAJ4u1IeVFKCujBEuSr3yj9L9CZpCxQCfYgZO e+MVu8TbK1ViLL5zA6i9ui8= =W8zs -END PGP SIGNATURE-
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 08:47:46AM +0100, Colin Watson wrote:
> On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:
> > I was asking for real examples in order to discuss how the case of
> > bind and db.root is *not* a member of that set and how there may be a
> > genuine problem with the handling of installing over missing
> > configuration files.
>
> Maybe db.root just shouldn't be a conffile, that's all.
{Gesturing} That's what I'm saying.
>
> > 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.
>
> Sure there is: it's something like -o DPkg::Options=--force-confmiss.
OK. You got me. Is there any hope that's you'll at least cede that
that's not as straightforward as we *could* be?
>
> --
> Colin Watson [EMAIL PROTECTED]
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: > I was asking for real examples in order to discuss how the case of > bind and db.root is *not* a member of that set and how there may be a > genuine problem with the handling of installing over missing > configuration files. Maybe db.root just shouldn't be a conffile, that's all. > 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. Sure there is: it's something like -o DPkg::Options=--force-confmiss. -- Colin Watson [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
> Still, breaking bind's access to root name servers is particularly > troublesome because it may tend to break all net access. It may be > worthwhile to remove db.root from the list of configuration files. > Especially, because this list isn't something anyone should need to > change. I beg to disagree. Changing db.root is the primary way to use an alternate DNS root (either for an all-internal DNS, or to utilize an alternate DNS root than NetSol's). Just because you can't see why something might be configured differently doesn't mean other people can't.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 06:39:55PM -0500, Steve Greenland wrote: > On 21-Aug-02, 15:10 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: > > It would help to have an example. > > I could have sworn I had a footnote about /etc/cron.allow, with a > reference to the appropriate manpage :-). Okay, it's not the *best* > example, because I don't actually ship a cron.allow, but the point is > there: A missing cron.allow permits everybody to use crontab, while an > empty cron.allow forbids use of crontab by anybody (except root, of > course). It does appear that there are a couple of good examples. In fact, this is not one of them since what you ought to ship is a cron.allow that blocks everything, right? That way the default behavior is obvious to someone browsing the configuration. As far as I can tell, there aren't many 'dangerous' examples. A package may install a crontab file in cron.d that is deleted by the user. Apparently, apache2 performs directory scanning for configuration files, too. Examples such as BASH are definitely *not* dangerous since the default file contains a single, innocuous directive. As I wrote in another message, given that there is an override switch in dpkg, that switch would be helpful if available in apt-get.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 07:32:04PM -0400, Matt Zimmerman wrote: > On Wed, Aug 21, 2002 at 04:23:16PM -0700, Marc Singer wrote: > > > On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote: > > > _Any_ program whose default (Debian) configuration file specifies > > > options which are different from the compiled-in defaults. > > > > > > For specific examples, see almost any program on your system with a > > > global config file. > > > > Hand-waving doesn't constitute an example. > > How about bash? A missing /etc/bash.bashrc has a different effect than the > default /etc/bash.bashrc. A missing /etc/bash_completion has a different > effect than the default /etc/bash_completion. Missing /etc/skel/.bash* will > avoid having any .bash* files copied into new users' home directories. I > think that you have bash installed (assuming you run Debian), so you now > have an example that you can experiment with on your own system. And you > didn't have to go to the trouble of figuring it out for yourself. > > You may shut up now. This terse reply is obviously inappropriate. If you are annoyed, stop writing. I was asking for real examples in order to discuss how the case of bind and db.root is *not* a member of that set and how there may be a genuine problem with the handling of installing over missing 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. Still, breaking bind's access to root name servers is particularly troublesome because it may tend to break all net access. It may be worthwhile to remove db.root from the list of configuration files. Especially, because this list isn't something anyone should need to change.
Re: When bind9 reinstalls, no db.root
On 21-Aug-02, 15:10 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: > It would help to have an example. I could have sworn I had a footnote about /etc/cron.allow, with a reference to the appropriate manpage :-). Okay, it's not the *best* example, because I don't actually ship a cron.allow, but the point is there: A missing cron.allow permits everybody to use crontab, while an empty cron.allow forbids use of crontab by anybody (except root, of course). Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 04:23:16PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote: > > _Any_ program whose default (Debian) configuration file specifies > > options which are different from the compiled-in defaults. > > > > For specific examples, see almost any program on your system with a > > global config file. > > Hand-waving doesn't constitute an example. How about bash? A missing /etc/bash.bashrc has a different effect than the default /etc/bash.bashrc. A missing /etc/bash_completion has a different effect than the default /etc/bash_completion. Missing /etc/skel/.bash* will avoid having any .bash* files copied into new users' home directories. I think that you have bash installed (assuming you run Debian), so you now have an example that you can experiment with on your own system. And you didn't have to go to the trouble of figuring it out for yourself. You may shut up now. -- - mdz
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > > For example... > > _Any_ program whose default (Debian) configuration file specifies options > which are different from the compiled-in defaults. > > For specific examples, see almost any program on your system with a global > config file. Hand-waving doesn't constitute an example. > > -- > - mdz > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wednesday, August 21, 2002, at 09:08 PM, Marc Singer wrote: Without a single example, I don't see how installing a configuration file where there is none can have *any* affect on the system. Admittedly, replacing a configuration file may be undesirable. In addition to the example of configuration files that change compiled in defaults that has already been mentioned consider things like logcheck or apache2 which scan a directory processing all files within it.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > For example... _Any_ program whose default (Debian) configuration file specifies options which are different from the compiled-in defaults. For specific examples, see almost any program on your system with a global config file. -- - mdz
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 03:12:37PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 09:21:39PM +0100, Colin Watson wrote: > > On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote: > > > It would help to have an example. However, even if there is an > > > example I don't see how db.root fits in this category. > > > > Unfortunately there's no way for a package to override this aspect of > > dpkg's conffile handling. It would have to be handled entirely in the > > maintainer scripts in some different (and careful!) way. > > Is the feature triggered for files appearing in /etc? The documentation on conffiles is in section 11.7 of policy. -- Colin Watson [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
Marc Singer <[EMAIL PROTECTED]> writes: > Without a single example, I don't see how installing a configuration > file where there is none can have *any* affect on the system. > Admittedly, replacing a configuration file may be undesirable. > There might be (and surely are) programs, that will, given the lack of a config file, use their compiled-in defaults. So the installation of a config file will change the configuration of the program, unless the installed config file contains just the (also compiled-in) defaults. Regards, Andy -- Andreas Rottmann | [EMAIL PROTECTED]| [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 09:21:39PM +0100, Colin Watson wrote: > On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote: > > On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote: > > > To be, perhaps, a little more explicit: there are programs for which > > > the existence of an empty configuration file means something completely > > > different than a missing a configuration file[1]. Thus, for dpkg > > > conffile handling, removing a configuration file is a legitimate "edit". > > > > It would help to have an example. However, even if there is an > > example I don't see how db.root fits in this category. > > Unfortunately there's no way for a package to override this aspect of > dpkg's conffile handling. It would have to be handled entirely in the > maintainer scripts in some different (and careful!) way. Is the feature triggered for files appearing in /etc? > > -- > Colin Watson [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:21:17PM +0200, Oliver Kurth wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > > > Sounds like you want dpkg --force-confmiss. > > > > > > > > I wouldn't expect that since the documentation states: > > > > > > > > confmiss: Always install a missing configuration > > > > file. This is dangerous, since it means not pre- > > > > serving a change (removing) made to the file. > > > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > > > If the default configuration data in the file do something you don't want. > > > > For example... > > autofs. First thing I do when I install autofs in at networked environmemt is > rm /etc/auto.* > because I want to use the NIS maps. I don't think that example works for all of the auto.* files. The master file references the other files. Removing the master eliminates the references to the others. However, adding auto.furball won't affect autofs unless auto.master references it. > > Greetings, > Oliver > -- > Oliver Kurth > mailto:[EMAIL PROTECTED] http://leinekanal.de
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote: > > To be, perhaps, a little more explicit: there are programs for which > > the existence of an empty configuration file means something completely > > different than a missing a configuration file[1]. Thus, for dpkg > > conffile handling, removing a configuration file is a legitimate "edit". > > It would help to have an example. However, even if there is an > example I don't see how db.root fits in this category. Unfortunately there's no way for a package to override this aspect of dpkg's conffile handling. It would have to be handled entirely in the maintainer scripts in some different (and careful!) way. -- Colin Watson [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > > Sounds like you want dpkg --force-confmiss. > > > > > > I wouldn't expect that since the documentation states: > > > > > > confmiss: Always install a missing configuration > > > file. This is dangerous, since it means not pre- > > > serving a change (removing) made to the file. > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > For example... autofs. First thing I do when I install autofs in at networked environmemt is rm /etc/auto.* because I want to use the NIS maps. Greetings, Oliver -- Oliver Kurth mailto:[EMAIL PROTECTED] http://leinekanal.de pgps2x4kwT8dp.pgp Description: PGP signature
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote: > On 21-Aug-02, 14:42 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote: > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > > > To be, perhaps, a little more explicit: there are programs for which > the existence of an empty configuration file means something completely > different than a missing a configuration file[1]. Thus, for dpkg > conffile handling, removing a configuration file is a legitimate "edit". > It would help to have an example. However, even if there is an example I don't see how db.root fits in this category.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:04:28PM +0200, Josip Rodin wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > > > > Sounds like you want dpkg --force-confmiss. > > > > > > > > I wouldn't expect that since the documentation states: > > > > > > > > confmiss: Always install a missing configuration > > > > file. This is dangerous, since it means not pre- > > > > serving a change (removing) made to the file. > > > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > > > If the default configuration data in the file do something you don't want. > > > > For example... > > I don't know, but I know plenty of default configuration files that set > something up. Maybe "dangerous" is a bit extreme choice of words, but the > negative effect isn't implausible. Without a single example, I don't see how installing a configuration file where there is none can have *any* affect on the system. Admittedly, replacing a configuration file may be undesirable. Moreover, in this case, db.root is not really a configuration file. It is more like a library. If I ask for a package to be reinstalled, most users will expect all of the programs and libraries to be installed. Are you sure you agree that db.root should not be reinstalled with bind's programs? > > -- > 2. That which causes joy or happiness.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > > > Sounds like you want dpkg --force-confmiss. > > > > > > I wouldn't expect that since the documentation states: > > > > > > confmiss: Always install a missing configuration > > > file. This is dangerous, since it means not pre- > > > serving a change (removing) made to the file. > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > For example... I don't know, but I know plenty of default configuration files that set something up. Maybe "dangerous" is a bit extreme choice of words, but the negative effect isn't implausible. -- 2. That which causes joy or happiness.
Re: When bind9 reinstalls, no db.root
On 21-Aug-02, 14:42 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: > On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote: > > How could it be dangerous to install a *missing* configuration file? > > If the default configuration data in the file do something you don't want. > To be, perhaps, a little more explicit: there are programs for which the existence of an empty configuration file means something completely different than a missing a configuration file[1]. Thus, for dpkg conffile handling, removing a configuration file is a legitimate "edit". Steve [1] E.g. /etc/cron.allow (crontab(1)). -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > Sounds like you want dpkg --force-confmiss. > > > > I wouldn't expect that since the documentation states: > > > > confmiss: Always install a missing configuration > > file. This is dangerous, since it means not pre- > > serving a change (removing) made to the file. > > > > How could it be dangerous to install a *missing* configuration file? > > If the default configuration data in the file do something you don't want. For example...
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote: > > > I'm confused by the behavior of apt-get install --reinstall. I found > > > out yesterday that the /etc/bind/db.root file was missing on my name > > > server. I was able to recover by linking to an old copy and > > > restarting bind9. However, when deleted the link and performed the > > > --reinstall command, the db.root file was not restored. > > > > Sounds like you want dpkg --force-confmiss. > > I wouldn't expect that since the documentation states: > > confmiss: Always install a missing configuration > file. This is dangerous, since it means not pre- > serving a change (removing) made to the file. > > How could it be dangerous to install a *missing* configuration file? If the default configuration data in the file do something you don't want. -- 2. That which causes joy or happiness.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 08:24:58PM +0100, Colin Watson wrote: > On Wed, Aug 21, 2002 at 12:09:57PM -0700, Marc Singer wrote: > > I'm confused by the behavior of apt-get install --reinstall. I found > > out yesterday that the /etc/bind/db.root file was missing on my name > > server. I was able to recover by linking to an old copy and > > restarting bind9. However, when deleted the link and performed the > > --reinstall command, the db.root file was not restored. > > Sounds like you want dpkg --force-confmiss. I wouldn't expect that since the documentation states: confmiss: Always install a missing configuration file. This is dangerous, since it means not pre- serving a change (removing) made to the file. How could it be dangerous to install a *missing* configuration file?
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:09:57PM -0700, Marc Singer wrote: > I'm confused by the behavior of apt-get install --reinstall. I found > out yesterday that the /etc/bind/db.root file was missing on my name > server. I was able to recover by linking to an old copy and > restarting bind9. However, when deleted the link and performed the > --reinstall command, the db.root file was not restored. Sounds like you want dpkg --force-confmiss. -- Colin Watson [EMAIL PROTECTED]
