Hi.
Ich habe gestern unseren v6.2-Server benutzt, um einen Rechner per LINBO zu bestücken. Daher bin ich sicher, dass gestern noch alles lief. Heute scheiterte der Login (sogar als administrator) und bei näherem Nachsehen stellte ich fest, dass OpenLDAP nicht mehr lief. Ein Neustart via /etc/init.d/slapd restart brachte nur ein FAIL und im syslog steht die wenige aussagekräftige Mitteilung:
Jetzt weiß ich nicht mehr, woran es scheitert bzw was da plötzlich von gestern auf heute schief gelaufen ist. Festplattenplatz ist reichlich vorhanden…
Hat einer eine Idee?
slapd ist Version 2.4.28-1
Schöne Grüße und danke für Tipps.
Michael
laut Deiner ersten Fehlermeldung hat wohl der Sicherheitsmechanismus apparmor zugeschlagen, der mir von Zeit zu Zeit auch Probleme bereitet. Versuch mal:
Vorschlag eins: Serverneustart
Vorschlag zwei:
Mit:
sudo service apparmor teardown
den lästigen Gesellen mal ausschalten, dann openldap neustarten.
Hallo Christoph.
Serverneustart hat’s nicht gebracht; hatte ich natürlich schon versucht (und hier vergessen zu erwähnen). Was kann apparmor in die Knie gewzungen haben? Ich war der einzige User im System.
Der zweite Befehl liefert beim Runterfahren von AppArmor OK aber beim Start von OpenLDAP erneut ein FAIL.
Leider ist das also nicht die Lösung. Im Syslog taucht bei nicht laufendem AppArmor übrigens gar keine Fehlermeldung mehr auf. Dort sieht alles richtig aus, doch der Dienst startet trotzdem nicht.
Michael
Kann gerade keinen Screenshot schicken, aber es gab keine Fehlermeldung im Syslog. Es sah im Log alles richtig aus, doch es gab trotzdem ein FAIL.
Sorry, genauer geht es gerade nicht.
Michael
Die Platte ist nicht voll aber es gibt aktuell ein Problem mit dem Hypervisor (Proxmox) bzw dem eingebauten RAID. Es scheint eine Platte im RAID abgerauscht zu sein?!? Muss noch genauer geprüft werden.
Aber ist es möglich, dass sich die linuxmuster-VM bzw ausgerechnet OpenLDAP deshalb so merkwürdig verhält? Alle anderen Dienste sind wohlgemerkt ganz normal hoch gefahren.
Das Problem ist gelöst … und es lag wieder mal an unerwarteter Stelle:
Wir haben LetsEncrypt auf dem Server laufen, um gültige Zertifikate zu haben. Das setzt scheinbar ein paar Rechte von /etc/ssl/private anders als es OpenLDAP gefällt. Jedenfalls lief der Server monatelang ohne Neustart sauber durch, so dass der Fehler mit dem nicht mehr startenden slapd bisher nicht aufgefallen ist.
Lösung des Problems: Die Dateien server.pem / server.key unter /etc/ssl/private müssen root:ssl-cert gehören. Das war hier für die .key-Datei nach einem LetsEncrypt-Update nicht (mehr) der Fall!
Wenn man das wieder ändert, startet der Service slapd auch wieder. Geholfen hat es, das Loglevel unter /etc/ldap/slapd.conf --> loglevel 0 auf 256 zu ändern. Erst danach gab es eine Fehlermeldung im Syslog, mit der man etwas anfangen konnte (“main: TLS init def ctx failed: -1”). Zuvor wurde gar nichts gelogged, so dass alles OK aussah doch der Service dennoch nicht lief.
Vielleicht hilft’s auch anderen. Ich bin froh, dass unser Server wieder läuft…
Schöne Grüße,
Michael
