Univention Bugzilla – Bug 28807
dbus kann nach Systemstart UID's nicht auflösen
Last modified: 2015-07-21 09:53:52 CEST
Beim Start eines Systems wird zunächst dbus gestartet, dann nscd. Das führt dazu, das dbus UID's nicht auflösen kann. Normale Benutzer können nach einem System-Start dbus nicht verwenden. Das hat dann wieder Auswirkungen auf diverse Sachen im Desktop Umfeld (polkit Fehler bei der Anmeldung am KDE, ...) -> siehe Bug #23864 1. dbus sollte für normale Benutzer verwendbar sein. Einzige bisher gefundene und praktikable Lösung ist, binddn und bindpw in /etc/libnss-ldap.conf zu verwenden (anstatt rootbindpw und *.secret Datei). Dadurch kann dbus bzw. nss beim Start die LDAP credentials auf /etc/libnss-ldap.conf auslesen und später verwenden. Achtung: Ändert man /etc/libnss-ldap.conf versucht dbus die Datei nochmals zu lesen. 2. Die Änderungen aus Bug #23864 sollten rückgängig gemacht werden. Beim Start von KDE wird normalerweise polkit-kde durch /etc/xdg/autostart/polkit-kde-authentication-agent-1.desktop gestartet. Das hatte zu einem Fehler geführt, da dbus nicht verwendbar war. Ohne diese Tool kann man aber diverse Dinge, die root Rechte benötigen, im Desktop nicht machen (Uhrzeit setzen, etc.) Unser KDE Profil sollte also wieder dahingehend geändert werden, dass polkit-kde wieder normal (mit dem nun hoffentlich gefixten dbus) startet -> profiles/kde4-menu/.config/autostart/polkit-kde-authentication-agent-1.desktop löschen
Anpassungen univention-pam: * Im Template für libnss-ldap.conf wird nun noch binddn (ldap/hostdn) und, falls /etc/machine.secret vorhanden, der Inhalt daraus als bindpw gesetzt. Das Konfig File bekommt die Permissions 440 und gehört dem Benutzer messagebus, so dass dbus daraus lesen kann. * Es gibt nun ein Passwort-Change Skript univention-libnss-ldap, dass ein commit auf libnss-ldap.conf macht. univention-kde * kde4-menu/.config/autostart/polkit-kde-authentication-agent-1.desktop wurde entfernt (sorgte dafür, dass polkit-kde-authentication-agent-1 bei der Anmeldung NICHT gestartet wurde)
Scheinbar verhindert die Änderung das Joinen von Client Systemen: root@master701:~# ls -la /etc/libnss-ldap.conf -r--r----- 1 messagebus root 731 19. Okt 12:17 /etc/libnss-ldap.conf root@master701:~# su - test1$ Kein Verzeichnis, Anmeldung mit HOME=/ I have no name!@master701:/$ Abgemeldet root@master701:~# chown root.root /etc/libnss-ldap.conf root@master701:~# su - test1$ Kein Verzeichnis, Anmeldung mit HOME=/ I have no name!@master701:/$ Abgemeldet root@master701:~# /etc/init.d/nscd stop Stopping NSCD: (not running). root@master701:~# su - test1$ Kein Verzeichnis, Anmeldung mit HOME=/ I have no name!@master701:/$ Abgemeldet root@master701:~# ls -la /etc/libnss-ldap.conf -r--r----- 1 root root 731 19. Okt 12:17 /etc/libnss-ldap.conf root@master701:~# chmod 644 /etc/libnss-ldap.conf root@master701:~# su - test1$ Kein Verzeichnis, Anmeldung mit HOME=/ test1master701:/$ Abgemeldet root@master701:~# → Erst nach der Ändrung der Berechtigungen auf 644 bekomme ich wieder einen Namen. test1 ist ein Memberserver und der scheitert beim Herunterladen des Zertifikats.
In der Ausgabe von comment #2 sehe ich root@master701:~# /etc/init.d/nscd stop Stopping NSCD: (not running). Ich gehe jetzt davon aus, dass in den Tests der nscd gar nicht lief. 3.1-0 Join eines Member mit laufendem nscd auf dem Master hat funktioniert. Wenn auf dem Master kein nscd läuft, dann klappt der Join nicht. chmod: Zugriff auf „/etc/univention/ssl/ucsCA/CAcert.pem“ nicht möglich: Datei oder Verzeichnis nicht gefunden Check TLS connection ldap_start_tls: Connect error (-11) 3.0-2 Hier ist ein ähnliches Verhalten zu beobachten. Mit auf dem Master laufendem nscd klappt der Join, sonst nicht Message: failed to create Member Server (1) [option --bindpwd requires argument] univention-join wird als Administrator ausgeführt und wenn der nscd auf dem Master nicht läuft, gibt es Probleme, weil der Administrator seinen eigenen passwd Eintrag nicht bekommt. Z.B. wird in univention-join (3.0-2) irgendwann eine Passwort-Datei auf dem Master kopiert univention-scp /tmp/tmp.qUdhWKHepj \ /tmp/tmp.qUdhWKHepj Administrator@master.amd64.de:/tmp/tmp.qUdhWKHepj Das geht mit unknown user 2002 lost connection schief, wodurch der ganze Join fehlschlägt. In 3.1 ist vermutlich an univention-join etwas geändert wurde, es bricht nun beim Kopieren des CA Zertifikat ab. univention-scp /tmp/tmp.kBJjIRRAPS/dcpwd \ -q Administrator@master.ucs.new:/etc/univention/ssl/ucsCA/CAcert.pem /etc/univention/ssl/ucsCA/ unknown user 2002 Es sieht für mich also so aus, als hätten wir ein Problem beim Join ohne laufendem nscd auf dem Master. Das hat aber mit diesem Bug erstmal nicht viel zu tun (siehe Bug #28961). Auch vorher konnten normale Benutzer nss nicht über ldap benutzen, da dafür /etc/machine.secret gebraucht wurde.
OK: Datum und Uhrzeit als Administrator ändern (nach Eingabe des root Passwort) OK: Benutzer- und Gruppenauflösung funktioniert OK: libnss-ldap.conf wird bei der Passwortänderung neu geschrieben OK: Changelog: OK
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".