On Thu, Oct 26, 2017 at 09:31:47AM -0500, David Wright wrote: > > Judging by your address and earlier comment, you're much closer to > Debian's strategy than I am, but I thought the thrust of Debian was > to coerce/persuade packages to cooperate on /etc/resolv.conf so that > one package did not overwrite the actions of another on starting, > and could unroll their own changes when terminating. It's always > worked here with ifup and dhclient, but that's less complex than > your own situation using bind. (I use /etc/hosts for my own LAN.) > You make a good point. However, I think that requiring the user/admin to implement a hook script in order to reliably get dhclient to do the right thing is a bit much. That is why I made the suggestion about the configuration directive.
> > An official hack (Debian) rather than an unofficial one (sys admin)? > The most remarkable thing in this thread is the alleged defeat of > chattr +i. (a) it's difficult to believe that some package comes > along and unsets i (immutable attribute), changes the file, and sets > i again, which is what you allege. (b) although I agreed with Gene > that a watch could be left untriggered by i being set, this would > only happen if a package tried to naively change resolv.conf; the > behaviour alleged in (a) would still trigger the watch at the time > i was temporarily unset. (c) the third alternative is failure of > i to do its job, which seems unlikely. > I had several terminal windows open and I am beginning to suspect that I was mistaken (at least initially) about having set +i. In particular, when I later tried again (possibly for the first time it now seems) I observed that new temporary files were littered in /etc after the dhclient-script attempt to overwrite the original /etc/resolv.conf failed. I am going to just call it user error on my part. > So perhaps Debian should just adopt chattr +i as the official way > of doing what Gene, Greg and you want, with a warning that you > might want to clean up any clutter (resolv.conf.foo…) periodically. > Anything that interfered with that could then be filed as a bug. > I do not find this a particularly good solution because it would likely interfere with managing a system via puppet, ansible, etc. There is definitely a use case for "this file should be changeable only by the administrator, not by any automated functionality from an installed package." > BTW did you find out why you were getting DHCP negotiations > every 3 or 4 minutes? The lease you posted was for 16005 seconds, > over 4 hours. > I don't recall this being a problem except for when I manually ran dhclient to force a new negotiation. I have not observed anything that makes me think there is an issue with premature renegotiation. Regards, -Roberto -- Roberto C. Sánchez
