On 02/01/2019 07:35, Samuli Seppänen wrote: > Hi, > > Il 31/12/18 01:08, David Sommerseth ha scritto: [...snip...] >> And IIRC, we managed to get the new unit files into the Debian openvpn 2.4 >> package. And I just hope that they are updated with whatever we provide in >> our tarballs; if not - it might be considered broken packaging. The reason >> you'll find the b0rken unit files in the upstream Debian packages is to not >> break old existing installs. Which is nice, just that it behaves broken >> regardless. > > And this is exactly the reason I did _not_ remove openvpn.service or > openvpn@.service from our Ubuntu 18.04 packages.
Okay, I was a bit unclear. The approach used with openvpn.service and
openvpn@.service are broken by (Debian) design. Quite many users have
reported that these service files does not work at all. But I'll admit, I'm
not really up-to-date if these service files have been updated by
distro-packagers later on.
It would be far better to pop up a README file at install/update time saying
"These unit files are gone, use the new ones instead." The reason is that
_our_ packages are different than Debian's packages, so they shouldn't need to
try to duplicate the Debian packages in every detail.
Secondly, if OpenVPN is built with systemd support there are a few other
surprises some users have reported to me, when not using the unit files which
makes use of the openvpn<->systemd interface in the C code. We even do some
intercepts related to the --daemon if systemd is detected, where it is
effectively ignoring --daemon (as that is not needed with the new systemd
files). My memory is blurry here, though.
The alternative is to provide an alternative to openvpn@.service, which does
not add all the client and server specific hardening, automatic restarts, etc,
etc, but ensures the openvpn<->systemd interface is intact.
But for the openvpn.service, there is no alternative to killing it. It's an
odd approach where it, IIRC, generates new unit files on-the-fly for specific
openvpn configs and then starts them. I have some vague memories that it
would even overwrite existing unit files. It is just generally a horrendous
approach, which tries to make the unit (ini) file behave like the old rc init
shell script. It feels list it tries to build a space rocket out of a
trolley; I'm not saying it's impossible, it's just not pretty and might even
be quite unsafe in many aspects. Some times it is needed to draw a line and
say: From here we do it differently.
>>
>> So if anyone is in doubt ... UPGRADE to the openvpn-{server,client}@.service
>> unit files ASAP.
>
> I'll mention this in the README.Debian. I added a short "notes from
> upstream" section there anyways.
>
> Do you have links to bug reports that would clarify why the old unit
> files are broken? If I'm not mistaken one of the issues was related to
> OpenVPN on Amazon EC2 and status check #2 not passing when an instance
> of openvpn@.service was running.
That's one of the issues. I've gotten several reports since the v2.4 release,
covering all kind of scenarios as well, the vast majority of those issues
disappeared when switching to our new ones. I have discussed this many times
on IRC, I know there existed some issues both in Trac and elsewhere - but
right now I don't have a good list of them handy.
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
