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

[David Wright]

On Thu 02 Mar 2023 at 10:32:41 (+0100), daven...@tuxfamily.org wrote:
> On 2023-03-02 00:24, David Wright wrote:
> > On Tue 28 Feb 2023 at 16:05:14 (+0100), daven...@tuxfamily.org wrote:
> > > On 2023-02-28 05:27, David Wright wrote:
> > > > On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:
> > > > > On 2023-02-23 02:59, cono...@panix.com wrote:
> >  [ … ]
> > 
> > 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.
> > 
> 
> This system never had any debian 10 or lower. It has been issued to my
> by $worksplace
> in december 2021, initially running windows.
> 
> I erased the full disk and installed à "default" (official image)
> debian 11, from an LXDE live USB image

I know nothing about LXDE (or other DEs).

> It has never had any interface named eth0. I still fail to see why
> setup conf would refer to eth0 at all

Some clues are the setup's contents, other files on the system with
contemporaneous timestamps, /var/log/installer/syslog's contents, and so on.

> Then I few month later, I finally took the time to debug why WiFi card
> didn't work/what firmware is needed
> Debian's firmware packaged started supporting the WLAN/WiFi card
> after I installed my system.
> 
> So then I installed the firmware. I most likely installed wpasuppicant
> the same day, and tested it worked.
> 
> Not sure about ifup thought. Doesn't seem to be a wpasupplicant
> dependency.
> 
> akb@akira:~$ LC_ALL=C aptitude why ifupdown
> p   netscript-2.4 Provides ifupdown
> p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> p   bridge-utils  Suggests ifupdown
> akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> p   netscript-2.4 Provides ifupdown

This suggests that you or the installer installed ifupdown, and that
it's a top-level package. I would have expected a response more like:

  $ aptitude why apt-file
  Manually installed, current version 3.2.2, priority optional
  No dependencies require to install apt-file
  $ 

but I guess the Provides has some influence. Both ifupdown2 and
netscript can be used instead of ifupdown, though the latter is
for a more specialised scenario.

It's always possible that ifupdown was installed as an alternative
to connman, which is also in the Live image. I don't know which gets
started by default, either in Live, or the subsequent installation
from Live.

> Why openresolv wouldn't work?

That doesn't parse, and without any context, I don't know what it means.

Cheers,
David.

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

[tomas]

On Thu, Mar 02, 2023 at 12:14:14PM -0600, David Wright wrote:
> On Thu 02 Mar 2023 at 17:23:23 (-), Curt wrote:
> > On 2023-03-02, David  wrote:

[...]

> > Those seem like antithetical concepts.
> 
> The state is identical in both cases, hence using the same letter.
> OTOH the paths to that state can be different, and that's significant
> because installing and then purging a package can have side-effects
> on the system that don't get reverted to the inital state, eg the
> installation of Depends/Recommends.

Heh, you stole my thoughts. I was going "hm, the node in the state
diagram is the same, just the edges are different" :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[David Wright]

On Thu 02 Mar 2023 at 17:23:23 (-), Curt wrote:
> On 2023-03-02, David  wrote:
> > On Fri, 3 Mar 2023 at 00:19, Greg Wooledge  wrote:
> >
> >> Man, I really wish the aptitude(8) man page would explain how to read
> >> the output of "why".  What does the "p" mean?  Purged?  There's nothing
> >> in the man page that explains the symbols in the first 3 columns, as
> >> far as I can find.

It's easy to miss, because the key to the letters is given in running
text a hundred lines away. (man chmod is a loathsome example of this
format.) The reference below is much better, as the figure is a table
(as well as being comprehensive).

> > Yeah. It does mean purged, or never installed.
> >
> >p - the package and all its configuration files were removed, or the
> >package was never installed.
> 
> Those seem like antithetical concepts.

The state is identical in both cases, hence using the same letter.
OTOH the paths to that state can be different, and that's significant
because installing and then purging a package can have side-effects
on the system that don't get reverted to the inital state, eg the
installation of Depends/Recommends.

> >>From here (Buster):
> >   grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README

and bullseye.

Cheers,
David.

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

[Curt]

On 2023-03-02, David  wrote:
> On Fri, 3 Mar 2023 at 00:19, Greg Wooledge  wrote:
>
>> Man, I really wish the aptitude(8) man page would explain how to read
>> the output of "why".  What does the "p" mean?  Purged?  There's nothing
>> in the man page that explains the symbols in the first 3 columns, as
>> far as I can find.
>
> Yeah. It does mean purged, or never installed.
>
>p - the package and all its configuration files were removed, or the
>package was never installed.

Those seem like antithetical concepts.

>>From here (Buster):
>   grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README
>
>


-- 

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

[David]

On Fri, 3 Mar 2023 at 02:18,  wrote:
> On 2023-03-02 14:19, Greg Wooledge wrote:
> > On Thu, Mar 02, 2023 at 02:01:57PM +0100, daven...@tuxfamily.org wrote:

> >> > > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
> >> > > > p   netscript-2.4 Provides ifupdown
> >> > > > p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> >> > > > p   bridge-utils  Suggests ifupdown
> >> > > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> >> > > > p   netscript-2.4 Provides ifupdown
> >
> >> dpkg -l netscript-2.4 or even dpkg -l | grep netscript
> >>
> >> Don't return anything… Not sure why "aptitude why ifupdown" mentions
> >> netscript-2.4 at all

You could try 'aptitude -v why' to add verbosity.

/usr/share/aptitude/README has some discussion about
the behaviour of 'why' and 'why-not'. Under the heading
'why, why-not'.

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

[davenull]

On 2023-03-02 14:19, Greg Wooledge wrote:

On Thu, Mar 02, 2023 at 02:01:57PM +0100, daven...@tuxfamily.org wrote:


> > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
> > > p   netscript-2.4 Provides ifupdown
> > > p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> > > p   bridge-utils  Suggests ifupdown
> > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> > > p   netscript-2.4 Provides ifupdown



dpkg -l netscript-2.4 or even dpkg -l | grep netscript

Don't return anything… Not sure why "aptitude why ifupdown" mentions
netscript-2.4 at all


Oh, that's reassuring.  And also confusing.

Man, I really wish the aptitude(8) man page would explain how to read
the output of "why".  What does the "p" mean?  Purged?  There's nothing
in the man page that explains the symbols in the first 3 columns, as
far as I can find.


I wonder if aptitude just uses the dpkg-query abbreviations,
so "purged" seems a reasonable guess. But yeah, it would be
much more helpful if aptitude(8) man was not that ambiguous
about those abbreviations



I have *no* idea how to interpret this:

unicorn:~$ aptitude why ifupdown
p   netscript-2.4 Provides ifupdown
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown
unicorn:~$ dpkg -l ifupdown | tail -n1
ii  ifupdown   0.8.36   amd64high level tools to
configure network interfaces

Maybe "aptitude why" simply can't handle packages that are part of
the base system ("Essential", or priority "required" or "important"),
or which have been manually installed and aren't part of a 
dependency...?


unicorn:~$ aptitude why bash
i   bash-builtins Depends bash (= 5.1-2+deb11u1)
unicorn:~$ aptitude why dpkg
i   google-chrome-stable PreDepends dpkg (>= 1.14.0)
unicorn:~$ aptitude why abcde
Manually installed, current version 2.9.3-1, priority optional
No dependencies require to install abcde

OK, I guess it handles manually installed packages.  But not base
system packages... at least not in a way one would expect.

In any case, ifupdown is an "important" package, and should be present
on almost all Debian systems, regardless of what "aptitude why" says
about it.

unicorn:~$ dpkg -s ifupdown | grep Prio
Priority: important


Good to know. I'd except it to be installed by default by the way. 
Looking again at files in /etc/network, there are


drwxr-xr-x 2 root root 4096  2 déc.   2021 if-post-down.d
drwxr-xr-x 2 root root 4096  2 déc.   2021 if-pre-up.d

The laptop was installed on the 2nd December 2021, so the files existed 
from day one,

But if-down.d and if-up.d content was updated later.
Must by the reason why someone (don't remember their name) on this 
thread suggested I have installed

ifupdown a few months laters.

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

[David]

On Fri, 3 Mar 2023 at 00:19, Greg Wooledge  wrote:

> Man, I really wish the aptitude(8) man page would explain how to read
> the output of "why".  What does the "p" mean?  Purged?  There's nothing
> in the man page that explains the symbols in the first 3 columns, as
> far as I can find.

Yeah. It does mean purged, or never installed.

   p - the package and all its configuration files were removed, or the
   package was never installed.

>From here (Buster):
  grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README

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

[Greg Wooledge]

On Thu, Mar 02, 2023 at 02:01:57PM +0100, daven...@tuxfamily.org wrote:

> > > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
> > > > p   netscript-2.4 Provides ifupdown
> > > > p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> > > > p   bridge-utils  Suggests ifupdown
> > > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> > > > p   netscript-2.4 Provides ifupdown

> dpkg -l netscript-2.4 or even dpkg -l | grep netscript
> 
> Don't return anything… Not sure why "aptitude why ifupdown" mentions
> netscript-2.4 at all

Oh, that's reassuring.  And also confusing.

Man, I really wish the aptitude(8) man page would explain how to read
the output of "why".  What does the "p" mean?  Purged?  There's nothing
in the man page that explains the symbols in the first 3 columns, as
far as I can find.

I have *no* idea how to interpret this:

unicorn:~$ aptitude why ifupdown
p   netscript-2.4 Provides ifupdown   
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown   
unicorn:~$ dpkg -l ifupdown | tail -n1
ii  ifupdown   0.8.36   amd64high level tools to configure 
network interfaces

Maybe "aptitude why" simply can't handle packages that are part of
the base system ("Essential", or priority "required" or "important"),
or which have been manually installed and aren't part of a dependency...?

unicorn:~$ aptitude why bash
i   bash-builtins Depends bash (= 5.1-2+deb11u1)
unicorn:~$ aptitude why dpkg
i   google-chrome-stable PreDepends dpkg (>= 1.14.0)
unicorn:~$ aptitude why abcde
Manually installed, current version 2.9.3-1, priority optional
No dependencies require to install abcde

OK, I guess it handles manually installed packages.  But not base
system packages... at least not in a way one would expect.

In any case, ifupdown is an "important" package, and should be present
on almost all Debian systems, regardless of what "aptitude why" says
about it.

unicorn:~$ dpkg -s ifupdown | grep Prio
Priority: important

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

[davenull]

On 2023-03-02 13:47, daven...@tuxfamily.org wrote:

On 2023-03-02 13:32, Greg Wooledge wrote:
On Thu, Mar 02, 2023 at 10:32:41AM +0100, daven...@tuxfamily.org 
wrote:
This system never had any debian 10 or lower. It has been issued to 
my by

$worksplace
in december 2021, initially running windows.



akb@akira:~$ LC_ALL=C aptitude why ifupdown
p   netscript-2.4 Provides ifupdown
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown
akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
p   netscript-2.4 Provides ifupdown


unicorn:~$ apt-cache show netscript-2.4
[...]
Description-en: Linux 2.4/2.6/3.x router/firewall/VM host network 
config system.
 This is a router and firewall network configuration system.  It is 
specific to
 the 2.4.x and 2.6.x kernel series. This system is in production use, 
even

 though this is an experimental version.
[...]
 DON'T use this on a pure server - it is VERY useful for a Virtual 
Machine
 server with complex networking needs.  This is because of its 
comprehensive
 network configuration capabilities.  Thus it is a tempting 
replacement

 when you have to rip out NetworkManager on a server.


That sounds pretty terrifying to me.  I'm surprised it works *at all*
with a Debian 11 (or higher?  you didn't say what you *are* running,
only what you're *not* running) kernel.


Obviously NOT those old kernels. I'm runnning kernel 5.10

~$ uname -r
5.10.0-21-amd64

Why is this paquet installed at all then?


dpkg -l netscript-2.4 or even dpkg -l | grep netscript

Don't return anything… Not sure why "aptitude why ifupdown" mentions 
netscript-2.4 at all

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

[davenull]

On 2023-03-02 13:32, Greg Wooledge wrote:

On Thu, Mar 02, 2023 at 10:32:41AM +0100, daven...@tuxfamily.org wrote:
This system never had any debian 10 or lower. It has been issued to my 
by

$worksplace
in december 2021, initially running windows.



akb@akira:~$ LC_ALL=C aptitude why ifupdown
p   netscript-2.4 Provides ifupdown
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown
akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
p   netscript-2.4 Provides ifupdown


unicorn:~$ apt-cache show netscript-2.4
[...]
Description-en: Linux 2.4/2.6/3.x router/firewall/VM host network 
config system.
 This is a router and firewall network configuration system.  It is 
specific to
 the 2.4.x and 2.6.x kernel series. This system is in production use, 
even

 though this is an experimental version.
[...]
 DON'T use this on a pure server - it is VERY useful for a Virtual 
Machine
 server with complex networking needs.  This is because of its 
comprehensive

 network configuration capabilities.  Thus it is a tempting replacement
 when you have to rip out NetworkManager on a server.


That sounds pretty terrifying to me.  I'm surprised it works *at all*
with a Debian 11 (or higher?  you didn't say what you *are* running,
only what you're *not* running) kernel.


Obviously NOT those old kernels. I'm runnning kernel 5.10

~$ uname -r
5.10.0-21-amd64

Why is this paquet installed at all then?

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

[Greg Wooledge]

On Thu, Mar 02, 2023 at 10:32:41AM +0100, daven...@tuxfamily.org wrote:
> This system never had any debian 10 or lower. It has been issued to my by
> $worksplace
> in december 2021, initially running windows.

> akb@akira:~$ LC_ALL=C aptitude why ifupdown
> p   netscript-2.4 Provides ifupdown
> p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> p   bridge-utils  Suggests ifupdown
> akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> p   netscript-2.4 Provides ifupdown

unicorn:~$ apt-cache show netscript-2.4
[...]
Description-en: Linux 2.4/2.6/3.x router/firewall/VM host network config system.
 This is a router and firewall network configuration system.  It is specific to
 the 2.4.x and 2.6.x kernel series. This system is in production use, even
 though this is an experimental version.
[...]
 DON'T use this on a pure server - it is VERY useful for a Virtual Machine
 server with complex networking needs.  This is because of its comprehensive
 network configuration capabilities.  Thus it is a tempting replacement
 when you have to rip out NetworkManager on a server.


That sounds pretty terrifying to me.  I'm surprised it works *at all*
with a Debian 11 (or higher?  you didn't say what you *are* running,
only what you're *not* running) kernel.

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

[davenull]

On 2023-03-02 00:24, David Wright wrote:

On Tue 28 Feb 2023 at 16:05:14 (+0100), daven...@tuxfamily.org wrote:

On 2023-02-28 05:27, David Wright wrote:
> On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:
> > On 2023-02-23 02:59, cono...@panix.com wrote:

 [ … ]

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.



This system never had any debian 10 or lower. It has been issued to my 
by $worksplace

in december 2021, initially running windows.

I erased the full disk and installed à "default" (official image) debian 
11, from an LXDE live USB image
It has never had any interface named eth0. I still fail to see why setup 
conf would refer to eth0 at all


Then I few month later, I finally took the time to debug why WiFi card 
didn't work/what firmware is needed
Debian's firmware packaged started supporting the WLAN/WiFi card 
after I installed my system.


So then I installed the firmware. I most likely installed wpasuppicant 
the same day, and tested it worked.


Not sure about ifup thought. Doesn't seem to be a wpasupplicant 
dependency.


akb@akira:~$ LC_ALL=C aptitude why ifupdown
p   netscript-2.4 Provides ifupdown
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown
akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
p   netscript-2.4 Provides ifupdown

Why openresolv wouldn't work?



Cheers,
David.

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

[David Wright]

On Tue 28 Feb 2023 at 16:05:14 (+0100), daven...@tuxfamily.org wrote:
> On 2023-02-28 05:27, David Wright wrote:
> > On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:
> > > On 2023-02-23 02:59, cono...@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
easie

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

[Tixy]

On Tue, 2023-02-28 at 16:05 +0100, daven...@tuxfamily.org wrote:
> 
> 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

Or eno for ethernet too. My ethernet started out as eno2 when I
did the initial install and this changed to eno1 when I disabled the
onboard wireless in the bios.

-- 
Tixy 

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

[davenull]

On 2023-02-28 05:27, David Wright wrote:

On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:

On 2023-02-23 02:59, cono...@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)


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.

---

ls -lR /etc/network* /etc/systemd/network*
-rw-r--r-- 1 root root   60  9 oct.   2021 /etc/networks
-rw-r--r-- 1 root root  609  2 févr.  2021 /etc/systemd/networkd.conf

/etc/network:
total 24
drwxr-xr-x 2 root root 4096 21 févr. 15:52 if-down.d
drwxr-xr-x 2 root root 4096  2 déc.   2021 if-post-down.d
drwxr-xr-x 2 root root 4096  2 déc.   2021 if-pre-up.d
drwxr-xr-x 2 root root 4096 21 févr. 15:52 if-up.d
-rw-r--r-- 1 root root  321  2 déc.   2021 interfaces
drwxr-xr-x 2 root root 4096  2 déc.   2021 interfaces.d

/etc/network/if-down.d:
total 8
-rwxr-xr-x 1 root root 1015  6 févr.  2021 avahi-autoipd
-rwxr-xr-x 1 root root 1677 13 janv.  2022 clamav-freshclam-ifupdown
lrwxrwxrwx 1 root root   32  2 déc.   2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


/etc/network/if-post-down.d:
total 4
-rwxr-xr-x 1 root root 1409  7 mars   2020 wireless-tools
lrwxrwxrwx 1 root root   32  2 déc.   2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


/etc/network/if-pre-up.d:
total 12
-rwxr-xr-x 1 root root  344 30 juin   2016 ethtool
-rwxr-xr-x 1 root root 4191  7 mars   2020 wireless-tools
lrwxrwxrwx 1 root root   32  2 déc.   2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


/etc/network/if-up.d:
total 12
-rwxr-xr-x 1 root root  923  6 févr.  2021 avahi-autoipd
-rwxr-xr-x 1 root root 1677 13 janv.  2022 clamav-freshclam-ifupdown
-rwxr-xr-x 1 root root 1685 30 juin   2016 ethtool
lrwxrwxrwx 1 root root   32  2 déc.   2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


/etc/network/interfaces.d:
total 4
-rw-r--r-- 1 root root 63  9 oct.   2021 setup

/etc/systemd/network:
total 0

---

Not sue if it contains anything DHCP client related
Beside the /etc/network/interfaces.d/setup which contains only local 
interface and eth0
But again. I don't to fully stop using DHCP, which is would be the most 
obvious 

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

[David Wright]

On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:
> On 2023-02-23 02:59, cono...@panix.com wrote:
> > On 2/22/23, 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.
> > 
> > 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.

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

[Greg Wooledge]

On Mon, Feb 27, 2023 at 03:14:40PM +0100, daven...@tuxfamily.org wrote:
> I did
> 
> - chattr +i /etc/revolv.conf
> 
> And when auditd showed a (failed) delete event on /etc/resolv.conf
> 
> I grepped "resolv.conf" recursively on /var/log/, and All I've found are
> entries in
> 
> - /var/log/installer from more than 1 year ago, since the log file is small,
> I guess it has never been rotated
> - audit.log, since write and append  to "/etc/resolv.conf" are audited
> - auth.log : authentication related to commands I've used this morning,
> which are "auditctl -w /etc/resolv.conf -p wa" and "chattr +i
> /etc/revolv.conf"
> 
> But whatever process tried to delete "/etc/resolv.conf" whidle it was
> immutable, didn't leave traces.
> Not even a log for permission error because of the immutable flag. At least
> not in /var/log anyway.

I can't say I'm shocked.  But you *did* find an entry from auditd, which
presumably has a timestamp.  Check to see what was happening right at
that moment in other log files.

In particular, check whether a DHCP client daemon renewed its DHCP lease
at that time.

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

[davenull]

Hello

On 2023-02-24 11:27, daven...@tuxfamily.org wrote:

On 2023-02-24 10:27, to...@tuxteam.de wrote:
On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org 
wrote:


[...]

BUT I will make sure to take some time to dig into the logs monday.
Now that I have an idea what I'm looking for, totally agree logs are
better than suspicion


I did

- chattr +i /etc/revolv.conf

And when auditd showed a (failed) delete event on /etc/resolv.conf

I grepped "resolv.conf" recursively on /var/log/, and All I've found are 
entries in


- /var/log/installer from more than 1 year ago, since the log file is 
small, I guess it has never been rotated

- audit.log, since write and append  to "/etc/resolv.conf" are audited
- auth.log : authentication related to commands I've used this morning, 
which are "auditctl -w /etc/resolv.conf -p wa" and "chattr +i 
/etc/revolv.conf"


But whatever process tried to delete "/etc/resolv.conf" whidle it was 
immutable, didn't leave traces.
Not even a log for permission error because of the immutable flag. At 
least not in /var/log anyway.

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

[David Wright]

On Fri 24 Feb 2023 at 10:19:38 (+0100), daven...@tuxfamily.org wrote:
> > […]
> > vpnc_script has about eight methods available for setting up and
> > reverting resolv.conf. Which is used depends on the presence of
> > a binary, checked in turn from this list:
> > 
> >   /etc/openwrt_release  modify_resolvconf_openwrt
> >   /usr/bin/resolvectl   modify_resolved_manager
> >   /usr/bin/busctl   modify_resolved_manager_old
> >   /sbin/resolvconf  modify_resolvconf_manager
> >   /sbin/netconfig   modify_resolvconf_suse_netconfig
> >   /sbin/modify_resolvconf   modify_resolvconf_suse
> >   /usr/sbin/unbound-control modify_resolvconf_unbound
> >   otherwise modify_resolvconf_generic
> > 
> > Perhaps you could check which of those binaries you have.
> 
> I have they two resolved_manager binaries, but since systemd-resolvd
> service is disabled and stopped on my system, I highly doubt these are
> used.
> It's more likely modify_resolvconf_generic
> 
> However, I didn't notice any vnpc_script malfunction. It does what it
> is expected to do. I'm like 99% sure the problem is dhclient deleting
> and recreating /etc/resolv.conf as it sees fit, multiple times a day,
> and deleting whatever vpnc_script has put in that file.

If that's the case, then unfortunately the vnpc_script gives you no
protection against that happening. All it appears to do, when you
connect, is to write:

  #@VPNC_GENERATED@ -- this file is generated by vpnc
  # and will be overwritten by vpnc
  # as long as the above mark is intact"

at the start of resolv.conf, so that when you disconnect, it can check
if that first string is still there and, if it is, restore the previous
contents of the file.

Meanwhile, anything else might overwrite the file, and if it does,
it's likely that the vnpc_script won't even be able to restore the
previous version of the file when you disconnect.

You'll notice that none of the other functions actually reference
resolv.conf itself, but will store the real file elsewhere, and
publish it through a symlink.

> > > > But how do you manage /etc/resolv.conf with connman. I don't use it,
> > 
> > Actually I was interested in what sets up your ordinary networking,
> > the one that uses your ISP, when you're not "at work" …
> 
> - ConnMan is used to manually connect to/disconnect from wired, and
> much less often wireless (wifi, bluetooth) networks
> - dhclient is used for DHCP request

They should work with either of the resolvconf packages that Debian
supplies, resolvconf and openresolv. I use the latter, as iwd documents
that it supports it. I know there are people on this list who use connman.

> - My OpenWRT router with DHCP is used as gateway for my subnet,
> answers to DHCP requests

I do much the same, with my router (two, actually) connected to the
ISP's ethernet connector.

> - Then there's is toward my ISP's all-in-one router/modem + TV set top
> box + telephony bullshit (I don't use anything but Interne, but ISP
> enforces their "triple play bullshit so I have to do with that all in
> one device… There's no alternatives for DOCSIS, Since I can't get FTTH
> yet, which my current router doesn't support yet, either way I'm
> dependant on ISP router)

Everything of ours runs from my router, so the ISP's is just a
glorified modem.

Cheers,
David.

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

[Greg Wooledge]

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:
> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.

Then use one of the methods listed at 
to address that, and see if it fixes the problem.

The simplest one to test would be
.  It doesn't
involve installing any new packages.

If your testing is successful (e.g. a whole day goes by and the
resolv.conf file is not unexpectedly altered), then things get a little
bit trickier.  If I understand correctly, you're working on a laptop,
and your desired configuration is:

 * At boot time, allow the DHCP client to set up resolv.conf.

 * Once that has been done, disallow all further modifications of
   resolv.conf by the DHCP client.

 * Allow modifications of resolv.conf by vpnc_script at any time.

The tricky part here is how to write a function that determines whether
dhclient should be allowed to modify the file ("is it boot time") or not.
Perhaps you could use something awful like "if the system uptime is less
than 5 minutes, allow it".

Another hack that comes to mind would be writing something that removes
the resolv.conf file at shutdown time.  Then, the dhclient hook function
would allow dhclient to write the file if and only if it doesn't exist.

Or... the reverse of this.  Keep a second file which serves as a flag
indicating that the resolv.conf file has already been configured once.
Remove this flag at boot time (make sure that happens *early*, before
dhclient is started), and then write your dhclient hook function to
allow the modification if and only if the flag file doesn't exist.  Then
create the flag file after doing the modification.

I'm not sure which of those is the least bad.  Maybe you can come up
with some other ideas.

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

[tomas]

On Fri, Feb 24, 2023 at 11:27:40AM +0100, daven...@tuxfamily.org wrote:

> [...] totally agree logs are better than suspicion

But please, don't take my snark all too seriously. On reread I
realize it might have sounded harsher than it was meant.

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[davenull]

On 2023-02-24 10:27, to...@tuxteam.de wrote:

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:

[...]

However, I didn't notice any vnpc_script malfunction. It does what it 
is

expected to do. I'm like 99% sure the problem is dhclient deleting and
recreating /etc/resolv.conf as it sees fit, multiple times a day, and
deleting whatever vpnc_script has put in that file.


Instead of 99% suspicions you could just look into your 
/var/log/syslog:

dhclient does leave enough traces there. Bonus point if you correlate
these timestamps with your resolv.conf mod time :-)

Cheers


Goode point. Thank you for the reminder :)

I do only partial week remote work, been in the office the last days.
So in order for the problem to happen again, I need to wait monday, only 
then I might dig into the log files.


The thing is: at first, I didn't suspect dhclient until recently (after 
I started this thread) so I need to wait for the next remote work day.
During my last days of remote work, I just used auditd to see if I can 
see process name when the file is deleted/recreated.
The event was captured by auditd but the process name was missing from 
the audit.log file, so I had no idea what's to look for., in which log 
file(s).


I'm still sure it isn't vpnc_script. vpnc_script leaves identification 
comments on the file
And dhclient is more like to know only about what my home's DHCP tells 
it, than my work's place DNS resolver, that's why I suspect dhclient.
BUT I will make sure to take some time to dig into the logs monday. Now 
that I have an idea what I'm looking for, totally agree logs are better 
than suspicion

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

[tomas]

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:

[...]

> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.

Instead of 99% suspicions you could just look into your /var/log/syslog:
dhclient does leave enough traces there. Bonus point if you correlate
these timestamps with your resolv.conf mod time :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[davenull]

Hello,


[…]
vpnc_script has about eight methods available for setting up and
reverting resolv.conf. Which is used depends on the presence of
a binary, checked in turn from this list:

  /etc/openwrt_release  modify_resolvconf_openwrt
  /usr/bin/resolvectl   modify_resolved_manager
  /usr/bin/busctl   modify_resolved_manager_old
  /sbin/resolvconf  modify_resolvconf_manager
  /sbin/netconfig   modify_resolvconf_suse_netconfig
  /sbin/modify_resolvconf   modify_resolvconf_suse
  /usr/sbin/unbound-control modify_resolvconf_unbound
  otherwise modify_resolvconf_generic

Perhaps you could check which of those binaries you have.



I have they two resolved_manager binaries, but since systemd-resolvd 
service is disabled and stopped on my system, I highly doubt these are 
used.

It's more likely modify_resolvconf_generic

However, I didn't notice any vnpc_script malfunction. It does what it is 
expected to do. I'm like 99% sure the problem is dhclient deleting and 
recreating /etc/resolv.conf as it sees fit, multiple times a day, and 
deleting whatever vpnc_script has put in that file.





> But how do you manage /etc/resolv.conf with connman. I don't use it,


Actually I was interested in what sets up your ordinary networking,
the one that uses your ISP, when you're not "at work" …


- ConnMan is used to manually connect to/disconnect from wired, and much 
less often wireless (wifi, bluetooth) networks

- dhclient is used for DHCP request
- My OpenWRT router with DHCP is used as gateway for my subnet, answers 
to DHCP requests
- Then there's is toward my ISP's all-in-one router/modem + TV set top 
box + telephony bullshit (I don't use anything but Interne, but ISP 
enforces their "triple play bullshit so I have to do with that all in 
one device… There's no alternatives for DOCSIS, Since I can't get FTTH 
yet, which my current router doesn't support yet, either way I'm 
dependant on ISP router)





Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be
generated according to my home router's DHCP tells the computer


… yes, that one.

Cheers,
David.

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

[tomas]

On Thu, Feb 23, 2023 at 11:39:03PM -0600, David Wright wrote:

[...]

> vpnc_script has about eight methods available for setting up and
> reverting resolv.conf. Which is used depends on the presence of
> a binary, checked in turn from this list:
> 
>   /etc/openwrt_release  modify_resolvconf_openwrt
>   /usr/bin/resolvectl   modify_resolved_manager
>   /usr/bin/busctl   modify_resolved_manager_old
>   /sbin/resolvconf  modify_resolvconf_manager
>   /sbin/netconfig   modify_resolvconf_suse_netconfig
>   /sbin/modify_resolvconf   modify_resolvconf_suse
>   /usr/sbin/unbound-control modify_resolvconf_unbound
>   otherwise modify_resolvconf_generic
> 
> Perhaps you could check which of those binaries you have.

Thanks for this one. I think this is the most constructive
contribution to this thread.

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[David Wright]

On Thu 23 Feb 2023 at 10:44:35 (+0100), daven...@tuxfamily.org wrote:
> On 2023-02-22 22:08, David Wright wrote:
> > On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote:
> > 
> > > What I want is: setting up /etc/resolv.conf ONLY
> > > -  at system startup/initial network connexion.
> > > - when openconnect is executed and connects to work's VPN
> > > - when openconnect is ^C-ed and disconnects from the works VPN
> > > (cleaning it's mess in the routing table, interfaces, /etc/resolv's
> > > and other netwwork stuff it might have modified, makes sense)
> > 
> > What's the output from   ls -l /etc/resolv.conf
> 
> -rw-r--r-- 1 root root 104 23 févr. 09:35 /etc/resolv.conf
> 
> With the ctime changing more or less often, since it is
> deleted/recreated by what I suspect to do DHCP requests (see
> audit.log)

Being a real file, it's not protected from being modified by any
process that wants to. A resolv.conf manager will set up resolv.conf
as a symlink to a file that it controls, so that it can manage
contention between different processes.

> > What's responsible for restoring the previous contents of
> > /etc/resolv.conf to your normal network connection when you
> > finish "work" and tear down the VPN.
> 
> openconnect does. When it's CTRL-C-ed to disconnect from the workplace
> VPN, resolv.conf is reverted back to my home network resolver
> Not sure whether vpnc_script just calls the DHCP client (probably
> dhclient since it's the only dhcp client preinstalled, at least I'm
> aware of)
[ … ]
> > One way of finding the process is to  # chattr +i /etc/resolv.conf
> > while you're "at work", so that you get permission errors in the
> > logs when it happens. (Remember to chattr -i before you "stop work".)
> 
> Thank you. I'll give it a try, But I won't be on remote work before
> next week
> Which log file is used for that?
> So instead of grepping /var/log/ recursively when the problem occurs.
> I'd tail -f the right file to find the "rogue" process right away

I don't know. I thought the destination was chosen more by the program
than the error type. Perhaps daemon.log and syslog might be good
candidates. Of course, after the event you can check them all.

> openconnect uses something called vpnc_script.
> When openconnects is exc, resolv.conf contains the appropriate info as
> well a comment including "VPNC_GENERATED"
> 
> > but I read there's a plug-in for that. Is openconnect correctly
> > informing connman when it finishes.
> 
> Whether it informs connmann or cleans after itself without involving
> connmann, I don't know and I'm not sure how to check that out.
> I'm not familiar with how vpnc_script works and what it does _exactly_
> But it does clean up the config and network config is left in working
> state when openconnect disconnects

vpnc_script has about eight methods available for setting up and
reverting resolv.conf. Which is used depends on the presence of
a binary, checked in turn from this list:

  /etc/openwrt_release  modify_resolvconf_openwrt
  /usr/bin/resolvectl   modify_resolved_manager
  /usr/bin/busctl   modify_resolved_manager_old
  /sbin/resolvconf  modify_resolvconf_manager
  /sbin/netconfig   modify_resolvconf_suse_netconfig
  /sbin/modify_resolvconf   modify_resolvconf_suse
  /usr/sbin/unbound-control modify_resolvconf_unbound
  otherwise modify_resolvconf_generic

Perhaps you could check which of those binaries you have.

> > But how do you manage /etc/resolv.conf with connman. I don't use it,

Actually I was interested in what sets up your ordinary networking,
the one that uses your ISP, when you're not "at work" …

> Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be
> generated according to my home router's DHCP tells the computer

… yes, that one.

Cheers,
David.

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

[Reco]

Hi.

On Thu, Feb 23, 2023 at 11:31:44AM +0100, daven...@tuxfamily.org wrote:
> > If it is DHCP: You might do a countermeasure in
> > /etc/dhcp/dhclient.conf. On my system I have an entry as below.
> > 
> > interface "wlp4s0" {
> > supersede domain-name-servers 127.0.0.1;
> 
> Unfortunately, I can't use supersede parameter because I need to use
> different resolvers at different times/in different contexts.
> 
> I would need something more… conditional
> 
> IF openconnect is running and has modified resolv.conf, leave that
> file alone unless you are openconnect Otherwise, when there's no VPN
> active, you can do normal DHCP requests and accept whatever
> currently-active network's router/DHCP tells you and update resolve
> conf accordingly

openconnect has that helpful --script option, which calls
/usr/share/vpnc-scripts/vpnc-script by default.
All you need is to make a copy of that script, modify dhclient.conf
at "connect" and "disconnect" phases accordingly, and then call your
modified script from openconnect.

Reco

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

[davenull]

On 2023-02-23 10:54, to...@tuxteam.de wrote:

On Thu, Feb 23, 2023 at 10:44:35AM +0100, daven...@tuxfamily.org wrote:

[...]

Thank you. I'll give it a try, But I won't be on remote work before 
next

week
Which log file is used for that?


That depends: it's the perpetrator's choice where to log (or whether
to log at all, sadly).

So instead of grepping /var/log/ recursively when the problem occurs. 
I'd

tail -f the right file to find the "rogue" process right away


You know that you can tail -f more than one file, do you?

I just learnt that from a colleague. Enormously handy.

Cheers


Interesting! I didn't knew that. Thanks for the tip.

I knew about and I just remembered multitail, which I never used that 
much, cause can be too noisy… But I guess I'm going to use "grep 
resolv.conf"… But if the "rogue" process doesn't log anything… I'll be 
stuck… worth trying either way. Thanks

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

[Jeremy Ardley]

On 23/2/23 18:23, daven...@tuxfamily.org wrote:

Hello,

On 2023-02-23 02:59, cono...@panix.com wrote:

On 2/22/23, 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.


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.)

    John


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.


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?


As a general comment on resolving name service problems you need to 
become acquainted with nsswitch


I have only recently become aware of it. It's central in determining 
just how your system looks up lots of things including DNS names.


Some research and reading is required (for me and perhaps most?)

--
Jeremy
(Lists)

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

[davenull]

Hi

On 2023-02-22 18:30, Christoph Brinkhaus wrote:
Am Wed, Feb 22, 2023 at 06:12:29PM +0100 schrieb 
daven...@tuxfamily.org:


= context =
For the context, I use a Debian 11 laptop for work. When I work 
remotely
from home, I have to use a cisco VPN. Good thing is there is 
openconnect,
which does work, and in teh case of ym work's VPN, it does wor. 
cisco's

spyware/downloaded binry, namely using the --csd-wrapper
/usr/libexec/openconnect/"

[snip]

= end of context =
What I want is: setting up /etc/resolv.conf ONLY
-  at system startup/initial network connexion.
- when openconnect is executed and connects to work's VPN
- when openconnect is ^C-ed and disconnects from the works VPN 
(cleaning
it's mess in the routing table, interfaces, /etc/resolv's and other 
netwwork

stuff it might have modified, makes sense)

Here's what I know:
- Whatever process does that seems does what I highly suspect to be 
DHCP [1]
requests every now and then. Home's router answers giving it's own 
address
as both gateway and DNS resolver. And said process thinks it's OK to 
delete
and recreate resolv.conf with the wrong content… breaking everything 
work's

related while the VPN is still active


If it is DHCP: You might do a countermeasure in
/etc/dhcp/dhclient.conf. On my system I have an entry as below.

interface "wlp4s0" {
supersede domain-name-servers 127.0.0.1;


Unfortunately, I can't use supersede parameter because I need to use 
different resolvers at different times/in different contexts.


I would need something more… conditional

IF openconnect is running and has modified resolv.conf, leave that file 
alone unless you are openconnect
Otherwise, when there's no VPN active, you can do normal DHCP requests 
and accept whatever currently-active network's router/DHCP tells you and 
update resolve conf accordingly



}

I run unbound as a resolver. The entry in dhcclient.conf prevents that
the entry in /etc/resolv.conf is overwritten.

[snip]

My setup is stoneage like compared to your context.
Anyhow, I hope this is at least useful as a pointer :-).

Kind regards,
Christoph

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

[davenull]

Hello,

On 2023-02-23 02:59, cono...@panix.com wrote:

On 2/22/23, 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.


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.)

John


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.


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?

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

[tomas]

On Thu, Feb 23, 2023 at 10:44:35AM +0100, daven...@tuxfamily.org wrote:

[...]

> Thank you. I'll give it a try, But I won't be on remote work before next
> week
> Which log file is used for that?

That depends: it's the perpetrator's choice where to log (or whether
to log at all, sadly).

> So instead of grepping /var/log/ recursively when the problem occurs. I'd
> tail -f the right file to find the "rogue" process right away

You know that you can tail -f more than one file, do you?

I just learnt that from a colleague. Enormously handy.

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[davenull]

Hello

On 2023-02-22 22:08, David Wright wrote:

On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote:


What I want is: setting up /etc/resolv.conf ONLY
-  at system startup/initial network connexion.
- when openconnect is executed and connects to work's VPN
- when openconnect is ^C-ed and disconnects from the works VPN
(cleaning it's mess in the routing table, interfaces, /etc/resolv's
and other netwwork stuff it might have modified, makes sense)


What's the output from   ls -l /etc/resolv.conf



-rw-r--r-- 1 root root 104 23 févr. 09:35 /etc/resolv.conf

With the ctime changing more or less often, since it is 
deleted/recreated by what I suspect to do DHCP requests (see audit.log)



What's responsible for restoring the previous contents of
/etc/resolv.conf to your normal network connection when you
finish "work" and tear down the VPN.


openconnect does. When it's CTRL-C-ed to disconnect from the workplace 
VPN, resolv.conf is reverted back to my home network resolver
Not sure whether vpnc_script just calls the DHCP client (probably 
dhclient since it's the only dhcp client preinstalled, at least I'm 
aware of)





- I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
connmann as the default network manager) ships with systemd-resolvd
disabled and I'm totally OK with it
- I do use connmann and didn't replace it with anything else
- The process that deletes and recreates /etc/resolv.conf runs as
root. I used auditd to detect when changes that file… but I can't a
get any process name. I can just see it's root


One way of finding the process is to  # chattr +i /etc/resolv.conf
while you're "at work", so that you get permission errors in the
logs when it happens. (Remember to chattr -i before you "stop work".)


Thank you. I'll give it a try, But I won't be on remote work before next 
week

Which log file is used for that?
So instead of grepping /var/log/ recursively when the problem occurs. 
I'd tail -f the right file to find the "rogue" process right away




But how do you manage /etc/resolv.conf with connman. I don't use it,


openconnect uses something called vpnc_script.
When openconnects is exc, resolv.conf contains the appropriate info as 
well a comment including "VPNC_GENERATED"



but I read there's a plug-in for that. Is openconnect correctly
informing connman when it finishes.


Whether it informs connmann or cleans after itself without involving 
connmann, I don't know and I'm not sure how to check that out.

I'm not familiar with how vpnc_script works and what it does _exactly_
But it does clean up the config and network config is left in working 
state when openconnect disconnects





I was expecting to see a process name it the audit.log file BUT it
didn't happened so I'm still stuck. so my question is: How to debug
that further, and identify the exact process that screw up with
/etc/resolv.conf file… So from there I could search for a way to
prevent that by modifying the rights config file or whatever…


Whatever the "rogue process" is should be informing whatever the
"/etc/resolv.conf controller" is, shouldn't it, rather than being
blocked. (It might be legitimate rather than "rogue".)


Yes, I certainly don't want to block the process entirely, I just want 
to find some mechanism that works in the following way


"Leave /etc/resolv.conf alone, ONLY IF you're not openconnect/a 
vpnc_script AND WHEN openconnect is running"


Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be 
generated according to my home router's DHCP tells the computer


Thank you for your help either way. It gives me some interesting 
pointers :)




Cheers,
David.

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

[John Conover]

On 2/22/23, 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.

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.)

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

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

[Cindy Sue Causey]

On 2/22/23, 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! *

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

[David Wright]

On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote:

> What I want is: setting up /etc/resolv.conf ONLY
> -  at system startup/initial network connexion.
> - when openconnect is executed and connects to work's VPN
> - when openconnect is ^C-ed and disconnects from the works VPN
> (cleaning it's mess in the routing table, interfaces, /etc/resolv's
> and other netwwork stuff it might have modified, makes sense)

What's the output from   ls -l /etc/resolv.conf

What's responsible for restoring the previous contents of
/etc/resolv.conf to your normal network connection when you
finish "work" and tear down the VPN.

> - I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
> connmann as the default network manager) ships with systemd-resolvd
> disabled and I'm totally OK with it
> - I do use connmann and didn't replace it with anything else
> - The process that deletes and recreates /etc/resolv.conf runs as
> root. I used auditd to detect when changes that file… but I can't a
> get any process name. I can just see it's root

One way of finding the process is to  # chattr +i /etc/resolv.conf
while you're "at work", so that you get permission errors in the
logs when it happens. (Remember to chattr -i before you "stop work".)

But how do you manage /etc/resolv.conf with connman. I don't use it,
but I read there's a plug-in for that. Is openconnect correctly
informing connman when it finishes.

> I was expecting to see a process name it the audit.log file BUT it
> didn't happened so I'm still stuck. so my question is: How to debug
> that further, and identify the exact process that screw up with
> /etc/resolv.conf file… So from there I could search for a way to
> prevent that by modifying the rights config file or whatever…

Whatever the "rogue process" is should be informing whatever the
"/etc/resolv.conf controller" is, shouldn't it, rather than being
blocked. (It might be legitimate rather than "rogue".)

Cheers,
David.

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

[Greg Wooledge]

On Wed, Feb 22, 2023 at 06:12:29PM +0100, 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, [...]

Then it's probably the Debian DHCP client, rewriting resolv.conf
according to what your router's DHCP server told it to use.

 has several different strategies
for working around this sort of issue.

Good luck.

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

[Christoph Brinkhaus]

Am Wed, Feb 22, 2023 at 06:12:29PM +0100 schrieb daven...@tuxfamily.org:
> 
> = context =
> For the context, I use a Debian 11 laptop for work. When I work remotely
> from home, I have to use a cisco VPN. Good thing is there is openconnect,
> which does work, and in teh case of ym work's VPN, it does wor. cisco's
> spyware/downloaded binry, namely using the --csd-wrapper
> /usr/libexec/openconnect/"
[snip]
> = end of context =
> What I want is: setting up /etc/resolv.conf ONLY
> -  at system startup/initial network connexion.
> - when openconnect is executed and connects to work's VPN
> - when openconnect is ^C-ed and disconnects from the works VPN (cleaning
> it's mess in the routing table, interfaces, /etc/resolv's and other netwwork
> stuff it might have modified, makes sense)
> 
> Here's what I know:
> - Whatever process does that seems does what I highly suspect to be DHCP [1]
> requests every now and then. Home's router answers giving it's own address
> as both gateway and DNS resolver. And said process thinks it's OK to delete
> and recreate resolv.conf with the wrong content… breaking everything work's
> related while the VPN is still active

If it is DHCP: You might do a countermeasure in
/etc/dhcp/dhclient.conf. On my system I have an entry as below.

interface "wlp4s0" {
supersede domain-name-servers 127.0.0.1;
}

I run unbound as a resolver. The entry in dhcclient.conf prevents that
the entry in /etc/resolv.conf is overwritten.

[snip]

My setup is stoneage like compared to your context.
Anyhow, I hope this is at least useful as a pointer :-).

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

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

[Roberto C . Sánchez]

On Wed, Feb 22, 2023 at 06:12:29PM +0100, 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,

I will admit up front that I did not read your message in great detail.
However, overall it seems like you are experiencing something similar to
what I experienced in the past.

Here was what I found and how I solved the problem:

https://lists.debian.org/debian-user/2017/10/msg00896.html

The entire thread is rather large, so I didn't just point you to the
beginning of it, but you might find other parts of the discussion
illuminating as well.

Regards,

-Roberto
-- 
Roberto C. Sánchez