Я использую Debian GNU / Linux 8.7 с Postfix 2.11.3-1 в качестве MTA. Внезапно, то есть без изменений в настройке 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 и два Другой аналогичные вопросы по ServerFault, это связано с тем, что postfix запускается chrooted, но не имеет необходимых файлов, предположительно, /etc/servicesв его спул-каталоге, а именно /var/spool/postfix.
Я проверил и действительно /etc/services был отсутствует из /var/spool/postfix. Я скопировал (не символическая ссылка) /etc/services к /var/spool/postfix/etc. Увы, безрезультатно.
Затем я поигрался с отключением chroot jail для двоичного файла postfix smtp в /etc/postfix/master.cf и обнаружил, что когда я отключаю chroot для типа службы unix, почта доставляется нормально. То есть следующие /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 не присутствовать в chroot jail на /var/spool/services, должно быть, неправильно настроен мой chroot.
Итак, я снова включил chroot, загрузил исходный код Postfix, проверил сценарий настройки chroot для Linux, который поставляется с исходным дистрибутивом Postfix, и запустил его:
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
Однако это опять же не устранило мою настройку.
Я также пробовал добавить "-v" в конфигурацию smtp в /etc/postfix/master.cf, но отчеты об ошибках не стали более подробными.
На данный момент я в своем уме. Что еще можно проверить? Как я могу исправить свою настройку, чтобы снова включить chroot для двоичного файла postfix smtp?
Для справки, моя установка:
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
Постфикс не (пока) защищено AppArmor:
root@schroeder:~# apparmor_status
apparmor module is loaded.
apparmor filesystem is not mounted.
Я проверил, является ли это известной ошибкой на домашней странице Postfix и в системе отслеживания ошибок Debian для пакета postfix.
Я также искал ресурсы, ссылки на которые есть на домашней странице Postfix и в списках рассылки, но единственный 'решение' Я нашел это для сборки Postfix из исходников. Я тоже попробовал, но ошибка не исчезла.
Я наткнулся на ту же проблему. В моем случае это произошло из-за моей настройки с использованием zfs с установленным / var / spool с установленным флагом noexec. Решением было сбросить этот флаг на смонтированной файловой системе.
Видеть https://github.com/zfsonlinux/zfs/issues/6803#issuecomment-378271799 для большего.
В заключение Postfix, по-видимому, полагается на динамически подключаемую библиотеку, также помещенную в chroot-тюрьму в / var / spool / postfix для чтения своей базы данных услуг. В случае запуска этой папки или любой из ее родительских папок в отдельной файловой системе, которая монтируется с опцией noexec установить, что эта библиотека не будет загружена, поскольку код будет казнен. С точки зрения Postfix, это особо не рассматривается. Вместо этого он видит и регистрирует более общую проблему с чтением базы данных служб.
Эта же проблема возникла у меня после попытки установить postfix на Fedora 28 с включенным chroot для smtp через файл /etc/postfix/master.cf.
после прочтения одного из многих файлов readme, в частности
/postfix-3.3.1/README_FILES/BASIC_CONFIGURATION_README
Я смог понять, что есть сценарий, который мне нужно запустить, чтобы правильно запустить postfix chrooted.
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/
вот так:
[root@slackware-1.0 ~]$ cd postfix-3.3.1/examples/chroot-setup/
[root@slackware-1.0 chroot-setup]$ ls
AIX42 BSDI2 BSDI3 FreeBSD2 FREEBSD3 HPUX10 HPUX9 IRIX5 IRIX6 LINUX2 NETBSD1 NEXTSTEP3 OPENSTEP4 OSF1 Solaris10 Solaris2 Solaris8
[root@slackware-1.0 chroot-setup]$ chmod +x LINUX2
[root@slackware-1.0 chroot-setup]$ ./LINUX2
вы должны запустить этот сценарий как root или sudo, поскольку он копирует файлы в каталог / var / spool / postfix из etc, lib, lib64 и usr, и они должны принадлежать root. Это произошло только после выполнения скрипта, он работал нормально и перезагрузил постфикс, но у меня все еще были ошибки, поэтому я отладил очень старый скрипт и обнаружил, что в 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, заключенный в тюрьму, сначала найдите сценарий, который копирует правильные файлы в / var / spool / postfix / исправить ошибку в copy_cond () функцию и выполнить как root, или, по крайней мере, так я это сделал.
небольшое дополнение:
для тех, кто использует SELinux, вероятно, было бы неплохо ввести / var / spool / postfix / и запустите restorecon -Rv, если вы беспокоитесь, что это может что-то испортить, вы можете просто запустить его для файлов, которые вы переместили
[root@slackware-1.0 postfix]# restorecon -Rv etc/ lib/ lib64/ usr/
Я не нашел фактического источника ошибки, но, к моему удивлению (и тревоге), я мог исправить это следующим образом:
apt remove --purge postfix
apt install postfix postfix-doc
Более того, насколько я могу судить, это не измените любую соответствующую настройку. Я сохранил резервную копию конфигурации предварительной очистки на /etc/postfix.backup, и /etc/postfix/main.cf делает не существенно отличаться от /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 только постольку, поскольку chrooting снова включен (и работает):
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, видимо, сделал не вызвать проблему в первую очередь.
Я до сих пор не знаю, что сделал.