PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ldap gau. läuft aber kein connect



ramsys
23.11.05, 17: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 :eek:
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, 17:35
Hast mal db_recover laufen lassen? Mal nach der Konfigurationsdatei geguckt?

ramsys
23.11.05, 18: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, 20: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, 20: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, 21: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/01/rsimai_slox_db_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, 12: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, 16: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/showthread.php?t=198170&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, 20:19
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, 20: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, 21: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, 23:05
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, 20: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, 13: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, 18: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..."

ramsys
28.11.05, 10:03
Ich mische mich mal kurz ein ;)
Die DB lebt wieder. Allerdings hat sie den Datenstand von annodazumal.
Hat zufällig einer von euch beiden die schalter im Kopf wenn man mit
smbldap-useradd -w ein Konto erzeugen will welches ein gültiges Windowsmaschienenkonto ertellen will?
Da alle Profile noch da sind reicht es wenn ich das manuell machen.
Kann zwar über den NT Usermgr Konten erstellen, bekomme aber beim svrmgr n Zugriff verweigert?!?
Das hat jetzt nix mit dem gau zu tun. Wundere mich trotzedm das das nicht geht.

Schonb mal ein erstes Dankeschön

BedriddenTech
28.11.05, 16:36
Gültige Maschinenkonten legt man meines Wissens mit smbpasswd an. Dazu muß ein "Benutzerkonto" nach dem Muster "Maschinename$" erstellt werden, das dann mit smbpasswd -m Maschinenname hinzugefügt wird. Wenn du den Sambaserver für LDAP konfiguriert hast, schreibt das Programm die Einträge in die Datenbank.

ramsys
28.11.05, 18:23
Aber wenn man ein Maschinenkonte anlegt während man einen Clienten in der Domäne als Admin über Windows aufnimmt wird doch das adduserscript genutzt welches in der smb.conf angegeben ist.
Dort steht dann als adduserscript smblap-useradd -m %u oder wars g?
Hab die conf gerade nicht da. Das klappt auch bestens.
Wenn ich das manuell tippe fehlen da ein paar parameter im ldap ?!?
Über den svrmgr kommt zugriff verweigert während ich aber mit dem usrmgr hingegen problemlos user anlegen kann und auch gruppen.
Auch das hinzufügen der User zu beispielsweise domain admins für inatallationszwecke klappt bestens darüber?
Meiner Meinung nach sollte soch die authentifizierung bei beiden tools die selbe sein oder?

PS: Nach dem bearbeiten des Ldap und einem rcldap stop / start oder auch normalen neustarten des gesammten servers gab es keine Probleme mehr.
Dann kann ja nur das init0 den ldap unsauber beendet haben....
Jedenfalls mache ich nach neuen einträgen jetzt immer ein rcldap stop / start.

mamue
29.11.05, 11:00
Jedenfalls mache ich nach neuen einträgen jetzt immer ein rcldap stop / start.
Das ist nicht nötig und der Sinn will sich mir auch nicht so recht erschließen. Sichere die Daten lieber regelmäßig mit slapcat. Das geht auch im laufenden Betrieb. Das Ergebniss ist eine ldif-Datei im Klartext, die sich mit recht großer Wahrscheinlichkeit auch unter anderen/neueren OpenLDAP-Versionen wieder einlesen lässt (slapadd).

mamue

ramsys
29.11.05, 17:47
Naja wenn man son gau durch hat und liest sowas, macht man manchmal komische sachen ;) Mich würde dennoch interessieren wo ldap diesen alten Datenbestand her hatte da dort fast nur noch daten drinn waren welche ich schon vor über einen Monat gelöscht hatte.

mamue
30.11.05, 17:06
Bei Änderungen werden in /var/lib/ldap log_* Dateien angelegt, anhand derer OpenLDAP AFAIK die Datenbank restauriert. Wenn dort welche fehlten oder defekt waren, dürfte der letzte Stand fehlen.

mamue

ramsys
01.12.05, 21:35
Aha. Danke.
Habe so das gefühl das es der stand ist von vor den damals letzten neustart / ldaprestart. Hängt das damit zusammen?

Apropos wie oft lässt du deine Dienste eigentlich restarten?
Wenn bei mir bisher nix geändert wurde liefen die Server eigentlich über Monate bis halt mal irgend was angepasst wurde und einen restart des dienstes erforderte. Sollte man das gelegentlich mal machen ?!?!?!?!
Darüber is mir bisher noch nix unter gekommen.

mamue
02.12.05, 09:33
Ich bin ganz sicher nicht der Maßstab für perfekte Serverwartung, aber ich starte den Dienst nie neu, ausser natürlich bei einem Serverneustart. Ich mache mindestens einmal wöchentlich eine Sicherung mit slapcat (slapcat -l /irgendwohin/ldaif-$(date -I).ldif) und zusätzlich vor grösseren "Umbauaktionen". Bei Bedarf lässt sich die Datenbank innerhalb weniger Minuten wieder herstellen. Das geht und darauf habe ich auch schon zurückgreifen müssen.
Ich denke mal, dass einer der log_* Dateien bei Dir defekt war. Aber das ist mehr oder weniger geraten.

mamue

ramsys
02.12.05, 17:47
Na ich bin da auch eher schlampig :)

Starte die diversen dienste auchn ur neu wenn es muß.
DNS dhcp oder so. Von ladap mache ich nach änderungen, da zur Zeit täglich neue User hinzukommen n Backup (slapcat). Ansonnsten starte ich auch nix neu. Letztens gabs ne Ramkur für alle Server. Da erst merkte ich das der DHCP Server noch nicht automatisch Startet obwohl der schon Monate läuft :)