Re: resolv.conf (was Re: electrons/the Internet [racism redacted])

[David Christensen]

On 3/4/24 13:11, Greg Wooledge wrote:

On Mon, Mar 04, 2024 at 12:36:54PM -0800, David Christensen wrote:

I believe Debian rewrites /etc/resolv.conf on every boot.


This is not correct.  It's *partly* correct if you ignore a lot of
complicating factors.

Short version: read <https://wiki.debian.org/resolv.conf>.

Long version follows:

If you have a static network interface configuration, defined in
/etc/network/interfaces, with no DHCP client, no VPN stuff going on,
etc. then your /etc/resolv.conf will not be changed.  You can edit the
file and put whatever you want in it, and it'll remain as you wish it
to be.

Unfortunately, almost *nobody* has a setup like this any more.

In a more typical environment, you get your IP address via DHCP, which
means you're running a DHCP client daemon.  Most DHCP client daemons
will rewrite the /etc/resolv.conf file every time they refresh their
DHCP lease.  This may indeed happen at boot time, but it'll also happen
a couple times a day during normal operations.

So, a simple instruction like "edit /etc/resolv.conf" is no longer
possible.  Even worse, there's no single *alternative* either.  You can't
even say "do ___ instead".

To put the correct values into your /etc/resolv.conf file nowdays, you
have to select a *strategy*.  You need to find an indirect way to put
the right content into some *other* place, in such a way that it will
eventually find its way into /etc/resolv.conf every time the file is
rewritten.  And there are *lots* of strategies that will work, so you
can't even say "obviously this one is best".  Life is not that simple.

Or, you could use chattr +i to make the /etc/resolv.conf file immutable,
so DHCP clients and other programs cannot overwrite it.

Either way, you take ownership of whatever strategy you decide to use,
together with its pros and cons.  You'll have to understand that on *this*
system, you went with *this* strategy, and remember where to put your
changes, and how to make them.  Or at the very least, you'll need to be
*aware* of all the strategies you've got in play on all of your systems,
and know how to identify which one is in use on any given system.



Thank you for the clarification.  Thankfully, my gateway DHCP server and 
my Debian instances work together.



David

Re: resolv.conf (was Re: electrons/the Internet [racism redacted])

[Markus Schönhaber]

04.03.24, 22:11 +0100, Greg Wooledge:

> Instead,
> we will have another hundred-message argument, in which half the
> participants will have no idea what the issue is (but will chime in loudly
> anyway), and the second half will simply attack whatever strategies the
> third half have selected.

You made my day :-)

-- 
Regards
  mks

Re: resolv.conf (was Re: electrons/the Internet [racism redacted])

[Jeffrey Walton]

On Mon, Mar 4, 2024 at 4:12 PM Greg Wooledge  wrote:
>
> On Mon, Mar 04, 2024 at 12:36:54PM -0800, David Christensen wrote:
> > I believe Debian rewrites /etc/resolv.conf on every boot.
>
> This is not correct.  It's *partly* correct if you ignore a lot of
> complicating factors.
> [...]
>
> All of this is documented on <https://wiki.debian.org/resolv.conf>
> but it's a virtual certainty that nobody in this thread will read that
> wiki page and select a strategy and implement it and be happy.  Instead,
> we will have another hundred-message argument, in which half the
> participants will have no idea what the issue is (but will chime in loudly
> anyway), and the second half will simply attack whatever strategies the
> third half have selected.

Lol... so true. The internet never misses an opportunity to argue!

> resolv.conf (was Re: electrons/the Internet [racism redacted])

And I think I hear someone approaching with the Mjölnir hammer.
Someone might be plonked over the head.

Jeff

resolv.conf (was Re: electrons/the Internet [racism redacted])

[Greg Wooledge]

On Mon, Mar 04, 2024 at 12:36:54PM -0800, David Christensen wrote:
> I believe Debian rewrites /etc/resolv.conf on every boot.

This is not correct.  It's *partly* correct if you ignore a lot of
complicating factors.

Short version: read <https://wiki.debian.org/resolv.conf>.

Long version follows:

If you have a static network interface configuration, defined in
/etc/network/interfaces, with no DHCP client, no VPN stuff going on,
etc. then your /etc/resolv.conf will not be changed.  You can edit the
file and put whatever you want in it, and it'll remain as you wish it
to be.

Unfortunately, almost *nobody* has a setup like this any more.

In a more typical environment, you get your IP address via DHCP, which
means you're running a DHCP client daemon.  Most DHCP client daemons
will rewrite the /etc/resolv.conf file every time they refresh their
DHCP lease.  This may indeed happen at boot time, but it'll also happen
a couple times a day during normal operations.

So, a simple instruction like "edit /etc/resolv.conf" is no longer
possible.  Even worse, there's no single *alternative* either.  You can't
even say "do ___ instead".

To put the correct values into your /etc/resolv.conf file nowdays, you
have to select a *strategy*.  You need to find an indirect way to put
the right content into some *other* place, in such a way that it will
eventually find its way into /etc/resolv.conf every time the file is
rewritten.  And there are *lots* of strategies that will work, so you
can't even say "obviously this one is best".  Life is not that simple.

Or, you could use chattr +i to make the /etc/resolv.conf file immutable,
so DHCP clients and other programs cannot overwrite it.

Either way, you take ownership of whatever strategy you decide to use,
together with its pros and cons.  You'll have to understand that on *this*
system, you went with *this* strategy, and remember where to put your
changes, and how to make them.  Or at the very least, you'll need to be
*aware* of all the strategies you've got in play on all of your systems,
and know how to identify which one is in use on any given system.

All of this is documented on <https://wiki.debian.org/resolv.conf>
but it's a virtual certainty that nobody in this thread will read that
wiki page and select a strategy and implement it and be happy.  Instead,
we will have another hundred-message argument, in which half the
participants will have no idea what the issue is (but will chime in loudly
anyway), and the second half will simply attack whatever strategies the
third half have selected.

And in another month or two, we'll do it all again.

Re: Populating IPv6 DNS addresses in resolv.conf

[Max Nikulin]

On 01/11/2023 17:41, Timothy M Butterworth wrote:

All,

Thanks for all your help. I was able to get it mostly working:

# Generated by NetworkManager
search home.arpa
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 192.168.104.233
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2001:4860:4860::
nameserver 2001:4860:4860::8844
nameserver 2600:380:bc53:b864::b3

I did not want the DNS name servers to be populated but I can live with it.


Do you mean that you prefer to avoid 192.168.104.233 
2600:380:bc53:b864::b3 received from DHCP?


Perhaps the 3 servers limitation may be relieved by allowing 
NetworkManager to run dnsmasq.

Re: Populating IPv6 DNS addresses in resolv.conf

[Timothy M Butterworth]

All,

Thanks for all your help. I was able to get it mostly working:

# Generated by NetworkManager
search home.arpa
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 192.168.104.233
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2001:4860:4860::
nameserver 2001:4860:4860::8844
nameserver 2600:380:bc53:b864::b3

I did not want the DNS name servers to be populated but I can live with it.

thank again for your help

Tim


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Populating IPv6 DNS addresses in resolv.conf

[Max Nikulin]

On 30/10/2023 20:04, Timothy M Butterworth wrote:

sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection

[...]

[ipv6]
addr-gen-mode=stable-privacy
dns=2001:4860:4860::,2001:4860:4860::8844;
dns-search=home.arpa;
ignore-auto-dns=true #I tried with this on, commented out and set to false
may-fail=false
method=auto


I have tried to add a DNS server through GUI. The result is

[ipv6]
addr-gen-mode=stable-privacy
dns=2001:4860:4860::;
method=auto

Disconnect and connect again.

cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 10.0.2.3
nameserver 2001:4860:4860::

It is a qemu VM, it gets DHCPv4 lease, but not DHCPv6 one. I have not 
tried to customize /etc/dhclient. Another data point with manually added 
IPv6 DNS server is Pocket's message

https://lists.debian.org/msgid-search/94ff954f-7d28-4a86-bdea-bd2c82196...@columbus.rr.com

Re: Populating IPv6 DNS addresses in resolv.conf

[Max Nikulin]

On 31/10/2023 04:02, Pocket wrote:

On 10/30/23 15:50, Timothy M Butterworth wrote:


I know it is using dhclient because I typod the domain name supersede 
domain-name "home.apra"; and it populated .apra in resolv.conf.


Sorry, it is not clear for me what did you do and what result you got. 
There is a script that may run ifupdown hooks:

/etc/NetworkManager/dispatcher.d/01-ifupdown
I hope, dhclient settings do not conflict with NetworkManager connection 
properties.



/etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf)

[main]
# rc-manager=
# auth-polkit=true
# dhcp=internal

^^

This states that you are running two DHCP clients as I suspected.


I would not be so sure. Notice "[ifupdown] managed=false". It is better 
to have a look into "ps axuwwf" for DHCP-related stuff (dhclient, 
udhcpcd). I hope, systemd-networkd does not try to manage interfaces


networkctl

should report "unmanaged". I assume that NetworkManager uses its 
internal DHCP client and it is OK.


Timothy, are you sure that "Pixel5" sends a DHCP lease? I have almost no 
experience with IPv6. I would try other methods for IPv6. I hope,


nmcli connection show Pixel5

may shed more light on IPv6 configuration state. Finally, do not neglect 
"journalctl -b" messages (even though I find NetworkManager log messages 
rather noisy).

Re: Populating IPv6 DNS addresses in resolv.conf

[Pocket]

On 10/30/23 15:50, Timothy M Butterworth wrote:



On Mon, Oct 30, 2023 at 1:18 PM Pocket  wrote:


On 10/30/23 09:04, Timothy M Butterworth wrote:

Hello All,

I have been following the recent emails regarding resolv.conf. I
almost have my system running perfectly. The only thing I am
missing is the population of IPv6 DNS addresses.

sudo less /etc/dhcp/dhclient.conf
supersede domain-name "home.arpa";
supersede dhcp6.domain-search "home.arpa";
supersede dhcp6.name-servers 2001:4860:4860::,
2001:4860:4860::8844;
supersede domain-name-servers 8.8.8.8, 8.8.4.4;

sudo less /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[global-dns]
searches=home.arpa

sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection

[ipv4]
dns=8.8.4.4,8.8.8.8;
dns-search=home.arpa;
ignore-auto-dns=true #I tried with this on, commented out and set
to false
may-fail=false
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns=2001:4860:4860::,2001:4860:4860::8844;
dns-search=home.arpa;
ignore-auto-dns=true #I tried with this on, commented out and set
to false
may-fail=false
method=auto

sudo less /etc/resolv.conf
domain home.arpa
search home.arpa
nameserver 8.8.8.8
nameserver 8.8.4.4

For some reason I am not getting any IPv6 Name Servers populated.

Any thoughts are appreciated.

Tim



Why not use NetworkManagers internal DHCP client.

That is what I have done and then I don't need dhclient or dhcpcd.

I am not sure that you are really using dhclient as NetworkManager
has not been set to use dhclient from the configuration that you
have posted.


I know it is using dhclient because I typod the domain name supersede 
domain-name "home.apra"; and it populated .apra in resolv.conf.


What is the output from:

NetworkManager --print-config

Notice in the following dhcp=internal in my configuration

NetworkManager --print-config


sudo NetworkManager --print-config
# NetworkManager configuration: 
/etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf)


[main]
# rc-manager=
# auth-polkit=true
# dhcp=internal


^^

This states that you are running two DHCP clients as I suspected.

That is probably why you have the results you have.


From the docs page: 
https://networkmanager.dev/docs/api/latest/NetworkManager.conf.html


||




This key sets up what DHCP client NetworkManager will use. Allowed 
values are |dhclient|, |dhcpcd|, and |internal|. The |dhclient| and 
|dhcpcd| options require the indicated clients to be installed. The 
|internal| option uses a built-in DHCP client which is not currently as 
featureful as the external clients.


If this key is missing, it defaults to |internal|. If the chosen plugin 
is not available, clients are looked for in this order: |dhclient|, 
|dhcpcd|, |internal|.


The commented entries are the defaults if not explicitly set

--

It's not easy to be me

Re: Populating IPv6 DNS addresses in resolv.conf

[Timothy M Butterworth]

On Mon, Oct 30, 2023 at 1:18 PM Pocket  wrote:

>
> On 10/30/23 09:04, Timothy M Butterworth wrote:
>
> Hello All,
>
> I have been following the recent emails regarding resolv.conf. I almost
> have my system running perfectly. The only thing I am missing is the
> population of IPv6 DNS addresses.
>
> sudo less /etc/dhcp/dhclient.conf
> supersede domain-name "home.arpa";
> supersede dhcp6.domain-search "home.arpa";
> supersede dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;
> supersede domain-name-servers 8.8.8.8, 8.8.4.4;
>
> sudo less /etc/NetworkManager/NetworkManager.conf
> [main]
> plugins=ifupdown,keyfile
>
> [ifupdown]
> managed=false
>
> [global-dns]
> searches=home.arpa
>
> sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection
>
> [ipv4]
> dns=8.8.4.4,8.8.8.8;
> dns-search=home.arpa;
> ignore-auto-dns=true #I tried with this on, commented out and set to false
> may-fail=false
> method=auto
>
> [ipv6]
> addr-gen-mode=stable-privacy
> dns=2001:4860:4860::,2001:4860:4860::8844;
> dns-search=home.arpa;
> ignore-auto-dns=true #I tried with this on, commented out and set to false
> may-fail=false
> method=auto
>
> sudo less /etc/resolv.conf
> domain home.arpa
> search home.arpa
> nameserver 8.8.8.8
> nameserver 8.8.4.4
>
> For some reason I am not getting any IPv6 Name Servers populated.
>
> Any thoughts are appreciated.
>
> Tim
>
>
> Why not use NetworkManagers internal DHCP client.
>
> That is what I have done and then I don't need dhclient or dhcpcd.
>
> I am not sure that you are really using dhclient as NetworkManager has not
> been set to use dhclient from the configuration that you have posted.
>

I know it is using dhclient because I typod the domain name supersede
domain-name "home.apra"; and it populated .apra in resolv.conf.


> What is the output from:
>
> NetworkManager --print-config
>
> Notice in the following dhcp=internal in my configuration
>
> NetworkManager --print-config
>

sudo NetworkManager --print-config
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf
(lib: no-mac-addr-change.conf)

[main]
# rc-manager=
# auth-polkit=true
# dhcp=internal
# iwd-config-path=
plugins=ifupdown,keyfile
configure-and-quit=no

[global-dns]
searches=home.arpa

[ifupdown]
managed=false

[logging]
# backend=journal
# audit=true

[device]
# wifi.backend=wpa_supplicant

[device-31-mac-addr-change]
match-device=driver:eagle_sdio,driver:wl
wifi.scan-rand-mac-address=no



> # NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf
> (lib: no-mac-addr-change.conf)
>
> [main]
> # rc-manager=
> # auth-polkit=true
> # dhcp=internal
> # iwd-config-path=
> plugins=ifupdown,keyfile
> configure-and-quit=no
>
> [global-dns]
> options=ends0 trust-ad
>
> [ifupdown]
> managed=false
>
> [logging]
> # backend=journal
> # audit=true
>
> [device]
> # wifi.backend=wpa_supplicant
> wifi.scan-rand-mac-address=no
>
> [device-31-mac-addr-change]
> match-device=driver:eagle_sdio,driver:wl
> wifi.scan-rand-mac-address=no
>
> # no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"--
>
> --
>
> It's not easy to be me
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Populating IPv6 DNS addresses in resolv.conf

[Timothy M Butterworth]

On Mon, Oct 30, 2023 at 11:09 AM Max Nikulin  wrote:

> On 30/10/2023 20:04, Timothy M Butterworth wrote:
> > sudo less /etc/resolv.conf
> > domain home.arpa
> > search home.arpa
> > nameserver 8.8.8.8
> > nameserver 8.8.4.4
>
> I do not see "# Generated by NetworkManager" here.
>
>  nmcli connection
>
NAMEUUID  TYPE  DEVICE
Pixel5  e70d426b-3a26-4b29-bf59-edb3dcdfdbc3  wifi  wlo1


>  nmcli device
>
DEVICE  TYPE  STATE   CONNECTION
wlo1wifi  connected   Pixel5



>  NetworkManager --print-config
>
sudo NetworkManager --print-config
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf
(lib: no-mac-addr-change.conf)

[main]
# rc-manager=
# auth-polkit=true
# dhcp=internal # Am I correct in thinking that this setting enables the
internal DHCP client.
# iwd-config-path=
plugins=ifupdown,keyfile
configure-and-quit=no

[global-dns]
searches=home.arpa

[ifupdown]
managed=false

[logging]
# backend=journal
# audit=true

[device]
# wifi.backend=wpa_supplicant

[device-31-mac-addr-change]
match-device=driver:eagle_sdio,driver:wl
wifi.scan-rand-mac-address=no

# no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"


>  ls -l /etc/resolv.conf
>
 lsattr /etc/resolv.conf
>

I just changed this back to using chattr +i with the IPv6 addresses added.



> As to /etc/dhcp/dhclient.conf and /etc/network/interfaces, I may be
> wrong, but perhaps independent instances for IPv4 and IPv6 may be
> running (if actual connection is managed through ifupdown)
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Populating IPv6 DNS addresses in resolv.conf

[Pocket]

On 10/30/23 09:04, Timothy M Butterworth wrote:

Hello All,

I have been following the recent emails regarding resolv.conf. I 
almost have my system running perfectly. The only thing I am missing 
is the population of IPv6 DNS addresses.


sudo less /etc/dhcp/dhclient.conf
supersede domain-name "home.arpa";
supersede dhcp6.domain-search "home.arpa";
supersede dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;
supersede domain-name-servers 8.8.8.8, 8.8.4.4;

sudo less /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[global-dns]
searches=home.arpa

sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection

[ipv4]
dns=8.8.4.4,8.8.8.8;
dns-search=home.arpa;
ignore-auto-dns=true #I tried with this on, commented out and set to false
may-fail=false
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns=2001:4860:4860::,2001:4860:4860::8844;
dns-search=home.arpa;
ignore-auto-dns=true #I tried with this on, commented out and set to false
may-fail=false
method=auto

sudo less /etc/resolv.conf
domain home.arpa
search home.arpa
nameserver 8.8.8.8
nameserver 8.8.4.4

For some reason I am not getting any IPv6 Name Servers populated.

Any thoughts are appreciated.

Tim



Why not use NetworkManagers internal DHCP client.

That is what I have done and then I don't need dhclient or dhcpcd.

I am not sure that you are really using dhclient as NetworkManager has 
not been set to use dhclient from the configuration that you have posted.


What is the output from:

NetworkManager --print-config

Notice in the following dhcp=internal in my configuration

NetworkManager --print-config
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf 
(lib: no-mac-addr-change.conf)


[main]
# rc-manager=
# auth-polkit=true
# dhcp=internal
# iwd-config-path=
plugins=ifupdown,keyfile
configure-and-quit=no

[global-dns]
options=ends0 trust-ad

[ifupdown]
managed=false

[logging]
# backend=journal
# audit=true

[device]
# wifi.backend=wpa_supplicant
wifi.scan-rand-mac-address=no

[device-31-mac-addr-change]
match-device=driver:eagle_sdio,driver:wl
wifi.scan-rand-mac-address=no

# no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"--

--

It's not easy to be me

Re: Populating IPv6 DNS addresses in resolv.conf

[Marco M.]

Am 30.10.2023 um 22:08:46 Uhr schrieb Max Nikulin:

> On 30/10/2023 20:04, Timothy M Butterworth wrote:
> > sudo less /etc/resolv.conf
> > domain home.arpa
> > search home.arpa
> > nameserver 8.8.8.8
> > nameserver 8.8.4.4  
> 
> I do not see "# Generated by NetworkManager" here.

That is because NM manages the file. Some users use other managers
(resolvconf, systemd-resolve) or create the file manually.
The content of the file is relevant, which software created it is
secondary.

Re: Populating IPv6 DNS addresses in resolv.conf

[Max Nikulin]

On 30/10/2023 20:04, Timothy M Butterworth wrote:

sudo less /etc/resolv.conf
domain home.arpa
search home.arpa
nameserver 8.8.8.8
nameserver 8.8.4.4


I do not see "# Generated by NetworkManager" here.

nmcli connection
nmcli device
NetworkManager --print-config
ls -l /etc/resolv.conf
lsattr /etc/resolv.conf

As to /etc/dhcp/dhclient.conf and /etc/network/interfaces, I may be 
wrong, but perhaps independent instances for IPv4 and IPv6 may be 
running (if actual connection is managed through ifupdown)

Populating IPv6 DNS addresses in resolv.conf

[Timothy M Butterworth]

Hello All,

I have been following the recent emails regarding resolv.conf. I almost
have my system running perfectly. The only thing I am missing is the
population of IPv6 DNS addresses.

sudo less /etc/dhcp/dhclient.conf
supersede domain-name "home.arpa";
supersede dhcp6.domain-search "home.arpa";
supersede dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;
supersede domain-name-servers 8.8.8.8, 8.8.4.4;

sudo less /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[global-dns]
searches=home.arpa

sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection

[ipv4]
dns=8.8.4.4,8.8.8.8;
dns-search=home.arpa;
ignore-auto-dns=true #I tried with this on, commented out and set to false
may-fail=false
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns=2001:4860:4860::,2001:4860:4860::8844;
dns-search=home.arpa;
ignore-auto-dns=true #I tried with this on, commented out and set to false
may-fail=false
method=auto

sudo less /etc/resolv.conf
domain home.arpa
search home.arpa
nameserver 8.8.8.8
nameserver 8.8.4.4

For some reason I am not getting any IPv6 Name Servers populated.

Any thoughts are appreciated.

Tim


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Making resolv.conf immutable [was: Bookworm: NetworkManager]

[tomas]

On Sat, Oct 21, 2023 at 01:08:58PM -0400, Pocket wrote:
> 
> On 10/21/23 12:49, Greg Wooledge wrote:
> > On Sat, Oct 21, 2023 at 12:23:45PM -0400, Pocket wrote:
> > > I want NetworkManager to not over write /etc/resolv.conf
> > https://wiki.debian.org/resolv.conf
> > 
> openresolv or resolvconf is not installed
> 
> no dhcp client is running only networkmanager is installed/running
> 
> making /etc/resolv.conf immutable is not the answer

Sigh. Since I have been one of those proposing this for some
time, i feel somewhat responsible for that meme having escaped
the lab. So let me state this:

  I never proposed making resolv.conf immutable as a
  "solution". I always knew and said that this is going
  to bite the sysadmin in the rear two years down the
  street.

  What I have proposed it for is as a debugging tool:
  make it immutable and watch the logs to see who complains.
  If found, configure the culprit to your taste. If not,
  look for another debugging approach.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: /etc/resolv.conf changes every booting time

[songbird]

gene heskett wrote:
...
> I load up a file I want to 3d print in cura, slice it into gcode, click 
> on save to disk. kde gets in the way so it opens a tab on the toolbar at 
> the bottom of the screen and to continue I have to click on that tab. 
> 20% of the time the where do you want to save it requester pops up 
> instantly but 80% of the time the whole workspace freezes for 2 minutes. 
> Eventually the save requester pops up and life goes on at normal speeds 
> I have the thought that both occurrences are different exhibits of the 
> same access problem. But thats just a WAG. The commonality is both apps 
> are AppImages, and my /home is a raid.  Is there a connection? w/o logs, 
> how can I tell.  There are no "user" logs.

  as i may have said before.  whatever you have going on
with file saving and file system access may be getting
stomped all over by whatever settings you have in the KDE
desktop or the particular application.  so one thing i
would do for sure is make sure that the KDE desktop file
extension associations that may be turned on to do anything
automatically are turned off (until you resolve where the
issue actually resides).

  once you have the KDE desktop stuff turned off then you
can at least know it isn't that which is mucking you up.

  from there is it some other thing?  well, if it now 
works then you've solved it, and if it hasn't been solved
then you've at least eliminated one variable.

  from there if it still does not work then you are up 
against any automatic automounter crap (which i find a
PITA so i remove it or find ways to turn it off which
then gets through another layer of possible variables).

  after that you should be down to the applcation and
what settings it has for dealing with file and accesses
and again i turn off all automatic stuff i can there to
make sure exactly what i'm trying to do can get done with
minimal interference.

  since you have network stuff going on which i hardly
ever do and i also don't do bluethooth, samba, ssh, rpc 
(or plenty of other things) well then you're going to
have to wade through those things and see what each may 
let you do to narrow down where the issue is at.

  when you have a complicated system it may be well 
worth it to set up a blank slate new machine and put in
each layer and test it before adding the next to see
which step is going kerblooey.  if i'm running a 
production system this is a natural and common 
procedure for any upgrade and debugging.  gotta have a
way to do tests that doesn't shut down production.


  songbird

Re: /etc/resolv.conf changes every booting time

[songbird]

Eduardo M KALINOWSKI wrote:
...
> He just told you to not hijack threads, and there you go and your 
> immediate reply is to start talking about something completely unrelated 
> to the rest of the discussion.

  oops, sorry, i just replied again.


  songbird

Re: /etc/resolv.conf changes every booting time

[Eduardo M KALINOWSKI]

On 07/08/2023 23:45, gene heskett wrote:

On 8/7/23 21:47, Greg Wooledge wrote:

Start a new thread, and treat the problem seriously.  Show us the
commands you're running and their output.  Show us the relevant
parts of your configuration.

That particular problem has been solved, Greg, and 60 days later there's 
no way I can recreate all that.


There is at my age some considerable truth in the remark that I can't 
remember what I had for breakfast or if I even had any.  It might be 
funny to the younger folks here, until they can't recall it either...



Don't just tack it onto a different thread and make vague statements.
That won't solve anything.


Go back and look at me vs digikam. 

> [snip]

He just told you to not hijack threads, and there you go and your 
immediate reply is to start talking about something completely unrelated 
to the rest of the discussion.


--
If little else, the brain is an educational toy.
-- Tom Robbins

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: /etc/resolv.conf changes every booting time

[gene heskett]

On 8/7/23 21:47, Greg Wooledge wrote:

On Mon, Aug 07, 2023 at 09:03:47PM -0400, gene heskett wrote:

And I'm back
to hunting for the reason I can ping yahoo.com but not other machines on my
local net, that are fully identified in my hosts file or vice versa


Start a new thread, and treat the problem seriously.  Show us the
commands you're running and their output.  Show us the relevant
parts of your configuration.

That particular problem has been solved, Greg, and 60 days later there's 
no way I can recreate all that.


There is at my age some considerable truth in the remark that I can't 
remember what I had for breakfast or if I even had any.  It might be 
funny to the younger folks here, until they can't recall it either...



Don't just tack it onto a different thread and make vague statements.
That won't solve anything.


Go back and look at me vs digikam. No help here, no help there. All the 
clues and they are scant at best, the database can make its index files 
just fine which are on my raid, Digikam  can see every pix I've ever 
stored there, it can see every pix on the card in the camera, but when I 
ask it to download a pix from the camera, a jpg file, it winds up saying 
at the end without logging an error anyplace I've found, but claims the 
target directory selected to save the pix to, does not exist, when I can 
see it and its contents just fine in the other digikam window.


I load up a file I want to 3d print in cura, slice it into gcode, click 
on save to disk. kde gets in the way so it opens a tab on the toolbar at 
the bottom of the screen and to continue I have to click on that tab. 
20% of the time the where do you want to save it requester pops up 
instantly but 80% of the time the whole workspace freezes for 2 minutes. 
Eventually the save requester pops up and life goes on at normal speeds 
I have the thought that both occurrences are different exhibits of the 
same access problem. But thats just a WAG. The commonality is both apps 
are AppImages, and my /home is a raid.  Is there a connection? w/o logs, 
how can I tell.  There are no "user" logs.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: /etc/resolv.conf changes every booting time

[Greg Wooledge]

On Mon, Aug 07, 2023 at 09:03:47PM -0400, gene heskett wrote:
> And I'm back
> to hunting for the reason I can ping yahoo.com but not other machines on my
> local net, that are fully identified in my hosts file or vice versa

Start a new thread, and treat the problem seriously.  Show us the
commands you're running and their output.  Show us the relevant
parts of your configuration.

Don't just tack it onto a different thread and make vague statements.
That won't solve anything.

Re: /etc/resolv.conf changes every booting time

[gene heskett]

On 8/7/23 18:43, Brian wrote:

On Mon 07 Aug 2023 at 17:53:41 -0400, gene heskett wrote:


On 8/7/23 14:57, Brian wrote:

On Sun 06 Aug 2023 at 20:50:26 -0400, gene heskett wrote:

[...]


Sorry you are so offended by a hosts file user Andy, but when the guys


Did someone mention a hosts file? Is this an attempt to move discussion on
to a different toic? I thought 'chattr -i' and the wisdom of using it was
under discussion.


Its all related to networking.


A pathetic response.
  

My experience is that 'chattr -i' cripples the ability of my laptop to roam
on other networks.


I do not own a lappy.  The last one I had, an hp I paid about $1500 for, was
so poorly supported that when I went out someplace as a consulting engineer,
had to borrow a modem from the motel just to talk to their wifi about 50% of
the time. The rest of the time the wifi needed a reboot. Even windows xp
could not make the broadcom radio in it work. Its battery was as problematic
as the windows it came with, and when it died I tossed it. My expertise as a
broadcast consultant went out of date when the US went digital in mid-2008.
Now I just keep our local Ma and Pa daytimer on the air. I also don't have a
hell phone.


Even more pathetic. Taking one word (laptop) and making it central is typical
of your style of response. All me, me, me.

I don't recall being the 1st user of the word "laptop", what I am trying 
to prove is that linux is not windows, its far more versatile if you'll 
let it be, and that different people have different environments, I've 
been made to understand that resolv.conf is now not the place to put 
search order, that has now been moved to nssconfig.


There was once a stanza at the end of dhcpd.conf where one could setup 
his network by filling in the blanks and removing the # comments. If all 
else failed, that worked, But that was too easy so it was removed. And 
I'm back to hunting for the reason I can ping yahoo.com but not other 
machines on my local net, that are fully identified in my hosts file or 
vice versa. I've had it both ways in the last 3 major releases.


Consistency Brian, is what works best over the long haul for those to 
whom a computer is a tool to get a job done, not a plaything, and there 
does not seem to be any consistency.


Take care & stay well Brian.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: /etc/resolv.conf changes every booting time

[Brian]

On Mon 07 Aug 2023 at 17:53:41 -0400, gene heskett wrote:

> On 8/7/23 14:57, Brian wrote:
> > On Sun 06 Aug 2023 at 20:50:26 -0400, gene heskett wrote:
> > 
> > [...]
> > 
> > > Sorry you are so offended by a hosts file user Andy, but when the guys
> > 
> > Did someone mention a hosts file? Is this an attempt to move discussion on
> > to a different toic? I thought 'chattr -i' and the wisdom of using it was
> > under discussion.
> > 
> Its all related to networking.

A pathetic response.
 
> > My experience is that 'chattr -i' cripples the ability of my laptop to roam
> > on other networks.
> > 
> I do not own a lappy.  The last one I had, an hp I paid about $1500 for, was
> so poorly supported that when I went out someplace as a consulting engineer,
> had to borrow a modem from the motel just to talk to their wifi about 50% of
> the time. The rest of the time the wifi needed a reboot. Even windows xp
> could not make the broadcom radio in it work. Its battery was as problematic
> as the windows it came with, and when it died I tossed it. My expertise as a
> broadcast consultant went out of date when the US went digital in mid-2008.
> Now I just keep our local Ma and Pa daytimer on the air. I also don't have a
> hell phone.

Even more pathetic. Taking one word (laptop) and making it central is typical
of your style of response. All me, me, me.

-- 
Brian.

Re: /etc/resolv.conf changes every booting time

[gene heskett]

On 8/7/23 14:57, Brian wrote:

On Sun 06 Aug 2023 at 20:50:26 -0400, gene heskett wrote:

[...]


Sorry you are so offended by a hosts file user Andy, but when the guys


Did someone mention a hosts file? Is this an attempt to move discussion on
to a different toic? I thought 'chattr -i' and the wisdom of using it was
under discussion.


Its all related to networking.


My experience is that 'chattr -i' cripples the ability of my laptop to roam
on other networks.

I do not own a lappy.  The last one I had, an hp I paid about $1500 for, 
was so poorly supported that when I went out someplace as a consulting 
engineer, had to borrow a modem from the motel just to talk to their 
wifi about 50% of the time. The rest of the time the wifi needed a 
reboot. Even windows xp could not make the broadcom radio in it work. 
Its battery was as problematic as the windows it came with, and when it 
died I tossed it. My expertise as a broadcast consultant went out of 
date when the US went digital in mid-2008.   Now I just keep our local 
Ma and Pa daytimer on the air. I also don't have a hell phone.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: /etc/resolv.conf changes every booting time

[Andy Smith]

Hi Brian,

On Mon, Aug 07, 2023 at 07:57:07PM +0100, Brian wrote:
> On Sun 06 Aug 2023 at 20:50:26 -0400, gene heskett wrote:
> > Sorry you are so offended by a hosts file user Andy, but when the guys
> 
> Did someone mention a hosts file?

If I understand correctly, Gene identifies himself as "a hosts file
user" and one of his major delusions is that there is some
conspiracy within the Debian-like world to make the life of people
who make use of /etc/hosts very hard. One of the ways, in this
delusion, that it is made hard is by "forcing everyone to use a DHCP
server", which also leads to Gene's resolv.conf being modified,
which Gene does not like and uses the immutable file approach to
prevent.

I think since I have criticised the immutable resolv.conf "solution",
Gene has decided I must be part of this wide-ranging conspiracy and
so I must be offended that he *also* uses hosts files. That is, he's
saying I am offended by "a hosts file user", i.e. him and by
extension what he does, not offended by "a hosts file". It did take
me some effort to parse.

That is my best guess at how this particular one of Gene's bizarre
rants even tangentially connects with reality as I know it, anyway.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: /etc/resolv.conf changes every booting time

[Brian]

On Sun 06 Aug 2023 at 20:50:26 -0400, gene heskett wrote:

[...]

> Sorry you are so offended by a hosts file user Andy, but when the guys

Did someone mention a hosts file? Is this an attempt to move discussion on
to a different toic? I thought 'chattr -i' and the wisdom of using it was
under discussion.

My experience is that 'chattr -i' cripples the ability of my laptop to roam
on other networks.

-- 
Brian.

Re: /etc/resolv.conf changes every booting time

[tomas]

On Sun, Aug 06, 2023 at 08:50:26PM -0400, gene heskett wrote:

> Sorry you are so offended by a hosts file user Andy [...]

Now this is stuff for Quote of the Day ;-)

Thank you, Gene.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: /etc/resolv.conf changes every booting time

[gene heskett]

On 8/6/23 12:09, Andy Smith wrote:

Hello,

On Sun, Aug 06, 2023 at 07:37:35PM +0800, Jon Smart wrote:

Timothy M Butterworth wrote:
The file /etc.resolv.conf is just a soft link.

You need to:

1: Delete /etc/resolv.conf - rm /etc/resolv.conf
2: Create a new /etc/resolv.conf file: touch /etc/resolv.conf
3: Configure you nameservers
4: Make the file immutable: chattr +i /etc/resolv.conf


These 4 steps do work great!
Thanks a lot.


And so another one fails to spend the time to work out how their
operating system works for trivial minutiae like "how my network
gets set up", leaving a nice rake in the grass for some point in the
future when they are trying to debug something else. 

And we wonder why this list ends up dealing with the aftermath of
the Gene school of "don't understand it? Hit it with chattr +i / rm
/ apt-get purge!" so often.

Regards,
Andy

Sorry you are so offended by a hosts file user Andy, but when the guys 
decide to do networking differently, usually in the badly mistaken idea 
that everybody runs a dhcpd server even for their isolated local 
network, and don't check that their brainless changes don't screw up a 
host file based local network, or worse, don't care if it does, then you 
should expect that we WILL do what WE KNOW JUST WORKS.  Blaming me in 
that case is just plain poor form.  If there indeed IS a better way to 
deal with this in a hosts file system, then teach us /how/ WITHOUT 
ASSUMING we'll just run a dhcpd server with all the configuration sand 
maintenance bs that entails. Tain't gonna happen.


We hide our local stuff behind something like dd-wrt and its ilk for a 
reason.  As a guard dog, its an 800 lb pit bull with a very bad attitude.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: /etc/resolv.conf changes every booting time

[Jon Smart]

> On Sun, Aug 06, 2023 at 05:17:23PM +0800, Jon Smart wrote:
>> It's a VPS provided by a local ISP. The VPS has a static IPv4.
>> Do you know how to know if /etc/resolv.conf is modified by dhcp?
>
> The first thing you could do is check whether a DHCP client daemon
> is running.  That's usually a sign.
>
> Failing that, find out what your primary network interface's name is,
> and then find out how that network interface is brought up.  In a server
> configuration, it's *usually* brought up by a stanza in the
> /etc/network/interfaces file.  If that stanza consists of a line
> ending with "dhcp", then voila.
>
> If the primary network interface is not configured in /e/n/i then the
> second most likely configuration is NetworkManager.  Usually if NM
> is in the picture, /etc/resolv.conf will be a symlink, and you will
> see evidence of NM both in the symlink's target, and in the contents
> of the file.  Thus,
>
> ls -ld /etc/resolv.conf
> cat /etc/resolv.conf
>
> Both of these should give you hints, if NM is involved.
>
>

Yes my system is exactly using NM for networking. so resolv.conf is just a
symlink. I delete that symlink and create a real file, put content into it
(no chattr needed), and reboot the OS everything works fine now.

regards.

Re: /etc/resolv.conf changes every booting time

[tomas]

On Sun, Aug 06, 2023 at 04:09:14PM +, Andy Smith wrote:

[...]

> And we wonder why this list ends up dealing with the aftermath of
> the Gene school of "don't understand it? Hit it with chattr +i / rm
> / apt-get purge!" so often.

I must admit that I was one of those proposing chattr +i in this
context (it feels like half to one decade ago). To my defense, I
said then (and repeat now) that I don't recommend it as a permanent
fix, rather as a debugging tool. The next step would be to go to
the logs and see which software is complaining. Then you know which
man pages to hit :-)

Leaving "chattr +i" behind in /etc at random spots will come back
to shoot you painfully in the foot (e.g. at the next system upgrade,
when you'll have forgotten about it).

If the sysadmin is me, I'll just leave it for as long as the single
debugging session lasts.

Then you'll [1] come here, whining ;-)

Cheers

[1] No, not you, Andy. This was more the generic "you" :-)

-- 
tomás


signature.asc
Description: PGP signature

Re: /etc/resolv.conf changes every booting time

[Andy Smith]

Hi Greg,

On Sun, Aug 06, 2023 at 08:48:25AM -0400, Greg Wooledge wrote:
> On Sun, Aug 06, 2023 at 07:37:35PM +0800, Jon Smart wrote:
> > These 4 steps do work great!
> > Thanks a lot.
> 
> These same steps are also on the wiki page that's been discussed many
> times in this thread.  You might want to read what the wiki has to
> say about it, especially about /etc filling up with temporary files.
> 
> They're also the same steps that someone else in this thread has
> criticized.  Again.  As you can see, some people simply *despise* this,
> despite how simple and effective it is.

So you honestly do not see a problem with how this has played out,
despite your tone in the preceding paragraph where you seem
exasperated that Jon has not taken the time to understand the
problem or read any of the documentation or basically do anything
that involves effort on their part?

I'm surprised I need to clarify this, but I'm not disappointed
because Jon chose to make a file immutable, I'm disappointed because
Jon leapt at the option that involved pasting some commands in
without understanding them or what is actually going on with their
machine. And not purely because I think Jon ought to understand
these things as some pure ideal state of being, but objectively
because when Jon hits any sort of networking problem in future, Jon
will STILL have no idea how their network is actually set up. Which
is astonishing for someone wanting to run a server. And this
attitude will be applied to other parts of the system. And this list
will see Jon or someone like them again very soon and be asked to
unpick this behaviour.

Here I think chattr +i is a useful tool that should be used to reach
a state of understanding if necessary, not an actual fix. I agree
that it belongs at the bottom of documentation and couched with
caveats, not handed out as a "just do this". That's very sad to see.
And even sadder to see promoted as the "solution".

Cheers,
Andy
> 

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: /etc/resolv.conf changes every booting time

[Andy Smith]

Hello,

On Sun, Aug 06, 2023 at 07:37:35PM +0800, Jon Smart wrote:
> > Timothy M Butterworth wrote:
> > The file /etc.resolv.conf is just a soft link.
> >
> > You need to:
> >
> > 1: Delete /etc/resolv.conf - rm /etc/resolv.conf
> > 2: Create a new /etc/resolv.conf file: touch /etc/resolv.conf
> > 3: Configure you nameservers
> > 4: Make the file immutable: chattr +i /etc/resolv.conf
> 
> These 4 steps do work great!
> Thanks a lot.

And so another one fails to spend the time to work out how their
operating system works for trivial minutiae like "how my network
gets set up", leaving a nice rake in the grass for some point in the
future when they are trying to debug something else. 

And we wonder why this list ends up dealing with the aftermath of
the Gene school of "don't understand it? Hit it with chattr +i / rm
/ apt-get purge!" so often.

Regards,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: /etc/resolv.conf changes every booting time

[tomas]

On Sun, Aug 06, 2023 at 07:06:01AM -0400, Timothy M Butterworth wrote:
> On Sun, Aug 6, 2023 at 6:13 AM Jon Smart  wrote:
> 
> > It's a VPS provided by a local ISP. The VPS has a static IPv4.
> > Do you know how to know if /etc/resolv.conf is modified by dhcp?
> >
> > Thanks.
> >
> >
> > >
> > > Hi Jon,
> > >
> > >> I have removed the default systemd-resolved local dns service following
> > >> the link below,
> > >>
> > >>
> > https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu
> > >>
> > >> And I have unbound installed and enabled as local DNS server.
> > >>
> > >> But every time I reboot the server, the configuration file
> > >> /etc/resolv.conf changes to a default one. So every time I have to
> > >> update
> > >> its content to:
> > >>
> > >> nameserver 127.0.0.1
> >
> The file /etc.resolv.conf is just a soft link.

Not always, so please make sure it is /before/ you follow the
steps below.

> You need to:
> 
> 1: Delete /etc/resolv.conf - rm /etc/resolv.conf
> 2: Create a new /etc/resolv.conf file: touch /etc/resolv.conf
> 3: Configure you nameservers
> 4: Make the file immutable: chattr +i /etc/resolv.conf

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: /etc/resolv.conf changes every booting time

[Greg Wooledge]

On Sun, Aug 06, 2023 at 05:17:23PM +0800, Jon Smart wrote:
> It's a VPS provided by a local ISP. The VPS has a static IPv4.
> Do you know how to know if /etc/resolv.conf is modified by dhcp?

The first thing you could do is check whether a DHCP client daemon
is running.  That's usually a sign.

Failing that, find out what your primary network interface's name is,
and then find out how that network interface is brought up.  In a server
configuration, it's *usually* brought up by a stanza in the
/etc/network/interfaces file.  If that stanza consists of a line
ending with "dhcp", then voila.

If the primary network interface is not configured in /e/n/i then the
second most likely configuration is NetworkManager.  Usually if NM
is in the picture, /etc/resolv.conf will be a symlink, and you will
see evidence of NM both in the symlink's target, and in the contents
of the file.  Thus,

ls -ld /etc/resolv.conf
cat /etc/resolv.conf

Both of these should give you hints, if NM is involved.

Re: /etc/resolv.conf changes every booting time

[Greg Wooledge]

On Sun, Aug 06, 2023 at 07:37:35PM +0800, Jon Smart wrote:
> Unattributed:
> > The file /etc.resolv.conf is just a soft link.

Not always.

> > You need to:
> >
> > 1: Delete /etc/resolv.conf - rm /etc/resolv.conf
> > 2: Create a new /etc/resolv.conf file: touch /etc/resolv.conf
> > 3: Configure you nameservers
> > 4: Make the file immutable: chattr +i /etc/resolv.conf
> >
> 
> These 4 steps do work great!
> Thanks a lot.

These same steps are also on the wiki page that's been discussed many
times in this thread.  You might want to read what the wiki has to
say about it, especially about /etc filling up with temporary files.

They're also the same steps that someone else in this thread has
criticized.  Again.  As you can see, some people simply *despise* this,
despite how simple and effective it is.

Re: /etc/resolv.conf changes every booting time

[Eduardo M KALINOWSKI]

On 06/08/2023 00:26, Greg Wooledge wrote:

I'm also forced to relegate the chattr solution to the end of the page,
and couch it in caveats, because some people think that it's wrong.
They can't say WHY it's wrong, of course.  Maybe because it's too simple
and effective.  I dunno.


How about the fact that it just solves the symptom but not the real problem?

/etc/resolv.conf does not change by itself, some tool must be making the 
(possibly undesired) changes, so in most cases, I'd say it's better to 
configure that tool to stop changing resolv.conf, or to add the 
nameservers you want instead of whatever the tool auto discovers. Or 
perhaps you don't even need that tool (in a server with static IP, for 
example).


I'm not saying that chattr +i should never be used, but it should be the 
last resort, and the user should know what they're doing and possible 
consequences.



--
The idle man does not know what it is to enjoy rest.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: /etc/resolv.conf changes every booting time

[Jon Smart]

> On Sun, Aug 6, 2023 at 6:13 AM Jon Smart  wrote:
>
>> It's a VPS provided by a local ISP. The VPS has a static IPv4.
>> Do you know how to know if /etc/resolv.conf is modified by dhcp?
>>
>> Thanks.
>>
>>
>> >
>> > Hi Jon,
>> >
>> >> I have removed the default systemd-resolved local dns service
>> following
>> >> the link below,
>> >>
>> >>
>> https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu
>> >>
>> >> And I have unbound installed and enabled as local DNS server.
>> >>
>> >> But every time I reboot the server, the configuration file
>> >> /etc/resolv.conf changes to a default one. So every time I have to
>> >> update
>> >> its content to:
>> >>
>> >> nameserver 127.0.0.1
>>
> The file /etc.resolv.conf is just a soft link.
>
> You need to:
>
> 1: Delete /etc/resolv.conf - rm /etc/resolv.conf
> 2: Create a new /etc/resolv.conf file: touch /etc/resolv.conf
> 3: Configure you nameservers
> 4: Make the file immutable: chattr +i /etc/resolv.conf
>

These 4 steps do work great!
Thanks a lot.

regards.

Re: /etc/resolv.conf changes every booting time

[Timothy M Butterworth]

On Sun, Aug 6, 2023 at 6:13 AM Jon Smart  wrote:

> It's a VPS provided by a local ISP. The VPS has a static IPv4.
> Do you know how to know if /etc/resolv.conf is modified by dhcp?
>
> Thanks.
>
>
> >
> > Hi Jon,
> >
> >> I have removed the default systemd-resolved local dns service following
> >> the link below,
> >>
> >>
> https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu
> >>
> >> And I have unbound installed and enabled as local DNS server.
> >>
> >> But every time I reboot the server, the configuration file
> >> /etc/resolv.conf changes to a default one. So every time I have to
> >> update
> >> its content to:
> >>
> >> nameserver 127.0.0.1
>
The file /etc.resolv.conf is just a soft link.

You need to:

1: Delete /etc/resolv.conf - rm /etc/resolv.conf
2: Create a new /etc/resolv.conf file: touch /etc/resolv.conf
3: Configure you nameservers
4: Make the file immutable: chattr +i /etc/resolv.conf


> >>
> >> (points to unbound)
> >>
> >> How to stop the auto-changes to /etc/resolv.conf after rebooting?
> >
> > In case you get the configuration overwritten by DHCP you can avoid that
> > by the following lines in /etc/dhcp/dhclient.conf.
> >
> > interface "bond0" {
> > supersede domain-name-servers 127.0.0.1;
> > }
> >
> > Just replace the interface name with yours.
> >
> > Kind regards,
> > Christoph
> > --
> > Ist die Katze gesund
> > schmeckt sie dem Hund.
> >
>
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀c

Re: /etc/resolv.conf changes every booting time

[Christoph Brinkhaus]

Am Sun, Aug 06, 2023 at 05:17:23PM +0800 schrieb Jon Smart:
Hi Jon,
> It's a VPS provided by a local ISP. The VPS has a static IPv4.
> Do you know how to know if /etc/resolv.conf is modified by dhcp?
> 
I am not sure about the details. But with DHCP a bunch of network
configuration items can be send from the server to the client. The
nameserver configuration is one of the items.

Kind regards,
Christoph
> 
> >
> > Hi Jon,
> >
> >> I have removed the default systemd-resolved local dns service following
> >> the link below,
> >>
> >> https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu
> >>
> >> And I have unbound installed and enabled as local DNS server.
> >>
> >> But every time I reboot the server, the configuration file
> >> /etc/resolv.conf changes to a default one. So every time I have to
> >> update
> >> its content to:
> >>
> >> nameserver 127.0.0.1
> >>
> >> (points to unbound)
> >>
> >> How to stop the auto-changes to /etc/resolv.conf after rebooting?
> >
> > In case you get the configuration overwritten by DHCP you can avoid that
> > by the following lines in /etc/dhcp/dhclient.conf.
> >
> > interface "bond0" {
> > supersede domain-name-servers 127.0.0.1;
> > }
> >
> > Just replace the interface name with yours.
> >
> > Kind regards,
> > Christoph
> > --
> > Ist die Katze gesund
> > schmeckt sie dem Hund.
> >
> 
> 

-- 
Ist die Katze gesund
schmeckt sie dem Hund.


signature.asc
Description: PGP signature

Re: /etc/resolv.conf changes every booting time

[Jon Smart]

It's a VPS provided by a local ISP. The VPS has a static IPv4.
Do you know how to know if /etc/resolv.conf is modified by dhcp?

Thanks.


>
> Hi Jon,
>
>> I have removed the default systemd-resolved local dns service following
>> the link below,
>>
>> https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu
>>
>> And I have unbound installed and enabled as local DNS server.
>>
>> But every time I reboot the server, the configuration file
>> /etc/resolv.conf changes to a default one. So every time I have to
>> update
>> its content to:
>>
>> nameserver 127.0.0.1
>>
>> (points to unbound)
>>
>> How to stop the auto-changes to /etc/resolv.conf after rebooting?
>
> In case you get the configuration overwritten by DHCP you can avoid that
> by the following lines in /etc/dhcp/dhclient.conf.
>
> interface "bond0" {
> supersede domain-name-servers 127.0.0.1;
> }
>
> Just replace the interface name with yours.
>
> Kind regards,
> Christoph
> --
> Ist die Katze gesund
> schmeckt sie dem Hund.
>

Re: /etc/resolv.conf changes every booting time

[Christoph Brinkhaus]

Am Sun, Aug 06, 2023 at 09:28:55AM +0800 schrieb Jon Smart:

Hi Jon,

> I have removed the default systemd-resolved local dns service following
> the link below,
> 
> https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu
> 
> And I have unbound installed and enabled as local DNS server.
> 
> But every time I reboot the server, the configuration file
> /etc/resolv.conf changes to a default one. So every time I have to update
> its content to:
> 
> nameserver 127.0.0.1
> 
> (points to unbound)
> 
> How to stop the auto-changes to /etc/resolv.conf after rebooting?

In case you get the configuration overwritten by DHCP you can avoid that
by the following lines in /etc/dhcp/dhclient.conf.

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

Just replace the interface name with yours.

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


signature.asc
Description: PGP signature

Re: /etc/resolv.conf changes every booting time

[Greg Wooledge]

On Sat, Aug 05, 2023 at 10:52:35PM -0500, Nicholas Geovanis wrote:
> On Sat, Aug 5, 2023, 10:27 PM Greg Wooledge  wrote:
> 
> > On Sat, Aug 05, 2023 at 10:05:31PM -0500, Nicholas Geovanis wrote:
> > > On Sat, Aug 5, 2023, 9:13 PM Greg Wooledge  wrote:
> > >
> > > > On Sun, Aug 06, 2023 at 09:28:55AM +0800, Jon Smart wrote:
> > > > > How to stop the auto-changes to /etc/resolv.conf after rebooting?
> > > >
> > > > https://wiki.debian.org/resolv.conf
> > > >
> > >
> > > Contrary to what that page states, auto changes to resolv.conf are never
> > > appropriate in the server environment. The statement there that it works
> > > fine in a "properly configured server" is the boilerplate escape hatch
> > for
> > > that inconvenient fact :-)
> >
> > Those words do not appear on that page.  I don't know which sentence(s)
> > you're actually referring to.
> 
> 
> I'm referring to these exact words:
> "It also works well for many desktop and server systems, so long as the
> network infrastructure is perfect."
> 
> Its a red herring because the DNS infrastructure in a data center is static
> at the IP address and host name level. And I feel certain that any network
> infrastructure constructed by humans is imperfect to some degree.
> There's their escape hatch.

Not all Debian systems are in a "data center".  Sometimes they're on a
home network, or a workplace network.  In both of those environments,
the DHCP server may be questionable -- either because it's being provided
by a cheap router (home), or because it's being managed by a different
department (workplace).

Some workplaces require the use of DHCP to configure network interfaces,
even when the DHCP server behaves in a way you do not wish.  For example,
it may offer DNS nameservers that are not the ones you want to use.  So,
many of us are running Debian systems where the IP address has to come
from DHCP, for political reasons, but the DNS servers that would come
from DHCP are *undesired*.

Therefore, we want to edit /etc/resolv.conf ourselves, and not let the
DHCP client daemon, or any other program, change it.

Therefore, this wiki page.

Do you have a specific wording change you'd like to see?

Is there any part of the page that is actually *incorrect*?

Are there any alternative solutions that are *missing*?

Re: /etc/resolv.conf changes every booting time

[Nicholas Geovanis]

On Sat, Aug 5, 2023, 10:27 PM Greg Wooledge  wrote:

> On Sat, Aug 05, 2023 at 10:05:31PM -0500, Nicholas Geovanis wrote:
> > On Sat, Aug 5, 2023, 9:13 PM Greg Wooledge  wrote:
> >
> > > On Sun, Aug 06, 2023 at 09:28:55AM +0800, Jon Smart wrote:
> > > > How to stop the auto-changes to /etc/resolv.conf after rebooting?
> > >
> > > https://wiki.debian.org/resolv.conf
> > >
> >
> > Contrary to what that page states, auto changes to resolv.conf are never
> > appropriate in the server environment. The statement there that it works
> > fine in a "properly configured server" is the boilerplate escape hatch
> for
> > that inconvenient fact :-)
>
> Those words do not appear on that page.  I don't know which sentence(s)
> you're actually referring to.


I'm referring to these exact words:
"It also works well for many desktop and server systems, so long as the
network infrastructure is perfect."

Its a red herring because the DNS infrastructure in a data center is static
at the IP address and host name level. And I feel certain that any network
infrastructure constructed by humans is imperfect to some degree.
There's their escape hatch.

The closest thing I see there is "so
> long as the network infrastructure is perfect", which refers to the DHCP
> server, not the Debian system.
>
> A lot of us run Debian systems on networks where we DO NOT CONTROL the
> DHCP server, and have to work around it.  That's what the introduction
> of the page is talking about.
>
> In any case, appeasing EVERY reader is impossible.  I have to use vague
> wording to try to make sure nobody is offended that their personal
> preference configuration is not snubbed.  No matter how utterly batshit
> insane such a configuration may be from my point of view.
>
> I'm also forced to relegate the chattr solution to the end of the page,
> and couch it in caveats, because some people think that it's wrong.
> They can't say WHY it's wrong, of course.  Maybe because it's too simple
> and effective.  I dunno.
>
> People are horrible sometimes.
>
> With all that in mind, and considering that this is a WIKI and you may
> edit it your damned SELF if you disagree with the content, what is your
> actual disagreement?
>
>

Re: /etc/resolv.conf changes every booting time

[Greg Wooledge]

On Sat, Aug 05, 2023 at 10:05:31PM -0500, Nicholas Geovanis wrote:
> On Sat, Aug 5, 2023, 9:13 PM Greg Wooledge  wrote:
> 
> > On Sun, Aug 06, 2023 at 09:28:55AM +0800, Jon Smart wrote:
> > > How to stop the auto-changes to /etc/resolv.conf after rebooting?
> >
> > https://wiki.debian.org/resolv.conf
> >
> 
> Contrary to what that page states, auto changes to resolv.conf are never
> appropriate in the server environment. The statement there that it works
> fine in a "properly configured server" is the boilerplate escape hatch for
> that inconvenient fact :-)

Those words do not appear on that page.  I don't know which sentence(s)
you're actually referring to.  The closest thing I see there is "so
long as the network infrastructure is perfect", which refers to the DHCP
server, not the Debian system.

A lot of us run Debian systems on networks where we DO NOT CONTROL the
DHCP server, and have to work around it.  That's what the introduction
of the page is talking about.

In any case, appeasing EVERY reader is impossible.  I have to use vague
wording to try to make sure nobody is offended that their personal
preference configuration is not snubbed.  No matter how utterly batshit
insane such a configuration may be from my point of view.

I'm also forced to relegate the chattr solution to the end of the page,
and couch it in caveats, because some people think that it's wrong.
They can't say WHY it's wrong, of course.  Maybe because it's too simple
and effective.  I dunno.

People are horrible sometimes.

With all that in mind, and considering that this is a WIKI and you may
edit it your damned SELF if you disagree with the content, what is your
actual disagreement?

Re: /etc/resolv.conf changes every booting time

[Nicholas Geovanis]

On Sat, Aug 5, 2023, 9:13 PM Greg Wooledge  wrote:

> On Sun, Aug 06, 2023 at 09:28:55AM +0800, Jon Smart wrote:
> > How to stop the auto-changes to /etc/resolv.conf after rebooting?
>
> https://wiki.debian.org/resolv.conf
>

Contrary to what that page states, auto changes to resolv.conf are never
appropriate in the server environment. The statement there that it works
fine in a "properly configured server" is the boilerplate escape hatch for
that inconvenient fact :-)

Re: /etc/resolv.conf changes every booting time

[Greg Wooledge]

On Sun, Aug 06, 2023 at 09:28:55AM +0800, Jon Smart wrote:
> How to stop the auto-changes to /etc/resolv.conf after rebooting?

https://wiki.debian.org/resolv.conf

Re: /etc/resolv.conf changes every booting time

[jeremy ardley]

On 6/8/23 09:28, Jon Smart wrote:

Hello

I have removed the default systemd-resolved local dns service following
the link below,

https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu

And I have unbound installed and enabled as local DNS server.

But every time I reboot the server, the configuration file
/etc/resolv.conf changes to a default one. So every time I have to update
its content to:

nameserver 127.0.0.1

(points to unbound)

How to stop the auto-changes to /etc/resolv.conf after rebooting?

Thanks.



What is the new contents of /etc/resolv.conf?

If it mentions NetworkManager then that is the cause of your problems 
and you will have to follow web instructions to change NetworkManager 
behaviour.

/etc/resolv.conf changes every booting time

[Jon Smart]

Hello

I have removed the default systemd-resolved local dns service following
the link below,

https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu

And I have unbound installed and enabled as local DNS server.

But every time I reboot the server, the configuration file
/etc/resolv.conf changes to a default one. So every time I have to update
its content to:

nameserver 127.0.0.1

(points to unbound)

How to stop the auto-changes to /etc/resolv.conf after rebooting?

Thanks.

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]

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

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 <https://wiki.debian.org/resolv.conf>
to address that, and see if it fixes the problem.

The simplest one to test would be
<https://wiki.debian.org/resolv.conf#Configuring_dhclient>.  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.

<https://wiki.debian.org/resolv.conf> 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

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

[davenull]

Hello,

= 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/"


When I start openconnect, it usses some vpnc sript to write a porper, 
working, /etc/resolv.conf, with the right (work's) DNS resolver IP in 
it. And it works.
That worked flawlessly for months. But some months ago, probably after 
an upgrade or something (because I definitely didn't change anything), 
something started to screw up with /etc/resolv.conf.


So issue is not openconnect-related, at was just for the context. And to 
make it clear that totally disabling DHCP and writing the whole network 
config manually is not reasonably doable in my context. Because it's a 
laptop, sometime used with VPN, sometimes without it (even from home, 
occasionally, like during training on which I need to access external 
VMs that are not withelisted workplace's firewalls) so network context 
varies sometimes.

= end of context =

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.


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
- Such requests which varies a lot and inst consistent, can be twice or 
tree time in 10 minutes or 3-5 times during one afternoon…). sometimes 
it happens the minute after I restart the VPN client to recreate a 
working resolv.conf file, sometimes it leaves the file alone for 15, 
minutes or even 2-3 hours…
- I never configured anything that to do repetitive/time-random DHCP 
requests. Except of course the initial DHCP request the system is first 
started and connected in the morning when I satrt my work day, wich is 
configurerd by default when you install debian for desktop/laptop/with 
DEs and network managers and all the fancy stuff.
- 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
Here's what tail -f audit.log | grep --color resolv.conf shown what it 
happens


--
type=PATH msg=audit(1677072201.558:572): item=3 name="/etc/resolv.conf" 
inode=786763 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 
nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 
cap_frootid=0OUID="root" OGID="root"
type=PATH msg=audit(1677072201.558:572): item=4 name="/etc/resolv.conf" 
inode=784351 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 
nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 
cap_frootid=0OUID="root" OGID="root"

--

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…


1. But didn't sniff network packets to confirma or infirm that, because 
I might wait for long time for it to happen, making extremely huge pcap 
files… Unless I know exactly what to filter out from input to have 
compact dumps… If it's not DHCP, aned I filter anything but DHCP, I'll 
end up with nothing. If I don't filter anything and it doesn't happen 
before 2 or 3 hours, it will take a shitload too much space form my home 
partition and would be PITA to use wireshark's search functions and 
display filters, and search for specific stuff, that w

Re: /etc/resolv.conf en Debian Bookworm

[Camaleón]

El 2022-04-28 a las 16:32 +, Guillermo Sosa escribió:

Este correo tampoco me ha llegado a la bandeja de entrada.
No veía los correos de Guillermo porque Gmail los marca como spam :-?

(...)

> El jueves, 28 de abril de 2022 a las 11:27, Camaleón  
> escribió:
> 
> 
> > El 2022-04-28 a las 10:24 +0200, fernando sainz escribió:
> >
> > > El mié, 27 abr 2022 a las 23:55, Guillermo Sosa (auxt...@protonmail.com)
> > > escribió:
> >
> >
> > No sé por qué pero este correo de Guillermo no me llegó (no está en
> > spam ni en la carpeta Todos de Gmail) :-?
> >
> > > > Buenas tardes aquí en Argentina.
> > > > Desde hace años, mas precisamente desde Stretch, construyo mi 
> > > > distribución
> > > > (con lb build) personalizada; hoy uso la "estable" Bullseye, pero ya 
> > > > estoy
> > > > experimentando con Bookworm. De hecho hace un mes mas o menos que estoy
> > > > probandola con escritorios Cinnamon, Mate y Xfce. Hasta 10 ó 12 días 
> > > > atrás
> > > > todas funcionaban perfecto, pero de repente, con cualquier DE, 
> > > > comenzaron a
> > > > tener problemas con /etc/resolv.conf tanto en live-system como 
> > > > instaladas a
> > > > disco. De hecho ese archivo, que en la jaula chroot se activa (ustedes 
> > > > lo
> > > > deben saber) con el comando; *cp /etc/resolv.conf 
> > > > chroot/etc/resolv.conf,
> > > > *o sea copiando el resolv.conf del sistema anfitrión al sistema en
> > > > construcción en la carpeta chroot. El mismo es un archivo de texto plano
> > > > con el siguiente contenido:
> > > >
> > > > # Generated by NetworkManager
> > > > search fibertel.com.ar http://fibertel.com.ar
> > > > nameserver 192.168.0.1
> > > >
> > > > Donde fibertel.com.ar es mi proovedor de internet, y el nameserver
> > > > calculo que se asigna de acuerdo a mi dirección IP
> > > >
> > > > /etc/resolv.conf al salir de la jaula chroot o al salir del sistema en
> > > > modo live, se borra y cada vez que iniciamos "network-manager" como dice
> > > > mas arriba vuelve a generarlo.
> > > > Y acá viene el tema, desde hace diez días ocurre que una vez terminado 
> > > > el
> > > > sistema, hacer la imágen ISO y correrla se genera un /etc/resolv.conf 
> > > > que
> > > > en realidad es un enlace a:
> > > > /run/systemd/resolve/resolv.conf, pero es un enlace vacío, ya que en
> > > > /run/systemd/ el directorio "resolve" y por lo tanto el archivo
> > > > "resolv.conf" NO EXISTEN. Lo mismo ocurre si se instala el sistema en 
> > > > disco
> > > > duro. Como consecuencia no se encuentran los DNS y lógicamente no se 
> > > > puede
> > > > acceder a la web.
> > > > Cabe aclarar que si instalo a disco, y luego reemplazo el 
> > > > /etc/*resolv.conf
> > > > enlace *por el un resolv.conf con el contenido que dejé mas arriba,
> > > > arranca la conexión.
> > > >
> > > > Esperando no haber sido demasiado extenso y que se aya entendido me 
> > > > quedo
> > > > a la espera de una respuesta, ya sea porque le haya ocurrido a alguien o
> > > > bien sepa de donde se genera el error/problema.
> > > > He buscado mucho en internet (y lo sigo haciendo) pero hasta ahora no
> > > > encuentro nada.
> >
> >
> > Hay varias formas de gestionar la red en Debian. Decide cuál vas a usar
> > o a darle prioridad, y en base a tu elección, configura el servicio
> > asociado para que se encargue de buscar el archivo de configuración de
> > los parámetros de la interfaz (IP, DNS, pasarela, enrutado, etc...).
> >
> > NetworkConfiguration
> > https://wiki.debian.org/NetworkConfiguration#A3_ways_to_configure_the_network
> >
> > systemd-resolved.service, systemd-resolved — Network Name Resolution
> > manager
> > https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
> >
> > > > Muchas gracias y saludos
> > > >
> > > > Guillermo E. Sosa
> > > > San Nicolás de los Arroyos
> > > > Bs. As. - Argentina
> > > >
> > > > Enviado con ProtonMail https://protonmail.com/ correo seguro.
> > >
> > > Mira a ver si está instalado el paquete "resolvconf"
> > >
> > > S2.
> >
> >
> > Saludos,
>

Re: /etc/resolv.conf en Debian Bookworm

[Guillermo Sosa]

Gracias Camaleon.
No, no lo estaba, pero como dije, nunca nesecité instalarlo, simplemente 
NetworkManager generaba un /etc/resolv.conf sin enlace, tanto en el arranque en 
modo Live como cuando se instalaba el sistema a l disco duro. Probé instalando 
el paquete "resolveconf", pero "no se que otro paquete" que ya no parece ser 
NetworkManager sigue generando un enlace simbólico a un directorio y archivo 
que no exixte /run/systemd/resolve/resolve.conf (el directorio resolve no 
existe y por lo tanto tampoco resolv.conf.
Vale comentarte que despues de instalar "resolvconf" como dijiste, dentro de 
él, o sea en /etc/resolveconf/resolve.conf.d/original, ese "original" es el 
resolve.conf que debería enlasarse, yo, puedo instalar el sistema y despues 
hacerlo manualmente, pero los que descargan la distro no van a andar haciendo 
eso, jajajaja.
auxtral.com.ar es el sitio, es una distribución personal que hago desde Stretch 
en el año 2018.
Gracias de nuevo. Espero estar explicándome bien en cuanto al problema, a mí me 
tiene totalmente descolocado. Todo lo que veo en la web respecto al tema, 
parece referirse a "un sistema ya instalado", yo nesecito solucionarlo un 
escalón antes "en un Live-System)
Saludos a todos



Guillermo E. Sosa
Auxtral GNU/Linux
San Nicolás de los Arroyos
Bs. As. - Argentina
www.auxtral.com.ar
Enviado con ProtonMail correo seguro.
--- Original Message ---
El jueves, 28 de abril de 2022 a las 11:27, Camaleón  
escribió:


> El 2022-04-28 a las 10:24 +0200, fernando sainz escribió:
>
> > El mié, 27 abr 2022 a las 23:55, Guillermo Sosa (auxt...@protonmail.com)
> > escribió:
>
>
> No sé por qué pero este correo de Guillermo no me llegó (no está en
> spam ni en la carpeta Todos de Gmail) :-?
>
> > > Buenas tardes aquí en Argentina.
> > > Desde hace años, mas precisamente desde Stretch, construyo mi distribución
> > > (con lb build) personalizada; hoy uso la "estable" Bullseye, pero ya estoy
> > > experimentando con Bookworm. De hecho hace un mes mas o menos que estoy
> > > probandola con escritorios Cinnamon, Mate y Xfce. Hasta 10 ó 12 días atrás
> > > todas funcionaban perfecto, pero de repente, con cualquier DE, comenzaron 
> > > a
> > > tener problemas con /etc/resolv.conf tanto en live-system como instaladas 
> > > a
> > > disco. De hecho ese archivo, que en la jaula chroot se activa (ustedes lo
> > > deben saber) con el comando; *cp /etc/resolv.conf chroot/etc/resolv.conf,
> > > *o sea copiando el resolv.conf del sistema anfitrión al sistema en
> > > construcción en la carpeta chroot. El mismo es un archivo de texto plano
> > > con el siguiente contenido:
> > >
> > > # Generated by NetworkManager
> > > search fibertel.com.ar http://fibertel.com.ar
> > > nameserver 192.168.0.1
> > >
> > > Donde fibertel.com.ar es mi proovedor de internet, y el nameserver
> > > calculo que se asigna de acuerdo a mi dirección IP
> > >
> > > /etc/resolv.conf al salir de la jaula chroot o al salir del sistema en
> > > modo live, se borra y cada vez que iniciamos "network-manager" como dice
> > > mas arriba vuelve a generarlo.
> > > Y acá viene el tema, desde hace diez días ocurre que una vez terminado el
> > > sistema, hacer la imágen ISO y correrla se genera un /etc/resolv.conf que
> > > en realidad es un enlace a:
> > > /run/systemd/resolve/resolv.conf, pero es un enlace vacío, ya que en
> > > /run/systemd/ el directorio "resolve" y por lo tanto el archivo
> > > "resolv.conf" NO EXISTEN. Lo mismo ocurre si se instala el sistema en 
> > > disco
> > > duro. Como consecuencia no se encuentran los DNS y lógicamente no se puede
> > > acceder a la web.
> > > Cabe aclarar que si instalo a disco, y luego reemplazo el 
> > > /etc/*resolv.conf
> > > enlace *por el un resolv.conf con el contenido que dejé mas arriba,
> > > arranca la conexión.
> > >
> > > Esperando no haber sido demasiado extenso y que se aya entendido me quedo
> > > a la espera de una respuesta, ya sea porque le haya ocurrido a alguien o
> > > bien sepa de donde se genera el error/problema.
> > > He buscado mucho en internet (y lo sigo haciendo) pero hasta ahora no
> > > encuentro nada.
>
>
> Hay varias formas de gestionar la red en Debian. Decide cuál vas a usar
> o a darle prioridad, y en base a tu elección, configura el servicio
> asociado para que se encargue de buscar el archivo de configuración de
> los parámetros de la interfaz (IP, DNS, pasarela, enrutado, etc...).
>
> NetworkConfiguration
> https://wiki.debian.org/NetworkConfiguration#A3_ways_to_configure_the_network
>
> systemd-resolved.service, systemd-resolved — Network Name Resolution
> manager
> https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
>
> > > Muchas gracias y saludos
> > >
> > > Guillermo E. Sosa
> > > San Nicolás de los Arroyos
> > > Bs. As. - Argentina
> > >
> > > Enviado con ProtonMail https://protonmail.com/ correo seguro.
> >
> > Mira a ver si está instalado el paquete "resolvconf"
> >
> > S2.
>
>
> Saludos,
>
> --
> Camaleón

Re: /etc/resolv.conf en Debian Bookworm

[Camaleón]

El 2022-04-28 a las 10:24 +0200, fernando sainz escribió:

> El mié, 27 abr 2022 a las 23:55, Guillermo Sosa ()
> escribió:

No sé por qué pero este correo de Guillermo no me llegó (no está en 
spam ni en la carpeta Todos de Gmail) :-?
 
> > Buenas tardes aquí en Argentina.
> > Desde hace años, mas precisamente desde Stretch, construyo mi distribución
> > (con lb build) personalizada; hoy uso la "estable" Bullseye, pero ya estoy
> > experimentando con Bookworm. De hecho hace un mes mas o menos que estoy
> > probandola con escritorios Cinnamon, Mate y Xfce. Hasta 10 ó 12 días atrás
> > todas funcionaban perfecto, pero de repente, con cualquier DE, comenzaron a
> > tener problemas con /etc/resolv.conf tanto en live-system como instaladas a
> > disco. De hecho ese archivo, que en la jaula chroot se activa (ustedes lo
> > deben saber) con el comando; *cp /etc/resolv.conf chroot/etc/resolv.conf,
> > *o sea copiando el resolv.conf del sistema anfitrión al sistema en
> > construcción en la carpeta chroot. El mismo es un archivo de texto plano
> > con el siguiente contenido:
> >
> > *# Generated by NetworkManager*
> > *search fibertel.com.ar <http://fibertel.com.ar>*
> > *nameserver 192.168.0.1*
> >
> > Donde fibertel.com.ar es mi proovedor de internet, y el nameserver
> > calculo que se asigna de acuerdo a mi dirección IP
> >
> > /etc/resolv.conf al salir de la jaula chroot o al salir del sistema en
> > modo live, se borra y cada vez que iniciamos "network-manager" como dice
> > mas arriba vuelve a generarlo.
> > Y acá viene el tema, desde hace diez días ocurre que una vez terminado el
> > sistema, hacer la imágen ISO y correrla se genera un /etc/resolv.conf que
> > en realidad es un enlace a:
> > /run/systemd/resolve/resolv.conf, pero es un enlace vacío, ya que en
> > /run/systemd/ el directorio "resolve" y por lo tanto el archivo
> > "resolv.conf" NO EXISTEN. Lo mismo ocurre si se instala el sistema en disco
> > duro. Como consecuencia no se encuentran los DNS y lógicamente no se puede
> > acceder a la web.
> > Cabe aclarar que si instalo a disco, y luego reemplazo el /etc/*resolv.conf
> > enlace *por  el un resolv.conf con el contenido que dejé mas arriba,
> > arranca la conexión.
> >
> > Esperando no haber sido demasiado extenso y que se aya entendido me quedo
> > a la espera de una respuesta, ya sea porque le haya ocurrido a alguien o
> > bien sepa de donde se genera el error/problema.
> > He buscado mucho en internet (y lo sigo haciendo) pero hasta ahora no
> > encuentro nada.

Hay varias formas de gestionar la red en Debian. Decide cuál vas a usar 
o a darle prioridad, y en base a tu elección, configura el servicio 
asociado para que se encargue de buscar el archivo de configuración de 
los parámetros de la interfaz (IP, DNS, pasarela, enrutado, etc...).

NetworkConfiguration
https://wiki.debian.org/NetworkConfiguration#A3_ways_to_configure_the_network

systemd-resolved.service, systemd-resolved — Network Name Resolution 
manager
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html

> >
> > Muchas gracias y saludos
> >
> >
> > Guillermo E. Sosa
> > San Nicolás de los Arroyos
> > Bs. As. - Argentina
> >
> >
> > Enviado con ProtonMail <https://protonmail.com/> correo seguro.
> >
> 
> 
> Mira a ver si  está instalado el paquete "resolvconf"
> 
> S2.

Saludos,

-- 
Camaleón 

Re: /etc/resolv.conf en Debian Bookworm

[fernando sainz]

El mié, 27 abr 2022 a las 23:55, Guillermo Sosa ()
escribió:

> Buenas tardes aquí en Argentina.
> Desde hace años, mas precisamente desde Stretch, construyo mi distribución
> (con lb build) personalizada; hoy uso la "estable" Bullseye, pero ya estoy
> experimentando con Bookworm. De hecho hace un mes mas o menos que estoy
> probandola con escritorios Cinnamon, Mate y Xfce. Hasta 10 ó 12 días atrás
> todas funcionaban perfecto, pero de repente, con cualquier DE, comenzaron a
> tener problemas con /etc/resolv.conf tanto en live-system como instaladas a
> disco. De hecho ese archivo, que en la jaula chroot se activa (ustedes lo
> deben saber) con el comando; *cp /etc/resolv.conf chroot/etc/resolv.conf,
> *o sea copiando el resolv.conf del sistema anfitrión al sistema en
> construcción en la carpeta chroot. El mismo es un archivo de texto plano
> con el siguiente contenido:
>
> *# Generated by NetworkManager*
> *search fibertel.com.ar <http://fibertel.com.ar>*
> *nameserver 192.168.0.1*
>
> Donde fibertel.com.ar es mi proovedor de internet, y el nameserver
> calculo que se asigna de acuerdo a mi dirección IP
>
> /etc/resolv.conf al salir de la jaula chroot o al salir del sistema en
> modo live, se borra y cada vez que iniciamos "network-manager" como dice
> mas arriba vuelve a generarlo.
> Y acá viene el tema, desde hace diez días ocurre que una vez terminado el
> sistema, hacer la imágen ISO y correrla se genera un /etc/resolv.conf que
> en realidad es un enlace a:
> /run/systemd/resolve/resolv.conf, pero es un enlace vacío, ya que en
> /run/systemd/ el directorio "resolve" y por lo tanto el archivo
> "resolv.conf" NO EXISTEN. Lo mismo ocurre si se instala el sistema en disco
> duro. Como consecuencia no se encuentran los DNS y lógicamente no se puede
> acceder a la web.
> Cabe aclarar que si instalo a disco, y luego reemplazo el /etc/*resolv.conf
> enlace *por  el un resolv.conf con el contenido que dejé mas arriba,
> arranca la conexión.
>
> Esperando no haber sido demasiado extenso y que se aya entendido me quedo
> a la espera de una respuesta, ya sea porque le haya ocurrido a alguien o
> bien sepa de donde se genera el error/problema.
> He buscado mucho en internet (y lo sigo haciendo) pero hasta ahora no
> encuentro nada.
>
> Muchas gracias y saludos
>
>
> Guillermo E. Sosa
> San Nicolás de los Arroyos
> Bs. As. - Argentina
>
>
> Enviado con ProtonMail <https://protonmail.com/> correo seguro.
>


Mira a ver si  está instalado el paquete "resolvconf"

S2.

/etc/resolv.conf en Debian Bookworm

[Guillermo Sosa]

Buenas tardes aquí en Argentina.
Desde hace años, mas precisamente desde Stretch, construyo mi distribución (con 
lb build) personalizada; hoy uso la "estable" Bullseye, pero ya estoy 
experimentando con Bookworm. De hecho hace un mes mas o menos que estoy 
probandola con escritorios Cinnamon, Mate y Xfce. Hasta 10 ó 12 días atrás 
todas funcionaban perfecto, pero de repente, con cualquier DE, comenzaron a 
tener problemas con /etc/resolv.conf tanto en live-system como instaladas a 
disco. De hecho ese archivo, que en la jaula chroot se activa (ustedes lo deben 
saber) con el comando; cp /etc/resolv.conf chroot/etc/resolv.conf, o sea 
copiando el resolv.conf del sistema anfitrión al sistema en construcción en la 
carpeta chroot. El mismo es un archivo de texto plano con el siguiente 
contenido:

# Generated by NetworkManager
search fibertel.com.arnameserver 192.168.0.1

Donde fibertel.com.ar es mi proovedor de internet, y el nameserver calculo que 
se asigna de acuerdo a mi dirección IP

/etc/resolv.conf al salir de la jaula chroot o al salir del sistema en modo 
live, se borra y cada vez que iniciamos "network-manager" como dice mas arriba 
vuelve a generarlo.
Y acá viene el tema, desde hace diez días ocurre que una vez terminado el 
sistema, hacer la imágen ISO y correrla se genera un /etc/resolv.conf que en 
realidad es un enlace a:
/run/systemd/resolve/resolv.conf, pero es un enlace vacío, ya que en 
/run/systemd/ el directorio "resolve" y por lo tanto el archivo "resolv.conf" 
NO EXISTEN. Lo mismo ocurre si se instala el sistema en disco duro. Como 
consecuencia no se encuentran los DNS y lógicamente no se puede acceder a la 
web.
Cabe aclarar que si instalo a disco, y luego reemplazo el /etc/resolv.conf 
enlace por el un resolv.conf con el contenido que dejé mas arriba, arranca la 
conexión.

Esperando no haber sido demasiado extenso y que se aya entendido me quedo a la 
espera de una respuesta, ya sea porque le haya ocurrido a alguien o bien sepa 
de donde se genera el error/problema.
He buscado mucho en internet (y lo sigo haciendo) pero hasta ahora no encuentro 
nada.

Muchas gracias y saludos

Guillermo E. Sosa
San Nicolás de los Arroyos
Bs. As. - Argentina

Enviado con [ProtonMail](https://protonmail.com/) correo seguro.

Re: rdnssd not updating /etc/resolv.conf

[Jeremy Ardley]

On 10/4/22 7:04 am, Jeremy Ardley wrote:

I've installed rdnssd

The host has ipv6 enabled in /etc/network/interfaces and it's 
acquiring an IPv6 address via RA in addition to having a static IPv6 
Address


rdnssd is running but nothing is changing in /etc/resolv.conf or 
/var/run/rdnssd/resolv.conf




The RA does include DNS information

root@orangepi-r1:~# radvdump
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::fca5:6fff:fe75:6129
# received by interface enxc0742bffdceb
#

interface enxc0742bffdceb
{
    AdvSendAdvert on;
    # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
    AdvManagedFlag off;
    AdvOtherConfigFlag on;
    AdvReachableTime 0;
    AdvRetransTimer 0;
    AdvCurHopLimit 0;
    AdvDefaultLifetime 1800;
    AdvHomeAgentFlag off;
    AdvDefaultPreference medium;
    AdvSourceLLAddress on;
    AdvLinkMTU 1500;

    prefix 2403:5800:c101:b700::/64
    {
        AdvValidLifetime 3776;
        AdvPreferredLifetime 2776;
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr off;
    }; # End of prefix definition


    RDNSS fe80::fca5:6fff:fe75:6129
    {
        AdvRDNSSLifetime 0;
    }; # End of RDNSS definition


    DNSSL lan bronzemail.com
    {
        AdvDNSSLLifetime 1800;
    }; # End of DNSSL definition

}; # End of interface definition


--
Jeremy


OpenPGP_signature
Description: OpenPGP digital signature

rdnssd not updating /etc/resolv.conf

[Jeremy Ardley]

I've installed rdnssd

The host has ipv6 enabled in /etc/network/interfaces and it's acquiring an IPv6 
address via RA in addition to having a static IPv6 Address

rdnssd is running but nothing is changing in /etc/resolv.conf or 
/var/run/rdnssd/resolv.conf

Any suggestions?

root@orangepi-r1:~# cat /etc/network/interfaces
source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
   address 192.168.0.1/24

auto enxc0742bffdceb

iface enxc0742bffdceb inet dhcp

iface enxc0742bffdceb inet6 static
    address 2403:5800:c101:b700:beef::face/64
    # use SLAAC to get global IPv6 address from the router
    autoconf 1
    accept_ra 1
    privext 2

cat /var/run/rdnssd/resolv.conf

search lan bronzemail.com

cat /etc/resolv.conf
nameserver 10.31.40.4
nameserver 10.31.40.5
search lan bronzemail.com

root@orangepi-r1:~# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state DOWN group 
default qlen 1000
    link/ether 02:42:7d:73:5a:21 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
   valid_lft forever preferred_lft forever
3: enxc0742bffdceb:  mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
    link/ether c0:74:2b:ff:dc:eb brd ff:ff:ff:ff:ff:ff
    inet 10.31.40.242/24 brd 10.31.40.255 scope global dynamic enxc0742bffdceb
   valid_lft 84677sec preferred_lft 84677sec
    inet6 2403:5800:c101:b700:b99c:4896:34af:8926/64 scope global temporary 
dynamic
   valid_lft 3012sec preferred_lft 2011sec
    inet6 2403:5800:c101:b700:c274:2bff:feff:dceb/64 scope global dynamic 
mngtmpaddr
   valid_lft 3012sec preferred_lft 2011sec
    inet6 2403:5800:c101:b700:beef::face/64 scope global
   valid_lft forever preferred_lft forever
    inet6 fe80::c274:2bff:feff:dceb/64 scope link
   valid_lft forever preferred_lft forever
4: wlan0:  mtu 1500 qdisc mq state DOWN 
group default qlen 1000
    link/ether 44:b2:95:fc:5f:74 brd ff:ff:ff:ff:ff:ff

root@orangepi-r1:~# route -n6

Kernel IPv6 routing table

Destination    Next Hop   Flag Met Ref Use If

2403:5800:c101:b700::/64   :: U    256 2 0 
enxc0742bffdceb

fe80::/64  :: U    256 1 0 
enxc0742bffdceb

::/0   fe80::fca5:6fff:fe75:6129  UGDAe 1024 4 0 
enxc0742bffdceb

::1/128    :: Un   0   6 0 lo

2403:5800:c101:b700:b99c:4896:34af:8926/128 :: Un   0   
3 0 enxc0742bffdceb

2403:5800:c101:b700:beef::face/128 :: Un   0   5 0 
enxc0742bffdceb

2403:5800:c101:b700:c274:2bff:feff:dceb/128 :: Un   0   
2 0 enxc0742bffdceb

fe80::c274:2bff:feff:dceb/128  :: Un   0   3 0 
enxc0742bffdceb

ff00::/8   :: U    256 6 0 
enxc0742bffdceb

::/0   :: !n   -1  1 0 lo

root@orangepi-r1:~# lsof | grep rdnssd

rdnssd 977  root  cwd   DIR  179,1 4096 
 2 /
rdnssd 977  root  rtd   DIR  179,1 4096 
 2 /
rdnssd 977  root  txt   REG  179,1    17880 
  1188 /usr/sbin/rdnssd
rdnssd 977  root  mem   REG  179,1   113596 
  6997 /usr/lib/arm-linux-gnueabihf/libpthread-2.31.so
rdnssd 977  root  mem   REG  179,1   973416 
  6819 /usr/lib/arm-linux-gnueabihf/libc-2.31.so
rdnssd 977  root  mem   REG  179,1    22488 
  7004 /usr/lib/arm-linux-gnueabihf/librt-2.31.so
rdnssd 977  root  mem   REG  179,1   110012 
  6718 /usr/lib/arm-linux-gnueabihf/ld-2.31.so
rdnssd 977  root    0r  CHR    1,3  0t0 
 3 /dev/null
rdnssd 977  root    1w  CHR    1,3  0t0 
 3 /dev/null
rdnssd 977  root    2w  CHR    1,3  0t0 
 3 /dev/null
rdnssd 977  root    3wW REG   0,23    3 
   379 /run/rdnssd.pid
rdnssd 977  root    4r FIFO   0,12  0t0 
  8479 pipe
rdnssd 978    rdnssd  cwd   DIR  179,1 4096 
 2 /
rdnssd 978    rdnssd  rtd   DIR  179,1 4096 
 2 /
rdnssd 978    rdnssd  txt   REG  179,1    17880 
  1188 /usr/sbin/rdnssd
rdnssd 978    rdnssd  mem

Bind9, /etc/network/interfaces och resolv.conf?

[Jens A Andersson]

Hoppas någon kan ge mej ett råd.

Har i många kört en lokal dns-server som forwarder och som root för min 
egen högst privata och lokala domän. Vid en av de senaste 
apt-uppgraderingarna slutade dns-server att fungera fullt ut.


I probklemlösandet stöter jag på denna fråga: Ska den serverns egen 
lokala dns-serveradress konfigureras i /etc/network/interfaces 
(dns-server 127.0.0.1) eller i /etc/resolv.conf? Enligt apt list är inte 
resolvconf installerad.


Servern kör Debian 11.

Tack på förhand.
--
//Jens

==
Jens Andersson  ja...@barbanet.com
VHF: SC8895 MMSI:265586130
PGP finger print:
BD36 399B 2594 74DA  EFAB B72C B655 55D1

Re: 11.2 sometimes wrong /etc/resolv.conf

[Anssi Saari]

Christian Groessler  writes:

> Hi,
>
> when I boot my laptop with Debian 11.2 and LAN cable connected, I'm
> sometimes getting a wrong /etc/resolv.conf.
>
> The resolv.conf is not in fact wrong, but it's the one from the Wifi
> network. But when booting with network cable connected I want to have
> the resolv.conf of the cabled network.

I think you mean when you're plugged in both wifi and ethernet are
connected and your whole connection is over one or the other, probably
whichever connected last? So your question is really, how to turn off
wifi when using fixed ethernet? Using NetworkManager, one might guess?

It's surprising to me this doesn't seem to be handled by NetworkManager
GUI. Or actually when I think of how weird and broken and undocumented
NetworkManager is, maybe I shouldn't be surprised.

Anyways, here's an explanation on how to make NetworkManager do what I
guess you want it to do:
https://unix.stackexchange.com/questions/487640/disable-wifi-on-connection-to-ethernet-with-networkmanager

Re: 11.2 sometimes wrong /etc/resolv.conf

[ghe2001]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



‐‐‐ Original Message ‐‐‐
On Thursday, March 10, 2022 9:22 AM, Christian Groessler  
wrote:

> Hi,
>
> when I boot my laptop with Debian 11.2 and LAN cable connected, I'm
> sometimes getting a wrong /etc/resolv.conf.
>
> The resolv.conf is not in fact wrong, but it's the one from the Wifi
> network. But when booting with network cable connected I want to have
> the resolv.conf of the cabled network.
>
> Can I somehow force this? That the "cabled-network-nameserver" is used
> when the cable is connected?

How about:

Create a resolv.com file with the cable network info (with a different name; I 
use /etc/resolv.com.qw).

Create a shell script that gets the current IP (hostname -I), checks for the 
desired nameserver IP, and copies your resolv.com.qw to /etc/resolv.com if 
necessary.  Or maybe always copy the file (one-liner in .bashrc) if you always 
want the same nameserver and want to save a couple ms.

Put the script at the bottom of the .bashrc (or equiv) in everybody's login dir.

The script will run when anybody logs in -- long after the network has been 
configured.

--
Glenn English


-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJiKlPnACEJEJ/XhjGCrIwyFiEELKJzD0JScCVjQA2Xn9eG
MYKsjDKYKAgAk87zZAIrAyhVKU9YD1cU4vXoZ08xLBJGQfy78yKXFaAEEwEw
qfg83L6YsDEdqX01DFU7Gvv0DyrPfNatit+Ut2/76cLJkfzDiGeqB1KzyI3a
R+yzLJy0aq71Ww/8dG4XUEAXt7ieIop3akjnmIHa0qUxo7rrFvVr8hG1hT22
NLWYGqFBgB4TnXJMbGDEyIXZUmsnvdzXcn883sXWna++Hg5r179rt+EG+rwn
vL0LWaeKV7TccFnP8J1siLFi9ZkeAZ5w5JXvPlkL5UKLnfIabcu1CORRHsIP
jWLSSs7ywRrwskvc/6+HvlsljPKbCsEPk3qocNoiAxkN6O+7t6FMdg==
=xTLN
-END PGP SIGNATURE-

Re: 11.2 sometimes wrong /etc/resolv.conf

[Charles Curley]

On Thu, 10 Mar 2022 17:22:34 +0100
Christian Groessler  wrote:

> when I boot my laptop with Debian 11.2 and LAN cable connected, I'm 
> sometimes getting a wrong /etc/resolv.conf.
> 
> The resolv.conf is not in fact wrong, but it's the one from the Wifi 
> network. But when booting with network cable connected I want to have 
> the resolv.conf of the cabled network.
> 
> Can I somehow force this? That the "cabled-network-nameserver" is
> used when the cable is connected?

The cable network's DHCP server should provide the relevant information
automatically. If you are using NetworkManager, you can insert a script
to find out what it provides into /etc/NetworkManager/dispatcher.d/.
Something like:

echo "Routers value is |$DHCP4_ROUTERS|. IP4_GATEWAY is
|$IP4_GATEWAY|." echo "Environment is:" printenv

and send the output to a log file. The variable you want is
DHCP4_DOMAIN_NAME_SERVERS, and possibly others (see the results from
printenv).

You may have to request certain information from a badly configured
server. In your /etc/dhcp/dhclient.conf, something like:

request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
rfc3442-classless-static-routes, ntp-servers;

You will probably need at least the second and/or third line.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

11.2 sometimes wrong /etc/resolv.conf

[Christian Groessler]

Hi,

when I boot my laptop with Debian 11.2 and LAN cable connected, I'm 
sometimes getting a wrong /etc/resolv.conf.


The resolv.conf is not in fact wrong, but it's the one from the Wifi 
network. But when booting with network cable connected I want to have 
the resolv.conf of the cabled network.


Can I somehow force this? That the "cabled-network-nameserver" is used 
when the cable is connected?


regards,
chris