Hallo LUG,
Wir haben hier einen Cluster aus zwei Servern mit replizierter LDAP- Datenbank basierend auf RHEL4 (CentOS 4). Nach einem Neustart ist es nicht mehr möglich sich als normaler User auf dem Rechner mit der Slave-LDAP-Datenbank einzuloggen. LDAP (OpenLDAP) startet ohne Fehlermeldungen und ein Vergleich des Datenbestandes auf beiden Rechnern mit slapcat zeigt identische Daten. Beim Versuch sich mit ssh einzuloggen, meckert sshd wegen eines "illegal user". Ich habe die Protokolle von beiden Rechnern angehängt. "Good" zeigt einen erfolgreiches Login auf dem Master, "failed" den gescheiterten auf dem Slave. Anscheinend kann sshd den user nicht finden.
Ich bin nun etwas ratlos, wo ich anfangen soll zu suchen. Kann mir jemand helfen?
Viele Grüße
Markus Ullmann
Markus Ullmann schrieb:
Hallo LUG,
Hallo,
Wir haben hier einen Cluster aus zwei Servern mit replizierter LDAP- Datenbank basierend auf RHEL4 (CentOS 4). Nach einem Neustart ist es nicht mehr möglich sich als normaler User auf dem Rechner mit der Slave-LDAP-Datenbank einzuloggen. LDAP (OpenLDAP) startet ohne Fehlermeldungen und ein Vergleich des Datenbestandes auf beiden Rechnern mit slapcat zeigt identische Daten. Beim Versuch sich mit ssh einzuloggen, meckert sshd wegen eines "illegal user". Ich habe die Protokolle von beiden Rechnern angehängt. "Good" zeigt einen erfolgreiches Login auf dem Master, "failed" den gescheiterten auf dem Slave. Anscheinend kann sshd den user nicht finden.
Ich bin nun etwas ratlos, wo ich anfangen soll zu suchen. Kann mir jemand helfen?
- funktioniert die LDAP db wirklich? - ist nsswitch korrekt eingerichtet? - ist PAM korrekt eingerichtet? - was steht in der auth.log vom sshd?
MfG -Dimitri aka Tristan-777
Hallo,
Am 10.10.2006 um 17:21 schrieb Dimitri Puzin:
- funktioniert die LDAP db wirklich?
Ich glaube hier liegt das Problem. Laut 'netstat -l' ist der LDAP- Port 389 nicht offen. Der "slapd"-Prozess läuft und bringt keine Fehlermeldung. Wenn ich bei 'ldapsearch' auf dem slave keinen Host angebe, funktioniert die Abfrage. Gebe ich den Slave an, kommt "ldap_bind: Can't contact LDAP server (-1)" Ich habe an der Konfiguration nichts geändert. Kann man OpenLDAP dazu bewegen Debuginformationen auszugeben?
Ich habe auf dem Master heute früh Updates eingespielt, den Slave unangetastet gelassen. Wegen ein paar Problemen dabei musste ich beide neu starten. Seit dem funktioniert es nicht mehr.
Vielen Dank
Markus
Markus Ullmann m.ullmann@web.de (Di 10 Okt 2006 18:58:02 CEST):
Hallo,
Am 10.10.2006 um 17:21 schrieb Dimitri Puzin:
- funktioniert die LDAP db wirklich?
Ich glaube hier liegt das Problem. Laut 'netstat -l' ist der LDAP- Port 389 nicht offen. Der "slapd"-Prozess läuft und bringt keine Fehlermeldung.
Der Port muß ja nicht offen sein.
In /etc/ldap/ldap.conf (Debian, bei Fedora/RH/CentOS möglicherweise leicht daneben, aber die in der URI und BASE und dgl. steht) sollte die URI bzw. der LDAP-Server drinstehen. Möglicherweise hast Du bisher ldapi:/// genutzt, und plötzlich hast Du keine Permissions für den Socket mehr. Früher konnte man dem slapd beim Anlegen der Socketdatei (ja, die legt er jedesmal neu an) auch die gewünschten Permissions mitgeben (x-mod), das scheint, zumindest aktuell in Debian sarge nicht mehr zu gehen.)
Symptom war, daß ich als root 'getent passwd' haben konnte, als hans aber nicht.
(Welches Interface PAM bzw. NSS nutzen, steht in /etc/pam_ldap.conf bzw. /etc/libnss-ldap.conf (wieder: Debian, bei anderen eventuell etwas anders). Vielleicht steht dort ja auch ldapi:/// drin.
Was tun? Slapd auch ldap://localhost/ erlauben (wird meist beim Start mit festgelegt, sollte bei einem ps zu sehen sein), und dann allen sagen, daß ldap://localhost/ zu nutzen ist. Ist zwar Overkill, aber anderes wußte *ich* mir nicht zu helfen.
Best regards from Dresden Viele Grüße aus Dresden Heiko Schlittermann
Am Dienstag, 10. Oktober 2006 16:20 schrieb Markus Ullmann:
Hallo LUG,
Wir haben hier einen Cluster aus zwei Servern mit replizierter LDAP- Datenbank ...
Das müsste hier auch mal aufgesetzt werden. Immer schön wenn es Experten dafür auf der Liste gibt :-)
Nach einem Neustart ist es nicht mehr möglich sich als normaler User auf dem Rechner mit der Slave-LDAP-Datenbank einzuloggen.
Evt. automatische Updates eingespielt? Ist aber auch egal.
Liefert ein "getent passwd" die Systembenutzer und die LDAP-Accounts? Dann ist der Fehler nicht bei LDAP+PAM sondern irgendwo bei ssh+PAM.
LDAP (OpenLDAP) startet ohne Fehlermeldungen und ein Vergleich des Datenbestandes auf beiden Rechnern mit slapcat zeigt identische Daten. Beim Versuch sich mit ssh einzuloggen, meckert sshd wegen eines "illegal user". Ich habe die Protokolle von beiden Rechnern angehängt. "Good" zeigt einen erfolgreiches Login auf dem Master, "failed" den gescheiterten auf dem Slave. Anscheinend kann sshd den user nicht finden.
Unterscheiden sich die /etc/ssh/sshd_config zwischen master und slave? Ich tippe auf eine Zeile mit "UsePAM yes". Oder in einer der vielen Dateien die von PAM+LDAP+SSH auf dem Weg durchs System durchforstet werden (/etc/nsswitch.conf; /etc/pam.d/* ; /etc/ldap.conf; /etc/openldap/*)
Ich bin nun etwas ratlos, wo ich anfangen soll zu suchen. Kann mir jemand helfen?
Eventuell.
Viel Erfolg
Jens Weiße
lug-dd@mailman.schlittermann.de
-
Dimitri Puzin -
Heiko Schlittermann -
Jens Weiße -
Markus Ullmann