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
