On Thu, Jun 09, 2016 at 02:30:50PM -0400, micah wrote: > Package: stunnel4 > Version: 3:5.32-1 > Severity: wishlist > Tags: patch > > Hi, > > It would be nice if stunnel4 had systemd integration, perhaps a unit file > such as the following could be used? > > [Unit] > Description=Universal SSL tunnel for network daemons > After=network.target > After=syslog.target > > [Install] > WantedBy=multi-user.target > Alias=stunnel.target > > [Service] > Type=forking > ExecStart=/usr/bin/stunnel /etc/stunnel/stunnel.conf > ExecStop=/usr/bin/killall -9 stunnel > > # Give up if ping don't get an answer > TimeoutSec=600 > > Restart=always > PrivateTmp=false
Hi,
Thanks for the suggestion, and thanks for the provided sample file!
Also, apologies for not replying sooner.
Actually, I've been thinking about providing a native systemd unit /
service file for quite some time now, and there's just one thing that
has stopped me from doing that: the SysV init script provided by
upstream and used in the Debian package allows the users to have more
than one stunnel service defined in separate /etc/stunnel/*.conf files
and start/stop individual services by running
/etc/init.d/stunnel4 start|stop filename
...thereby starting/stopping the stunnel instance defined in
the /etc/stunnel/filename.conf file.
However... your bug report made me stop and think for a second, and
I figured out (and then tested it) that this does not actually work as
intended on a systemd installation, since there is a file in /lib/lsb/
that redirects all /etc/init.d/* calls to systemctl invocations; well,
systemctl then figures out that there is no systemd service file and
runs the /etc/init.d/ script again, but by this time the "filename"
argument has been long forgotten, and the invocation starts or stops
all of the tunnels defined in /etc/stunnel/*.conf files.
Of course I know that I can run /etc/init.d/stunnel4 with the env var
_SYSTEMCTL_SKIP_REDIRECT set to a non-empty string, but even this does
not really work as intended: if I start a new stunnel instance this way,
it will not be in the /system.slice/stunnel4.service cgroup, and this
will be at the very least inconsistent, if not somewhat broken.
Unfortunately it seems that systemd has no provisions whatsoever for
passing arguments to the service scripts, other than, of course, putting
stuff in environment variables. So, at this point, I'm not entirely
sure what to do. I see a couple of options available:
1. Brace for the inevitable backlash of all three users who actually
*use* the "start/stop individual tunnels" functionality (and have
either not migrated to systemd or not noticed that it doesn't work
any more) and drop the support for it; this would be a deviation from
upstream, but it would bring back consistency and allow us to have
a real systemd service/unit file for stunnel. The main problem with
this is that there might indeed be people who use the "start/stop
several tunnels defined by /etc/stunnel/*.conf files" part even
without the "control them invididually" one; so I'll have to write
a small wrapper for the systemd service that starts and stops several
stunnel instances (come to think, this wrapper might very well invoke
the SysV init script with the _SYSTEMCTL_SKIP_REDIRECT variable
defined... however, in this case I don't see a real benefit to having
a systemd file at all, and removing this functionality altogether
might provoke the more deserved anger of a larger userbase).
2. Keep the half-broken current state and stubbornly insist that there
are actual users of the "start/stop individidual tunnels"
functionality who know what they are doing; to be honest, I don't
really like this option, since the current state is indeed broken
insofar as it advertises functionality that it cannot reliably and
fully provide.
3. Try to write some kind of stunnel control tool as mentioned in
the SysV init script (but that has not actually materialized so far)
that reads a single /etc/stunnel/*.conf file and controls this
particular instance, then use it in the SysV and systemd files,
*then* try to pitch it to Dr. Trojnara upstream and, most probably,
get a "this is not quite the way I intended it" response, since he
does indeed hint at a slightly different implementation. Okay, so
maybe I could write it to parse all the /etc/stunnel/*.conf files and
start/stop services based on section names there, which would
actually be quite close to the idea that he hints at in the init
script. However, even this has a couple of drawbacks: first off, the
name and the command-line options of the tool may not be quite what
Dr. Trojnara has envisioned, and second, I don't think it's even
possible to do that - I don't think it's very easy to place the
newly-started stunnel process into the proper systemd cgroup, not if
the command has been issued from a user shell that might be in a very
different cgroup with various restrictions (cgexec -g does not always
allow you to start a process in a cgroup "better" than your own).
So this might involve a new kind of systemd service - an "overlord"
one that has a control socket and receives "start/stop this stunnel
instance" commands from stunnelctl... by no means impossible, but
possibly another deviation from upstream's ideas.
4. Keep the current half-broken situation for a while while I discuss
all of this, including my ideas for implementing the stunnelctl tool
and the "overlord" service, with Dr. Trojnara.
Honestly, I'm leaning towards option 4 - "further discussion".
I suppose that László Böszörményi (in his capacity of the actual
uploader of stunnel4) has also received this bug report, so if you or
László have any ideas, let me know; otherwise I'll bring this up on the
stunnel-users mailing list in a couple of days.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
