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