[gelöst]:opsi-convert für Migration/opsi Server-Migration mittels API

[r4tzeblitz]

Hallo zusammen,

kann ich den "opsi-convert" Befehl dazu nutzen Daten von einen Server auf den anderen zu transferieren? Verliert der alte Server durch den "convert" die Daten in irgendeiner Weise?
Meine Vorstellung für eine Server Migration sind:

1. Aufbau eines neuen opsi-Servers (neuer Name, neue IP usw...)
2. Übernahme der Daten vom alten Server durch "opsi-convert" ohne eventuelle neue Pakete und die Informationen dazu zu überschreiben
3. Wechseln der Clients auf den neuen Server durch Änderung der configserver.url

Ist das mit "opsi-convert" möglich? Ich scheue mich vor einer Rücksicherung eines Backups da auf dem neuen Server schon neue Produkte vorhanden sind.

Danke im Voraus für die Antworten.

Grüße
ratze

[ueluekmen]

Hi,

ja man kann opsi-convert auch in diese Richtung benutzen. Dann geht er local auf das eine Backend und Remote auf das andere Backend auf dem neuen Server. Ich würde es aber dennoch nicht so machen, weil:

a) das opsi-convert ist dafür gedacht schnell von einem ins andere Backend zu konvertieren und ist eigentlich nicht für Servermigrationen konzipiert.
b) ist das opsi-convert, wenn man es so einsetzt extrem LAHM.

Im übrigen ist es auch nichts anderes als die Daten aus einem Backup zurück zu sichern.

Wenn es den neuen Server schon gibt, dann gibt es auch elegantere Methoden, wie man die Clients migriert. Am besten und einfachsten über einen Supportvertrag. Kleiner Tip, wenn man von den Clients nur die Statis holen will, kann man auch einzelne Objekte von dem einen Server exportieren und auf dem neuen importieren. Das ganze macht über den Webservice Sinn. Vielleicht auch ein Migrations-opsi-Paket bauen, wie man es braucht oder wie schon erwähnt einkaufen ist auch immer ein Option .

[r4tzeblitz]

Danke für den Hinweis. Das mit dem Support bin ich gerade schon am klären
Dann werde ich mich mal ein bisschen mit der API auseinandersetzen.

[r4tzeblitz]

Hallo zusammen,

ich würde gerne noch einmal nachhaken:

Ich habe nun mit Hilfe der API Methoden die Clients und die Produktinformationen von unserem alten opsi Server exportiert und dann auf dem neuen Server eingespielt. Dazu gehören der Clientname, die MAC und die Beschreibung + die Informationen der zugeordneten Software und der Installationsstatus.
Wenn ich jetzt über den configed des alten Servers die RPC Adresse ändere meckert der Client, nach Übernahme der Daten, das der hostKey nicht übereinstimmt. Würde es schaden wenn ich auf dem neuen Server die alten HostKeys importiere? Und würde es reichen, damit sich die Clients verbinden können? Oder ist das Ganze schon viel zu viel händische Anpassung im System?

Viele grüße

Ratze

[ueluekmen]

Hi,

vergleich doch mal den alten und den neuen Server mit den Hostkeys.

Oder ist das Ganze schon viel zu viel händische Anpassung im System?

Ja, auf alle Fälle, aber es darf ja nicht zu einfach sein, sonst macht es keinen Spaß. Ansonsten bist du fleißig am basteln, da würde ich sagen, probieren geht über studieren

[r4tzeblitz]

Guten Morgen!
Ja, ich habe das einfach via API gemacht und habe so die Möglichkeit über den configed des alten opsi Servers einfach den Host-Parameter "configserver.url" auf den neuen opsi Server verweisen zu lassen.
Nach einem Neustart ziehen sich die Clients diese Konfig und nach einem zweiten Neustart verbinden sie sich anstandslos mit dem neuen Server und beginnen auch sofort etwaige Installations-Aktionen anzuwenden. Wahnsinn! Ich bin begeistert.

Der einzige Wermutstropfen ist folgender Fehler beim Abruf von install-Logs:

Code: Alles auswählen

Exception while data reading, de.uib.opsicommand.JSONthroughHTTP$JSONCommunicationException: receiving json

Den bekomme ich auch, wenn ich den opsi-client-agent installiere oder den betreffenden Client neu installiere. Lustigerweise habe ich bei einem Client schon feststellen können das das Log nach irgendeiner Installation auf einmal ohne JSON Fehler abrufbar war

Kann ich irgendwo den JSON Befehl, der diesen Fehler auslöst sehen?

update: Das liegt, wie auch schon oft im Forum bemerkt, anscheinend an den TLS Einstellungen. Ich hatte schon Angst

[r4tzeblitz]

Hallo zusammen!

Falls es jemanden interessiert hier der Weg wie ich die Server- und Clientmigration mittels API Methoden umgesetzt habe (es gibt vermutlich 1000 einfachere Wege, aber diesen Weg bin ich gegangen):

Zuerst wurde ein neuer Server mit neuem Namen und IP installiert. Mittels opsi-product-updater wurden die uib Pakete installiert. Anschließend wurden die Softwarepakte vom alten Server mit ihrer .opsi Datei eingespielt. Dies betraf aber nicht die uib Pakete.
Zuerst habe ich mir die Daten aus dem alten System gezogen. Das geschah auf dem alten Server für die Clients mit folgendem Befehl welcher dann in eine CSV Datei umgeleitet wurde:

Code: Alles auswählen

opsi-admin -d -S method host_getObjects

(Das -S ist für die einfachere Darstellung)
Damit erhielt ich die wichtigsten Daten zu den Clients (Name, Beschreibung, opsiHostKey, MAC)

Das gleiche wurde mittels folgendem Befehl für die Produkte auf den Clients gemacht:

Code: Alles auswählen

opsi-admin -d -S method productOnClient_getObjects

Danach konnte ich bei den CSV Dateien mit dem Notepad++ bearbeiten und mit Hilfe von "Suchen und Makieren" -> makierte/nicht markierte Löschen und mit Makros in folgendermaßen aussehende CSV Dateien umwandeln:
Clientname.Domain;Beschreibung;ee:ee:ee:ee:ee:ee;29510042456ebe244e1acc6cf88a8b3b(HostKey)

Mit einem Shell Skript konnte ich dann diese CSV Datei auslesen und daraus ein Shell-Skript erstellen, welcher die Hosts mittels API anlegte:

Code: Alles auswählen

#!/bin/bash
inputfile="./opsi-clients.csv"
SaveIFS=$IFS
IFS=";"
while read  id desc mac hk
do
	echo "opsi-admin -d method host_createOpsiClient $id $hk '"$desc"' '""' '"$mac"'" >> command.sh
done < "$inputfile"
IFS=$SaveIFS 

Heraus kam eine "command.sh" welche ich ausführen konnte und die dann alle Clients via API anlegte. (Achtung! Den opsiserver selbst aus der Liste entfernen)

Bei den Produktzuordnungen war der Weg ähnlich. Anpassen mit Notepad++ bis folgendes herauskam:
clientid;Actionsanforderung;SW-Version;Paket-version;Installations-Status;Produkt-ID

Dann wieder mit dem Shell-Skript die API Befehle zusammenbauen:

Code: Alles auswählen

inputfile="./products-on-clients.csv"
SaveIFS=$IFS
IFS=";"
while read clientid actreq provers pavers inststat prodid
do
	echo "opsi-admin -d method setProductState $prodid $clientid '"$inststat"' '"$actreq"' '"$provers"' '"$pavers"'" >> prod-command.sh

done < "$inputfile"

IFS=$SaveIFS 

Und anschließend das "herausfallende" Skript ausführen. Das hat dann für ca. 500 Clients knappe 3 Stunden gebraucht, da für jeden Client alle Produkte und Installationsanforderungen gesetzt wurden.

danach musste ich nur noch über den Configed auf dem Alten Server den Parameter "configserver.url" auf den neuen Server verdrehen und nach zwei Neustarts (beim ersten wird sich vom alten Server die neue Konfig geholt und beim zweiten meldet er sich schon am neuen Server an).
Kontrollieren lässt sich dies durch den "lastSeen" Wert im ConfigEd.

Vielleicht hilft es ja dem einen oder anderen bei der Migration.
Wenn noch etwas nicht ganz klar ist gebt mir einfach Bescheid.

Grüße

ratze

[zylex]

Hallo r4tzeblitz,

nur ein kleines danke von mir, super Anleitung, hat bei mir gut funktioniert! Ich habe nur zusätzlich noch Excel benutzt um die Daten in der CSV in die richtige Reihenfolge zu bringen, das geht dort ganz leicht z.B mit der "Verketten" Funktion. Man sollte das Ergebnis dann nur per Copy&Paste in eine Text-Datei unter Linux kopieren, da bei einer Windows-CSV das Shell-Script eventuell ein "^M" anfügt (bei mir an den Hostkey).

Grüße