OpenVPN
Add support for resolvconf interface
For systems with more complex DNS configurations, that also do not want to use systemd-resolved, it would be convenient to add support for resolvconf interface, in the same way as NetworkManager also supports this.
Do you have any pointers to how NetworkManager integrates with resolvconf?
The challenge with /etc/resolv.conf based DNS resolver configuration is that it does not support split-DNS. So I don't quite fully understand how that fits into "more complex DNS configurations". Using only /etc/resolv.conf will always send DNS queries to the first responding nameserver line.
I've been pondering on adding support for dnsmasq support, though, which can also be used by NetworkManager as well. There might still need to be a few "running methods", depending on if NetworkManager is to be involved or not.
Otherwise, to use a similar approach to resolvconf interacting directly with /etc/resolv.conf, OpenVPN 3 Linux can use that as well instead of systemd-resolved:
# openvpn3-admin netcfg-service --config-unset systemd-resolved
# openvpn3-admin netcfg-service --config-set resolv-conf /etc/resolv.conf
Then you need to ensure the openvpn3-service-netcfg service is stopped and restarted. This will require all VPN sessions to be stopped first; this process is responsible for providing the tun/dco interfaces to the VPN client processes (openvpn3-service-client).
Do you have any pointers to how NetworkManager integrates with
resolvconf?
Closing due to lack of response.
Whoa?!
There nowadays even is a Wikipedia article on resolvconf if you had diffitusties to find it other ways, and the origival resolvconf project documents the interface under "Usage information for developers".
So what you'd ideally do, is check presence of resolvconf and then use it as documented instead of overwriting the /etc/resolv.conf.
@cd-eho If you're on a system running that version of resolvconf (there are more variants of it; I've lost track if which one is used in which distro) .... then you should really consider using systemd-resolved instead.
The systemd-resolved does not need any special privileges (resolvconf typically need to be run as root) except what is granted via the polkit policy. And it supports split-DNS out-of-the-box.
OpenVPN 3 Linux is designed to run with as little privileges as possible. systemd-resolved fits well into this scope; where even the --resolvconf feature is stretching this far too long - giving the process more privileges than it really should have. Since there has been less than a handful requests for the /usr/{,s}bin/resolvconf approach since the v10_beta release (July 2020) plus that supporting that approach would mean implementing additional layers to handle privilege separation properly (you need to pipe data to a process running as root) .... this is not going to get much priority unless someone is willing to provide the needed patches to add this support in an appropriate way. Currently those requesting this feature is extremely few. (We have more requests for 32-bit OS support, which is also very low - to set this in perspective).
systemd-resolved should, as far as I understand, be enabled by default in Debian 12 and Ubuntu 18.04 and newer. Debian 11 and older are already EOL (and Ubuntu 20.04 and newer are the only non-EOL Ubuntu releases). Other distros have also enabled systemd-resolved by default - with the RHEL-8 and RHEL-9 as the only exception of officially supported distributions.
Basically, disabling systemd-resolved on a modern LInux distribution should have pretty strong reasons, based on that it is the default on most common distributions today.