[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Seeking help with OpenVPN scripts and systemd



On Tuesday, 9 de September de 2014 16:51:20 Alberto Gonzalez Iniesta escribió:
> AltSubject: For those who care about OpenVPN
> 
> Dear fellow developers,
> 
> This is a cry for help. I've been trying to support systemd in OpenVPN for
> some time, but the results are not satisfactory. I'd like to keep the
> current (SysV) behaviour in systemd but it's becoming quite an annoying
> task.
> 
> I'd love to hear recommendations, receive patches or any other help with
> this. Let me explain what the SysV init script did, so you can figure out
> what I'd like to achieve. If you aren't interested in the task you may
> skip the rest of this mail.
> 
> What was working?
> -----------------
> 
> First of all, openvpn in Debian is able to run several VPN daemons.
> Depending on the value of the configuration variable AUTOSTART (in
> /etc/default/openvpn): - all -> A daemon for each of the configuration
> files found in /etc/openvpn - none -> Do not manage any VPN (they can be
> started manually or through a directive in /etc/network/interfaces
> - A list of the VPNs you want automatically managed (i.e. AUTOSTART="work
>   home"). The rest can be managed manually.
> 
> In order to be able to control individual VPNs the init.d script accepts a
> second argument (after start/stop/...) with the name of the VPN to manage.
> I know this was a hack, but it worked like a charm. This is no longer
> possible with systemd.
> 
> stop, reload, soft-restart and cond-restart will only affect running VPNs.
> The last one is specially important in upgrades, when the currently running
> daemons have to restart. That includes those VPNs that are managed
> automatically (in AUTOSTART) *and* those started manually or through a
> network/interfaces directive. Whereas restart will only affect those
> managed automatically unless a VPN name is specified.
> 
> In addition to the init.d script, there are two script in
> /etc/network/if-(up|down).d/openvpn that allow for VPNs to be managed when
> interfaces are brought up or down. So you may have AUTOSTART=none, or
> AUTOSTART="home office", and then enable "work" tunnel when only when using
> a specific network interface.
> 
> Where are we now?
> -----------------
> 
> The latest version of openvpn's package (in experimental) includes two
> service files for systemd. One instantiated (openvpn@.service) allows the
> control of single VPNs, piece of cake.
> 
> The main issue is with the other one, openvpn.service, that tries to
> replace the old init.d script and all its features. It is, currently,
> calling a helper script that (tries to) mimic(s) the former behaviour.
> 
> First of all, the script can only be called with start, stop or reload
> arguments. So no distinction can be made between a restart and a
> stop-then-start. So there's no way (i.e.  on an upgrade) to restart all
> VPNs (those in AUTOSTART *and* those manually controlled), since "start"
> and "stop" should only manage those in AUTOSTART.
> 
> Another problem is the package upgrade to systemd in a running system,
> since the VPNs started with the current init.d script are not recognized
> by openvpn@NAME.service. So when upgrading the package from the
> non-systemd-enabled package (< 2.3.2-7) to the package with the service
> files, we end up with two active VPNs (the one that was running, and one
> started by systemd) for each AUTOSTARTed configuration.
> 
> If you know systemd and would like to help with this please Cc: me (since
> I'm not subscribed to -devel) or mail me directly. You may find the
> current git repo for openvpn in Debian at:
> git.debian.org/git/collab-maint/openvpn.git
> 
> Thanks,
> 
> Alberto

Hi Alberto

openvpn package should Conflitcs systemd in order to avoid systemd being 
installed and so messing with OpenVPN-working systems, until systemd gets 
appropiately fixed or you get a workaround.

Regards

er Envite

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: