Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright <deblis@lionunicorn.co.uk>]

On Tue 28 Feb 2023 at 16:05:14 (+0100), davenull@tuxfamily.org wrote:
> On 2023-02-28 05:27, David Wright wrote:
> > On Thu 23 Feb 2023 at 11:23:30 (+0100), davenull@tuxfamily.org wrote:
> > > On 2023-02-23 02:59, conover@panix.com wrote:
> > > 
> > > […]
> > > 
> > > On the newer work laptop on the other hand, there is that eth0 block,
> > > there's is no eth0 interface on my system (there's enp.* and enx.*
> > > systemd names, instead)
> > > BUT I never had the slow/timeout-waiting boot process unlike the
> > > personal was reinstall from zero instead of upgraded years ago only to
> > > change HDD to SSD, and to change partitioning to encrypted LVM.
> > 
> > What are these enp… (waste of time hiding that name) and enx…
> > interfaces (and any others), and what are they used for.
> > 
> 
> It's the systemd-style so-called "predictable" interfaces names.
> Replacing the older the eth0, wlan0, and so on…
> 
> ens-something (annoying name made of multiple letters and digits) is
> the new name for eth0
> wlx-something or wlp-something for wlan0
> enx-insert-long-hexadecimal-number-here is well… I have no damn idea.
> 
> Seen this last one only my work's computer, not personal one. Much
> newer, maybe have some optional network hardware?
> Not sure, but it's not virtual interface for the VPN. which is still
> named tun0 as it used to be before systemd.
> And the unknown interface is still around even without the VPN process
> running
> 
> And it's not really hiding. it's just a name I can never fully remember
> and didn't bother to check full name. It doesn't really matter.
> What matters is the interface is not called eth0 anymore, but is
> instead called ens-whatever-thefullname-is. And the interface name
> used in
> /etc/network/interfaces.d/setup refers to a network interface which
> doen't exist anymore
> 
> Yet it does NOT break the network, that why I think something else
> replaced.
> Otherwise, I fail to see how it would work while referencing to the
> wrong interface name.
> 
> (Also, the new name for wlan0 interface is "wlx" followed by an UID
> *on some* systems. not all
> So it actually does make sense to hide it, for such systems)

Yes, sorry, I won't bother with understanding what interfaces are
present on which systems, and which ones are used for what, when.
(If you reread my question above, you'll see that I didn't ask you
to reveal the MAC address of your wifi, BTW.)

> > > So my guess is /etc/network/interface.* has been replaced with
> > > something also. Since it refers to non-exitent interfaces names
> > > without breaking the network or slowing down the boot process.
> > > 
> > > Also, the switching to systemd styles interfaces names has been
> > > following by a weird behaviour on my personal computer. It has a
> > > "failed" error message at startup, for the network (or is networking?
> > > it never remember the correct name) service, without breaking the
> > > network… it weirdly just works. I never figured out what replaces that
> > > service. If anyone has any idea?
> > 
> > Different installation scripts and/or individual sysadmins can place
> > files with a variety of names in /etc/network/interface.d/. So their
> > removal can be rather sporadic: Debian won't know their names, and
> > deinstallation scripts might leave them, if they get run at all.
> > 
> > It's worrying that such files are there if they have the wrong
> > interface names in them. It might suggest ancient cruft or, just
> > as easily, network installation scripts that are broken, or designed
> > for a different system/distribution.
> > 
> > What's the output from   ls -lR /etc/network* /etc/systemd/network*
> 
> Here's the output.
> 
 [ … ]
> 
> Not sue if it contains anything DHCP client related
> Beside the /etc/network/interfaces.d/setup which contains only local
> interface and eth0

Well, it looks like cruft from an earlier installation of networking;
and a couple of months later, you installed ifupdown and wpasupplicant,
by the looks of things. I don't know whether /etc/network/interfaces
itself would interfere with however connman is configured.

> But again. I don't to fully stop using DHCP, which is would be the
> most obvious thing I could do on the setup file if it were used.
> 
> I just don't want the DHCP client send requests to my home's network
> instead of sending requests through the VPN route
> so the workplace's DHCP sees and answers to the requests, instead of
> home router answering to these requests
> 
> I fail to see why the DHCP client would send it requests to
> 192.168.1.1 (my home's gateway) instead of using the VPN
> interface/route/whatever.
> dhclient must have some wrong conf, but I never changed the default
> conf, So I have no idea what part may be wrong or what's missing

I had thought that it might be possible to configure a package like
openresolv to manage the contention between the configurations, but
judging what I've learned about your networking setup, it's probably
easier just to hack it, using the method at the bottom of the wiki
page, simply making resolv.conf immutable when your vpn starts up,
and mutable when it stops, using Reco's suggestion. That should save
you bothering with how the rest of your configuration is set up.
And do remember to make the file mutable at boot time, in case your
computer should crash while it's immutable.

Cheers,
David.