如何解决这个问题

Question 1

如何解决这个问题

在服务管理器下运行的服务不应尝试自我守护进程，不应使用不稳定且危险的 PID 文件机制，并且不应（在绝大多数常见情况下）放弃权限本身。所有这些都将由服务管理系统正确完成。

因此，当您stunnel像这样在命令行中运行时，它应该让 shell 等待，直到您终止/停止该进程。

所有在非特权用户帐户的支持下运行、设置减少的文件系统访问以及实际上（对于那些能够继承和使用打开套接字文件描述符的程序）打开侦听套接字都是服务管理的领域。

这就是 systemd 人们天真地称之为运行守护进程的“新风格”方式。事实上，这正是 daemontools 用户在过去二十年中一直所说的运行守护进程的方式，也是 IBM 在过去四分之一个世纪中一直所说的方式。

该非特权用户帐户不应该是nobody，它可以被列为文件的所有者。相关服务不需要所有权许可任何文件或目录根本不，因此非特权用户帐户应该是专门为此目的创建的帐户，例如：

useradd --shell /usr/bin/true mysql-stunnel-d

在 systemd 中设置一个chroot()环境实际上并不简单，因为/bin/stunnel它读取的所有文件（根据其 doco，除了证书文件和配置文件之外，还包括相当多的系统内容；诸如/dev/zeroNSS 配置系统和时区数据库之类的东西需要使用进行配置BindReadOnlyPaths。更简单的方法是Protect…机制。

配置文件

套接字由套接字单元来描述。 stunnel不懂该LISTEN_FDS协议，但它是 UCSPI-TCP 兼容的。因此套接字单元必须描述一个接受套接字：

; /etc/systemd/service/mysql-stunnel.socket
[单元]
描述=MySQL 的 SSL 包装器
文档=

[插座]
ListenStream=127.0.0.1:mysql
ListenStream=[::1]:mysql
接受=是
无延迟=是

[安装]
WantedBy=多用户.target

请注意，这是插座在这里启用/禁用/启动/停止，带有systemctl.这服务，由服务单元描述，按需自动启动通过插座。因为它是一个接受套接字，所以它是一个模板服务单元。它描述了服务管理所做的所有特权删除和设置：

; /etc/systemd/服务/[电子邮件受保护]
[单元]
描述=MySQL 的 SSL 包装器
文档=

[服务]
类型=简单
用户=mysql-stunnel-d
保护主页=是
保护系统=严格
PrivateTmp=是
标准输入=套接字
标准输出=插座
标准错误=期刊
ExecStart=/bin/stunnel /etc/stunnel/mysql-stunnel.conf

然后配置stunnel文件不处理任何服务管理的内容为它做:

# /etc/stunnel/mysql-stunnel.conf
证书 = /etc/pki/tls/certs/stunnel.pem
客户 = 是
前景 = 是
连接=10.0.0.3:3307

奖励内容

是的，这就是daemontools的方式。将这两个单元文件传递给convert-systemd-unitsfrom诺什工具集我们得到了一个run程序service（以及其他几个程序），它举例说明了如何通过 daemontools 方式完成此操作，并使用一组合适的链加载 UCSPI 和其他工具：

%系统控制转换systemd-units ./mysql-stunnel.socket
转换系统单元：警告：./[电子邮件受保护]：强制设置：[Service] StandardError = log
Convert-systemd-units：警告：./mysql-stunnel.socket：未使用的设置：[unit] 文档 =
转换系统单元：警告：./[电子邮件受保护]：未使用的设置：[service] standarderror = 日志
转换系统单元：警告：./[电子邮件受保护]：未使用的设置：[单位]文档=
%系统控制猫./mysql-stunnel
开始：#!/bin/nosh                
start:#从./mysql-stunnel.socket生成的启动文件
开始：真
停止：#!/bin/nosh
stop:#停止从./mysql-stunnel.socket生成的文件
停止：真
运行：#!/bin/nosh
run:#运行./mysql-stunnel.socket生成的文件
运行：#MySQL 的 SSL 包装器
运行：tcp-socket-listen 127.0.0.1 mysql
运行：tcp-socket-listen "::1" mysql
运行：移动到控制组../mysql-stunnel.service
运行：envuidgid --补充 -- mysql-stunnel-d
运行：userenv-fromenv
运行：取消共享--挂载
运行：set-mount-object --recursive Slave /
运行：make-private-fs --temp --homes
运行：make-read-only-fs --os --etc
运行：set-mount-object --recursive 共享/
运行：setuidgid --补充 -- mysql-stunnel-d
运行：tcp-socket-accept --无延迟
运行：./服务
服务：#!/bin/nosh
service:#由./生成的服务文件[电子邮件受保护]
服务：#MySQL 的 SSL 包装器
服务：/bin/stunnel /etc/stunnel/mysql-stunnel.conf
重新启动：#!/bin/sh
restart:#重新启动./生成的文件[电子邮件受保护]
restart:exec false # 忽略脚本参数
%

进一步阅读

乔纳森·德博因·波拉德 (2015)。[UNIX 客户端-服务器程序接口上的 gen]（https://jdebp.uk/FGA/UCSPI.html）。经常给出的答案。
乔纳森·德博因·波拉德 (2018)。convert-systemd-units。 小吃指南。软件。
乔纳森·德博因·波拉德 (2018)。不要滥用任何人运行的守护进程。。经常给出的答案。
乔纳森·德博因·波拉德 (2018)。设计 Unix 守护程序时要避免的错误。经常给出的答案。

Answer

如何解决这个问题

在服务管理器下运行的服务不应尝试自我守护进程，不应使用不稳定且危险的 PID 文件机制，并且不应（在绝大多数常见情况下）放弃权限本身。所有这些都将由服务管理系统正确完成。

因此，当您stunnel像这样在命令行中运行时，它应该让 shell 等待，直到您终止/停止该进程。

所有在非特权用户帐户的支持下运行、设置减少的文件系统访问以及实际上（对于那些能够继承和使用打开套接字文件描述符的程序）打开侦听套接字都是服务管理的领域。

这就是 systemd 人们天真地称之为运行守护进程的“新风格”方式。事实上，这正是 daemontools 用户在过去二十年中一直所说的运行守护进程的方式，也是 IBM 在过去四分之一个世纪中一直所说的方式。

该非特权用户帐户不应该是nobody，它可以被列为文件的所有者。相关服务不需要所有权许可任何文件或目录根本不，因此非特权用户帐户应该是专门为此目的创建的帐户，例如：

useradd --shell /usr/bin/true mysql-stunnel-d

在 systemd 中设置一个chroot()环境实际上并不简单，因为/bin/stunnel它读取的所有文件（根据其 doco，除了证书文件和配置文件之外，还包括相当多的系统内容；诸如/dev/zeroNSS 配置系统和时区数据库之类的东西需要使用进行配置BindReadOnlyPaths。更简单的方法是Protect…机制。

配置文件

套接字由套接字单元来描述。 stunnel不懂该LISTEN_FDS协议，但它是 UCSPI-TCP 兼容的。因此套接字单元必须描述一个接受套接字：

; /etc/systemd/service/mysql-stunnel.socket
[单元]
描述=MySQL 的 SSL 包装器
文档=

[插座]
ListenStream=127.0.0.1:mysql
ListenStream=[::1]:mysql
接受=是
无延迟=是

[安装]
WantedBy=多用户.target

请注意，这是插座在这里启用/禁用/启动/停止，带有systemctl.这服务，由服务单元描述，按需自动启动通过插座。因为它是一个接受套接字，所以它是一个模板服务单元。它描述了服务管理所做的所有特权删除和设置：

; /etc/systemd/服务/[电子邮件受保护]
[单元]
描述=MySQL 的 SSL 包装器
文档=

[服务]
类型=简单
用户=mysql-stunnel-d
保护主页=是
保护系统=严格
PrivateTmp=是
标准输入=套接字
标准输出=插座
标准错误=期刊
ExecStart=/bin/stunnel /etc/stunnel/mysql-stunnel.conf

然后配置stunnel文件不处理任何服务管理的内容为它做:

# /etc/stunnel/mysql-stunnel.conf
证书 = /etc/pki/tls/certs/stunnel.pem
客户 = 是
前景 = 是
连接=10.0.0.3:3307

奖励内容

是的，这就是daemontools的方式。将这两个单元文件传递给convert-systemd-unitsfrom诺什工具集我们得到了一个run程序service（以及其他几个程序），它举例说明了如何通过 daemontools 方式完成此操作，并使用一组合适的链加载 UCSPI 和其他工具：

%系统控制转换systemd-units ./mysql-stunnel.socket
转换系统单元：警告：./[电子邮件受保护]：强制设置：[Service] StandardError = log
Convert-systemd-units：警告：./mysql-stunnel.socket：未使用的设置：[unit] 文档 =
转换系统单元：警告：./[电子邮件受保护]：未使用的设置：[service] standarderror = 日志
转换系统单元：警告：./[电子邮件受保护]：未使用的设置：[单位]文档=
%系统控制猫./mysql-stunnel
开始：#!/bin/nosh                
start:#从./mysql-stunnel.socket生成的启动文件
开始：真
停止：#!/bin/nosh
stop:#停止从./mysql-stunnel.socket生成的文件
停止：真
运行：#!/bin/nosh
run:#运行./mysql-stunnel.socket生成的文件
运行：#MySQL 的 SSL 包装器
运行：tcp-socket-listen 127.0.0.1 mysql
运行：tcp-socket-listen "::1" mysql
运行：移动到控制组../mysql-stunnel.service
运行：envuidgid --补充 -- mysql-stunnel-d
运行：userenv-fromenv
运行：取消共享--挂载
运行：set-mount-object --recursive Slave /
运行：make-private-fs --temp --homes
运行：make-read-only-fs --os --etc
运行：set-mount-object --recursive 共享/
运行：setuidgid --补充 -- mysql-stunnel-d
运行：tcp-socket-accept --无延迟
运行：./服务
服务：#!/bin/nosh
service:#由./生成的服务文件[电子邮件受保护]
服务：#MySQL 的 SSL 包装器
服务：/bin/stunnel /etc/stunnel/mysql-stunnel.conf
重新启动：#!/bin/sh
restart:#重新启动./生成的文件[电子邮件受保护]
restart:exec false # 忽略脚本参数
%

进一步阅读

乔纳森·德博因·波拉德 (2015)。[UNIX 客户端-服务器程序接口上的 gen]（https://jdebp.uk/FGA/UCSPI.html）。经常给出的答案。
乔纳森·德博因·波拉德 (2018)。convert-systemd-units。 小吃指南。软件。
乔纳森·德博因·波拉德 (2018)。不要滥用任何人运行的守护进程。。经常给出的答案。
乔纳森·德博因·波拉德 (2018)。设计 Unix 守护程序时要避免的错误。经常给出的答案。

Question 2

你有一个拼写错误：

ExecStartPre=-/user/bin/chown nobody:nobody /var/run/stunnel

你的意思可能是/usr/bin/chown，不是/user/bin/chown。

另外，如果/var/run是的符号链接/run，您可以将目录创建命令替换为RuntimeDirectory=

RuntimeDirectory=stunnel

Answer

你有一个拼写错误：

ExecStartPre=-/user/bin/chown nobody:nobody /var/run/stunnel

你的意思可能是/usr/bin/chown，不是/user/bin/chown。

另外，如果/var/run是的符号链接/run，您可以将目录创建命令替换为RuntimeDirectory=

RuntimeDirectory=stunnel

Question 3

持续的隧道

由于 stunnel 处理 ssl 连接，这意味着使用 TCP 而不是 UDP，因此假设连接应该长期存在并不是没有道理的，对于这些情况，我发现 @JdeBP 的答案是绝对正确的；它已成为我进行此类单元的正确方法的参考点，特别是使用 Stunnel。

然而，如果相对于进程的生命周期而言，启动进程的成本很高，那么让 systemd 套接字侦听连接就没有什么意义了。作为比较 - 您不一定希望 Web 服务器为每个传入的 TCP 连接启动一个新实例，当然当轻量级线程是一种选择时。

同样，如果 stunnel 作为持久进程运行而不是为每个连接启动，则可以利用一些优化。此外，您不会为每个连接启动一个新进程，但据我了解，stunnel（取决于编译选项）可以使用实例化成本低得多的线程 - 并且您可以避免某些工作负载分布的潜在磁盘命中。

那么，我们如何将 stunnel 作为持久服务运行，同时听取 @JdeBP 的答案提供的所有优秀建议（避免 PID 文件，不滥用“nobody”，不分叉）？

以下是我使用不支持加密的客户端连接到受 ssl 保护的服务的基础。如果您的用例不同，您可能需要进行调整。

;/etc/stunneld.conf

client=yes 
;presuming that the upstream is ssl protected and the downstream is not

foreground=yes
;no forking. Use `quiet` to get less noisy logs

pid=
;no PID File, note that it must be blank to avoid PID creation

[my-upstream-service]
accept=x.x.x.x:pppp
;optional address, and mandatory port to listen on - can be a hostname instead of an address

connect=x.x.x.x:pppp 
;upstream ssl protected service

CApath=/etc/ssl/certs
;may be different in your distribution

verifyChain=yes
checkHost=example.com
;were required in my case as the ssl cert was specific to a hostname. Note that without the verification you're still vulnerable to MITM attacks.

;/etc/systemd/system/stunneld.service (location may be different in your distro)

[Unit]
Description=Stunnel Service
Documentation=

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
User=stunnel4
;my distro happened to provide a stunnel user as part of the package. YMMV
ProtectHome=yes
ProtectSystem=strict
PrivateTmp=yes
StandardError=journal
ExecStart=/usr/bin/stunnel /etc/stunneld.conf

这些配置允许我们将 stunnel 作为持久任务运行，这为我们提供了与执行许多小型连接而不是几个大型连接的上下文相关的优化优势。

Answer

持续的隧道

由于 stunnel 处理 ssl 连接，这意味着使用 TCP 而不是 UDP，因此假设连接应该长期存在并不是没有道理的，对于这些情况，我发现 @JdeBP 的答案是绝对正确的；它已成为我进行此类单元的正确方法的参考点，特别是使用 Stunnel。

然而，如果相对于进程的生命周期而言，启动进程的成本很高，那么让 systemd 套接字侦听连接就没有什么意义了。作为比较 - 您不一定希望 Web 服务器为每个传入的 TCP 连接启动一个新实例，当然当轻量级线程是一种选择时。

同样，如果 stunnel 作为持久进程运行而不是为每个连接启动，则可以利用一些优化。此外，您不会为每个连接启动一个新进程，但据我了解，stunnel（取决于编译选项）可以使用实例化成本低得多的线程 - 并且您可以避免某些工作负载分布的潜在磁盘命中。

那么，我们如何将 stunnel 作为持久服务运行，同时听取 @JdeBP 的答案提供的所有优秀建议（避免 PID 文件，不滥用“nobody”，不分叉）？

以下是我使用不支持加密的客户端连接到受 ssl 保护的服务的基础。如果您的用例不同，您可能需要进行调整。

;/etc/stunneld.conf

client=yes 
;presuming that the upstream is ssl protected and the downstream is not

foreground=yes
;no forking. Use `quiet` to get less noisy logs

pid=
;no PID File, note that it must be blank to avoid PID creation

[my-upstream-service]
accept=x.x.x.x:pppp
;optional address, and mandatory port to listen on - can be a hostname instead of an address

connect=x.x.x.x:pppp 
;upstream ssl protected service

CApath=/etc/ssl/certs
;may be different in your distribution

verifyChain=yes
checkHost=example.com
;were required in my case as the ssl cert was specific to a hostname. Note that without the verification you're still vulnerable to MITM attacks.

;/etc/systemd/system/stunneld.service (location may be different in your distro)

[Unit]
Description=Stunnel Service
Documentation=

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
User=stunnel4
;my distro happened to provide a stunnel user as part of the package. YMMV
ProtectHome=yes
ProtectSystem=strict
PrivateTmp=yes
StandardError=journal
ExecStart=/usr/bin/stunnel /etc/stunneld.conf

这些配置允许我们将 stunnel 作为持久任务运行，这为我们提供了与执行许多小型连接而不是几个大型连接的上下文相关的优化优势。

Question 4

就我而言，我没有任何配置文件。

为此，我有这个配置文件：

client = yes

[stunnel]
accept = 127.0.0.1:41194
connect = vpnserverhost:port

放置为/etc/stunnel/stunnel.conf

Answer

就我而言，我没有任何配置文件。

为此，我有这个配置文件：

client = yes

[stunnel]
accept = 127.0.0.1:41194
connect = vpnserverhost:port

放置为/etc/stunnel/stunnel.conf

如何解决这个问题

答案1

如何解决这个问题

配置文件

奖励内容

进一步阅读

答案2

答案3

持续的隧道

答案4

相关内容