Editing the DNS with Network Manager Non Root

[Richmond]

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?

[David Christensen]

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

[Richmond]

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.

[David Christensen]

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

[Richmond]

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

[David Christensen]

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

[Greg Wooledge]

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.

[Richmond]

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.

[David Wright]

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

[Greg Wooledge]

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.

[David Christensen]

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

[Greg Wooledge]

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

[David Wright]

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.

[David Wright]

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.

[to...@tuxteam.de]

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

[Richmond]

Is there a debian package for this? :

https://aur.archlinux.org/packages/xfce-polkit

"A simple PolicyKit authentication agent for XFCE"

[to...@tuxteam.de]

On Sat, May 14, 2022 at 10:50:46AM +0100, Richmond wrote:
> Richmond <rich...@criptext.com> writes:
>
> > David Christensen <dpch...@holgerdanske.com> writes:

[...]

> > 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.
>
> Is there a debian package for this? :
>
> https://aur.archlinux.org/packages/xfce-polkit
>
> "A simple PolicyKit authentication agent for XFCE"

There seem to be several options [1]. Gksu, some polkit thingy...
Blame my search engine if it fails ;-)


Cheers

[1] https://forum.xfce.org/viewtopic.php?id=11728
--
t

[Richmond]

Gksu is a frontend for su which a developer would apply to an app as I
understand it. I am dealing with an applet, so I cannot edit its icon
and put a wrapper in.

Some polkit thingy would be xfce-polkit I think, but I found no debian
package.

[David Christensen]

I do not see a package specifically for Xfce, but I do see one for MATE:

2022-05-14 15:11:15 root@laalaa ~
# apt-cache search policy kit | sort | grep polkit
gir1.2-polkit-1.0 - GObject introspection data for PolicyKit
libpolkit-agent-1-0 - PolicyKit Authentication Agent API
libpolkit-agent-1-dev - PolicyKit Authentication Agent API - development
files
libpolkit-gobject-1-0 - PolicyKit Authorization API
libpolkit-gobject-1-dev - PolicyKit Authorization API - development files
libpolkit-qt5-1-1 - PolicyKit-qt5-1 library
libpolkit-qt5-1-dev - PolicyKit-qt5-1 development files
lxpolkit - LXDE PolicyKit authentication agent
mate-polkit - MATE authentication agent for PolicyKit-1
mate-polkit-bin - MATE authentication agent for PolicyKit-1 (executable
wrapper script)
mate-polkit-common - MATE authentication agent for PolicyKit-1 (common
files)
polkit-kde-agent-1 - KDE dialogs for PolicyKit
ukui-polkit - UKUI authentication agent for PolicyKit-1



My Debian 11 Xfce has the following, installed by
debian-11.3.0-amd64-netinst.iso:

2022-05-14 15:13:47 root@laalaa ~
# dpkg-query -l '*polkit*'
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===========================-================-============-=================>
ii gir1.2-polkit-1.0 0.105-31+deb11u1 amd64 GObject
introspec>
un gir1.2-polkitagent-1.0 <none> <none> (no
description a>
ii libpolkit-agent-1-0:amd64 0.105-31+deb11u1 amd64 PolicyKit
Authent>
ii libpolkit-gobject-1-0:amd64 0.105-31+deb11u1 amd64 PolicyKit
Authori>
un polkit-1-auth-agent <none> <none> (no
description a>


David

[Richmond]

I got it working! that's the good news, the bad news is I am not sure
how. I installed all the packages above (except polkit-1-auth-agent
which seems to be an unreal package) but it still didn't work. Then I
went into synaptic (which incidentally did not prompt for a password)
and searched for xfce and found some packages relating to the panel
which were not installed, nor part of the xfce meta package. Also I
installed policykit-1-gnome which unfortunately doesn't come up on
searches for polkit. I think this last one may be the culprit but not
sure.

Thanks for your help, and the others.

[Vincent Lefevre]

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

[David Christensen]

On 5/15/22 06:53, Richmond wrote:
> David Christensen <dpch...@holgerdanske.com> writes:
>> On 5/14/22 05:57, Richmond wrote:
>>> <to...@tuxteam.de> writes:
>>>> On Sat, May 14, 2022 at 10:50:46AM +0100, Richmond wrote:

>>>>> Is there a debian package for this? :
>>>>>
>>>>> https://aur.archlinux.org/packages/xfce-polkit
>>>>>
>>>>> "A simple PolicyKit authentication agent for XFCE"

>> My Debian 11 Xfce has the following, installed by
>> debian-11.3.0-amd64-netinst.iso:
>>
>> 2022-05-14 15:13:47 root@laalaa ~ # dpkg-query -l '*polkit*'
>> Desired=Unknown/Install/Remove/Purge/Hold
>> |
>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name
>> Version Architecture Description
>> +++-===========================-================-============-=================>
>> ii gir1.2-polkit-1.0 0.105-31+deb11u1 amd64 GObject
>> introspec>
>> un gir1.2-polkitagent-1.0 <none> <none> (no description a> ii
>> libpolkit-agent-1-0:amd64 0.105-31+deb11u1 amd64 PolicyKit Authent> ii
>> libpolkit-gobject-1-0:amd64 0.105-31+deb11u1 amd64 PolicyKit Authori>
>> un polkit-1-auth-agent <none> <none> (no description a>
>
>
> I got it working! that's the good news, the bad news is I am not sure
> how. I installed all the packages above (except polkit-1-auth-agent
> which seems to be an unreal package) but it still didn't work. Then I
> went into synaptic (which incidentally did not prompt for a password)
> and searched for xfce and found some packages relating to the panel
> which were not installed, nor part of the xfce meta package. Also I
> installed policykit-1-gnome which unfortunately doesn't come up on
> searches for polkit. I think this last one may be the culprit but not
> sure.
>
> Thanks for your help, and the others.

I would say "you are welcome", but it sounds like your system is in a
crumbling state. I would backup/ check-in, pull the OS drive, insert a
fresh OS drive, do a fresh install, and check-out/ restore/ reconfigure.


David

[David Wright]

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.

[Richmond]

It isn't in a crumbling state, it just had a missing package. And this
was probably due to an undeclared dependence.

[Greg Wooledge]

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.

[David Wright]

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.

[David Wright]

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.