web-dev-qa-db-ja.com

postfix / smtp：致命的：不明なサービス：smtp / tcp –しかし、/ var / pool / postfix / etc / servicesは存在します

MTAとしてPostfix2.11.3-1を使用してDebianGNU/Linux8.7ボックスを実行しています。突然、つまりMTA設定を変更せずに、メールの配信が停止し、次のエラーが/var/log/mail.errに表示され始めました。

root@schroeder:~# tail /var/log/mail.err
Mar 21 12:51:01 schroeder postfix/smtp[25421]: fatal: unknown service: smtp/tcp
Mar 21 12:54:11 schroeder postfix/smtp[26397]: fatal: unknown service: smtp/tcp
Mar 21 12:54:12 schroeder postfix/smtp[26398]: fatal: unknown service: smtp/tcp
Mar 21 12:59:26 schroeder postfix/smtp[26553]: fatal: unknown service: smtp/tcp
Mar 21 12:59:26 schroeder postfix/smtp[26554]: fatal: unknown service: smtp/tcp
Mar 21 12:59:26 schroeder postfix/smtp[26555]: fatal: unknown service: smtp/tcp
Mar 21 12:59:26 schroeder postfix/smtp[26556]: fatal: unknown service: smtp/tcp
Mar 21 13:04:30 schroeder postfix/smtp[27797]: fatal: unknown service: smtp/tcp

Postfixドキュメント と twoother ServerFaultの同様の質問によると、これはpostfixがchrootされて実行されるが、必要なファイルが不足しているためです。おそらく/etc/services 、スプールディレクトリ、つまり/var/spool/postfix。

私がチェックしたところ、実際、/etc/servicesは/var/spool/postfixから欠落していました。だから私は（notsymlinked）/etc/servicesを/var/spool/postfix/etcにコピーしました。残念ながら、役に立たない。

次に、/etc/postfix/master.cfでpostfixのsmtpバイナリのchroot jailを無効にしてみましたが、unixサービスタイプのchrootを無効にすると、メールが正常に配信されることがわかりました。つまり、次の/etc/postfix/master.cfは正常に機能します。

root@schroeder:~# grep -v ^# /etc/postfix/master.cf
smtp      inet  n       -       -       -       -       smtpd
pickup    unix  n       -       -       60      1       pickup
cleanup   unix  n       -       -       -       0       cleanup
qmgr      unix  n       -       n       300     1       qmgr
tlsmgr    unix  -       -       -       1000?   1       tlsmgr
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce
defer     unix  -       -       -       -       0       bounce
trace     unix  -       -       -       -       0       bounce
verify    unix  -       -       -       -       1       verify
flush     unix  n       -       -       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
# The setting below is the one that I've changed.
# The vendor default is a dash in the fifth column.
smtp      unix  -       -       n       -       -       smtp
relay     unix  -       -       -       -       -       smtp
showq     unix  n       -       -       -       -       showq
error     unix  -       -       -       -       -       error
retry     unix  -       -       -       -       -       error
discard   unix  -       -       -       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       -       -       -       lmtp
anvil     unix  -       -       -       -       1       anvil
scache    unix  -       -       -       -       1       scache
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix  -       n       n       -       2       pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}

/etc/servicesが/var/spool/servicesのchrootjailに存在しないという他の何かが、私のchroot設定に問題があるに違いないと思いました。

そこで、chrootingを再度有効にし、Postfixソースをダウンロードし、Postfixソースディストリビューションに同梱されているLinuxのchrootセットアップスクリプトを確認して実行しました。

root@schroeder:~# cd /usr/local/src/
root@schroeder:/usr/local/src# curl https://fourdots.com/mirror/postfix/postfix-release/official/postfix-3.2.0.tar.gz | tar -xz 
root@schroeder:/usr/local/src# sh postfix-3.2.0/examples/chroot-setup/LINUX2
postfix/postfix-script: refreshing the Postfix mail system

ただし、これでもセットアップは修正されませんでした。

また、/etc/postfix/master.cfのSMTP構成に「-v」を追加しようとしましたが、エラーレポートが詳細になりませんでした。

この時点で、私は機知に富んでいます。他に何を確認できますか？ postfixのsmtpバイナリのchrootを再度有効にできるようにセットアップを修正するにはどうすればよいですか？

参考までに、私の設定：

root@schroeder:~# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = 127.0.0.1 ::1
mailbox_size_limit = 0
mydestination = schroeder.phl.univie.ac.at, localhost.phl.univie.ac.at, localhost
myhostname = schroeder.phl.univie.ac.at
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/phl.univie.ac.at.pem
smtpd_tls_key_file = /etc/ssl/private/phl.univie.ac.at.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes

接尾辞はnot（まだ）AppArmorによって保護されています：

root@schroeder:~# apparmor_status
apparmor module is loaded.
apparmor filesystem is not mounted.

これがPostfixのホームページとPostfixパッケージのDebianのバグトラッカーで既知のバグであるかどうかを確認しました。

Postfixホームページとメーリングリストにリンクされているリソースも検索しましたが、 'solution' 私が見つけたのはソースからPostfixをビルドすることだけです。私も試してみましたが、エラーが続きました。

linuxdebianpostfixchrootdebian-jessie
4
Odin Kroeger

私は同じ問題に出くわしました。私の場合、これは、フラグnoexecが設定された/ var/spoolがマウントされたzfsを使用したセットアップが原因でした。解決策は、マウントされたファイルシステムでそのフラグをクリアすることでした。

詳細については、 https://github.com/zfsonlinux/zfs/issues/6803#issuecomment-378271799 を参照してください。

結論として、Postfixは、サービスデータベースを読み取るために/ var/pool/postfixにchrootjailに配置されたダイナミックリンクライブラリに依存しているようです。オプションnoexec setでマウントされた別のファイルシステムでこのフォルダーまたはその親フォルダーのいずれかを実行する場合、このライブラリは実行されるコードを含むためにロードされません。 Postfixの観点からは、これは特に考慮されていません。代わりに、サービスデータベースの読み取りに関するより一般的な問題を確認してログに記録します。

2
Thomas Urban

/etc/postfix/master.cfファイルを介してsmtpに対してchrootが有効になっているFedora28にpostfixをインストールしようとした後に発生した同じ問題。

多くのreadmeファイルの1つを読んだ後、特に

/ postfix-3.3.1/README_FILES/BASIC_CONFIGURATION_README

私はpostfixchrootedを正しく実行するために実行する必要のあるスクリプトがあることに気づきました。

Note that a chrooted daemon resolves all filenames relative to the Postfix
queue directory (/var/spool/postfix). For successful use of a chroot jail, most
UNIX systems require you to bring in some files or device nodes. The examples/
chroot-setup directory in the source code distribution has a collection of
scripts that help you set up Postfix chroot environments on different operating
systems.

私が理解した問題は、私が実行する必要があるということでした。

LINUX2

にあるスクリプトファイル

/ postfix-3.3.1/examples/chroot-setup /

そのようです：

[[email protected] ~]$ cd postfix-3.3.1/examples/chroot-setup/   
[[email protected] chroot-setup]$ ls
AIX42  BSDI2  BSDI3  FreeBSD2  FREEBSD3  HPUX10  HPUX9  IRIX5  IRIX6  LINUX2     NETBSD1  NeXTSTEP3  OPENSTEP4  OSF1  Solaris10  Solaris2  Solaris8
[[email protected] chroot-setup]$ chmod +x LINUX2
[[email protected] chroot-setup]$ ./LINUX2

このスクリプトは、etc、lib、lib64、およびusrから/ var/boost/postfixディレクトリにファイルをコピーするため、rootまたはSudoとして実行する必要があり、rootが所有している必要があります。スクリプトを実行した後、正常に実行され、postfixをリロードしましたが、それでもエラーが発生したため、非常に古いスクリプトをデバッグしたところ、cond_copy（）関数にスラッシュがないことがわかりました。 。

正しいcond_copy（）関数は次のようになります

cond_copy() {
    # find files as per pattern in $1
    # if any, copy to directory $2
    dir=`dirname "$1"`
    pat=`basename "$1"`
    lr=`find "$dir/" -maxdepth 1 -name "$pat"`
    if test ! -d "$2" ; then exit 1 ; fi
    if test "x$lr" != "x" ; then $CP $1 "$2" ; fi
}

したがって、これがエラーであり、chroot jailed postfixを実行している場合は、最初に正しいファイルを/ var/pool/postfix /にコピーするスクリプトを見つけてcopy_cond（ ）関数を実行し、rootとして実行するか、少なくともそれを実行しました。

ちょっとした補遺：

sELinuxを実行している人にとっては、/ var/pool/postfix /と入力し、restorecon -Rvを実行することは、おそらくそれほど悪い考えではありません。移動したファイル

[[email protected] postfix]# restorecon -Rv etc/ lib/ lib64/ usr/
0
Chris

エラーの実際の原因は見つかりませんでしたが、驚いたことに（そしてがっかりしましたが）、次の方法で修正できました。

apt remove --purge postfix
apt install postfix postfix-doc

さらに、私が知る限り、これはnot関連する設定を変更しました。プレパージ構成のバックアップを/etc/postfix.backupに保持しましたが、/etc/postfix/main.cfはnot/etc/postfix.backup/main.cfとは関連性が異な​​ります。

root@schroeder:/etc/postfix# diff main.cf ../postfix.backup/main.cf
18c18
< readme_directory = /usr/share/doc/postfix
---
> readme_directory = no
21c21
< smtpd_tls_cert_file=/etc/ssl/certs/phl.univie.ac.at.crt
---
> smtpd_tls_cert_file=/etc/ssl/certs/phl.univie.ac.at.pem
38d37
< mailbox_command = procmail -a "$EXTENSION"
42d40
< html_directory = /usr/share/doc/postfix/html

また、/etc/postfix/master.cfは/etc/postfix.backup/master.cfとは異なり、chrootが再び有効になっている（そして機能している）場合に限ります。

root@schroeder:/etc/postfix# diff master.cf ../postfix.backup/master.cf
53c53
< smtp      unix  -       -       -       -       -       smtp
---
> smtp      unix  -       -       n       -       -       smtp

/etc/postfixの他のファイルは、/etc/postfix/backupの対応するコピーとまったく異なりません。

私は好奇心から、古い構成ファイルの使用に戻ったときに何が起こるかを確認しました。

root@schroeder:/etc/postfix# cp main.cf main.cf.backup
root@schroeder:/etc/postfix# cp ../postfix.backup/main.cf .
root@schroeder:/etc/postfix# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
echo 'A test.' | mail -s Test <censored>

テストメールが届きます。したがって、/etc/postfixの構成ファイルは、明らかに、notが最初に問題を引き起こしました。

私はまだ何をしたのか分かりません。

0
Odin Kroeger