Bug 1381413 - OpenVPN package does not install resolv.conf-manipulation scripts
Summary: OpenVPN package does not install resolv.conf-manipulation scripts
Alias: None
Product: Fedora
Classification: Fedora
Component: openvpn
Version: 29
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: David Sommerseth
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-10-04 03:36 UTC by W. Michael Petullo
Modified: 2018-12-20 23:55 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-12-20 23:55:26 UTC
Type: Bug

Attachments (Terms of Use)

Description W. Michael Petullo 2016-10-04 03:36:27 UTC
Description of problem:
The OpenVPN package includes two scripts at /usr/share/doc/openvpn/contrib/pull-resolv-conf/: client.up and client.down. These scripts update /etc/resolv.conf upon bringing up and down a VPN interface, respectively. It would be nice if these scripts were instead installed somewhere reasonable with executable permissions. This would allow the use of the "up" and "down" keywords in an OpenVPN configuration. I manually copied the scripts to /etc/openvpn, but having the package properly install them would make the scripts appear more "supported".

The scripts appear to work once they are installed and referenced from an OpenVPN configuration.

Version-Release number of selected component (if applicable):

Comment 1 Fedora Admin XMLRPC Client 2017-03-14 12:15:31 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 David Sommerseth 2017-04-24 17:43:52 UTC
Currently, those scripts are "contrib" scripts which is fairly unsupported upstream - and mostly only fixed if there are patches coming in.

That said, how Fedora have evolved with systemd, networkd and NetworkManager, we need something far better than these scripts if we are going to install anything by default.  I currently see these scripts as workaround solutions.

I acknowledge that these scripts mostly works, but it should be handled by informing networkd or NetworkManager over a D-Bus calls that there are new DNS resolvers to be used.  This way you can ensure it won't be a clash between the various mechanisms trying to manage all your network connections, plus you would avoid all types of various SELinux and other permission related issues.  This solution is also something which should be provided to the upstream project before coming into a Fedora package.

So based on this I'm closing this as a WONTFIX for now.  If you disagree, let's have a discussion about possible ways to resolve this.

Comment 3 W. Michael Petullo 2018-12-20 03:20:32 UTC
The sample client.up script installed with openvpn-2.4.6-3.fc29.x86_64 makes use of resolvconf. This seems compatible with systemd-resolv.

I would be willing to help write a better script if you could suggest how to do this. I am somewhat familiar with D-Bus, but could use some help identifying the D-Bus interfaces used to manage DNS by way of NetworkManager. I must admit, I am a little confused as to why resolvconf is not a good solution, since I thought this was the way to programmaticly adjust systemd-resolv's configuration.

I did come across an SELinux denial related to the interaction between client.up and resolvconf; see bug #1661065.

Comment 4 David Sommerseth 2018-12-20 23:55:26 UTC
I've had a a few longer discussion with NetworkManager developers at devconf.cz in 2018.  And from what I was told, there is no D-Bus interface available to just manage DNS settings.  NetworkManager expects to manage the complete interface to be willing to also manage the DNS settings.  Which is how the nm-openvpn plug-in kind of works, excepts it is far more intrusive as that approach also wants to manage and own the VPN process as well.

I've also had several discussions with one of the systemd-resolved developers as well in regards to integrate with this interface.  But it was generally recommended to look a solution with NetworkManager; which will require larger changes to NM.

I'm heavily involved in the openvpn3-linux [1] project nowadays, and this provides a way to tackle /etc/resolv.conf directly for now (but this will be expanded to support more alternatives in the future, systemd-resolved is one alternative).  We are also considering to look into the efforts of using the same "network config service" from openvpn3-linux in openvpn2; which would make it possible to start openvpn 2.x completely unprivleged and still get tun interfaces configured with routes and DNS.

But this all stems down to a single, annoying detail:  Who owns and manages /etc/resolv.conf ?

My current impression is that everyone expects it to keep their changes while nobody (process wise) wants to take ownership of that file - which is doomed to fail when you start with VPNs and more dynamic network environments.  And that all results in fun issues SELinux and lost DNS settings when the network changes.  The approach openvpn3-linux currently uses is far from ideal, but as a unexpected side-effect it actually takes more ownership of /etc/resolv.conf, simply because the SELinux file context ends up being wrong - so no other processes running contained cannot manipulate /etc/resolv.conf as long as it is still being managed by openvpn3-linux - which makes NetworkManager somewhat grumpy.

I'm closing this again, as this ticket is about installing client.{up,down} scripts as executables for manipulating DNS settings on a system.  This will currently not happen.  Something far better needs to be done, which is a different issue thus requires a different ticket - which should be handled in the upstream OpenVPN Trac system.

[1] https://github.com/OpenVPN/openvpn3-linux
    Fedora Copr packages: https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/

Note You need to log in before you can comment on or make changes to this bug.