An updated 2.5.7-2 build is now on the way into updates-testing. Please test this build and give the appropriate votes. Since this update caused so much issues and regressions, the 2.5.7-2 build requires more +1s than I normally require.
Upstream has sent a patch to the mailing list to be considered: https://patchwork.openvpn.net/patch/2504/
I've put together a few quick test builds
If some of you can do a quick test of those build to see if that helps, I can get a 2.5.7-2 prepared later this weekend.
This contains more related details as well: https://bugzilla.redhat.com/show_bug.cgi?id=2093069
@thm How do you start your client? Via the
openvpn-client@.service systemd unit or NetworkManager?
Input and in the BZs here will be brought up with the upstream community as well
@dpsh This is the expected behaviour. With OpenVPN 2.5, the openvpn binary no longer executes
ip commands. It integrates directly using the Netlink interface, provided by the Linux kernel, to configure the tun/tap intefaces and routing.
That is right. The tmpfiles.d stuff is related to systemd, which is EL7 and any Fedora releases after 17 or so. And /var/run/openvpn is packaged properly in openvpn-2.4.2 and openvpn-2.4.3, so this is no longer an issue. The openvpn-2.4.1 package this update is about, is obsolete and outdated.
Please test a far newer OpenVPN release. This release is obsolete. OpenVPN 2.4.3 was put submitted 5 days ago.
$ rpm -ql openvpn | grep run /var/run/openvpn $ rpm -q openvpn openvpn-2.4.3-1.el6.x86_64
This should not be an issue at all. You can find it here: FEDORA-EPEL-2017-9ec615ff74
Btw. the bz you reference is also an invalid reference. That is related to Fedora 26, which relies on systemd and its tmpfiles service. That does not exist on EL6.
@fkooman, Fun fact: I got complaints that updates didn't restart the openvpn services.
Yes, it should restart all profiles on the server. It is not something we can change now; the cat is already out of the bag. So the next update will restart the service anyhow, also if we add some "tunable feature" in the next update - it will be restarted regardless.
But I can look at adding a "don't restart" feature. For example something like checking if a file named /etc/openvpn/server/.update-no-restart exists or not. I'm not saying that's how it will be, but that is one plausible solution.
So to the longer answer why this was changed. When I cleaned up the .spec file, a lot of moving parts had to be changed at the same time (otherwise we wouldn't be finished with the clean up until after the next 5-6 updates). A lot of the changes involved moving over to standardized RPM macros for doing a lot of things. So I chose to ensure we don't break running services needlessly on automated updates until the dust had settled a bit. And now it felt like the right time to do what most users expects.
I've run openvpn-2.4.1-2.el6 on a SL6.7 since March 23 and 2.4.1-3.el6 since April 10. Both configured with server and client configurations. Everything works as expected in those configurations. The 2.4 release have otherwise been pushed out for el7, where the main difference is that el7 is systemd based and el6 still uses init.d scripts. So considering this to be reasonably safe.
The old approach or using the simpler Type=simple approach could havoc if the config file itself contains --daemon.
Just noticed this is slightly too much simplified and wrong.
The old approach had to use --daemon, as Type=fork tells systemd "this process forks a child process". Otherwise it would fail. And then it was required to use a PID file so systemd actually could manage the process somewhat.
Using just Type=simple (which is the default, if Type= is not provided) will fail if the OpenVPN configuration uses --daemon, as then the OpenVPN processes forks of a child process, daemonizes it and the parent process quits. Systemd would then be confused by this, as it doesn't expect the (parent) process to quit just like that.
So with Type=notify, OpenVPN actually detects that it is systemd who started the process, and then provides a "status string", including its PID value via sd_notify() inside the OpenVPN process directly. And when this is done, OpenVPN just ignores forking daemonizing if --daemon is provided, as that is not needed with this approach. So if a configuration file carries --daemon, it doesn't break anything by confusing systemd by the forking and daemonizing steps.
The second part of my answer in comment #9 in #1435831 actually answers that. The TL;DR answer is that OpenVPN v2.4 can talk directly to systemd and does not need to use PID files and a directory where to save them. This is solved by using Type=notify, which OpenVPN detects and uses sd_notify() under the hood.
In addition, if not using that approach but using Type=simple instead of Type=fork which the previous unit file used, the need to use both --daemon and PID files also goes away. So the approach used in the old unit file actually never was a good solution at all, making it unnecessary complicated by needing a tmpfiles.d config in addition.
However, using Type=notify have the advantage of ignoring --daemon in OpenVPN configuration files automatically. Which is not needed. The old approach or using the simpler Type=simple approach could havoc if the config file itself contains --daemon.