Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #248092 > unrolled thread

Editing the DNS with Network Manager Non Root

Back to article view | Back to linux.debian.user

Contents

  Editing the DNS with Network Manager Non Root Richmond <richmond@criptext.com> - 2022-05-11 16:20 +0200
    Re: Editing the DNS with Network Manager Non Root David Christensen <dpchrist@holgerdanske.com> - 2022-05-11 22:50 +0200
      Re: Editing the DNS with Network Manager Non Root Richmond <richmond@criptext.com> - 2022-05-12 16:40 +0200
        Re: Editing the DNS with Network Manager Non Root David Christensen <dpchrist@holgerdanske.com> - 2022-05-13 01:20 +0200
          Re: Editing the DNS with Network Manager Non Root Richmond <richmond@criptext.com> - 2022-05-13 18:30 +0200
            Re: Editing the DNS with Network Manager Non Root David Christensen <dpchrist@holgerdanske.com> - 2022-05-13 21:00 +0200
              Re: Editing the DNS with Network Manager Non Root Greg Wooledge <greg@wooledge.org> - 2022-05-13 21:10 +0200
                Re: Editing the DNS with Network Manager Non Root David Wright <deblis@lionunicorn.co.uk> - 2022-05-13 22:50 +0200
                  Re: Editing the DNS with Network Manager Non Root Greg Wooledge <greg@wooledge.org> - 2022-05-13 23:30 +0200
                    Re: Editing the DNS with Network Manager Non Root Greg Wooledge <greg@wooledge.org> - 2022-05-14 02:50 +0200
                      Re: Editing the DNS with Network Manager Non Root David Wright <deblis@lionunicorn.co.uk> - 2022-05-14 06:40 +0200
                      Re: Editing the DNS with Network Manager Non Root David Wright <deblis@lionunicorn.co.uk> - 2022-05-16 05:50 +0200
                        Re: Editing the DNS with Network Manager Non Root Greg Wooledge <greg@wooledge.org> - 2022-05-16 13:20 +0200
                          Re: Editing the DNS with Network Manager Non Root David Wright <deblis@lionunicorn.co.uk> - 2022-05-16 17:50 +0200
                    Re: Editing the DNS with Network Manager Non Root David Wright <deblis@lionunicorn.co.uk> - 2022-05-14 06:40 +0200
                      Re: Editing the DNS with Network Manager Non Root Vincent Lefevre <vincent@vinc17.net> - 2022-05-16 01:40 +0200
                        Re: Editing the DNS with Network Manager Non Root David Wright <deblis@lionunicorn.co.uk> - 2022-05-16 17:50 +0200
                    Re: Editing the DNS with Network Manager Non Root <tomas@tuxteam.de> - 2022-05-14 07:20 +0200
                Re: Editing the DNS with Network Manager Non Root David Christensen <dpchrist@holgerdanske.com> - 2022-05-14 00:10 +0200
              Re: Editing the DNS with Network Manager Non Root Richmond <richmond@criptext.com> - 2022-05-13 21:50 +0200
                Re: Editing the DNS with Network Manager Non Root Richmond <richmond@criptext.com> - 2022-05-14 12:20 +0200
                  Re: Editing the DNS with Network Manager Non Root <tomas@tuxteam.de> - 2022-05-14 13:30 +0200
                    Re: Editing the DNS with Network Manager Non Root Richmond <richmond@criptext.com> - 2022-05-14 15:20 +0200
                      Re: Editing the DNS with Network Manager Non Root David Christensen <dpchrist@holgerdanske.com> - 2022-05-15 00:20 +0200
                        Re: Editing the DNS with Network Manager Non Root Richmond <richmond@criptext.com> - 2022-05-15 16:20 +0200
                          Re: Editing the DNS with Network Manager Non Root David Christensen <dpchrist@holgerdanske.com> - 2022-05-16 02:30 +0200
                            Re: Editing the DNS with Network Manager Non Root Richmond <richmond@criptext.com> - 2022-05-16 11:40 +0200

Page 1 of 2  [1] 2  Next page →

#248092 — Editing the DNS with Network Manager Non Root

I have a network manager applet on my xfce4 desktop. I am logged in as a
non root user, and I can select edit connections and change the IPv4
settings to DHCP address only and then put in a DNS, then save. If I
look at /etc/resolv.conf though nothing has changed. Restarting
networking or rebooting makes no difference. Perhaps this menu option
should only appear for root, or should cause an error message for non
root users?

[toc] | [next] | [standalone]

#248111

On 5/11/22 06:55, Richmond wrote:
> I have a network manager applet on my xfce4 desktop. I am logged in as a
> non root user, and I can select edit connections and change the IPv4
> settings to DHCP address only and then put in a DNS, then save. If I
> look at /etc/resolv.conf though nothing has changed. Restarting
> networking or rebooting makes no difference. Perhaps this menu option
> should only appear for root, or should cause an error message for non
> root users?


I typically need to enter the root password whenever I make changes via 
the Xfce NetworkManager Applet.


Please run and post:

$ cat /etc/debian_version ; uname -a

$ ls -l /etc/resolv.conf

$ cat /etc/resolv.conf


David

[toc] | [prev] | [next] | [standalone]

#248129

David Christensen <dpchrist@holgerdanske.com> writes:

> On 5/11/22 06:55, Richmond wrote:
>> I have a network manager applet on my xfce4 desktop. I am logged in as a
>> non root user, and I can select edit connections and change the IPv4
>> settings to DHCP address only and then put in a DNS, then save. If I
>> look at /etc/resolv.conf though nothing has changed. Restarting
>> networking or rebooting makes no difference. Perhaps this menu option
>> should only appear for root, or should cause an error message for non
>> root users?
>
>
> I typically need to enter the root password whenever I make changes
> via the Xfce NetworkManager Applet.
>
>
> Please run and post:
>
> $ cat /etc/debian_version ; uname -a
>
> $ ls -l /etc/resolv.conf
>
> $ cat /etc/resolv.conf
>
>
> David
11.3
Linux marvin 5.16.0-0.bpo.3-amd64 #1 SMP PREEMPT Debian
5.16.11-1~bpo11+1 (2022-03-02) x86_64 GNU/Linux

-rw-r--r-- 1 root root 79 May 12 15:15 /etc/resolv.conf

# Generated by NetworkManager
nameserver 192.168.1.1
nameserver fe80::1%enp2s0

That address 192.168.1.1 is not what I usually have, I was
experimenting, trying to find out if my router is vulnerable to the DNS
spoofing reported recently.

[toc] | [prev] | [next] | [standalone]

#248140

On 5/12/22 07:17, Richmond wrote:
> David Christensen <dpchrist@holgerdanske.com> writes:
> 
>> On 5/11/22 06:55, Richmond wrote:
>>> I have a network manager applet on my xfce4 desktop. I am logged in as a
>>> non root user, and I can select edit connections and change the IPv4
>>> settings to DHCP address only and then put in a DNS, then save. If I
>>> look at /etc/resolv.conf though nothing has changed. Restarting
>>> networking or rebooting makes no difference. Perhaps this menu option
>>> should only appear for root, or should cause an error message for non
>>> root users?
>>
>>
>> I typically need to enter the root password whenever I make changes
>> via the Xfce NetworkManager Applet.
>>
>>
>> Please run and post:
>>
>> $ cat /etc/debian_version ; uname -a
>>
>> $ ls -l /etc/resolv.conf
>>
>> $ cat /etc/resolv.conf
>>
>>
>> David
> 11.3
> Linux marvin 5.16.0-0.bpo.3-amd64 #1 SMP PREEMPT Debian
> 5.16.11-1~bpo11+1 (2022-03-02) x86_64 GNU/Linux
> 
> -rw-r--r-- 1 root root 79 May 12 15:15 /etc/resolv.conf
> 
> # Generated by NetworkManager
> nameserver 192.168.1.1
> nameserver fe80::1%enp2s0
> 
> That address 192.168.1.1 is not what I usually have, I was
> experimenting, trying to find out if my router is vulnerable to the DNS
> spoofing reported recently.


The date and time on resolve.conf show that it is current.


"nameserver 192.168.1.1" looks plausible.


I am using a Debian 11 desktop with Xfce:

2022-05-12 15:58:09 dpchrist@laalaa ~
$ echo "'$PS1'"
'\n\D{%Y-%m-%d %H:%M:%S} \u@\h \w\n\$ '

2022-05-12 15:58:19 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a
11.3
Linux laalaa 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) 
x86_64 GNU/Linux

2022-05-12 15:58:27 dpchrist@laalaa ~
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 83 May 12 11:06 /etc/resolv.conf

2022-05-12 15:58:33 dpchrist@laalaa ~
$ cat /etc/resolv.conf
# Generated by NetworkManager
search tracy.holgerdanske.com
nameserver 192.168.5.1


If I right-click the Xfce NetworkManager Applet and choose Edit 
Connections, I get a window "Network Connections":

     Ethernet
        Wired connection 1

If I double-click "Wired connection 1", I get a windows "Editing Wired 
connection 1".  If I select the tab IPv4 Settings, there is a drop-down 
list labeled "Methods".

- It is currently set to "Automatic (DHCP)".  The remaining settings are:

     Additional static addresses -> empty

     Additional DNS servers -> empty

     Additional Search domains -> empty

     DHCP client ID -> empty

     Require IPv4 addressing for this connection to complete -> unchecked


If I choose "Automatic (DHCP) addresses only", the labels for the second 
and third settings change.  Putting in some test data:

     Additional static addresses -> Add:
	Address -> 192.168.123.45
	Netmask -> 255.255.255.0
	Gateway -> 192.168.5.1

     DNS servers -> 192.168.123.45,192.168.123.67

     Search domains -> frunobulax.org

     DHCP client ID -> empty

     Require IPv4 addressing for this connection to complete -> unchecked


I then click "Save".


I then enter the root password in the pop-up that opens.


I then close the "Network Connections" window and reboot.

2022-05-12 16:10:25 dpchrist@laalaa ~
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 104 May 12 16:09 /etc/resolv.conf

2022-05-12 16:10:34 dpchrist@laalaa ~
$ cat /etc/resolv.conf
# Generated by NetworkManager
search frunobulax.org
nameserver 192.168.123.45
nameserver 192.168.123.67


Is this the results you expect?


David

[toc] | [prev] | [next] | [standalone]

#248161

David Christensen <dpchrist@holgerdanske.com> writes:

> On 5/12/22 07:17, Richmond wrote:
>> David Christensen <dpchrist@holgerdanske.com> writes:
>> 
>>> On 5/11/22 06:55, Richmond wrote:
>>>> I have a network manager applet on my xfce4 desktop. I am logged in as a
>>>> non root user, and I can select edit connections and change the IPv4
>>>> settings to DHCP address only and then put in a DNS, then save. If I
>>>> look at /etc/resolv.conf though nothing has changed. Restarting
>>>> networking or rebooting makes no difference. Perhaps this menu option
>>>> should only appear for root, or should cause an error message for non
>>>> root users?
>>>
>>>
>>> I typically need to enter the root password whenever I make changes
>>> via the Xfce NetworkManager Applet.
>>>
>>>
>>> Please run and post:
>>>
>>> $ cat /etc/debian_version ; uname -a
>>>
>>> $ ls -l /etc/resolv.conf
>>>
>>> $ cat /etc/resolv.conf
>>>
>>>
>>> David
>> 11.3
>> Linux marvin 5.16.0-0.bpo.3-amd64 #1 SMP PREEMPT Debian
>> 5.16.11-1~bpo11+1 (2022-03-02) x86_64 GNU/Linux
>> -rw-r--r-- 1 root root 79 May 12 15:15 /etc/resolv.conf
>> # Generated by NetworkManager
>> nameserver 192.168.1.1
>> nameserver fe80::1%enp2s0
>> That address 192.168.1.1 is not what I usually have, I was
>> experimenting, trying to find out if my router is vulnerable to the DNS
>> spoofing reported recently.
>
>
> The date and time on resolve.conf show that it is current.

Yes, it is very odd. I have just gone through this process again, and it
does update the timestamp, but does not apply changes...

>
>
> "nameserver 192.168.1.1" looks plausible.

I put it in there, it is the address of my router, the gateway, which
responds to DNS queries but merely passes them to the address it has
obtained through DHCP. The only way I found to get an address into
resolv (other than editing it obviously) was by logging into the desktop
as root, which I rarely do.

>
>
> I am using a Debian 11 desktop with Xfce:
>
> 2022-05-12 15:58:09 dpchrist@laalaa ~
> $ echo "'$PS1'"
> '\n\D{%Y-%m-%d %H:%M:%S} \u@\h \w\n\$ '
>
> 2022-05-12 15:58:19 dpchrist@laalaa ~
> $ cat /etc/debian_version ; uname -a
> 11.3
> Linux laalaa 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29)
> x86_64 GNU/Linux
>
> 2022-05-12 15:58:27 dpchrist@laalaa ~
> $ ls -l /etc/resolv.conf
> -rw-r--r-- 1 root root 83 May 12 11:06 /etc/resolv.conf
>
> 2022-05-12 15:58:33 dpchrist@laalaa ~
> $ cat /etc/resolv.conf
> # Generated by NetworkManager
> search tracy.holgerdanske.com
> nameserver 192.168.5.1
>
>
> If I right-click the Xfce NetworkManager Applet and choose Edit
> Connections, I get a window "Network Connections":
>
>     Ethernet
>        Wired connection 1
>
> If I double-click "Wired connection 1", I get a windows "Editing Wired
> connection 1".  If I select the tab IPv4 Settings, there is a
> drop-down list labeled "Methods".
>
> - It is currently set to "Automatic (DHCP)".  The remaining settings are:
>
>     Additional static addresses -> empty
>
>     Additional DNS servers -> empty
>
>     Additional Search domains -> empty
>
>     DHCP client ID -> empty
>
>     Require IPv4 addressing for this connection to complete -> unchecked
>
>
> If I choose "Automatic (DHCP) addresses only", the labels for the
> second and third settings change.  Putting in some test data:
>
>     Additional static addresses -> Add:
> 	Address -> 192.168.123.45
> 	Netmask -> 255.255.255.0
> 	Gateway -> 192.168.5.1
>
>     DNS servers -> 192.168.123.45,192.168.123.67
>
>     Search domains -> frunobulax.org
>
>     DHCP client ID -> empty
>
>     Require IPv4 addressing for this connection to complete -> unchecked
>
>
> I then click "Save".
>
>
> I then enter the root password in the pop-up that opens.
>
>
> I then close the "Network Connections" window and reboot.
>
> 2022-05-12 16:10:25 dpchrist@laalaa ~
> $ ls -l /etc/resolv.conf
> -rw-r--r-- 1 root root 104 May 12 16:09 /etc/resolv.conf
>
> 2022-05-12 16:10:34 dpchrist@laalaa ~
> $ cat /etc/resolv.conf
> # Generated by NetworkManager
> search frunobulax.org
> nameserver 192.168.123.45
> nameserver 192.168.123.67
>
>
> Is this the results you expect?
>
>
> David

I didn't put in a search domain, netmask, or gateway.

I didn't get prompted for root access. Perhaps that is the problem?

stat /etc/resolv.conf shows that the file has been updated but its
content doesn't change.

[toc] | [prev] | [next] | [standalone]

#248167

On 5/13/22 09:02, Richmond wrote:
> David Christensen writes:
>> On 5/12/22 07:17, Richmond wrote:
>>> David Christensen writes:
>>>> On 5/11/22 06:55, Richmond wrote:
>>>>> I have a network manager applet on my xfce4 desktop. I am logged in as a
>>>>> non root user, and I can select edit connections and change the IPv4
>>>>> settings to DHCP address only and then put in a DNS, then save. If I
>>>>> look at /etc/resolv.conf though nothing has changed. Restarting
>>>>> networking or rebooting makes no difference. Perhaps this menu option
>>>>> should only appear for root, or should cause an error message for non
>>>>> root users?

>> If I choose "Automatic (DHCP) addresses only", the labels for the
>> second and third settings change.  Putting in some test data:
>>
>>      Additional static addresses -> Add:
>> 	Address -> 192.168.123.45
>> 	Netmask -> 255.255.255.0
>> 	Gateway -> 192.168.5.1
>>
>>      DNS servers -> 192.168.123.45,192.168.123.67
>>
>>      Search domains -> frunobulax.org
>>
>>      DHCP client ID -> empty
>>
>>      Require IPv4 addressing for this connection to complete -> unchecked
>>
>>
>> I then click "Save".
>>
>>
>> I then enter the root password in the pop-up that opens.
>>
>>
>> I then close the "Network Connections" window and reboot.
>>
>> 2022-05-12 16:10:25 dpchrist@laalaa ~
>> $ ls -l /etc/resolv.conf
>> -rw-r--r-- 1 root root 104 May 12 16:09 /etc/resolv.conf
>>
>> 2022-05-12 16:10:34 dpchrist@laalaa ~
>> $ cat /etc/resolv.conf
>> # Generated by NetworkManager
>> search frunobulax.org
>> nameserver 192.168.123.45
>> nameserver 192.168.123.67
>>
>>
>> Is this the results you expect?

> I didn't put in a search domain, netmask, or gateway.


Put them in and try again.  Without crawling the code, we have no idea 
what actually matters.


> I didn't get prompted for root access. Perhaps that is the problem?


I would suspect it indicates that Network Manager does not think your 
network settings changed.


> stat /etc/resolv.conf shows that the file has been updated but its
> content doesn't change.


My /etc/resolv.conf did not change after running Network Manager; it 
changed after rebooting.  (Is the former a bug or a feature?)


What happens if you create a new connection and use the Manual method?


If all else fails -- backup, pull the OS disk, insert a blank disk, do a 
fresh install, and restore.  Keep meticulous records.  Use a version 
control system.  Learn a scripting language and automate sysadmin chores.


David

[toc] | [prev] | [next] | [standalone]

#248168

On Fri, May 13, 2022 at 11:53:23AM -0700, David Christensen wrote:
> On 5/13/22 09:02, Richmond wrote:
> > stat /etc/resolv.conf shows that the file has been updated but its
> > content doesn't change.
> 
> My /etc/resolv.conf did not change after running Network Manager; it changed
> after rebooting.  (Is the former a bug or a feature?)

Typically, if your system is running a DHCP client daemon to manage
the addresses on any or all of your physical interfaces, the DHCP client
daemon will rewrite the /etc/resolv.conf file whenever it feels like it.
This could be each time the lease is renewed, or each time any piece of
information received from the DHCP server has changed since the previous
response, or... anything.

If you're fighting against your networking tools to maintain correct
content in your /etc/resolv.conf file, I suggest starting with
<https://wiki.debian.org/resolv.conf> which has details on some of
the choices available to you.

[toc] | [prev] | [next] | [standalone]

#248172

On Fri 13 May 2022 at 15:02:35 (-0400), Greg Wooledge wrote:
> On Fri, May 13, 2022 at 11:53:23AM -0700, David Christensen wrote:
> > On 5/13/22 09:02, Richmond wrote:
> > > stat /etc/resolv.conf shows that the file has been updated but its
> > > content doesn't change.
> > 
> > My /etc/resolv.conf did not change after running Network Manager; it changed
> > after rebooting.  (Is the former a bug or a feature?)
> 
> Typically, if your system is running a DHCP client daemon to manage
> the addresses on any or all of your physical interfaces, the DHCP client
> daemon will rewrite the /etc/resolv.conf file whenever it feels like it.
> This could be each time the lease is renewed, or each time any piece of
> information received from the DHCP server has changed since the previous
> response, or... anything.
> 
> If you're fighting against your networking tools to maintain correct
> content in your /etc/resolv.conf file, I suggest starting with
> <https://wiki.debian.org/resolv.conf> which has details on some of
> the choices available to you.

… and I'm afraid that you have to be prepared for a fair amount of
confusion when you read this wiki and its companion:
https://wiki.debian.org/NetworkConfiguration

I'll refer to these wikis as RC and NC to avoid adding to the confusion.

So, for example, under the heading "Configuring resolvconf" on RC,
the second word is a link to the package "resolvconf". Fair enough.

But the next paragraph talks of the file "/etc/resolvconf.conf",
which has nothing to do with the resolvconf /package/, but is the
configuration file for the /openresolv/ package.

Both these packages actually perform their task with a shell script
in /sbin/resolvconf, so when you read something about the resolvconf
/program/, it's a toss-up which program they're talking about.

(And that's ignoring the fact that if you stray outside Debian's
documentation, you might discover that they're writing about, for
example, "openresolv" actually packaged up as "resolvconf".)

Turning to NC, under the heading "The resolv.conf configuration file"
there's a section headed "The resolvconf program". If you happened
to install the openresolv package, this is not about /your/ resolvconf
program: it's about the resolvconf /package's/ program, but it never
mentions that. (The word package doesn't appear anywhere.)

AFAICT the way in which you configure the two packages is completely
different, as one (openresolv) uses a .conf file, whereas the other
responds to information it's fed through stdin.

And I haven't checked thoroughly, but I don't see anything about
whether, and how, systemd impacts these packages, though I believe
that if you tell systemd that you're using "resolvconf" rather than
systemd-resolved, that suffices for either of (open)resolv(conf).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248174

On Fri, May 13, 2022 at 03:39:39PM -0500, David Wright wrote:
> But the next paragraph talks of the file "/etc/resolvconf.conf",
> which has nothing to do with the resolvconf /package/, but is the
> configuration file for the /openresolv/ package.

What?  WHAT?!?

You know, I REALLY TRY.

If my BEST EFFORTS fall that far short, then whatever.  Maybe instead
of berating the wiki and the hard-working editors who TRIED OUR DAMNED
BEST to figure this shit out and document it for the world, you could,
like, help out?  Make it better?

*snort*  Yeah.  Right.

But, hey.  You know what WORKS?

chattr +i /etc/resolv.conf

THAT ONE WORKS!!  EVERY TIME!

But smug assholes in IRC insist that it's "wrong", or that it incurs
something they call "technical debt", whatever the hell THAT means,
and they keep trying to smother it.

Well, guess what?

If the "right ways" to do this ONE SIMPLE THING are so convoluted and
incomphrensible that we can't even DOCUMENT THEM correctly, maybe they
aren't so "right" after all!

Oh, and maybe whichever HALFWIT decided that there should be a program
named resolvconf and a configuration file named resolvconf.conf and
that these two should be UNRELATED TO EACH OTHER should stop inflicting
their decisions on Debian.  Just a thought.

P.S. this is the sanitized version of this email.  You're welcome.

[toc] | [prev] | [next] | [standalone]

#248178

On Fri, May 13, 2022 at 05:27:30PM -0400, Greg Wooledge wrote:
> 
> If my BEST EFFORTS fall that far short, then whatever.  Maybe instead
> of berating the wiki and the hard-working editors who TRIED OUR DAMNED
> BEST to figure this shit out and document it for the world, you could,
> like, help out?  Make it better?
> 
> *snort*  Yeah.  Right.

As expected, I have to do it all myself.

Is it better now?  Or are there still MORE things that should be obvious
and straightforward but are in fact traps set by the Debian developers
to make the lives of their users more difficult?

You know what I'm talking about, right?  What, you don't?  Here is a
quote from the resolvconf.conf(5) man page:

  
  NAME

  resolvconf.conf — resolvconf configuration file

  DESCRIPTION

  resolvconf.conf is the configuration file for resolvconf(8).


I defy anybody to read this and figure out that it really means "it's
the openresolv configuration file, used by the resolvconf(8) program
which is provided by the openresolv package, but NOT by the resolvconf(8)
program which is provided by the resolvconf package".

[toc] | [prev] | [next] | [standalone]

#248189

On Fri 13 May 2022 at 20:49:27 (-0400), Greg Wooledge wrote:
> On Fri, May 13, 2022 at 05:27:30PM -0400, Greg Wooledge wrote:
> > 
> > If my BEST EFFORTS fall that far short, then whatever.  Maybe instead
> > of berating the wiki and the hard-working editors who TRIED OUR DAMNED
> > BEST to figure this shit out and document it for the world, you could,
> > like, help out?  Make it better?
> > 
> > *snort*  Yeah.  Right.
> 
> As expected, I have to do it all myself.

You know, I really can't compete on this timescale. After I saw your
previous post at half-four, I went back out to do battle with a poison
ivy plant (always left till last thing in the day), bagged and trashed
it, cleaned up, showered, and cooked and ate dinner. (And consequently
I missed the entire Sky paper review.)

That presupposes that I was competent to write what you have.

> Is it better now?  Or are there still MORE things that should be obvious
> and straightforward but are in fact traps set by the Debian developers
> to make the lives of their users more difficult?
> 
> You know what I'm talking about, right?  What, you don't?  Here is a
> quote from the resolvconf.conf(5) man page:
> 
>   
>   NAME
> 
>   resolvconf.conf — resolvconf configuration file
> 
>   DESCRIPTION
> 
>   resolvconf.conf is the configuration file for resolvconf(8).
> 
> 
> I defy anybody to read this and figure out that it really means "it's
> the openresolv configuration file, used by the resolvconf(8) program
> which is provided by the openresolv package, but NOT by the resolvconf(8)
> program which is provided by the resolvconf package".

Agreed. And you do have to be letter-perfect:

$ man resolv<TAB><TAB>
resolv.conf      resolvconf.conf  resolved.conf    resolver         
resolvconf       resolvectl       resolved.conf.d  

… and know your digits (man resolvconf  gives you  man 1 resolvectl;
for  man resolvconf, you need  man 8 resolvconf).

Here's some more confusion fodder (from man resolvconf^H^H^H^Hctl):

RESOLVECTL(1)                     resolvectl                     RESOLVECTL(1)

NAME
       resolvectl, resolvconf - Resolve domain names, IPV4 and IPv6 addresses,
       DNS resource records, and services; introspect and reconfigure the DNS
       resolver

[ … ]

COMPATIBILITY WITH RESOLVCONF(8)
       resolvectl is a multi-call binary. When invoked as "resolvconf"
       (generally achieved by means of a symbolic link of this name to the
       resolvectl binary) it is run in a limited resolvconf(8) compatibility
       mode. It accepts mostly the same arguments and pushes all data into
       systemd-resolved.service(8), similar to how dns and domain commands
       operate. Note that systemd-resolved.service is the only supported
       backend, which is different from other implementations of this command.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248260

On Fri 13 May 2022 at 20:49:27 (-0400), Greg Wooledge wrote:

> Is it better now?  Or are there still MORE things that should be obvious
> and straightforward but are in fact traps set by the Debian developers
> to make the lives of their users more difficult?

I would certainly have benefited from reading that back in March, thanks.

I wonder whether it might be worth adding (my addition within ●●):

  … both provide the same program, ●which are allegedly identical
  at the commandline but implemented completely differently,● so you …

And would it be correct to add:

  If resolvconf is installed ●and you're using ifupdown●,
  you can [add] dns-nameserver entries in the appropriate
  stanza(s) in /etc/network/interfaces:

I'm not certain about whether all the other network
configurator's ignore any interface that's mentioned in
/e/n/i, like wicd did and NetworkManager is alleged to do.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248271

On Sun, May 15, 2022 at 10:40:01PM -0500, David Wright wrote:
>   … both provide the same program, ●which are allegedly identical
>   at the commandline but implemented completely differently,● so you …

I don't think that's correct.  They have the same *name*, but they
have entirely different invocations, means of operation, configuration,
and so on.  Neither one is a drop-in replacement for the other.  That's
part of what makes the whole situation so egregious.

And it turns out there's a potential third one, too -- systemd's
resolvctl has special behavior if invoked by a symlink named resolvconf.
Fortunately for us, no such symlink exists by default, so all that's
present is a confusing man page.

> And would it be correct to add:
> 
>   If resolvconf is installed ●and you're using ifupdown●,
>   you can [add] dns-nameserver entries in the appropriate
>   stanza(s) in /etc/network/interfaces:

That one's pretty good.  I added something similar to the page.

[toc] | [prev] | [next] | [standalone]

#248280

On Mon 16 May 2022 at 07:12:35 (-0400), Greg Wooledge wrote:
> On Sun, May 15, 2022 at 10:40:01PM -0500, David Wright wrote:
> >   … both provide the same program, ●which are allegedly identical
> >   at the commandline but implemented completely differently,● so you …
> 
> I don't think that's correct.  They have the same *name*, but they
> have entirely different invocations, means of operation, configuration,
> and so on.  Neither one is a drop-in replacement for the other.  That's
> part of what makes the whole situation so egregious.

That's what I meant by "implemented completely differently",
but perhaps that wasn't a strong enough statement.

The claim is made in openresolv's man 8 resolvconf:

  "This implementation of resolvconf is called openresolv and
   is fully command line compatible with Debian's resolvconf,
   as written by Thomas Hood."

It looks about the same at the basic level of pkg resolvconf's
-a -d and -u, but the --… enabling options are presumably handled
by openresolv's configuraion file rather than at the command line.

So I think the claim that's being made is true for client programs
that shovel nameserver lines into its stdin, but not really for
the sysadmin setting it up.

> And it turns out there's a potential third one, too -- systemd's
> resolvctl has special behavior if invoked by a symlink named resolvconf.
> Fortunately for us, no such symlink exists by default, so all that's
> present is a confusing man page.

Yes, the complexity of systemd-resolved probably deserves a wiki page
of its own. With its four ways of handling /etc/resolv.conf, it's
sometimes difficult when reading systemd-resolved documentation
to know which mode is being talked about. And with systemd installed,
you can't get rid of it, only mask/disable it.

> > And would it be correct to add:
> > 
> >   If resolvconf is installed ●and you're using ifupdown●,
> >   you can [add] dns-nameserver entries in the appropriate
> >   stanza(s) in /etc/network/interfaces:
> 
> That one's pretty good.  I added something similar to the page.
> 

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248190

On Fri 13 May 2022 at 17:27:30 (-0400), Greg Wooledge wrote:
> On Fri, May 13, 2022 at 03:39:39PM -0500, David Wright wrote:
> > But the next paragraph talks of the file "/etc/resolvconf.conf",
> > which has nothing to do with the resolvconf /package/, but is the
> > configuration file for the /openresolv/ package.
> 
> What?  WHAT?!?
> 
> You know, I REALLY TRY.

I know. And your posts here certainly add more value to the list
than mine ever do.

> Oh, and maybe whichever HALFWIT decided that there should be a program
> named resolvconf and a configuration file named resolvconf.conf and
> that these two should be UNRELATED TO EACH OTHER should stop inflicting
> their decisions on Debian.  Just a thought.

Yes, it's odd. There are other cases where programs share the same
name. Usually these things are resolved (no pun intended) with
/etc/alternatives/, but here they seem to use Provides/Conflicts, and
those keywords only appear under openresolv, so if you look for
resolvconf in the Packages file, its entry carries no hint of the
existence of openresolv.

> If my BEST EFFORTS fall that far short, then whatever.  Maybe instead
> of berating the wiki and the hard-working editors who TRIED OUR DAMNED
> BEST to figure this shit out and document it for the world, you could,
> like, help out?  Make it better?
> 
> *snort*  Yeah.  Right.

Well, I've looked at these pages in the past, but never in any depth
because pkg resolvconf has been a luxury (originally installed IIRC
when I was playing with free vpns to download the odd BBC programme).
It always worked with wicd running the wifi, and I didn't give it
much thought.

Then last autumn, Stella posted about iwd, which interested me on
account of the demise of wicd. As you can see from my posts, I was
only aware of resolvconf and systemd-resolved as alternatives. (You
contributed at one point.)

But with the new year, I took up the idea of using iwd myself.
Unfortunately I got sidetracked by the buster version which, counting
in iwd-years, came out of the ark.

By mid-March, I'd figured that out, connected with both versions,
but left buster by the wayside (posting some caveats IIRC), and
concentrated on configuring bullseye.

Interestingly, I used the archlinux wiki, and some posts it referred
to, to hack the snag that iwd is unable to update /etc/resolv.conf
without realising that it documents openresolv, not resolvconf (but
uses the other name).

But I went on to try using systemd-resolved to see if that produced
a "cleaner" configuration, ie one without said hack. This was partly
on account of Thomas Pircher's post which uses a real pick'n'mix of
methods to configure the network.

But AFAICT it seemed that systemd-resolved was aimed more at programs
withing to call on a program to resolve an address for them, rather
than just maintain /etc/resolv.conf for competing interests. So it
was either slow, or failed, obviously waiting for something to time
out somewhere.

During April, the penny dropped that there were resolvconf and
openresolv packages, completely distinct, and so I downloaded
openresolv on May3 and installed it on May4. By May8, I was happy
enough to settle on openresolv as a replacement for resolvconf,
as it worked well with iwd and systemd-networkd. It does require
a three-line hack as above. I wrote that I would likely post it.

I haven't yet tested this configuration on the road, so to speak,
so do you think I'd pass as a past master at this game.

> But, hey.  You know what WORKS?
> 
> chattr +i /etc/resolv.conf
> 
> THAT ONE WORKS!!  EVERY TIME!
> 
> But smug assholes in IRC insist that it's "wrong", or that it incurs
> something they call "technical debt", whatever the hell THAT means,
> and they keep trying to smother it.

I didn't know the jargon, but the definition seems reasonably clear.
We hear about systems on this list where quick and dirty workarounds
have accumulated until it's very difficult to diagnose any problems
because nothing is configured quite as it should be.

> Well, guess what?
> 
> If the "right ways" to do this ONE SIMPLE THING are so convoluted and
> incomphrensible that we can't even DOCUMENT THEM correctly, maybe they
> aren't so "right" after all!

Well, AFAICT if you're using openresolv, then it looks as if
resolvconf=NO in /etc/resolvconf.conf should be pretty watertight,
assuming we don't have a yes≢true scenario like last week's.

OTOH it doesn't look easy with the resolvconf package. If you use
systemd's ability to mask the service, it's not clear whether you'd
get the desired fixed value at all.

But that could be completely simplistic, or just plain wrong.

> P.S. this is the sanitized version of this email.  You're welcome.

This is the stream of consciousness version of this email.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248255

On 2022-05-13 23:31:44 -0500, David Wright wrote:
> Well, I've looked at these pages in the past, but never in any depth
> because pkg resolvconf has been a luxury (originally installed IIRC
> when I was playing with free vpns to download the odd BBC programme).
> It always worked with wicd running the wifi, and I didn't give it
> much thought.

But resolvconf does not work well with unbound (users of postfix
and unbound may be interested in the postfix fix of bug 1003152).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#248282

On Mon 16 May 2022 at 01:30:56 (+0200), Vincent Lefevre wrote:
> On 2022-05-13 23:31:44 -0500, David Wright wrote:
> > Well, I've looked at these pages in the past, but never in any depth
> > because pkg resolvconf has been a luxury (originally installed IIRC
> > when I was playing with free vpns to download the odd BBC programme).
> > It always worked with wicd running the wifi, and I didn't give it
> > much thought.
> 
> But resolvconf does not work well with unbound (users of postfix
> and unbound may be interested in the postfix fix of bug 1003152).

That's quite an epic, and I wouldn't claim to understand all of it.
But have you bought your train tickets yet, for repeating the journey
using openresolv? :)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248191

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 13, 2022 at 05:27:30PM -0400, Greg Wooledge wrote:
> On Fri, May 13, 2022 at 03:39:39PM -0500, David Wright wrote:
> > But the next paragraph talks of the file "/etc/resolvconf.conf",
> > which has nothing to do with the resolvconf /package/, but is the
> > configuration file for the /openresolv/ package.
> 
> What?  WHAT?!?
> 
> You know, I REALLY TRY.

[...]

Rest elided.

Wow. This must be an example of what I call "emergent evil". Evil
emerges without anyone really intending it, like an anthill's
emergent behaviour.

Thanks for educating a happy person: in my box, neither resolvconf
nor openresolv are installed, and now I know I better keep it like
that.

FWIW, NetworkManager isn't either: it went out of the window
ages ago, while I was at a customer's premises, had configured my
ethernet and NM, installed by default, looked out of said window
and thought "oh, there's a WLAN out there, let's configure it
and set the default route to that".

A debugging session followed, after which I have no NM anymore.

The only program touching /etc/resolv.conf that I know of at
the moment is dhclient. And I found out the chattr way. It's
in some way satisfying to chattr a file and catch those
malfeasants whining in the logs :-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#248175

On 5/13/22 12:02, Greg Wooledge wrote:
> On Fri, May 13, 2022 at 11:53:23AM -0700, David Christensen wrote:
>> On 5/13/22 09:02, Richmond wrote:
>>> stat /etc/resolv.conf shows that the file has been updated but its
>>> content doesn't change.
>>
>> My /etc/resolv.conf did not change after running Network Manager; it changed
>> after rebooting.  (Is the former a bug or a feature?)
> 
> Typically, if your system is running a DHCP client daemon to manage
> the addresses on any or all of your physical interfaces, the DHCP client
> daemon will rewrite the /etc/resolv.conf file whenever it feels like it.
> This could be each time the lease is renewed, or each time any piece of
> information received from the DHCP server has changed since the previous
> response, or... anything.


How do I trigger a re-write of /etc/resolv.conf after making changes 
with Network Manager?


Why doesn't Network Manager do that for me?


David

[toc] | [prev] | [next] | [standalone]

#248170

David Christensen <dpchrist@holgerdanske.com> writes:

> On 5/13/22 09:02, Richmond wrote:
>> David Christensen writes:
>>> On 5/12/22 07:17, Richmond wrote:
>>>> David Christensen writes:
>>>>> On 5/11/22 06:55, Richmond wrote:
>>>>>> I have a network manager applet on my xfce4 desktop. I am logged in as a
>>>>>> non root user, and I can select edit connections and change the IPv4
>>>>>> settings to DHCP address only and then put in a DNS, then save. If I
>>>>>> look at /etc/resolv.conf though nothing has changed. Restarting
>>>>>> networking or rebooting makes no difference. Perhaps this menu option
>>>>>> should only appear for root, or should cause an error message for non
>>>>>> root users?
>
>>> If I choose "Automatic (DHCP) addresses only", the labels for the
>>> second and third settings change.  Putting in some test data:
>>>
>>>      Additional static addresses -> Add:
>>> 	Address -> 192.168.123.45
>>> 	Netmask -> 255.255.255.0
>>> 	Gateway -> 192.168.5.1
>>>
>>>      DNS servers -> 192.168.123.45,192.168.123.67
>>>
>>>      Search domains -> frunobulax.org
>>>
>>>      DHCP client ID -> empty
>>>
>>>      Require IPv4 addressing for this connection to complete -> unchecked
>>>
>>>
>>> I then click "Save".
>>>
>>>
>>> I then enter the root password in the pop-up that opens.
>>>
>>>
>>> I then close the "Network Connections" window and reboot.
>>>
>>> 2022-05-12 16:10:25 dpchrist@laalaa ~
>>> $ ls -l /etc/resolv.conf
>>> -rw-r--r-- 1 root root 104 May 12 16:09 /etc/resolv.conf
>>>
>>> 2022-05-12 16:10:34 dpchrist@laalaa ~
>>> $ cat /etc/resolv.conf
>>> # Generated by NetworkManager
>>> search frunobulax.org
>>> nameserver 192.168.123.45
>>> nameserver 192.168.123.67
>>>
>>>
>>> Is this the results you expect?
>
>> I didn't put in a search domain, netmask, or gateway.
>
>
> Put them in and try again.  Without crawling the code, we have no idea
> what actually matters.
>
>
>> I didn't get prompted for root access. Perhaps that is the problem?
>
>
> I would suspect it indicates that Network Manager does not think your
> network settings changed.
>
>
>> stat /etc/resolv.conf shows that the file has been updated but its
>> content doesn't change.
>
>
> My /etc/resolv.conf did not change after running Network Manager; it
> changed after rebooting.  (Is the former a bug or a feature?)
>
>
> What happens if you create a new connection and use the Manual method?
>
>
> If all else fails -- backup, pull the OS disk, insert a blank disk, do
> a fresh install, and restore.  Keep meticulous records.  Use a version 
> control system.  Learn a scripting language and automate sysadmin chores.
>
>
> David

I switched to the mate desktop, and the procedure works, i.e. it prompts
for a root password and updates resolv.conf, after disconnecting and
reconnecting the network.

I expect there is some component of xfce4 which is supposed to prompt
for the root password. Perhaps it is not installed. I don't know what it
is called.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web