После установки libsasl2-3-2.1.26-alt5 SASL Postfix authentication поломался: warning: SASL authentication failure: Internal Error -4 in server.c near line 1757 Jun 24 06:15:49 protein last message repeated 2 times Jun 24 06:15:49 protein postfix/smtpd[21089]: warning: xsasl_cyrus_server_get_mechanism_list: no mechanism available Jun 24 06:15:49 protein postfix/smtpd[21089]: fatal: no SASL authentication mechanisms Судя по всему, это вот этот баг: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638045
Нет, это оказалось другое. Исправил так: # cd /usr/lib # rm -rf sasl2/ # ln -sT sasl2-3 sasl2 # service saslauthd restart # service courier-authdaemon restart После чего SASL authentication заработала нормально (это на i32 архитектуре). То есть проблема в том, что cyrus-sasl2-2.1.26-alt5 не знает про /usr/lib/sasl2-3/ от libsasl2-3-2.1.26-alt5.
Это результат исправления bug #30113. То есть, сломался saslauthd, получается ? pluginviewer плагины показывает ? У меня показывает. И с libsasl2-3 тоже всё в порядке: у меня Curus-IMAP через mysql-плагин работает.
И courier-authdaemon тоже через sasl авторизует ? А он работал без симлинка, или, тоже, нет ? И, ещё: Postfix и Courier перезапускались после обновления libsasl2-3, или со старой библиотекой в памяти так и продолжали работать ?
(In reply to comment #2) > Это результат исправления bug #30113. > > То есть, сломался saslauthd, получается ? Да, похоже cyrus-sasl2 тут ни причем. Я даже не помню, зачем он у меня стоит - пользуюсь связкой Postfix, Courier-IMAP, SASL, MySQL (auxprop). > pluginviewer плагины показывает ? Сейчас он все, что надо показывает, а как оно было до ручной правки симлинков в системе - этого я не знаю. > У меня показывает. И с libsasl2-3 тоже всё в порядке: у меня Curus-IMAP через > mysql-плагин работает. У меня Courier-IMAP с аутентикацией через MySQL auxprop плагин. SASL в Courier-IMAP работал и не вызывал проблем и после обновления. Это только Postfix smtpd падать на SASL auth начал.
(In reply to comment #3) > И courier-authdaemon тоже через sasl авторизует ? А он работал без симлинка, > или, тоже, нет ? > > И, ещё: Postfix и Courier перезапускались после обновления libsasl2-3, или со > старой библиотекой в памяти так и продолжали работать ? Все перезапускалось и сервер перезагружался тоже. Не помогало. Зато простой симлинк на старое имя пути к библиотекам - помогло сразу.
(In reply to comment #4) > > То есть, сломался saslauthd, получается ? > > Да, похоже cyrus-sasl2 тут ни причем. saslauthd в пакете cyrus-sasl2, как раз. Это если он под подозрением... > Сейчас он все, что надо показывает, а как оно было до ручной правки > симлинков в системе - этого я не знаю. Так надо симлинк убрать и проверить. У меня никаких симлинков нет, Cyrus-IMAP работает нормально и pluginviewer всё показывает. # ls -dl /usr/lib/sa* drwxr-xr-x 2 root root 4096 Jun 17 12:28 /usr/lib/sasl2-3 # rpm -qa|grep "cyrus\|sasl" cyrus-imapd-2.4.17-alt1 libsasl2-3-2.1.26-alt5 cyrus-sasl2-2.1.26-alt5 libsasl2-plugin-sql-2.1.26-alt5 > У меня Courier-IMAP с аутентикацией через MySQL auxprop плагин. SASL в > Courier-IMAP работал и не вызывал проблем и после обновления. Это только > Postfix smtpd падать на SASL auth начал. Странно весьма. У одного пользователя библиотеки всё хорошо (Courier-IMAP), у другого - нет (Postfix). А Postfix в chroot ? chroot-окружение у него обновлялось ?
Ещё вопрос, а это вот зачем ? # rm -rf sasl2/ Если всё правильно было, этого каталога, по идее, не должно было остаться. Никакого самосбора нет случайно ?
нужны консультанты по Postfix...
(In reply to comment #8) > нужны консультанты по Postfix... Когда я вас просил не ломать прямую и обратную совместимость, вы меня не услышали...
(В ответ на комментарий №9) > Когда я вас просил не ломать прямую и обратную совместимость, вы меня не > услышали... Если вчитаться, дело сейчас вовсе не в soname, а в упаковке в соответствии с http://www.altlinux.org/Shared_Libs_Policy C libsasl2-3-2.1.26-alt3 никаких проблем не было, кроме конфликта с libsasl2. А делать в соответствии с Shared_Libs_Policy пришлось бы рано или поздно. Я считаю, что лучше это делать раньше.
(В ответ на комментарий №10) > кроме конфликта с libsasl2. В смысле в спеке: 2014-06-04 Gleb F-Malinovskiy <glebfm at altlinux.org> 2.1.26-alt4 - Drop Conflicts: libsasl2 to comply SharedLibs Policy. Ну и CVE-2013-4122 можно было исправить не дожидаясь, пока за cyrus-sasl я возьмусь, если что. Так что, предлагаю думать, почему все работают (Courier-IMAP и Cyrus-IMAP, по крайней мере), а Postfix - нет, а не заниматься обвинениями.
Смотрю, делается попытка старый soname вернуть в сборке 2.1.26-alt6 ? В общем-то, это неправильно, так как именно сейчас soname совпадает с апстримным и является правильным. Это раз. А два - soname когда-нибудь ещё раз сменится. Беда не из-за soname, а из-за выноса плагинов в %libdir/sasl2-3 из %libdir/sasl2. Причём, на сколько я понимаю, проблему это вызвало только у Postfix: вот на этот вопрос никто не ответил пока: http://lists.altlinux.org/pipermail/sisyphus/2014-June/362434.html
Эта неделя у меня посвободнее ожидается, попробую себе Postfix поставить куда-нибудь и воспроизвести проблему, особенно, если мне кто-нибудь пример проблемной конфигурации в почту пошлёт.
(In reply to comment #7) > Ещё вопрос, а это вот зачем ? > > # rm -rf sasl2/ > > Если всё правильно было, этого каталога, по идее, не должно было остаться. > Никакого самосбора нет случайно ? Нет, никакой сомосборки не было. Но в процессе настройки постфикса и всей почтовой связки, на каком-то этапе, в этот каталог были скопированы (возможно - руками) несколько левых файлов (pem сертификаты). Когда и зачем - не вспомнить уже, у меня этот сервер с 2006 года стоит. Только эти файлы там и оставались после обновления. Возможно, скрипт инсталляции не смог их удалить и молча упал? В логах обновления никаких ошибок не было, это я точно помню. Удаление каталога и старых pem-файлов описанное выше никак не повредило аутентификации (они давно уже в другом месте ищутся SASL-ом).
(In reply to comment #14) > несколько левых файлов (pem сертификаты). Понятно. Это, действительно, причина, чтобы каталог /usr/lib/sasl2 остался: rpm не удаляет непустые каталоги. Но на работоспособность нового пакета повлиять это было не должно.
Проверил "saslauthd -o pam" (-o rimap изначально использовался) с таким конфигом /etc/sasl2/Sendmail.conf: ============ pwcheck_method: saslauthd mech_list: LOGIN PLAIN ============ SQL проверил с таким конфигом Sendmail.conf (опции запуска saslauthd тут не влияют уже): ============ pwcheck_method: saslauthd mech_list: LOGIN PLAIN allow_plaintext: true auxprop_plugin: sql sql_engine: mysql sql_hostnames: 127.0.0.1 sql_user: xxxx sql_passwd: xxxx sql_database: xxxx sql_select: select passwd.passwd from passwd,usergroup where username='%u' and passwd.device=64 and passwd.deleted=0 ============= SQL-запрос, конечно, под мою базу. Всё работает. Так что баг, вероятно, именно в Postfix. Sendmail пересобирался последний раз раньше, чем cyrus-sasl2, который вызвал проблему с Postfix, Sendmail-у изменения в alt5 не повредили.
> warning: SASL authentication failure: Internal Error -4 in server.c near line 1757 А кто вот это вот написал ? Что-то я это сообщение у себя в логе получить не могу. Оно к Postfix относится, или к saslauthd ? Пока в коде Postfix обнаружилось такое вот место: #if SASL_VERSION_MAJOR >= 2 *path = strdup("/etc/postfix/sasl:@libdir@/sasl2"); #else *path = strdup("/etc/postfix/sasl:@libdir@/sasl"); #endif Как без жёсткой ссылки обходятся остальные клиенты, не знаю пока. С другой стороны, это даёт возможность вынести символьную ссылку /usr/lib/sasl2 в /etc, что несколько более удобно.
Предлагаю сделать так: bug 30270. Этот баг перевешивать не стал для удобства поиска.
В общем, похоже, что Postfix - единственный клиент, который не учитывает возможность сборки cyrus-sasl2 с --with-plugindir=
