Comments

41 Comments

@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.

karma

Confirming the 2.4.3.4-1.el7 works as expected.

BZ#1429542 tripwire cron.daily e-mail address check fails

Sorry! I now spotted my testing was against the wrong version in epel-testing.

BZ#1429542 tripwire cron.daily e-mail address check fails

The issue in bug #1429542 is NOT fixed in this update.

BZ#1429542 tripwire cron.daily e-mail address check fails
karma

Tested on an up-to-date CentOS production server, acting as an OpenVPN client. Works very well.

BZ#1391481 openvpn-2.3.13 is available
karma

Tested on two up-to-date Scientific Linux 7.2 x86_64 production servers, one acting as server the other as client. All works very fine. Using latest upstream systemd unit files [1] instead of the much simpler ones packaged in EPEL.

[1] https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12764.html

BZ#1391481 openvpn-2.3.13 is available
karma

Updated two openvpn clients from 2.3.6 to 2.3.7 on ScientificLinux 6.6 without any issues.

karma

Upgraded from 2.3.6 to 2.3.7 on ScientificLinux 7.1 without any issues. This box runs openvpn as a server.

Smoke tested both TUN and TAP mode on RHEL 5.8 without any issues.

Tested tun and tap mode on RHEL6.3 successfully

Done some smoketesting on RHEL5.5, looking good.

Smoke tested on RHEL5.4 x86_64, looks good! The same python-dmidecode version (3.10.7) is already shipped as part of Red Hat Enterprise MRG and works well there as well. The EPEL version have only fixed a few packaging errors. Will move this one to stable rather quickly, unless somebody finds something really bad.