Настройка моего почтового сервера работала годами. Недавно у меня возникла следующая проблема:
Настройка почты: sendmail + dovecot + procmail
Хост-файловый сервер: CentOS 6.8, NFS экспортирует почтовые каталоги на ...
Почтовый сервер: CentOS 7.3, работает как гостевая виртуальная машина на хосте через libvirtd / qemu, NFS монтирует / var / spool / mail с хоста.
Симптомы: и dovecot, и procmail выдают ошибки (подробности ниже), которые, похоже, указывают на то, что у них нет разрешения на запись в / var / spool / mail. Однако, / var / spool / mail имеет самые общие разрешения, которые я знаю как дать, как на файловом сервере NFS, так и на почтовом клиенте NFS.
На почтовом сервере (клиент NFS):
$ ls -lhd /var/spool/mail
drwxrwxrwt 5 root mail 6.8M Mar 29 12:37 /var/spool/mail
На почтовом сервере: / etc / fstab:
filehost:/mail/inbox /var/spool/mail nfs defaults 0 0
На хосте NFS:
$ ls -lhd /mail/inbox
drwxrwxrwt. 5 root mail 6.8M Mar 29 12:41 /mail/inbox
В filehost: / etc / exports:
/mail/inbox mailserver(rw,no_root_squash,async,nohide)
Ни одна из систем не запускает SELinux или iptables (я полагаюсь на брандмауэр нашего сайта).
Я вижу такие вещи:
Файлы с именами типа BOGUS.normaluser.hex-string. Соответствующее сообщение журнала:
29 марта 12:14:34 mailserver procmail [20922]: поддельный "/var/spool/mail/normaluser.lock" переименован в "/var/spool/mail/BOGUS.normaluser.xGAs"
Это может сильно раздражать, поскольку бывали случаи, когда поддельным объявлялся не только файл блокировки, но и почтовый ящик обычного пользователя. С точки зрения обычного пользователя их почтовый ящик исчезает по мере их появления. перечитываю их почту.
Файлы с именами, начинающимися с подчеркивания, например, _2-E, eu92YB.mailserver.domain.
Нет соответствующих сообщений журнала. Содержание этих файлов (которые всегда имеют размер 1 или 31-33 байта) предполагает, что это файлы блокировки. На веб-странице, которую я видел вчера, описан кто-то, использующий strace для определения того, что procmail записывает эти файлы, но я не знаю, как использовать strace, чтобы подтвердить это для себя (и я не могу найти страницу сегодня).
Когда я перечисляю файлы, я вижу, что это chmod 400, возможно, поэтому они не удаляются:
-r-------- 1 normaluser mail 1 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain -r-------- 1 normaluser mail 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain -r-------- 1 normaluser mail 1 Mar 29 12:31 _uZF,kF-2YB.mailserver.domain -r-------- 1 normaluser mail 1 Mar 29 12:31 _uZF.kF-2YB.mailserver.domain -r-------- 1 normaluser mail 1 Mar 29 12:31 _uZF+kF-2YB.mailserver.domain
Mar 29 12:31:01 mailserver dovecot: imap(normaluser): Error: unlink(/var/spool/mail/normaluser.lock) failed: Operation not permitted Mar 29 12:31:01 mailserver dovecot: imap(normaluser): Error: file_dotlock_create() failed with mbox file /var/spool/mail/normaluser: Operation not permitted
Для пользователей не удаляемый файл блокировки означает, что вся их обработка почты останавливается, пока я вручную не удалю файл блокировки. Разрешения кажутся нормальными:
-rw------- 1 normaluser theirgroup 33 Mar 29 12:30 normaluser.lock
I ' Я немного поигрался с опциями голубятни, основываясь на вики-сайте dovecot, надеясь, что где-то ошибся. Текущие соответствующие значения:
mmap_disable = yes
dotlock_use_excl = yes
mail_fsync = optimized
mail_nfs_storage = no
mail_nfs_index = no
mail_privileged_group=mail
Установка mail_nfs_storage = yes, похоже, ничего не меняет, так как этот параметр (согласно вики dovecot) имеет отношение к нескольким почтовым серверам, обращающимся к одному и тому же каталогу через NFS, что не так. Вот.
Я гуглил и возился, но не могу отследить проблему. Я прошу все, что я упустил, или предложения по дополнительной диагностике, которую я мог бы запустить.
Позже:
Я приближаюсь к решению. На почтовом сервере клиента:
$ cd /var/spool/mail
$ sudo -u normaluser touch test
$ sudo -u normaluser rm test
Нет проблем.
$ sudo -u dovenull touch test
$ sudo -u dovenull rm test
rm: cannot remove ‘test’: Operation not permitted
$ ls -lh test
-rw-r--r-- 1 nobody nobody 0 Mar 31 12:03 test
Ага! Учетной записи dovenull не разрешено ничего делать в каталоге, импортированном по NFS. Я попытался добавить учетную запись dovenull на сервер NFS (с тем же uid / gid), но это не так. t решил проблему:
$ sudo -u dovenull rm test
rm: cannot remove ‘test’: Operation not permitted
$ ls -lh test
-rw-r--r-- 1 dovenull dovenull 0 Mar 31 12:03 test
Это похоже на проблему с idmap. Вот единственные раскомментированные строки в idmap.conf как на клиенте, так и на сервере:
[General]
Domain = mydomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
[Translation]
Method = nsswitch
Я близок ... Я чувствую это ...
Но позже:
Я чувствую все, что хочу , но это не значит, что у меня есть ответ. Я получил учетную запись dovenull, чтобы иметь возможность как создавать, так и удалять в / var / spool / mail (это было связано с внимательным просмотром /etc/nssswitch.conf и пониманием, что мне нужно перезапустить NIS), но это не решило мою проблему. проблема. Учетная запись dovenull не пишет в / var / spool / mail.
Я использовал auditctl:
auditctl -w /var/spool/mail -p war -k mail-inbox
ausearch -k mail-inbox > mail-inbox.txt
и убедился, что дополнительные файлы .lock и BOGUS были созданы dovecot, а файлы подчеркивания «_» были созданы procmail. Я не буду публиковать журналы аудита, если кто-то не захочет их видеть; они показывают, что файлы создаются с правильными разрешениями (uid, gid, euid и т. д.), а удаления неуспешны, даже если вызов удаления выполняется с такими же разрешениями.
Так что могло вызвать создание файла, но его невозможно удалить?
Мне удалось решить эту проблему, но она выявила другую (менее важную) проблему.
Подсказка заключалась в том, что иногда, когда я перечислял / var / spool / mail в клиенте NFSv4, я видел что-то вроде этого:
-r-------- 1 4294967294 mail 1 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain
-r-------- 1 4294967294 mail 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain
-rw------- 1 normaluser mail 1 Mar 29 12:31 normaluser
Затем, когда я сразу после этого выполнял «ls -lh», я Я видел:
-r-------- 1 normaluser mail 1 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain
-r-------- 1 normaluser mail 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain
-rw------- 1 normaluser mail 1 Mar 29 12:31 normaluser
Это число, 4294967294, равно -2 в 32-битных целых числах без знака и часто является UID, присвоенным учетной записи nfsnobody. Это подсказало мне, что могут быть временные проблемы с idmapd. Это соответствовало бы тому, что я наблюдал: иногда почтовый сервер действовал так, как будто у него не было разрешений rwx через NFS, даже после того, как он только что создал этот файл. Поскольку только NFSv4 использует idmapd (по крайней мере, для версий NFS), я переключился на NFSv3, изменив строку в файле / etc / fstab на NFS-клиенте почтового сервера:
filehost:/mail/inbox /var/spool/mail nfs defaults,vers=3 0 0
Затем я перезагрузил почтовый сервер и вуаля! Проблемы с NFS исчезли. Для справки, я несколько раз перезагружал почтовый сервер при диагностике проблемы, так что это не случай «исправлено простой перезагрузкой».
Конечно, возникает вопрос, почему idmapd имеет проблемы. Любой желающий может посмотреть мою конфигурацию idmapd.conf выше. Но это отдельный вопрос, и для меня он гораздо менее важен. Я могу когда-нибудь опубликовать этот вопрос на serverfault.
Позже:
Быстрый поиск в Интернете дал мне следующее: Частично неправильное отображение uid с nfs4 / idmapd / ldap-auth
Исправление было реализовано в ядре 3.13, но текущая CentOS7 - это ядро 3.10. Я не знаю, перенесла ли Redhat исправление в свое текущее ядро CentOS7.
Это подсказывает мне причину проблемы: я постоянно добавляю новых активных пользователей в нашу кластерную среду. В какой-то момент я должен был опрокинуть количество пользователей в / var / spool / mail, чтобы вызвать ошибку idmapd.