Bug#826883: stunnel4: Please provide systemd unit file

[micah]

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



-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages stunnel4 depends on:
ii adduser 3.114
ii libc6 2.22-11
ii libssl1.0.2 1.0.2h-1
ii libsystemd0 230-2
ii libwrap0 7.6.q-25
ii netbase 5.3
ii openssl 1.0.2h-1
ii perl 5.22.2-1

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn logcheck-database <none>

-- no debconf information

[Peter Pentchev]

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 ro...@ringlet.net ro...@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

[Michał Trojnara]

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

[Peter Pentchev]

On Mon, Jun 27, 2016 at 01:03:09PM +0300, Peter Pentchev wrote:
> 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...
[snip example file for a single stunnel instance]

>
> 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 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 stu...@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.

-- Peter Pentchev <ro...@debian.org> Fri, 12 Feb 2021 00:28:35 +0200

This change is present in all of Debian unstable (sid), testing,
stable (bookworm) and oldstable (bullseye).

Does this meet your needs? Apologies for not mentioning it sooner...

G'luck,
Peter

--
Peter Pentchev ro...@ringlet.net ro...@debian.org p...@storpool.com

[u...@net9.cf]

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.

--
u34

[Peter Pentchev]

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.

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

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

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

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.

> It did worked well, until a reboot. After which it
> failed, supposedly because of the pid file.

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?

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

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!

[u...@net9.cf]

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.

--
u34

[u...@net9.cf]

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?

--
u34