При перезапуске saslsauthd я продолжаю получать следующие разрешения на /var/run/saslauthd реж:
drwx--x---
Это делает, например, Exim не может разговаривать с saslauthd.
Если я изменю разрешения следующим образом:
chmod o+x /var/run/saslauthd
..Эксим снова может поговорить с Саслаутом. Однако, как я уже писал, /etc/init.d/saslauthd restart достаточно снова сменить разрешения на 710.
Я ничего не нашел в /etc/init.d/saslauthd сценарий, чтобы это произошло. Что тут происходит?
ОС: Debian 7.0.
Проверьте / etc / group на эту запись:
sasl: x: 45: cyrus, Debian-exim
Каталог / var / run / saslauthd должен принадлежать группе sasl. Добавление Exim в группу sasl должно помочь.
Еще немного о каталоге / var / run.
/ var / run используется для хранения вспомогательных файлов для демонов. Это процессы, работающие в фоновом режиме. Наиболее распространенное использование - хранение pid процесса демона. Это упрощает для связанных сценариев запуска / остановки отправку сигнала уничтожения при попытке остановить эти процессы. Вы уже можете почувствовать, что данные в / var / run очень изменчивы. Таким образом, этот каталог очищается при каждой перезагрузке.
saslauthd создает такую информацию о времени выполнения при собственном запуске. И это гарантирует создание каталога с правами доступа, ожидаемыми saslauthd.
Отрывок из сценария инициализации saslauthd:
# If there is a statoverride for the run directory, then pull
# permission and ownership information from it and create the directory.
# Otherwise, we create the directory with default permissions and
# ownership (root:sasl, 710).
if dpkg-statoverride --list $RUN_DIR > /dev/null; then
createdir `dpkg-statoverride --list $RUN_DIR`
else
createdir root sasl 710 $RUN_DIR
fi
Кажется, можно даже разрешить другому владельцу и режиму доступа для каталога saslauth через dpkg-statoverride. Но я не знаком с этим и не рекомендую такие действия. Добавление exim в группу sasl - правильное решение.