Вопрос или проблема
Я настраиваю сервер Postfix/Dovecot/LDAP на Debian Squeeze с виртуальными почтовыми ящиками (в отличие от псевдонимов). Я успешно настроил Dovecot и Postfix, правильно настроенный для обращения к LDAP для virtual_mailbox_maps, но как только я подключаю virtual_mailbox_domains, появляются эти ошибки и нет доставки:
Jun 5 15:52:51 extranet postfix/smtpd[2090]: warning: problem talking to service rewrite: Success
Jun 5 15:52:51 extranet postfix/master[1432]: warning: process /usr/lib/postfix/trivial-rewrite pid 2219 killed by signal 6
Jun 5 15:52:51 extranet postfix/master[1432]: warning: /usr/lib/postfix/trivial-rewrite: bad command startup -- throttling
Вот postconf -d mail_version:
# postconf -d mail_version
mail_version = 2.7.1
Вот postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
allow_untrusted_routing = yes
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 24h
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
debug_peer_level = 2
debug_peer_list = 124.149.148.61
delay_warning_time = 4h
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mailbox_size_limit = 0
maximal_queue_lifetime = 24h
mydestination = mail.example.com, extranet.example.com, localhost
myhostname = mail.example.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination
relayhost =
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
permit_mynetworks, reject_unauth_destination,
check_recipient_access hash:/etc/postfix/access,
reject_non_fqdn_sender, check_sender_access hash:/etc/postfix/sender_access,
reject_non_fqdn_hostname, reject_invalid_hostname, check_helo_access hash:/etc/postfix/helo_access,
reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, permit
smtpd_sasl_auth_enable = no
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.com.2013.chain.pem
smtpd_tls_key_file = /etc/ssl/private/exampl.2013.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = no
virtual_mailbox_domains = ldap:/etc/postfix/ldap_virtual_domains.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap_virtual_maps.cf
virtual_transport = dovecot
/etc/postfix/ldap_virtual_maps.cf:
server_host = ldaps://mail.example.com/
search_base = ou=People,dc=example,dc=com
version = 3
bind_dn = uid=mail,ou=Services,dc=example,dc=com
bind_pw = *************
query_filter = (&(objectclass=inetOrgPerson)(mail=%s))
result_attribute = mail
И вот /etc/postfix/ldap_virtual_domains.cf:
server_host = ldaps://mail.example.com/
search_base = ou=Domains,dc=example,dc=com
version = 3
bind_dn = uid=mail,ou=Services,dc=example,dc=com
bind_pw = ************
query_filter = associatedDomain=%s
result_attribute = associatedDomain
Если я запускаю ручную проверку с помощью postmap, я получаю ответ:
# postmap -q example.com ldap:/etc/postfix/ldap_virtual_domains.cf
example.com
Ручные ldap-поиски тоже работают. Я использую те же учетные данные для успешных virtual_mailbox_maps, которые работают, поэтому я немного озадачен.
P.S. Поиск LDAP для virtual_mailbox_maps тоже не работал. Виртуальный транспорт Dovecot работал. По какой-то причине это было упущено из виду, так что LDAP-запросы не работали для postfix, но работали для postmap.
Это просто обоснованное предположение, но, вероятно, вам не хватает /dev/random или /dev/urandom в /var/spool/postfix.
Как вы можете видеть, процесс trivial-rewrite убит сигналом SIGABRT, что обычно происходит на системах Debian и Ubuntu (в контексте Postfix), потому что libldap, который связан c GnuTLS, не находит /dev/random или /dev/urandom в каталоге chroot Postfix /var/spool/postfix. У меня была эта проблема в прошлом тоже.
Просто создайте mkdir /var/spool/postfix/dev и либо скопируйте cp -a /dev/urandom /var/spool/postfix/dev и cp -a /dev/random /var/spool/postfix/dev по мере необходимости, либо используйте mknod в /var/spool/postfix/dev.
Посмотрите https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/81242 и http://comments.gmane.org/gmane.mail.postfix.user/211261 для обсуждения.
Ответ от daff не сработал для меня в моем контейнере Docker. Поэтому я отключил chroot для переписывания в master.cf.
Это был действительно долгий путь, чтобы выяснить, что сообщение об ошибке
dict_ldap_lookup: Search error -1: Can't contact LDAP server
warning: ldap:/etc/postfix/ldap/virtual_transport.cf lookup error for "*"
warning: dict_ldap_connect: Unable to bind to server ldap://host.docker.internal:13389 with dn uid=postfix,dc=example,dc=com: -1 (Can't contact LDAP server)
было вызвано средой chroot
Ответ или решение
Для решения проблемы с Postfix, где LDAP-поиск работает для virtual_mailbox_maps, но не срабатывает для virtual_mailbox_domains, следует внимательно рассмотреть несколько технических аспектов. Ситуация выглядит следующим образом: вы настроили систему на Debian Squeeze с использованием Postfix, Dovecot и LDAP, где все почтовые ящики виртуальные. Несмотря на то, что поиск LDAP успешно выполняется для virtual_mailbox_maps, при подключении virtual_mailbox_domains появляются ошибки, указывающие на проблемы с доставкой.
Теория
При настройке Postfix для использования LDAP в качестве источника данных для виртуальных доменов и карт, часто возникают сложности с правильной конфигурацией, особенно в средах, где используется chroot. Chroot окружение изолирует некоторые системные ресурсы, такие как директории и устройства, необходимые для корректной работы приложений, вызывая тем самым ошибки, если, например, не настроены необходимые специальные файлы устройств в chroot директории Postfix. Одной из таких распространённых проблем является отсутствие /dev/random или /dev/urandom, необходимых для работы библиотек, используемых LDAP, что приводит к падению процесса trivial-rewrite с сигналом 6 (SIGABRT).
Пример
Давайте рассмотрим пример конфигурации и типичных шагов для устранения подобных проблем. У вас должны быть файлы конфигурации Postfix и LDAP, такие как ldap_virtual_maps.cf и ldap_virtual_domains.cf, правильно настроены. Ключевые параметры, которые необходимо сверить:
- server_host – адрес LDAP-сервера. Убедитесь, что он доступен из окружения Postfix.
- search_base – поисковая база LDAP. Она должна быть корректной и такой, чтобы запрашиваемая информация была доступна.
- bind_dn и bind_pw – учетные данные для подключения к LDAP. Они должны иметь доступ на чтение к указанным базам данных.
Если Postfix работает в режиме chroot, необходимо проверить наличие необходимых файлов устройств в окружении:
mkdir -p /var/spool/postfix/dev
cp -a /dev/random /dev/urandom /var/spool/postfix/devКроме того, использование postmap для проверки конфигурации LDAP как для виртуальных карт, так и для доменов дает уверенность, что сам LDAP работает корректно и возвращает ожидаемые результаты.
Применение
Применение вышеупомянутых решений в реальных условиях требует следующих шагов:
-
Проверка конфигурации:
- Выполните проверку всех конфигурационных файлов Postfix и LDAP на наличие синтаксических ошибок и соответствие назначениям. При необходимости откорректируйте
ldap_virtual_domains.cf, убедившись, что все параметры заданы корректно.
- Выполните проверку всех конфигурационных файлов Postfix и LDAP на наличие синтаксических ошибок и соответствие назначениям. При необходимости откорректируйте
-
Настройка chroot окружения:
- Убедитесь, что все зависимости, используемые библиотеками LDAP, доступны в chroot окружении Postfix. Это может потребовать копирования или создания специальных файлов, таких как
/dev/randomи/dev/urandom, в/var/spool/postfix/dev.
- Убедитесь, что все зависимости, используемые библиотеками LDAP, доступны в chroot окружении Postfix. Это может потребовать копирования или создания специальных файлов, таких как
-
Отладка и диагностика:
- Включение дополнительных уровней отладки Postfix (например, с помощью параметра
debug_peer_levelиdebug_peer_list) может предоставить более детализированную информацию о происходящих процессах и помочь выявить причину сбоя. - Проверьте журналы системы на наличие дополнительных указателей на источники проблемы.
- Включение дополнительных уровней отладки Postfix (например, с помощью параметра
-
Тестирование и проверка:
- После внесения изменений убедитесь, что система работает как ожидается. Выполните полное тестирование на уровне как доставки, так и получения почты.
- Используйте
postmapдля симуляции и проверки запросов LDAP отдельно от Postfix, чтобы удостовериться в корректности работы LDAP.
Если все вышеперечисленные шаги не решают проблему, может потребоваться временно отключить chroot для процесса rewrite, как это было сделано в Docker-контейнере, описанном в вашем примере. Это позволит убедиться, является ли проблема действительно связанной с ограничениями chroot. Однако, стоит помнить, что отключение chroot может нести в себе риски с точки зрения безопасности, поэтому следует рассматривать это как временное отладочное решение.
Кроме того, поддержка и документация сообщества Postfix и LDAP может предложить дополнительные советы и рекомендации по более глубокому решению специфичных проблем, связанных с использованием LDAP в специфичных конфигурациях почтового сервера. Поддержание актуальности вашего программного обеспечения и его компонентов также играет ключевую роль в устранении возможных ошибок и повышения безопасности системы.