Comments
dsommers
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.
@fkooman, Those issues we've discussed should be covered by this new openvpn-2.4.1-2.el7 build. This build should not break openvpn@.service units upon boot any more.
This update has been unpushed.
Yes! I have received some positive reports on these exact changes in F25 and F26, so I will update this update with a new build during today. Bugzilla #1435831is the one covering this issue.
@anonymous, This sounds like an invalid tls-auth key file. Earlier versions could somehow try to make some sense out of it. But most commonly that would result in a weaker security compared to using a proper key file. The reason I believe this is due to the last part of the line "(0/128/256 bytes found/min/max)". It means it didn't find any keying material at all, and it expects at least 128 bits.
Users experiencing these issues must update their keys ASAP, regardless of OpenVPN version. The recommended way is to let OpenVPN generate the key: $ openvpn --secret tls-auth.key --genkey
@dimitrisk, I will have a new 2.4.1-3 update soon which takes care of the /etc/openvpn/{client,server} directories and fixes a lot of the rpmlint issues as well.
@alexpl, I completely agree that the process around v2.4 have been incredibly ugly. I appreciate the work of former package maintainers, they've done a great job over a long period of time. Unfortunately, the state of the package had drifted away from upstream expectations and there was a lot of legacy cruft which in several areas was just wrong. So despite the v2.4 upgrade not really being this dramatic, it turned out way more ugly than I wanted. And in all this, I didn't consider the state of openvpn@.service carefully enough. The initial plan was that users of openvpn@.service wouldn't notice this at all in F25 and F26, but there were some entanglements I didn't consider carefully enough. Depending on how F25/F26 goes with all this fixed, I will consider if openvpn@.service deprecation will be postponed from F27 to F28. And I will certainly send mails to Fedora ML once the dust settles. Silly of me not doing that in the beginning.
Again, I'm truly sorry about this mess. But I'm the type of person who seldom looks back and rather tries to fix issues ASAP and move forward.
Sorry! The wrong build was added to this one. It should be openvpn-2.4.1-3.fc26. Fixing now.
This update has been unpushed.
@fkooman, there is a potential issue with this update where OpenVPN will not start after a reboot if using the old and deprecated openvpn@.service units. The new ones (openvpn-client@.service and openvpn-server@.service) should work fine.
I will backport several of the packaging enhancements from rawhide and F25 which should resolve this issue - and a few other ones as well. Hopefully I will manage that this week.
@thm, that is hardly an OpenVPN package issue. That is an issue which needs to be solved by NetworkManager-openvpn plug-in, which is outside maintained by the NetworkManager team.
You can also "workaround" this by either adding just the IPv4 addresses to the appropriate hostname in /etc/hosts ... or by using an IPv4 address instead of a hostname in NetworkManager.
Confirming the 2.4.3.4-1.el7 works as expected.
Sorry! I now spotted my testing was against the wrong version in epel-testing.
The issue in bug #1429542 is NOT fixed in this update.
This update has been unpushed.