Bug 1381413
| Summary: | OpenVPN package does not install resolv.conf-manipulation scripts | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | W. Michael Petullo <mike> |
| Component: | openvpn | Assignee: | David Sommerseth <dazo> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 29 | CC: | dazo, gwync, huzaifas, steve |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-12-20 23:55:26 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
W. Michael Petullo
2016-10-04 03:36:27 UTC
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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. 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. 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/
|