Seite 1 von 1
Opsi isst sich selbst auf
Verfasst: 06 Sep 2012, 20:10
von ppbi
Hallo zusammen,
leider habe ich bei einem Laptop, auf dem ich Windows 7 mit Hilfe von OPSI 4.0.1 installieren wollte, aus Versehen den Namen des OPSI-Servers als Rechnernamen angegeben (wie das passieren konnte? Ich habe mich gleichzeitig mit einem Kollegen unterhalten und war nicht bei der Sache).
Diese Installation schlug nach Auswahl des Windows-Pakets fehl (Meldung: "failed to decrypt (error on server)"). Auch die Installation mit dem richtigen Rechnernamen schlug mit der gleichen Meldung fehl. Danach habe ich versucht, den fälschlicherweise angelegten OPSI-Client aus der Liste zu löschen, das funktionierte aber nicht. Einen anderen Client konnte ich löschen. Deshalb habe ich die INI-Datei aus dem opsi/config/clients-Verzeichnis gelöscht, dann war der Eintrag weg.
Das war aber nicht alles, was weg war. Sämtliche Produkte und Netbook-Produkte stehen im Config Editor nicht mehr drin.
Jetzt kommt nach der Vergabe des Rechnernamens und der Eingabe der Adminkennung immer folgende Meldung:
"Verbindung zu Server 'SERVER-IP' fehlgeschlagen: Opsi authentication error: Application 'opsi linux bootimage 20120119' on client 'CLIENT-IP' did neither supply session id nor password (error on server)" Man kann Abbrechen oder einen "Client erzeugen". Wenn ich letzteres auswähle, erscheint wieder der "Opsi authentication error" wie oben.
Im Log steht dann auch "No netboot product installable".
Wie kann es sein, daß OPSI quasi Selbstmord begeht und gibt es einen einfachen Weg, das rückgängig zu machen? Vielen Dank!
Re: Opsi isst sich selbst auf
Verfasst: 07 Sep 2012, 07:53
von mhaegele
ppbi hat geschrieben:Hallo zusammen,
leider habe ich bei einem Laptop, auf dem ich Windows 7 mit Hilfe von OPSI 4.0.1 installieren wollte, aus Versehen den Namen des OPSI-Servers als Rechnernamen angegeben (wie das passieren konnte? Ich habe mich gleichzeitig mit einem Kollegen unterhalten und war nicht bei der Sache).
Diese Installation schlug nach Auswahl des Windows-Pakets fehl (Meldung: "failed to decrypt (error on server)"). Auch die Installation mit dem richtigen Rechnernamen schlug mit der gleichen Meldung fehl. Danach habe ich versucht, den fälschlicherweise angelegten OPSI-Client aus der Liste zu löschen, das funktionierte aber nicht. Einen anderen Client konnte ich löschen. Deshalb habe ich die INI-Datei aus dem opsi/config/clients-Verzeichnis gelöscht, dann war der Eintrag weg.
Das war aber nicht alles, was weg war. Sämtliche Produkte und Netbook-Produkte stehen im Config Editor nicht mehr drin.
Jetzt kommt nach der Vergabe des Rechnernamens und der Eingabe der Adminkennung immer folgende Meldung:
"Verbindung zu Server 'SERVER-IP' fehlgeschlagen: Opsi authentication error: Application 'opsi linux bootimage 20120119' on client 'CLIENT-IP' did neither supply session id nor password (error on server)" Man kann Abbrechen oder einen "Client erzeugen". Wenn ich letzteres auswähle, erscheint wieder der "Opsi authentication error" wie oben.
Im Log steht dann auch "No netboot product installable".
Wie kann es sein, daß OPSI quasi Selbstmord begeht und gibt es einen einfachen Weg, das rückgängig zu machen? Vielen Dank!
Wow. Rein von der Logik her kann der Opsi Server ja sich nicht komplett selbst zerstören weil er nicht gleichzeitig das Linux Image booten kann und dieses von sich selbst abholen, bei mehreren Opsi Servern könnte das aber evtl. sogar funktionieren?.
Ich weiß es ist jetzt blöd aber ich versuche mich immer zu konzentrieren bevor ich etwas potentiell gefährliches mache, einfach nochmal kurz sammeln und dann erst Abschuß ... (Seit ich in der Hektik am privaten PC mal das Homeverzeichnis versehentlich mit mehreren Jahren Urlaubsbildern ohne Backup überschrieben hatte umso mehr) trotzdem passieren pro Jahr immer noch so 1-3 Minikatastrophen
.
Backup vorhanden, zurückspielen, vergleichen?
Falls nicht und es fehlen tatsächlich gelöschte config dateien könnte evtl. photorec helfen ...
MH
Re: Opsi isst sich selbst auf
Verfasst: 07 Sep 2012, 11:49
von ueluekmen
Hi,
der Titel ist etwas gewagt
.... Wir können leider nicht jeden Bedienungsfehler abfangen, aber das ist nicht das erste mal, dass genau das passiert.
mhaegele hat geschrieben:bei mehreren Opsi Servern könnte das aber evtl. sogar funktionieren?
Das kann tatsächlich passieren. Wenn man einen Depotserver zu einem Client macht und der auf Netboot steht, und ein Netbootproduct auf ask before inst false steht, dann würde das system vernichtet werden. Aber das sind etwas zu viele Zufälle auf einmal, nur sollte man nach Murphy niemals nie sagen
Man hätte das Problem auch fixen können, wenn es das host-Objekt noch gäbe, ansonsten kann man versuchen mal mit:
die Sache zu bereinigen, vielleicht klappt das und opsi spukt sich selbst wieder aus
aber es kann auch sein, dass es nicht funktioniert.
mhaegele hat geschrieben:Backup vorhanden
Man sollte generell opsi-backup per conjob laufen lassen!
Re: Opsi isst sich selbst auf
Verfasst: 25 Sep 2012, 13:52
von ppbi
Hallo zusammen,
vielen Dank für die Antworten, ich wollte mich nochmal melden, um zu berichten, wie es ausgegangen ist. Leider waren die entscheidenden Teile von OPSI nicht im Backup, so daß wir ihn neu aufgesetzt und alle Clients neu installiert haben (so konnte ich mich wieder an die Zeit als Turnschu-Admin erinnern). Immerhin konnten wir das für ein Update auf 4.0.2 nutzen. Wieder was gelernt
Re: Opsi isst sich selbst auf
Verfasst: 26 Sep 2012, 12:23
von r.roeder
Hallo,
zur Vermeidung solcher Versehen verweigert die neue Version des opsi-configed (z.Zt. im testing-Repository), dass ein Client mit dem Name eines Depotservers neu angelegt wird. Die allerneueste (4.0.2.5.6)
bezieht bei der Prüfung auch den Namen eines ohne Depotverwaltung genutzten configservers ein...
Gruß
Rupert Röder
Re: Opsi isst sich selbst auf
Verfasst: 26 Sep 2012, 12:27
von mhaegele
r.roeder hat geschrieben:Hallo,
zur Vermeidung solcher Versehen verweigert die neue Version des opsi-configed (z.Zt. im testing-Repository), dass ein Client mit dem Name eines Depotservers neu angelegt wird. Die allerneueste (4.0.2.5.6)
bezieht bei der Prüfung auch den Namen eines ohne Depotverwaltung genutzten configservers ein...
Gruß
Rupert Röder
Sauber.
Nun traue ich mich endlich den Kollegen die Netboot Produkte zu zeigen
.
scnr:
btw Anekdote:
Linux Konferenz Einsteigerforum:
- Frage eines Zuhörers: "Was machen Sie um Fehler durch Superuser Anmeldung und potentielle unabsichtliche "Zerstörungen" zu vermeiden?"
Antwort Dozent (Uni Admin): "Ich versuche mich zu konzentrieren wenn ich als Root arbeite" ...
Fand ich ganz nett
.
Viele Grüsse
MH