fail2ban.sockここで説明されているように、Zabbix が Fail2ban を監視できるように、ファイルに特定のグループ/権限を設定しました。https://github.com/hermanekt/zabbix-fail2ban-discovery-
サービスの再起動後に権限が正しいことを確認するために、systemd サービス構成に次の行を追加しました。
[Service]
ExecStartPost=/bin/sh -c "while ! [ -S /run/fail2ban/fail2ban.sock ]; do sleep 1; done"
ExecStartPost=/bin/chgrp fail2ban /run/fail2ban/fail2ban.sock
ExecStartPost=/bin/chmod g+w /run/fail2ban/fail2ban.sock
を使用して手動でサービスを再起動しようとすると、完全に機能します。しかし、何らかの理由で、再起動後に機能しません。ダミーを使用しsystemctl restart fail2banて にいくつかのデバッグ行を追加してみましたが、それらは存在するため、アクションが実行されています。しかし、起動時にアクセス許可を書き換える何か他のもののように見えます。トラブルシューティング方法について何かアイデアはありますか?ExecStartPostechoExecStartPost
答え1
これはおそらく「タイミング」の問題のように見えます。最初のエントリExecStartPostがタイムアウトしたか、複数のExecStartPostエントリがシリアルに評価されずに並列で実行されている (Typeユニットの指定やその他の設定のため) か、または同様の問題が考えられます...
これを 1 行で書き直したり、スクリプトで 1 つのExecStartPostパラメータを使用したりすることもできます。
/run/fail2banディレクトリ（たとえばExecStartPre）にデフォルトの ACL を設定せずに、ソケットが最初に正しい権限で作成されるようにするのはなぜですか?https://unix.stackexchange.com/a/1315/452987
そこで、次のようなことを試してください。
ExecStartPre=-/bin/mkdir -p /run/fail2ban && /bin/setfacl -d -m g:fail2ban:rw /run/fail2ban
別の方法としては、systemd ユニットの パラメータを使用するか、内のパラメータを使用して、fail2ban ソケットへの別のパスを永続的なディレクトリ (/opt/fail2banの代わりになど/run/fail2ban)に設定するだけです。そして、権限を永続的に設定します。-ssocket/etc/fail2ban/fail2ban.local
答え2
systemdサービスユニットを使用しているので、systemd ソケットユニットも同様です。ソケット ユニットを作成すると、systemd がソケット ファイルを管理します。所有権と権限はSocketMode、、、SocketUserおよびを使用して設定できますSocketGroup。次に、サービス ユニットの セクションで を[Unit]追加しますRequires=yourservice.socket。