Description of problem: When I connect to VPN using the openconnect binary (i.e. _not_ via NM gnome applet), DNS settings received from the VPN don't get applied and it prints the output of "resolvectl" on my screen. I managed to reproduce the problem separately (without the vpn script). It tries to do the following: [root@leonidp-laptop ~]# echo 'nameserver 10.124.57.240 nameserver 192.241.164.20' | /sbin/resolvconf -a tun0 This line _should_ add the two nameservers to tun0 local DNS settings (as seen at resolvectl). However, all it does is print the current DNS settings, like I would have called resolvectl without arguments. Version-Release number of selected component (if applicable): systemd-239-3.fc29 How reproducible: 100% Steps to Reproduce: 1. [root@leonidp-laptop ~]# echo 'nameserver 10.124.57.240 nameserver 192.241.164.20' | /sbin/resolvconf -a tun0 Actual results: resolvectl output Expected results: DNS settings updated in tun0 output Additional info:
Reproduced with /usr/share/doc/openvpn/contrib/pull-resolv-conf/client.up and /usr/sbin/openvpn, see the line 94 in client.up: printf "%s\n" "${out}" | resolvconf -p -a "${dev}" This produces some ugly script output, but the file /run/systemd/resolve/resolv.conf is not affected.
I ran into this problem while using openconnect also, but I don't think just fixing this issue is going to make openconnect work. In the openconnect case, the invocation of resolvconf is from the vpnc-script that openconnect uses to configure the network and DNS. The vpnc-script looks in /etc/nsswitch.conf to see if "resolve" appears on the "hosts" line. If it doesn't, it tries to avoid depending on systemd-resolved. But if it sees the /sbin/resolvconf executable, it uses it. On Fedora 29, however, /sbin/resolvconf is a symbolic link to /bin/resolvectl, and resolvectl just talks to systemd-resolved, which vpnc-script doesn't appear to expect. So on systems where "resolve" doesn't appear on the "hosts" line of /etc/nsswitch.conf, name resolving still won't work. Since this seem to be the default configuration in Fedora 29, even on a freshly-installed system, that's not ideal. To make openconnect work for me on Fedora 29, I had to comment out the lines in vpnc-script that check for /sbin/resolvconf, and use the --script option of openconnect to point to my modified version of vpnc-script.
(In reply to Jim Hennessy from comment #2) > I ran into this problem while using openconnect also, but I don't think just > fixing this issue is going to make openconnect work. In the openconnect > case, the invocation of resolvconf is from the vpnc-script that openconnect > uses to configure the network and DNS. The vpnc-script looks in > /etc/nsswitch.conf to see if "resolve" appears on the "hosts" line. If it > doesn't, it tries to avoid depending on systemd-resolved. But if it sees > the /sbin/resolvconf executable, it uses it. On Fedora 29, however, > /sbin/resolvconf is a symbolic link to /bin/resolvectl, and resolvectl just > talks to systemd-resolved, which vpnc-script doesn't appear to expect. So > on systems where "resolve" doesn't appear on the "hosts" line of > /etc/nsswitch.conf, name resolving still won't work. Since this seem to be > the default configuration in Fedora 29, even on a freshly-installed system, > that's not ideal. > > To make openconnect work for me on Fedora 29, I had to comment out the lines > in vpnc-script that check for /sbin/resolvconf, and use the --script option > of openconnect to point to my modified version of vpnc-script. This is exactly the analysis and the workaround I'm using at the moment. However, according to resolvectl manpage, when it is invoked through the resolvconf symlink, it should work in the compatibility mode, i.e. it should accept the new configuration on stdin and feed it via dbus to systemd-resolved. I.e. this _should_ work (through resolved) whether nsswitch has a resolve line or not, only it doesn't. :) Btw, adding resolve to nsswitch and having vpnc-script use that also works, I tried. This might be the reason why it went undetected.
This seems to be corrected in 239-6.git9f3aed1.fc29. What now? Do I close this bug?
This seems to be the same as https://github.com/systemd/systemd/issues/9423. Please reopen if not fixed in systemd-239-6.git9f3aed1.fc29.
vpnc-script makes the — not entirely unreasonable — assumption that if /sbin/resolvconf exists, it works. We've broken that assumption in Fedora without fixing our vpnc-script package. What is the intended fix?
What do you mean "doesn't work"? With the errata, it should work. If there are further issues, open a new bug.
I'm guessing the last few comments were intended for issue https://bugzilla.redhat.com/show_bug.cgi?id=1648108.