Re: systemd-resolved/NetworkManager resolv.conf handling

[Barry <barry@xxxxxxxxxxxxxxxx>]

> On 2 Nov 2022, at 15:20, Thomas HUMMEL <thomas.hummel@xxxxxxxxxx> wrote:
> 
> On 10/31/22 12:19, Petr Menšík wrote:
> 
> Hello, thank you and Barry as well for your answers
> 
> 
>> I would suggest using strace to find what exactly it does and what it tries to modify. I expect sources for that client are not available.
> 
> Well, digging a little deeper, here's what I've found out:
> 
> 1) in the default case (described in my initial post), i.e.
> 
>    /etc/resolv.conf symlinked to systemd-resolved /run/systemd/resolve/stub-resolv.conf
>    no dns nor rc.manager directives in NM config
>    no F5 client NM profile
> 
> The vpn client:
> 
>    a) backs up /etc/resolv.conf to /etc/resolv.conf.fp-saved
>    b) readlinks the symlink
>    c) execve's /sbin/resolvconf providing nameservers (thus trying to play along with systemd-resolved) but on the wrong interface on my Fedora (eth0.f5 instead of tun0) [besides with a deprecated and not used arg (-m)]
> 
>    execve("/sbin/resolvconf", ["/sbin/resolvconf", "-a", "eth0.f5", "-m 0"], 0x7ffd13bf8568 /* 30 vars */ <unfinished ...>

So a dirty hack is to replace /sbin/resolvconf with a script that does-the-right-thing.
Uses resolvectl on the correct interface etc. But only when called by F5.

Clearly F5 vpn software is in need of updating to support options for modern linux.
Have you tried raising an issue with F5?

Barry

> 
>    d) set up tun0 interface and bring it up
> 
> -> hence we end up with:
> 
>    a) /etc/resolv.conf.fp-saved as a regular file, copy of /run/systemd/resolve/stub-resolv.conf
>    b) NM managed tun0 interface without and dns property in its profile nor any disk persistent profile
>    c) unchanded /etc/resolv.conf (still linked to /run/systemd/resolve/stub-resolv.conf
> 
> so, systemd-resolved not knowing about vpn nameservers and vpn nameresolution fails without workaround (like resolvectl dns adding the tun0 nameserver for instance)
> 
> 2) with NM handling /etc/resolv.conf as a regular file, i.e.
> 
>   /etc symlink rm-ed
>   dns=default
>   rc.manager=file
> 
> the F5 client consider it a 'legacy' setting and overwrite (which is wrong to me) NM managed /etc/resolv.conf regular file
> 
> it restores it when stopped by copying back /etc/resolv.conf.fp-saved
> 
> So, basically I'd say there are 2 bugs :
> 
> 1) legacy handling which seems to consider pre-NM era legacy
> 2) resolvconf call when systemd-resolved is used (at least on Fedora)
> 
> In any case, I don't understand why it does not set the NM profile ipv4.dns property, which would let much more chances for NM and/or resolved to work
> 
> Anyway, this leaves 2 unanswered questions, the first of which was my initial one:
> 
> 1) how could, when all resolv.conf-as-a-file-by-NM conf has been removed (by me) and symlink to stub has been restored (by me) systemd-resolved, with *no trace* of the vpn  nameservers in its own /run/systemd/resolv/resolv.conf nor seemingly nowhere else, can be still aware of the vpn nameservers (as described in my initial post scenario) ?
> 
> -> is there a persistent systemd-resolved cache on disk somewhere ?
> 
> 2) when running resolvconf by hand (resolvconf <int>) providing specific interface specific nameservers (on stdin), it seems to update the **global** /run/systemd/resolve/resolv.conf (hence making those nameservers available for all interfaces ?)
> 
> -> Is there any other place where the specific ns <-> interface is persited or stored or is this global updating all there is ?
> 
> Thanks for your help
> 
> --
> Thomas HUMMEL
>