LDAP hängt sich auf nach Update auf 4.1

Hallo,

ich nutze UCS mit Zarafa und zpush privat. Bis 4.0.4 war ich begeistert von dem tollen System, stabil und zuverlässig.
Seit dem Update auf 4.1 kommt es öfter vor, dass sich niemand mehr anmelden kann, egal ob auf der Konsole, der Web-UI oder bei Zarafa oder zpush. Ich habe im Zarafa-Log auch bereits einen Hinweis auf einen nicht anwortenden LDAP gesehen, sonst aber in den Logs nichts gefunden, was mich weiter gebracht hätte.
Welche Logs sollte ich mir anschauen?
Wer hat ähnliche Probleme und vielleicht schon eine Lösung?

Danke für Infos und Unterstützung

Thomas

Hallo,

das Problem ist bekannt und wir arbeiten daran, es so schnell wie möglich zu beheben ([bug]40059[/bug]).

Eine Mögliche Übergangslösung ist vorübergehend die Datei /etc/ldap/sasl2/slapd.conf zu löschen. Dadurch steht der Single-Sign-On/SAML Login in UMC nur eingeschränkt zur Verfügung.
Die Datei kann jederzeit wiederhergestellt werden mit dem Kommando: ucr commit /etc/ldap/sasl2/slapd.conf

Das Problem liegt an einem nicht erreichbaren LDAP-Dienst.
Um das Problem untersuchen zu können sind einige Informationen für uns hilfreich:

Entweder ein Core-Dump des hängenden slapd-Prozess. Dieser kann wie in sdb.univention.de/1316 beschrieben generiert werden.
Die erzeugte Datei kann hier hochgeladen werden: upload.univention.de/

Alternativ ist ein Backtrace des Prozesses auch hilfreich, dieser kann mit folgenden Kommandos als root auf dem hängenden System generiert werden:

apt-get install -y gdb slapd-dbg cyrus-sasl2-dbg cy2-saml-dbg pam-saml-dbg
gdb /usr/sbin/slapd "$(pidof slapd)" \
      --batch --ex 'thread apply all bt'

Welche Architektur (amd64/i386) hat das System?
Welche Apps und UCS-Komponenten sind auf dem System installiert?
Wird der SAML-Login benutzt?
Wie viel Last herrscht auf dem System und wie viele Benutzer sind ca. gleichzeitig angemeldet?

Zum erstellen des Core-Dumps muss der Prozess in hängendem Zustand mit dem folgenden Befehl getötet werden:

kill -11 "$(pidof slapd)"

[quote=“Best”]
Welche Architektur (amd64/i386) hat das System?[/quote]
Ich habe einen AMD64

Eigentlich nichts weltbewegendes, Zarafa, zpush, OpenVPN

Nicht, dass ich wüßte.

sehr wenig, das meiste sind Zarafa und zpush, da sind maximal 5 Benutzer gleichzeitig unterwegs.

Dump wird schwierig, da ich selten eine Session auf der Kiste offen habe. Mal schauen.

Gibt es, bei offener Session, eine Chance den LDAP zu reaktivieren ohne jedesmal einen Reboot zu machen?

Danke für Info

Thomas

vielen Dank für die Informationen.
Bei laufender Session als root kann “invoke-rc.d slapd restart” ausgeführt werden, dann ist kein Neustart des gesamten Systems notwendig.

Hallo,
wir haben gerade aktualisierte Pakete mit einer Vorabversion des Fixes veröffentlicht. Diese können durch einbinden der Komponente “glibc” und einem Upgrade eingespielt werden:

ucr set repository/online/component/glibc=true \
      repository/online/component/glibc/unmaintained=true
univention-upgrade
invoke-rc.d slapd restart

Wir würden uns natürlich über Ihre Rückmeldung freuen, wie sich das System mit den angepassten Paketen verhält. Ein offizielles errata-Update wird so schnell wie möglich veröffentlicht.

Hallo!
Wir haben heute die errata-Updates veröffentlicht, die das Problem beheben:
errata.software-univention.de/ucs/4.1/8.html
errata.software-univention.de/ucs/4.1/9.html
errata.software-univention.de/ucs/4.1/11.html
errata.software-univention.de/ucs/4.1/10.html

Nach dem Einspielen der erratum-Updates ist ein Neustart des Systems notwendig.

Danke, mache ich nachher gleich rein.

Sind damit die Änderungen, die ich entsprechend des Scripts vom 25.11. eingestellt habe, rückgängig oder muss ich hier noch etwas tun um aufzuräumen?

Danke für die Lösung

Thomas

Die UCR-Variablen sollten nur wieder gelöscht werden:

ucr unset repository/online/component/glibc repository/online/component/glibc/unmaintained

Wenn danach univention-upgrade ausgeführt wird werden alle von der Komponente installierten Pakete durch die neuen offiziellen Pakete ersetzt.

Mastodon