ldap gau. läuft aber kein connect

**ramsys** · 23.11.05, 16:29

Haben den Server etwas ram spendiert.
Nach dem neustart ruft kollege er kann sich nicht anmelden.
Blick aufs directory: Alles daten auf stand von September

Was kann da passiert sein?
Danach viel mir auf das beim versuch etwas neu ins directory zu schreiben
die ganze kiste hing. Lediglich nach einem ldap neustart von einer anderen console konnte man überhaupt wieder befehle eingeben. Nach 2-3 versuchen kommt nur noch cant contact ldap server (-1) auch in den messages steht nix dramatisches.
Also ldap läuft und wiederum doch nicht.

Hat wer ne rettende idee?
ldap status sagt aber running.
Wieso hats die daten im directory auf einen stand von september versetzt?
Alles lief vorm ramwechsel top.
Waren schon 30 user angelegt.
Hat super die profile gespeichert alles ging verdammt.
Please help

**BedriddenTech** · 23.11.05, 16:35

Hast mal db_recover laufen lassen? Mal nach der Konfigurationsdatei geguckt?

**ramsys** · 23.11.05, 17:45

Hi,
ldap.conf unter etc und openldap ist geblieben wie es war. Hab ich nachdem unter var/lib/ldap die db dateien stand September hatten als erstes gemacht.
db_recover hab ich noch nicht gemacht.
Bin jetzt leider 2 Tage beim workshop und komm blöder weise nicht an den server. Hab auch mal alles unter var/lib/ldap gesichert und gelöscht. Danach wollte ich mal die db neu aufbauen. Bringt nix da can' connect ldap server kommt. Wie konnte es überhaupt dazu kommen? Die db war quasi im urzustand bis auf einen user mit dem ich zum aufbau des netzes gearbeitet habe. Den user hatte ich aber vor dem gau schon längst gelöscht.
Kapier nich wo ldap die alten daten her hat. Hat der irgendwo ne art backup lungern?

**ramsys** · 23.11.05, 19:33

Hab beim stöbern gelesen das bdb mit ext3 oder reiserfs probs haben kann? was isn da dann? stand auch einiges wegen neustart und ldap probs in dem zudammenhang.

**BedriddenTech** · 23.11.05, 19:46

Gibt natürlich Backupgeschichten, aber ich weiß nicht, ob LDAP die automatisch anlegt. Prüf doch mal mit lsof, welche Dateien der Server öffnet. Oder leere das Datenverzeichnis mal (klar, mit Sicherung vorher), und schau mal, ob du dann wenigstens wieder verbinden kannst. Du könntest auch mal schaun, wann das System die Checkpoints gesetzt hat (die BDB macht das) und dann entsprechend wiederherstellen. Ich weiß nur nicht auswendig, wie das geht.

Von den Problemen weiß ich nichts, kannst du da genauere Informationen (Link, Suchstichwörter) geben? Ich habe nur folgendes gefunden:

Zu deinen Bedenken hinsichtlich reiserfs und bdb. Einerseits ist
reiserfs besser als ext2, da ein Eintrag im Verzeichnisdienst
ca. 3-5 KB groß ist, dementsprechend kleine inodes gewählt werden
können, und reiserfs bei kleinen Dateien performanter
ist. Andererseits führen beide Systeme, reiserfs und
Database-Management, Transaktionskontrollen durch, also doppelte
Arbeit, daher kann bei hohen Schreibzugriffen, reiserfs langsamer sein
als ext2, hohe Schreibzugriffe sind hier aber mehrere Hundert pro
Minute, gelegentliches Schreiben, 1 bis 2 pro Minute, oder sogar noch
weniger, beinträchtigen nicht die Leistungsfähigkeit.

**ramsys** · 23.11.05, 20:07

Hatte schon einmal das ldap verzeichniss geleert (mit backup) konnte jedoch keine db erstellen mit z.b. den smblap-populatescript. can't connect wie immmer.
Gefunden habe ich das mit den angeblichen problemen in der suse list:
http://portal.suse.com/sdb/de/2003/0...b_recover.html
Das komische ist nur das ich noch ein paar mal wenigstens in der db lesen konnte.
War zwar der stand von september aber wenigstens was. Danach war ganz aus.
Bei dem versuch daten anzulegen blieb das sys einfach stehen. zumindest in der console.
In vorsorglich anderen geöffneten consolen konnte ich wenigstens den ldap neustarten und dann wieder
in der ursprünglichen console weiter arbeiten.
Ich nutze übrigens ext3.
gruß

#edit
Weißt du zufällig wieviel suse maximal an ram abkann?
habs mit 6 gb probiert vor dem gau.
Bis wieviel würde auf dem server überhaupt ausgenutzt werden?

**mamue** · 24.11.05, 11:11

Ich habe gelegentlich Probleme gehabt mit OpenLDAP, wenn der Server nicht sauber heruntergefahren wurde (XFS).
Dabei hat mir eigentlich immer db_recover geholfen. Das ist auszuführen in deinem ldap-Datenbankverzeichnis, standardmässig wohl /var/lib/ldap. Wenn Du noch eine Sicherung hast (slapcat -l sicherung.ldif) kannst Du die mit slapadd -l sicherung.ldif wieder zurückschreiben. Vielleicht kannst Du ja noch (eventuell auch mal dafür OpenLDAP stoppen) diese Sicherung anlegen, bevor Du weitere Experimente machst. Ansonsten sollte Dir das Kommandozeilen-Tool "ldapsearch" Auskunft darüber geben, ob der LDAP server gerade läuft. Ich habe es schon gehabt, das openldap mit 100% CPU-last lief, weil eben die Datenbank "defekt" war.

HTH,
mamue

**ramsys** · 24.11.05, 15:49

Das erklärt vielleicht auch warum dann in der Aktuellen console alles hing wegen der 100% auslastung.
Hab auch unter dem link den ich gepostet habe gelesen das man im zusammenhang mit dem filesys ext3 und reiserfs auf ldbm gehen soll.
Was fällt euch dazu ein?

PS: Die 6 gb ram sollte suse 9.3 abkönnen oder?

#edit
Bin gerade auf den thread gestossen:
http://www.linuxforen.de/forums/show...highlight=ldap
Kommt mir ziemlich bekannt vor.
Öhm was heißt unsanft den server runter fahren?
Mir fällt ein mein kollege wollte beim ram einbauen zugucken und hat den server derweile glaube mit init 0 runter gefahren.
Kann das ein grund sein?
Dann steht in dem thread das er per cron jede nacht den ldap runter fährt.
Eigentlich wehre ich mich noch dagegen das ldap so heikel is.
Liege ich da hoffentlich falsch?

Gruß ramsy

**BedriddenTech** · 24.11.05, 19:19

Zitat von ramsys

Hab auch unter dem link den ich gepostet habe gelesen das man im zusammenhang mit dem filesys ext3 und reiserfs auf ldbm gehen soll.
Was fällt euch dazu ein?

Wir fahren SVN und LDAP auf ReiserFS und hatte nie Probleme damit, alles DBD. Ich würde dabei bleiben.

PS: Die 6 gb ram sollte suse 9.3 abkönnen oder?

Es gibt im Kernel eine entsprechende Option: "Support High Memory", da gibts die Stufen 1-4GB und 4-64GB. Ich weiß nicht, welche Einstellungen bei SuSE gemacht worden sind und wie das Verhalten ist, wenn man mehr reintut als beim Kernel eingestellt ist, aber nimm den Arbeitsspeicher doch mal raus und schau, was passiert...

**ramsys** · 24.11.05, 19:43

Ne hab auch am ram gebaut 1 -4 und 6 gb läuft ohne unterschied.
Aber guck mal mein edit oben an mit dem init 0.

**mamue** · 24.11.05, 20:46

Eigentlich werden doch auch beim init 0 alle Prozesse gebeten sich zu beenden, oder? Vielleicht hatte der ldap nicht genug Zeit <shrink>?
Ich habe ldap auf XFS, allerdings mit BDB, nicht DBD ;-)
Funktionierte die Reperatur mit db_recover nicht?

mamue

**ramsys** · 24.11.05, 22:05

Zitat von mamue

Eigentlich werden doch auch beim init 0 alle Prozesse gebeten sich zu beenden, oder? Vielleicht hatte der ldap nicht genug Zeit <shrink>?
Ich habe ldap auf XFS, allerdings mit BDB, nicht DBD ;-)
Funktionierte die Reperatur mit db_recover nicht?

mamue

Hehe und das geht mit bdb? lol
Hatte mir erhofft das init0 ne erklärung gewesen wäre.
Werde sonst immer n mulmiges gefühl haben nach einem neustart.
Komme erst wieder Montag dazu am Server zu arbeitn da ich
bei einem Entspannenden Workshop bin.

Gibts noch erklärungen für einen datenverlust?
Wie kommt ldap dazu ausgerechnet den Datenstand von September anzunehmen bevor garnix mehr ging?

**BedriddenTech** · 26.11.05, 19:56

Achtung, LDAP wird nicht mittels SIGTERM/SIGKILL heruntergefahren, d.h. mit den Signalen, die init an Prozesse sendet. Aus dem Adminhandbuch auf openldap.org:

To kill off slapd safely, you should give a command like this

kill -INT `cat /usr/local/var/slapd.pid`

where /usr/local/var is determined by configure.

Killing slapd by a more drastic method may cause information loss or database corruption.

Eindeutig "SIGINT", init sendet aber afaik, wie schon geschrieben, SIGTERM, dann SIGKILL. Vielleicht ist das eine Lösung? Ich habe den OpenLDAP-Dienst nie anders als mit SIGINT heruntergefahren, deswegen kann ich dazu nichts sagen, ich weiß aber, daß LDAP eher pingelig gegenüber Serverausfällen war, ich mußte dann immer "db_recover" benutzen.

**mamue** · 27.11.05, 12:28

Beim Herunterfahren werden doch eigentlich die stop-scripte aus /etc/init.d aufgerufen. Die sollten den slapd eigentlich richtig beenden. Jedenfalls stoppe ich slapd selten direkt, sonder eher über rcldap stop. Dass der slapd sich vielleicht nicht rechtzeitig beendet hat und von init gekillt wurde, könnte gut hinkommen.

mamue

**BedriddenTech** · 27.11.05, 17:52

Wenn ich bei mir mit "reboot" bzw. "shutdown" herunterfahre, kommen zuerst die Killskripte im vorigen Runlevel (sprich rc3.d/K??*), dann die Startskripte im neuen, dann kommt "Sending all Processes the TERM signal", dann dasselbe mit KILL, dann kommen die restlichen Kerneloperationen (md, SCSI-Cache, etc), dann ist aus.
Wenn ich mit init [60] herunterfahre, kommt *zuerst* "Sending all processes..."