Comments page #1 of 2 pages

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

  • Sorry, a little clarification. That bz comment you reference, is related to a Fedora release with systemd.

  • 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: https://bodhi.fedoraproject.org/updates/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.

  • Sorry, we have discovered some issues with the source tarball, so this needs to be rebuilt once upstream have fixed these issues.

  • This update has been unpushed.

  • This update was prepared before the proper CVE bugzillas were created, but here is the reference to them.

    #1450993 - CVE-2017-7478 openvpn: Unauthenticated DoS via large control packets

    #1450997 - CVE-2017-7479 openvpn: DoS due to exhaustion of packet-ID counter

  • This update was prepared before the proper CVE bugzillas were created, but here is the reference to them.

    #1450993 - CVE-2017-7478 openvpn: Unauthenticated DoS via large control packets

    #1450997 - CVE-2017-7479 openvpn: DoS due to exhaustion of packet-ID counter

  • This update was prepared before the proper CVE bugzillas were created, but here is the reference to them.

    #1450993 - CVE-2017-7478 openvpn: Unauthenticated DoS via large control packets

    #1450997 - CVE-2017-7479 openvpn: DoS due to exhaustion of packet-ID counter

  • This update was prepared before the proper CVE bugzillas were created, but here is the reference to them.

    #1450993 - CVE-2017-7478 openvpn: Unauthenticated DoS via large control packets

    #1450997 - CVE-2017-7479 openvpn: DoS due to exhaustion of packet-ID counter

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