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

Hi Guys,

I, as the upstream maintainer, strongly support option 1, that is to
drop supporting multiple instances of stunnel.  My rationale is:

1. It breaks systemd integration (verbosely discussed in this thread).

2. It is no longer useful after the "include" configuration file option
was introduced.

3. My long-term plan for stunnel is to introduce "stunnelctl" (similar
to "apachectl") to control the daemon.  This tool will not support
multiple instances of stunnel anyway.

It would be great to have it in Debian stretch...

Best regards,
	Mike

Hi,

I also have the problem here that systemctl start only starts the
first of my configured stunnels.

The most irritating problem for me is that the /etc/stunnel/README
still suggests that everything should work as designed, so I wait and
wait for the bug to get fixed.

Systemd fails to detect if the tunnels are running fine, and then it
can't start them. If I start services manually, systemd cant detect if
they are running because of some namespace magic, which shure is not
neccessarily bad just because I did not found a proper documentation
about that.

So lets face it: Right now, only one .conf file is supported. And it
is most likely that it will stay that way unless some sort of auto-add
for systemd services will be done.

As far as I remember openVPN has a similar issue, too.

So the solution for now for Stunnel for me will be to provide a some
sort of Makefile or update-stunnel4 shellscript which creates an
stunnel.conf from several stunnel.connection files and fire that on
each .connection file change right before I tell my puppet client to
check for the stunnel4 service.

regards
    Hans

For quite some time I've had a laptop, running stretch, with stunnel4
installed, with a single /etc/stunnel/foo.conf file, and after network
changes (switch WiFi network, fix broken DNS, etc.), I've found that
'systemctl restart stunnel4.service' doesn't actually restart the
stunnel4 process, and that I have to resort to manual 'killall -9
stunnel4'.

Today I decided to look at the state of stunnel and systemd, and I am
now running a setup that works quite well, utilizing systemd socket
activation introduced in stunnel 5.05.  Server is running jessie, with
stunnel4 3:5.30-1~bpo8+1 jessie-backports package, and systemd
215-17+deb8u6 jessie packages.  Clients are running stretch, with
stunnel4 3:5.39-2 and systemd 232-22.  Each host has two services
defined in /etc/stunnel/stunnel.conf, thus the stunnel4.socket unit has
two ListenStream= directives that match the the 'accept' parameters in
the stunnel.conf.

Initially I had thought this setup wouldn't work, I had been worried
that stunnel's systemd socket activation would behave exactly like inetd
activation, wherein the stunnel manual explains that INETD MODE is
basically one-stunnel-daemon-per-port and cannot distinguish multiple
services in a single configuration.  However after review of the source
code and some experimentation I found this is not the case.  The stunnel
daemon will enumerate the services defined in it's config and verify
that an equal number of FD's have been passed via sd_listen_fds.
However there is a caveat that the order of service declaration has to
match the order of ListenStream= directives, but luckily according to
sd_listen_fds(3) "If a daemon receives more than one file descriptor,
they will be passed in the same order as configured in the systemd
socket unit file".

I love it!  stunnel now starts on-demand, rather than at boot up, and
should the need to restart ever arise, 'systemctl stop stunnel4.service'
is reliable.

Furthermore, I added various systemd hardening directives.

Attached are the socket and service files.

On Mon, 27 Jun 2016 13:03:09 +0300 Peter Pentchev wrote:
 >
 > 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.

Hello,

Hopefully clicking reply in the web UI routes this to the correct place.

I've been using a systemd unit file for stunnel4 that *does* support
essentially the same thing as the init.d script.

Consider:

[Unit]
Description=Universal SSL tunnel for network daemons (%i)
After=network.target
After=syslog.target

[Service]
Type=forking
ExecStart=/usr/bin/stunnel4 /etc/stunnel/%i.conf
PIDFile=/var/lib/stunnel4/redis.pid
TimeoutSec=600
Restart=always
PrivateTmp=yes

[Install]
WantedBy=multi-user.target Alias=stunnel4.service

---

Starting a specific stunnel with this is achieved with

     systemctl start stunnel4@<name>.service

Within the systemd unit file, all occurrences of %i are replaced with
<name>.

I think this meets the requirements you described. It even allows enabling
and disabling specific stunnels for start at boot time.

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

[snip example file for a single stunnel instance]

...and I guess I should have marked this bug as fixed in version
3:5.56+dfsg-7 of the stunnel4 package; quoting from its NEWS.Debian file:

  For Debian installations running systemd, it is now possible to
  enable and start stunnel instances controlled by individual
  configuration files in the /etc/stunnel directory. The stunnel@
  service template, when instantiated, will start an stunnel process
  and look for an /etc/stunnel/<instance>.conf file.

  User services are also available under systemd: if started via
  `systemctl --user start stunnel@instance.service`, stunnel will
  look for a ~/.config/stunnel/<instance>.conf file.

  Please note that in both cases, the service files use the "simple"
  systemd service type, so the configuration must include
  a "foreground = yes" setting.

  To prevent confusion with the `stunnel4` systemd service that is
  automatically generated for the /etc/init.d/stunnel4 file,
  the SystemV stunnel4 service is NO LONGER automatically enabled.
  This means that new installations on Debian systems that use
  the SysV init package will need to enable the stunnel4 service.

Hello,
It looks to me as if https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826883#37 ,
from Mon, 24 Jul 2023 10:48:19 +0300 answers my severity raising request
sent on 24 Jul 2023 too. I am not micah at riseup.net. For completeness,
here are the my arguments from the serverity raising request:

    Setting higher severity because:
    My understanding is for bookworm, systemd-sysv-generator is used when no
    @instances used. This, in turn, will use $remote_fs from the LSB header
    at /etc/init.d/stunnel4. Which is converted by the generator to
    After=remote-fs.target. But the unit for remote-fs.target has
    DefaultDependencies=no. Which might cause stunnel4 to run before
    network-online.target. And fail. One solution can be to have $network at
    the LSB header of the /etc/init.d/stunnel4 file. Just providing a good
    systemd unit file could be a better solution. I tried to read the
    discussion the bug has about a good systemd unit file. I am not sure it
    is up to date.

As for the maintainer reply:

1. For me,
        $ systemctl is-enabled stunnel4
        stunnel4.service is not a native service, redirecting to systemd-sysv-install.
        Executing: /lib/systemd/systemd-sysv-install is-enabled stunnel4
        enabled

   It could be, not sure, this is because I had a stunnel4 service enabled
   before upgrading to Bookworm. That is, I had it enabled for Bullseye.
2. Am I right the suggested stunnel@ template has no dependencies, for
   example AFTER=network-online.target ? I created a drop-in snippet to
   have such dependency.
3. I stoped/disabled the generated unit, and enabled/started a template
unit. But I took most of the configuration for the template unit from what
the generated unit had. It did worked well, until a reboot. After which it
failed, supposedly because of the pid file. Right now I am back to the
systemd-sysv-install method, Though I had to reboot to get things supposedly
in order.

Appologies if I have manged to make the maintainer uppset. That was not
my intention.

Yeah, it is possible that it will remain enabled after an upgrade.
Maybe I should have mentioned that in the news entry I wrote back then, sorry.
I think the best way to proceed is to explicitly disable it.

Argh. Good catch, thanks! I will fix this in a future upload (and,
quite possibly, an upload to -stable and maybe -oldstable, too).

I am not entirely sure what you mean here. Did you mean that you did not
use the systemd stunnel@.service template, but wrote your own systemd
configuration? Or did you mean that you wrote/kept your own stunnel
configuration for that particular instance? If the latter, then yeah,
it is expected that a systemd instance for a particular stunnel config file
will Just Work(tm) if the SysV init script had managed to start stunnel
for that particular stunnel config file until now. If this was not
the case, that is a bug - it is entirely possible that I have missed
something.

That's weird. Can you show me the systemd instance configuration,
the stunnel config file, and the log messages of the failed attempt to
start the stunnel systemd unit instance after the reboot?

No, apologies if something I wrote sounded that way! It is my fault that
this bug report has been left unaddressed for years, even after I did
implement what should hopefully be a fix two years ago, and hence it is
my fault that any problems in the fix two years ago have been left
untested/unaddressed until now, so thank you!

G'luck,
Peter

The template seem to work now. With only a network.target depedency
drop-in added, and nothing else changed in the template.
I removed the pid line I had in stunnel configuration file, and had not
tried again with it. Yet the main issue it didn't work before was probably
the lack of a foregound = yes line in stunnel configuration.

Two observation, if I may:
1. /etc/logrotate.d/stunnel4 also requires sysv init methods:
    $ grep init /etc/logrotate.d/stunnel4
            /etc/init.d/stunnel4 reopen-logs > /dev/null
2. A more labor intense issue, I mean a feature request, is partial
   dropping the necessisty for a network.target dependecy in favor of the
   ability to late binding. I mean, stunnel will be able to bind to a
   required network interface when it appears.

To what degree can

    /usr/bin/pkill --full --signal USR1 /usr/bin/stunnel4

replace the current postrotate command at /etc/logrotate.d/stunnel4 ?

This has the requiement for stunnel4 to depend on procps, doesn't it?

stunnel4 (=3:5.74-2) has systemd unit files. Can this bug be closed?