Re: Why does resolv.conf keep changing?
On Wed, Oct 25, 2017 at 09:03:07AM -0400, Greg Wooledge wrote:
>
> I'm STILL waiting for the OP to give the most basic, fundamental details
> like showing the output of lsattr /etc/resolv.conf to prove that his/her
> assumptions are correct. IIRC it took two days for us to get proof that
> /etc/resolv.conf wasn't a symlink.
>
Here you go:
debian:/etc# lsattr /etc/resolv.conf
----i---------e---- /etc/resolv.conf
>
> P.S. All this talk about "mobile devices are the new normal, so we have
> to make everything 20 times as complicated, even for unmoving workstations
> and servers" can go screw itself.
>
+1
> If Debian developers who are responsible for resolvconf are reading this,
> and if they actually CARE about making things work correctly and sensibly,
> then here is yet another proposal: give us a way to QUICKLY and EASILY
> and RELIABLY tell resolvconf "never do anything". I don't care where it
> is, or what it looks like. Just make SOME way to configure the system so
> that /etc/resolv.conf is never touched in any way by ANYTHING. Resolvconf
DING! DING! DING! DING! DING! DING! DING!
I THINK WE HAVE A WINNER
> already intercepts all the incoming attempts to modify /etc/resolv.conf
> by dhclient et al., right? That's its entire purpose, right? So just
DING! DING! DING! DING! DING! DING! DING!
I THINK WE HAVE A WINNER
> give us a way to tell it to intercept those requests and do nothing.
>
> If you don't do this, we'll just continue using chattr +i, because that
> does what we want. (Except for this one person who still hasn't proved
> (s)he actually did it correctly.)
>
I did the below to see if creating a new resolv.conf and then moving the
old one of the way would allow a new resolv.conf to be installed even
when the immutable flag was set. Your further mention of dhclient
messing with resolv.conf was the critical piece that I was missing.
debian:/etc# lsattr /etc/resolv.conf
----i---------e---- /etc/resolv.conf
debian:/etc# cp /etc/resolv.conf /etc/resolv.conf.new
debian:/etc# lsattr /etc/resolv.conf.
lsattr: No such file or directory while trying to stat /etc/resolv.conf.
# (Note, I expected /etc/resolv.conf.new to be the only other file named
# similarly to /etc/resolv.conf, so I was surprised that shell
# completion failed to choose it automatically. The next line was after
# I hit tab-tab to see what else was there.)
debian:/etc# lsattr /etc/resolv.conf.
resolv.conf.dhclient-new.18344 resolv.conf.dhclient-new.26388 resolv.conf.dhclient-new.41226
resolv.conf.dhclient-new.21057 resolv.conf.dhclient-new.28437 resolv.conf.new
debian:/etc# lsattr /etc/resolv.conf.new
--------------e---- /etc/resolv.conf.new
debian:/etc# ls -l /etc/resolv.conf*
-rw-r--r-- 1 root root 62 Oct 24 23:14 /etc/resolv.conf
-rw-r--r-- 1 root root 25 Oct 23 11:14 /etc/resolv.conf.dhclient-new.18344
-rw-r--r-- 1 root root 25 Oct 25 03:09 /etc/resolv.conf.dhclient-new.21057
-rw-r--r-- 1 root root 25 Oct 23 14:38 /etc/resolv.conf.dhclient-new.26388
-rw-r--r-- 1 root root 25 Oct 25 06:47 /etc/resolv.conf.dhclient-new.28437
-rw-r--r-- 1 root root 25 Oct 23 18:56 /etc/resolv.conf.dhclient-new.41226
-rw-r--r-- 1 root root 62 Oct 25 09:28 /etc/resolv.conf.new
-rw-r--r-- 1 root root 66 Oct 23 19:29 /etc/resolv.conf~
debian:/etc# rm -f /etc/resolv.conf.new
debian:/etc# cat /etc/resolv.conf.dhclient-new.18344
nameserver 192.168.63.1
debian:/etc# lsattr /etc/resolv.conf
----i---------e---- /etc/resolv.conf
debian:/etc# cat /etc/resolv.conf
domain example.com
search example.com.
nameserver 127.0.0.1
This is clearly evidence that the problem is with dhclient
(isc-dhcp-client in my case). I am taking another look at the supersede
directives in /etc/dhcp/dhclient.conf to make sure that I am specifying
them correctly. If that fails, then I think I will need to do something
with /sbin/dhclient-script (which is apparently what is actually
changing the resolv.conf). According to dhclient-script(8) I can use a
hook to redefine the make_resolv_conf shell function to do nothing.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: