[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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 2/22/23, davenull@tuxfamily.org <davenull@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.
> > 
> > Might look at:
> > 
> >     /etc/network/interfaces.d/setup
> > 
> > as explained in "man interfaces". (That file can/might be changed via
> > the network symbol in the window manager's configuration bar/menu
> > system, usually required with root/sudo privileges.)
> 
> There's nothing relevant to change in that file. I don't want to have
> static IP. And the right interface name is not in it.
> 
> I'm not sure whether that file became totally obsoleled, or if it's
> not normal that it doesn't contain the expected interface name? has it
> been deprecated since debian switched to systemd so-called
> "predictable" iface names?
> 
> For some reasons, since debian 9 or 10 (id nor 8?), including debian
> 11 new installs (work laptop has been install slightly more than a
> year ago),
> that files only contains the eth0 and local interfaces name, while
> debian switched to systemd style interfaces names.
> I remembrer having slowed down boots because of the that, on my
> personal laptop, when debian switched to systemd style names and that
> file still referred to eth0 which doesn't exist
> So boot process was waiting for eth0 interface until I commented out
> that part (eth0 block) of interfaces files.
> 
> 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.

> 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*

Cheers,
David.


Reply to: