При переходе с 227-alt1 из бранча на 239-alt1 из сизифа имеются следующие симптомы (nss_ldap.conf сохраняем от предыдущей версии (а где, кстати noreplace??)): 1. После перезагрузки с консоли не пускает никого кто есть в базе. При этом авторизация на сервере проходит. 2. Если отломать сеть, то пустит локального рута с локальным паролем. Далее поднимаем сеть и у рута не работает sudo, su. `sudo true` банально сегфолтится. 3. getent при этом работает.
По поводу "не пускает"... Что написано в /etc/pam.d/system-auth?
#%PAM-1.0 auth sufficient /lib/security/pam_ldap.so auth required pam_tcb.so shadow fork prefix=$2a$ count=8 nullok account sufficient /lib/security/pam_ldap.so account required pam_tcb.so shadow fork password sufficient /lib/security/pam_ldap.so password required pam_passwdqc.so min=disabled,24,12,8,7 max=40 passphrase=3 match=4 similar=deny random=42 enforce=users retry=3 password required pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb session optional /lib/security/pam_ldap.so session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=002 session required pam_tcb.so session required pam_limits.so
Значит бага может быть и в pam_ldap и просто в pam, nss_ldap тут скорее всего не при чем! Попробуйте сделать sudo -u user true от рута, предварительно настроив для user право выполнять /bin/true... Если будет падать, то естественно strace -o log и этот лог в студию...
Created attachment 1119 [details] strace -o /tmp/log su - gorev -c /bin/true Запущено от рута сразу после rpm -Uvh nss_ldap-239-alt1.i586.rpm
Да, Женя я понимаю что проблема может быть в чем угодно. Я потратил 3 часа на колупание в strace-логах чтобы утверждать, что она в nss_ldap. Даже сейчас, сидя за чистым мастером, я не смог сделать твой testcase только потому, что сразу после установки сизифного nss_ldap все перестает работать. Это может легко воспроизвести каждый. Единственно что могу добавить, это вот: [gorev@smart gorev]$ sudo su Segmentation fault [gorev@smart gorev]$ strace -o /tmp/log sudo su Sorry, sudo must be setuid root. Ежели все-таки нужен хоть какой strace, то вывод команды `strace -o /tmp/log su - gorev -c /bin/true` приложен.
Готов подтвердить странное поведение связки pam_ldap nss_ldap. При установленом в nsswitch.conf поиске в ldap вот так: passwd: files ldap nisplus nis shadow: tcb files ldap nisplus nis group: files ldap nisplus nis Система становится не работоспособна, как более детально объяснить не знаю. После загрузки не войти ни локально ни удаленно. PAM настроен как описанно тут http://wiki.sisyphus.ru/admin/LdapWinbindUsers Так же, по косвенным признакам, отваливаются все процессы которые пытаются запустится не от root'а. При удалении записи об ldap в nsswitch.conf система успешно грузится. Заходим рутом возвращаем ldap в nsswitch.conf, перезапускаем nscd. И успешно работаем, делаем su в юзера и т.д... Пришлось убить 3 часа что бы все таки понять что система не работоспособна из за записи ldap в nsswitch.conf.
Смотрите #8410. У нас (с Nick S. Grechukh) уже есть давно рабочие сборки и мы их используем. Майнтейнер почему-то молчит...
*** This bug has been marked as a duplicate of 8410 ***
