As a folow up to #448884, here is another take at a service unit for openvpn: For whatever reason the unit currently shipped uses Type=forking and the PID file that goes with it, although systemd's design discourages this and openvpn easily allows for the service not to daemonise itself. The attached patch changes the unit to have systemd handle all supervision, gets rid of the PID file and also uses systemd to setup the working directory for openvpn. The tmpfile added in #448884 to create /var/run/openvpn is rendered obsolete by removing the PID file. TIA for considering Reproducible: Always
Created attachment 353538 [details, diff] proposed openvpn@.service change
Also it would be nice to have support for up.sh/down.sh scripts.
Right. As a starting point, I use this one on client machines: ExecStart=/usr/sbin/openvpn --config "/etc/openvpn/%I.conf" --up-delay --up-restart --script-security 2 --up /etc/openvpn/up.sh --down-pre --down /etc/openvpn/down.sh --setenv PEER_DNS yes That basically adapts the client branch (i.e. if PEER_DNS is "yes") in the openrc init script, it's not the way to go for servers.
Alexander, I think it's better to keep up.sh/down.sh support our of unit file and use --up/--down config file options. Calling scripts requires higher value script-security and thus our installation will be less restrictive by default. Agree? Malte, as for other systemd improvements. Fedora and arch[1] have same systemd unit files. Are there any real benefits behind these improvements? If not I'd better stay with something everybody use (to ease maintaining). So I'm inclined to close this bug as WORKSFORME until something really worth to improve will be found. [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/openvpn@.service?h=packages/openvpn P.S. I suggest to add patch from bug #515982 to improve openvpn handling in Gentoo with systemd.
Sure thing, if the unit file is more uniform accross distributions that way, I'm all in favour of that. Still wondering why there are quite a few units in distros as well as upstream that use forking when a non-forking solution is just as easy or even less cluttered with options, pid files etc. Maybe just a matter of habit. Anyway, I guess having consistent units is a Good Thing, too.
(In reply to Peter Volkov from comment #4) > Alexander, I think it's better to keep up.sh/down.sh support our of unit > file and use --up/--down config file options. Calling scripts requires > higher value script-security and thus our installation will be less > restrictive by default. Agree? Agreed. We should not bloat the unit file. I totally forgot that these options can be added to config file. :)
Great that we discussed this then and found comprise. Closing.
