ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | kde4, dbus, пользователи в ldap -- не работает | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Anton V. Boyarshinov <boyarsh> | ||||
| Component: | glibc-core | Assignee: | Gleb F-Malinovskiy <glebfm> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | aen, glebfm, ktirf, ldv, redbaron, sem, shrek, vitty, vsu | ||||
| Version: | unstable | ||||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
А dbus-launch запущен? Это свежепоставленная система или уже наставлено разных пакетов? dbus-launch запущен, но даже dbus-monitor --system ругается: Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. От "нормального" пользователя стартует. По просьбе Антона перевешиваю на dbus. https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/139098 Такое впечатление, что ни в Федоре ни в Убунту никто так и не заглянул собственно в код dbus.. А нам придётся... так и не должен dbus знать о пользователях из ldap, т.к. стартует еще до сети (В ответ на комментарий №5)
> так и не должен dbus знать о пользователях из ldap, т.к. стартует еще до сети
А он что -- вычитывает всех пользователей при старте и никого, кто появляется позже, за людей не считает? По идее ему следует проверять существование и полномочия пользователя при обращении..
по идее да. но на сколько я вижу все поднимают dbus выше ldap (В ответ на комментарий №7) > по идее да. но на сколько я вижу все поднимают dbus выше ldap Тогда нельзя сеть NM-ом поднимать.. Ну и, опять же, тогда при добавлении ldap-овского ползователя dbus на всех машинах перезапускать... Увы, это выглядит блокером для всей пятой платформы :( Видимо придётся разбираться и сурово патчить. Хотя прекрасно понимаю, что хотелось бы обойтись без этого.. (В ответ на комментарий №4) > https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/139098 > Здесь описано решение, разве нет? (В ответ на комментарий №9) > (В ответ на комментарий №4) > > https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/139098 > > > Здесь описано решение, разве нет? Прочитал #8 и понял, да. Похожий баг: https://bugzilla.redhat.com/show_bug.cgi?id=182464 (В ответ на комментарий №8) > (В ответ на комментарий №7) > > по идее да. но на сколько я вижу все поднимают dbus выше ldap > > Тогда нельзя сеть NM-ом поднимать.. Ну и, опять же, тогда при добавлении > ldap-овского ползователя dbus на всех машинах перезапускать... > http://www.openldap.org/lists/openldap-technical/200803/msg00021.html Здесь опускают ldap ниже всех. Похоже на это: https://bugzilla.redhat.com/show_bug.cgi?id=186527 Comment #54 From Andrew McNabb 2008-12-01 19:02:32 EDT ------- Until nss-ldapd replaces nss_ldap, this problem won't go away. Everything else is just a temporary workaround.
> Until nss-ldapd replaces nss_ldap, this problem won't go away. Everything else
> is just a temporary workaround.
Да, использование nss-ldapd решает проблему.
(In reply to comment #14) > > Until nss-ldapd replaces nss_ldap, this problem won't go away. Everything else > > is just a temporary workaround. > Да, использование nss-ldapd решает проблему. Нет, не решает, только маскирует. glibc-6:2.9-alt5 -> sisyphus: * Mon Apr 20 2009 Dmitry V. Levin <ldv@altlinux> 6:2.9-alt5 - glibc-doc is no longer required by glibc-devel (closes: #17963). - Backported fix for__res_maybe_init() from trunk (closes: #19657). (В ответ на комментарий №17)
> - Backported fix for__res_maybe_init() from trunk (closes: #19657).
Не уверен.. Обновил на тестовой машине glibc из Сизифа, обнулил и +i на /etc/resolv.conf , перезагрузил.
ldap, естественно, не доступен.
Вернул правильный resolv.conf, ldap по прежнему недоступен, nslcd пишет: resource is temporary unavalible.
ПОсле перезапуска nslcd всё работает.
(In reply to comment #18) > (В ответ на комментарий №17) > > - Backported fix for__res_maybe_init() from trunk (closes: #19657). > Не уверен.. Не уверен, что backported, или не уверен, что closes? > Обновил на тестовой машине glibc из Сизифа, обнулил и +i на > /etc/resolv.conf , перезагрузил. > ldap, естественно, не доступен. > Вернул правильный resolv.conf, ldap по прежнему недоступен, nslcd пишет: > resource is temporary unavalible. Это уже что-то новое. > ПОсле перезапуска nslcd всё работает. А если вернуть nss_ldap? (В ответ на комментарий №19) > > > - Backported fix for__res_maybe_init() from trunk (closes: #19657). > > Не уверен.. > > Не уверен, что backported, или не уверен, что closes? что closes ;) > > ПОсле перезапуска nslcd всё работает. > > А если вернуть nss_ldap? Установил дистрибутив от 17 числа (с nss_ldap). Первая загрузка -- глухое зависание до неработы numlock (вчера такое же одина раз было с nss-ldapd, Миша проинформирован). Перезагрузил, обновил glibc, init 1, обнулил resove, перезагрузил, всё работает. Сейчас с chattr попробую.. с chattr +i пустого resolve.conf после приведения его в норму после загрузки всё работает (с nss_ldap) образ с nss_ldap и новым glibc работает нормально. Рекомендую в 5.0 ;) *** Bug 19720 has been marked as a duplicate of this bug. *** |
Created attachment 3466 [details] xsession-errors:0 Была обнаружена неработоспособность kde4 в ситуации, когда инофрмация о пользователе доступна только через ldap. То есть если для ldap пользователя есть локальный пользователь с соответствующим id, то работает, для "честого" же ldap пользователя, для которого нет локальной записи с таким id виснет на старте. Консольный логин работает, id отдаёт релевантную инормацию