On 2/22/23, daven...@tuxfamily.org <daven...@tuxfamily.org> wrote: > > There is an unidentified process that decides it's ok to delete and > recreate /etc/resolv.conf without asking user/admin, > The problem is, the problematic process is not work's VPN related and > creates the file with wrong resolver's IP. The IP corresponds to my home > router IP, which does has a DNS resolver and it works as it should. BUT > my home's router DNS obviously don't know jack about work internal > servers, on which I work… and work's proxy as well, which when it cannot > be resolved… breaks everything using HTTP.
Hi.. I didn't know where to jump into this so am responding to that paragraph in its original post. Having just debootstrap'ed again, one thing I do is verify /etc/resolv.conf's content. The following, slightly lengthy blurb has begun showing up where I'd never seen it before. I'm sharing it with hopes maybe it hints at what might be a trigger for the reset: ++++++++ BEGIN CONTENT FROM NEW, UNALTERED /etc/resolv.conf FILE +++++++++ # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). # Do not edit. # # This file might be symlinked as /etc/resolv.conf. If you're looking at # /etc/resolv.conf and seeing this text, you have followed the symlink. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 trust-ad search . ++++++++ END CONTENT FROM NEW, UNALTERED /etc/resolv.conf FILE +++++++++ Those last three lines worked for Mint, but they did not work for Debian. So I defiantly altered that file. I commented those three lines out, tracked down my ISP's nameserver values,** and plugged them in. I was able to connect immediately after that. When I tried to do that with some other distribution, possibly Mint again, it would reset as is being described in this thread and as is seemingly implied in resolv.conf's "do not edit" line. I have no clue why Debian is not resetting now, but I'm VERY grateful it's remaining stable. Having now actually read more of that blurb, I didn't follow any symlinks. Thanks to issues over the years, /etc/resolv.conf is the first place I go if an Internet connection is not working as expected. Lastly, I just tried "ls -ld" on that long /run line to stub-resolv.conf. It's "no such file" so that would explain why it's not resetting on my end. Resolvectl is also pulling up as not found. Those all definitely explain why I'm able to type online right now. If I was feeling brave right now, I would try messing around with doing what it takes to get resolvectl in control, but I'm not (feeling brave). :) Cindy :) ** My ISP's nameserver values were found in connman's GUI, of all things. Connman has NEVER worked for me. I have no idea why it's working now. I didn't manually install it. Connman came in automatically somehow related to the LXQt desktop environment. Just leaving this here in case it somehow is playing a part in why my resolv.conf is not resetting. You never know.............. -- Talking Rock, Pickens County, Georgia, USA * GRUB IS WORKING! Just put ^ in front of metadata_csum_seed in mke2fs.conf! *
