Re: Why does resolv.conf keep changing?
On Thu 26 Oct 2017 at 07:46:24 (-0400), Roberto C. Sánchez wrote:
> On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote:
> >
> > Actually, there's no need to duplicate the effort. As I understand it,
> > resolvconf is basically an optional helper program. Software that
> > automatically modifies /etc/resolv.conf should first test for the presence
> > of resolvconf (whether that be checking for the configuration directory of
> > resolvconf or checking that resolvconf is running or... however resolvconf
> > desires to be detected). If resolvconf is available, the changes are
> > co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified
> > directly.
> >
> In my case resolvconf is not installed/available and I want resolv.conf
> to be left alone. I want any other package that thinks it needs to
> modify resolv.conf to leave it along. I also think that would be useful
> in the case where resolvconf gets unexpected installed later. That is
> not a specific concern for me, but in a situation where multiple
> administrators are involved with managing a system it could happen.
>
> Based on your proposal the situation which I have would not be
> addressed. I am specifically saying that there should be a way to mark
> resolv.conf as static so that any package that touches it can check for
> that directive. There is no need for packages to coordinate between
> themselves in that case. They need only to check for the marker in
> resolv.conf and if it is there (indicating that it should not be
> modified) then they simply discontinue processing.
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.)
> > The problem is that I don't think that resolvconf can require packages to
> > use it. This is similar to other higher-level APIs such as pulseaudio. If
> > the software knows to use pulseaudio, then it can get mixed, rerouted etc by
> > pulseaudio, but it's difficult to mandate that software stop sending audio
> > directly to /dev/dsp (well, unless you're a distribution which applies
> > patches to upstream software in order to harmonize the experience of its
> > users).
> >
>
> I can see the utility of resolvconf and in packages coordinating their
> modifications of resolv.conf. However, I still maintain that there
> should be a simple way for the admin to mark resolv.conf in such a way
> that no package will modify it. This should be possible without
> resorting to hacks like making resolv.conf immutable.
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.
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.
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.
Cheers,
David.
Reply to: