На моем сервере возникла ожидаемая проблема, когда я не могу подключиться с помощью почтового клиента.
Я просмотрел журналы сервера, и единственное, что может идентифицировать проблему, - это такие события, как следующие:
23 ноября 18:32:43 Hig3 dovecot: imap-login: Логин: user =, method = PLAIN, rip = xxxxxxxx, lip = xxxxxxx, TLS 23 ноября 18:32:55 Hig3 postfix / smtpd [11653]: подключиться с xxxxxxx .co.uk [xxxxxxx] 23 ноября, 18:32:55 Hig3 postfix / smtpd [11653]: предупреждение: ошибка аутентификации SASL: невозможно подключиться к серверу saslauthd: нет такого файла или каталога 23 ноября 18:32:55 Hig3 postfix / smtpd [11653]: предупреждение: xxxxxxx.co.uk [xxxxxxxx]: ошибка аутентификации SASL LOGIN: общий сбой 23 ноября 18:32:56 high3 postfix / smtpd [11653]: потеряно соединение после AUTH с xxxxxxx.co.uk [xxxxxxx] 23 ноября 18:32:56 Hig3 postfix / smtpd [11653]: отключение от xxxxxxx.co.uk [xxxxxxx]
Проблема необычная, потому что всего за полчаса до этого в моем офисе мне не предлагалось ввести правильное имя пользователя и пароль в моем почтовом клиенте. Я не вносил никаких изменений в сервер, поэтому я не могу понять, что могло бы произойти, чтобы эта ошибка возникла.
Поиск сообщений об ошибках дает различные результаты с «исправлениями», в которых я не уверен (очевидно, я не хочу ухудшать ситуацию или исправлять что-то, что не сломано).
Когда я бегу
тестыaslauthd -u xxxxx -p xxxxxx
Я также получаю следующий результат:
connect (): нет такого файла или каталога
Но когда я бегу
тестыaslauthd -u xxxxx -p xxxxxx -f / var / spool / postfix / var / run / saslauthd / mux -s smtp
Я получил:
0: ОК "Успех".
Я нашел эти команды на другом форуме и не совсем уверен, что они означают, но я надеюсь, что они могут указать на то, в чем может заключаться проблема.
Когда я бегу
ps -ef | grep saslauthd
Это результат:
root 1245 1 0 ноя 24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / run / saslauthd -r -n 5 root 1250 1245 0 ноя 24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / run / saslauthd -r -n 5 root 1252 1245 0 ноя 24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / run / saslauthd -r -n 5 root 1254 1245 0 ноя 24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / run / saslauthd -r -n 5 root 1255 1245 0 ноя 24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / run / saslauthd -r -n 5 root 5902 5885 0 08:51 pts / 0 00:00:00 grep --color = авто saslauthd
Если это имеет значение, я использую Ubuntu 10.04.1, Postfix 2.7.0 и Webmin / Virtualmin.
Postfix может работать в chroot (по умолчанию в /var/spool/postfix) или не. Если это так, он попытается открыть /var/spool/postfix/var/run/saslauthd/mux для аутентификации sasl. Если это не так, он попытается открыть /var/run/saslauthd/mux
Похоже, что по какой-то причине ваш экземпляр postfix работал в chroot-режиме, и этого больше нет. Это странно, но я так понимаю, исходя из деталей вашего вопроса. Если это случилось, вы можете изменить конфигурацию saslauthd, чтобы использовать /var/run/saslauthd или снова запустите postfix в chroot.
Чтобы узнать, работает ли ваш Postfix chroot, вы можете проверить /etc/postfix/master.cf:
smtp inet n - y - - smtpd или smtp inet n - - - - smtpdтогда твой Postfix работает в chroot;smtp inet n - n - - smtpd тогда твой Postfix НЕ работает в chroot.Этот чек исходит от /etc/default/saslauthd (Конфигурационный файл Ubuntu sasl).
Выглядит как postfix всегда ищет в chroot'ed месте saslauthd хотя он настроен на НЕ использовать среду chroot для своих служб.
Я нашел этот пост в блоге самым полезным, хотя он и датирован 2005 годом!
http://www.jimmy.co.at/weblog/?p=52
postfix выполняет chroot, поэтому он не может взаимодействовать с saslauthd. Это сложная часть:
rm -r /var/run/saslauthd/ mkdir -p /var/spool/postfix/var/run/saslauthd ln -s /var/spool/postfix/var/run/saslauthd /var/run chgrp sasl /var/spool/postfix/var/run/saslauthd adduser postfix sasl
Вы можете запустить saslauthd в режиме отладки, используя:
saslauthd -c -d -a pam -m /var/run/saslauthd
От вашего клиента сделайте следующее:
openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect mail.mydomain.com:587
При появлении запроса введите следующее:
HELO mynotebook.com
LOGIN PLAIN <base64code>
где base64code бит происходит из этого:
perl -MMIME::Base64 -e 'print encode_base64("\000username\000password");'
Отсутствие такого файла или каталога при попытке подключения предполагает, что сокет UNIX, на котором он ищет SASLAuthd, не существует.
Если ты бежишь ps -ef | grep saslauthdВы видите, что он все еще работает?
Если да, возможно, посмотрите, есть ли у него собственный журнал.
В противном случае может потребоваться перезагрузка.
Каждый раз, когда я сталкивался с подобной проблемой с saslauthd (и когда все остальное было проверено дважды), речь шла о правах доступа к каталогам / файлам. Проверьте каждый шаг этого /var/spool/postfix/var/run/saslauthd путь, чтобы убедиться, что saslauthd действительно может туда добраться.