Нет, это оказалось другое.

Исправил так:

# 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=