bei uns ist der Linuxmusterserver hängen geblieben und musste mit Power-OFF neugestartet werden.
Seit diesem Zeitpunkt kann sich kein Client mehr aufgrund von fehlenden Vertrauenstellung anmelden.
Was ich probiert habe:
matman - s - v 12345678 auf dem Client
sophomorix-passwd --force -u rechnername$ --passwd=12345678
ohne Erfolg.
Rechner aus Domäne entfernt und hinzugefügt. Ohne Erfolg.
Wie könnte ich die Vetrauenstellung reparieren ohne die Imges neu erstellen zu müssen? Mir ist der Inhalt wichtig und ich möchte ihn nicht verlieren.
bei uns ist der Linuxmusterserver hängen geblieben und musste mit
Power-OFF neugestartet werden.
Seit diesem Zeitpunkt kann sich kein Client mehr aufgrund von fehlenden
Vertrauenstellung anmelden.
Was ich probiert habe:
matman - s - v 12345678 auf dem Client
sophomorix-passwd --force -u rechnername$ --passwd=12345678
ohne Erfolg.
kann nichts bringen, weil der slapd nicht läuft.
Am Besten folgendes machen:
auf allen gemounteten Dateisystemen eine Datei anlegen die forcefsck
heißt: dann rebooten.
Also
touch /forcefsck
touch /var/forcefsck
touch /var/linbo/forcefsck
… und was sonst noch so eigene Partition ist.
Das kann man in der /etc/fstab nachschauen.
Nach dem reboot schauen, ob der slapd läuft
/etc/init.d/slapd status
Wenn er nicht läuft:
/etc/init.d/slapd start
Wenn er dann immernoch nciht läuft, dann muss der LDAP wieder
hergestellt werden.
Das geht aus der postgress mit folgendem Befehl:
sophomorix-dump-pg2ldap
Danach sollte der slapd wieder laufen (oder kann gestartet werden)
Hallo Holger, danke für deine Tipps mit forcefsck.
sldap war tatsächlich direkt nach dem crash nicht gelaufen, aber nachdem ich apparmor neu installiert habe laut dem verlinkten Artikel war als letzter Schritt auch
sophomorix-dump-pg2ldap
vorgesehen, danach lief sldap wieder.
Danach konnten bis auf 2 PCs alle wieder an der Domäne authentifizieren.
bei den restlichen 2 ging nichts ( einer davon unberührt, der andere manuell aus der domäne entfernt und erneut hinzugefügt), auch nicht mit mit mtaman und sophomorix-passwd. Die Befehle brachten keine Fehler, trotzdem fehlende Vertrauensstellung.
Auch nachdem ich die Maschinen aus der /Workstation Datei mit # rausgenommen habe, danach import_workstations und dann # weider gelöscht und erneut import_workstations.
Falls du noch eine Idee hättest wäre toll. Ansonsten meine ich bereits alle versuche aus dem Forum bis auf netdom resetpwd probiert zu haben. Aber wie ich gesehen habe ist das keine empfohlene vorgehensweise.
erzähl mal eion wenig mehr:
du hast nur 4 Clients?
Bei zweien geht es nun wieder, bei den anderen beiden nicht?
Ist das eine Hardwareklasse? Also verwenden die das selbe Image?
Hast du mal die IP Adressen der Clients kontrolliert? (die bei denen es
Probleme gibt)
Welche haben die?
Reden wir eigentlich von einer lmn62 oder einer lmn7?
ich habe 13 Clients. 2 Davon gehen nicht.
Es sind 2 Hardwareklassen , also 2 Images definiert. Es geht jeweils aus einem der Images ein Rechner nicht. IP Adressen und Mac Adressen habe ich überprüfft. 10.17.1.13 z.B.
Es geht um 6.2.9 Ich habe es in der Themaüberschrift erwähnt aber in Thread selbst dann vergessen.
Nur zum Verständnis: das Problem ist erst nach dem Crash des Servers aufgekommen. Letzte Woche lief noch alles ganz normal. Ich denke beim Crash hat es LDAP zerschossen und durch reparatur geht es wieder nur verstehe ich nicht ganz warum 2 nicht wieder rein können.
Einer der PCs der jetzt nicht geht wurde erst vor Paar monaten hinzugfügt. Kann es sein, dass bei LDAP Reparatur ein alter Stand wieder hergestellt wird und der PC daher nicht erkannt wird?
Nur zum Verständnis: das Problem ist erst nach dem Crash des Servers
aufgekommen. Letzte Woche lief noch alles ganz normal. Ich denke beim
Crash hat es LDAP zerschossen und durch reparatur geht es wieder nur
verstehe ich nicht ganz warum 2 nicht wieder rein können.
Einer der PCs der jetzt nicht geht wurde erst vor Paar monaten
hinzugfügt. Kann es sein, dass bei LDAP Reparatur ein alter Stand wieder
hergestellt wird und der PC daher nicht erkannt wird?
ja, das kann sein: ist aber unwahrscheinlich, da unsere scripte
„doppelte Buchführung“ machen: also immer gleichzeitig in ldap und pg
schreiben (wobei der LDAP auch in der pg liegt, damit es nicht zu
einfach ist ).
Soetwas hätte aber behoben werden müssen durch dein durchgeführtes:
raus aus der workstations, import, wieder rein in die workstations.
Lass uns mal noch einen Schritt weiter gehen:
raus aus der workstations, import, wieder rein in die workstations mit
neuem Namen, import
Dann Rechner booten, partitionieren und syncen und dann Daumendrücken
und Anmelden
dieses Verfahren hat heute bei mir zum Erfolg geführt. Das Image war zuvor in einer anderen Domäne in Verwendung. Nach dem Austritt, Neustart und Eintritt in die neue Domäne kam das Problem „Vertrauensstellung“.
).