FAQ:Arktur4/HWCrash sysadm: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
K (1 Versionen) |
(kat) |
||
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
__NOTOC__ | |||
{{Archiv}} | |||
== Nach einem Hardwarecrash startet sysadm nicht mehr == | == Nach einem Hardwarecrash startet sysadm nicht mehr == | ||
Zeile 41: | Zeile 45: | ||
---- | ---- | ||
<div align="right">[[FAQ:Arktur4|zurück]] | [[Hauptseite]]</div> | <div align="right">[[FAQ:Arktur4|zurück]] | [[Hauptseite]]</div> | ||
[[Kategorie:ArchivArktur40]] |
Aktuelle Version vom 16. März 2012, 13:16 Uhr
Archiv: Dieser Artikel beschreibt nicht die Funktionalität des derzeit aktuellen delixs-Servers. Er beschreibt ältere Schulserver-Funktionen und dient dem Zweck der Archivierung. |
Nach einem Hardwarecrash startet sysadm nicht mehr
Frage:
Nach einem Hardware-Crash habe ich Arktur zunächst auf anderer Hardware wieder zum Laufen gebracht.
Bei der weiteren Einrichtung bzw. Reparatur ließ sich die sysadm-Oberfläche nicht mehr aufrufen. Versucht man diese zu starten, kommt sofort die Meldung vom Verlassen der sysadm-Oberfläche.
Wie komme ich wieder an die sysadm-Oberfläche ran?
Antwort:
Bei einem Hardeware-Crash passierten vor allem zwei Sachen:
- Gerade zu dem Zeitpunkt geöffnete Dateien werden nicht ordnungsgemäß auf die Platte geschrieben. Ein Neustart des Servers behebt dieses Problem aber im Allgemeinen von selbst.
- Der LDAP-Server wird NICHT ordnungsgemäß beendet. Das endet eigentlich immer mit den oben beschriebenen Anmeldeproblemen. Der Grund ist, dass LDAP eine Datenbank benutzt, welche die Daten
binär auf der Platte speichert, so ähnlich wie dBase oder ein SQL-Server.
Also muss diese (nun defekte) binäre DB aus einem ASCII-Backup neu erstellt werden. Dazu hier die notwendigen Schritte:
- Melde Dich als root an der Console an:
- Restauriere die Datenbanken, indem Du sie löschst und anschließend neu erstellst.
/etc/init.d/ldap stop # Server anhalten rm -rf /var/lib/ldap/* # DB löschen slapadd -l /etc/ods/gesamt.ldif # Backup einspielen /etc/init.d/ldap start # Server starten
Jetzt sollte ein
su - sysadm
wieder funktionieren.
-- aus einer Mail von Harry J.