Re: Why does resolv.conf keep changing?
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
Reply to: