Bestehenden OPSI-Server inkl. Clients an einen Master hängen

Antworten
kinzi
Beiträge: 167
Registriert: 27 Okt 2010, 11:38

Bestehenden OPSI-Server inkl. Clients an einen Master hängen

Beitrag von kinzi »

Hallo,

ich habe an zwei Standorten zwei OPSI-Server mit einigen Clients. Beide sind derzeit vollkommen getrennt, also sind jeweils Config- und Depotserver für ihr eigenes Netz. Jetzt würde ich gerne den zweiten OPSI-Server als abgesetztes Depot des ersten einrichten, damit ich beide Netze von einem configed aus managen kann. Das funktioniert grundsätzlich auch, nur verliere ich durch das "opsi-setup --register-depot" die bisher auf dem zweiten Server vorhandenen Clients inkl. dem gesamten Inventory.

Kann ich die bestehenden Clients vorher oder nachher irgendwie exportieren/importieren? (Die Funktion "umziehen" hilft hier ja nicht.)

Wäre für ein paar Tipps dankbar!

-kinzi.
kinzi
Beiträge: 167
Registriert: 27 Okt 2010, 11:38

Re: Bestehenden OPSI-Server inkl. Clients an einen Master hä

Beitrag von kinzi »

Hat denn echt niemand eine Idee dazu?
Benutzeravatar
ueluekmen
uib-Team
Beiträge: 1939
Registriert: 28 Mai 2008, 10:53

Re: Bestehenden OPSI-Server inkl. Clients an einen Master hä

Beitrag von ueluekmen »

Hi kinzi,

Ideen haben bestimmt viele. Aber diese Art der Anfragen haben es schwer hier beantwortet zu werden und gehören eigentlich in den Professional Support. Ich denke das ist immer ein Überlegung Wert.

Aber ich gebe dir trotzdem einen Tip: Ihr nutzt bestimmt das Filebackend. Such mal im Manual nach FileBackend. Dann kannst du die Daten einfach Filebasiert zusammenführen. Danach würde ein opsi-setup --cleanup-backend nicht schaden. Vorher natürlich schönen Backup ziehen (Paranoid zu sein ist besser als nachher mit leeren Händen da zu stehen 8-) )

Die Clients müssen dann nur noch mitbekommen, dass sich der Server geändert hat. Da hast du mehrere Möglichkeiten. Solange dein alter Server noch läuft kannst du dort in den Serverkonfigurationen die clientconfig.configserver.url auf den neuen Server setzen. Dann sollten die automatisch auf den neuen Server kommen. Auf dem neuen Server würde ich zur Sicherheit opsi-client-agent direkt bei diesen Clients nochmal auf setup setzen.

Beim Inventory wird es da schon schwieriger. Wir empfehlen das auch eigentlich nie, da so eine Migration meistens nur Ärger macht und diese Daten sowieso schnell neu gezogen/generiert werden können.
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
kinzi
Beiträge: 167
Registriert: 27 Okt 2010, 11:38

Re: Bestehenden OPSI-Server inkl. Clients an einen Master hä

Beitrag von kinzi »

Hallo ueluekmen,

danke für die Antwort! Wir setzen derzeit auf beiden OPSI-Servern das File Backend ein, ja - außer für Audit, da haben wir MySQL, aber das lässt sich ja leicht durch swaudit und hwaudit wieder herstellen. OK, das ist schon mal ein guter Ansatz, das werde ich ausprobieren.

Eine Frage noch: Dass der zweite Server bereits ein Config-Server (mit aktiven Clients, SW-Depot, usw.) war spielt keine Rolle, oder? Ich nehme an, diese Funktionalität wird abgedreht beim "--register-depot"? Ich hatte es testweise (nach einem Snapshot :-) schon mal versucht, da war der zweite Config-Server aber immer noch erreichbar und bot mir auch beide Depots an - ist das by-design? Kann ich also den configed auf einem beliebigen Depot-Server aufrufen und komme immer zum Master-Server, oder war das auf Grund der o. a. Konstellation?

Ich hoffe, ich habe mich verständlich ausgedrückt. :-)

Gruß
kinzi
kinzi
Beiträge: 167
Registriert: 27 Okt 2010, 11:38

Re: Bestehenden OPSI-Server inkl. Clients an einen Master hängen

Beitrag von kinzi »

So, ich habe das zwischenzeitlich selbst hinbekommen, mit dem File-Backend ist es tatsächlich sehr einfach. Ich poste es hier mal kurz, vielleicht hat wieder einmal jemand das gleiche Bedürfnis. Übrigens haben wir inzwischen mehrere abgesetzte Depots auf diese Weise eingebunden, diese befinden sich sogar hinter einer Firewall (bzw. sogar mehreren), auf denen außerdem NAT gefahren wird, und es funktioniert trotzdem. :mrgreen: Einzig Wake-On-LAN und on-demand-Vorgänge funktionieren (noch?) nicht, außer die Clients sind ebenfalls statisch geNATted. (Die für NAT relevanten Punkte sind mit "NAT:" angeführt und können andernfalls weggelassen werden.)

Der zentrale Config-Server wird hier als "Master" bezeichnet, der OPSI-Server in der abgesetzten Organisationseinheit als "Depot".
  • Ein Backup vom Master und vom Depot erstellen (bzw. einen VMware-Snapshot o. ä.).
  • NAT: Auf den Clients den neuen Control-Server (Master) in die hosts-Datei eintragen (wenn der Name nicht richtig über DNS aufgelöst werden kann). Ich habe mir dazu ein OPSI-Paket gebaut, dass ich vor der ganzen Prozedur noch haben laufen lassen.
  • Sicherstellen, dass alle Pakete, die am Depot existieren auch am Master installiert sind, und zwar unter gleichem Namen und in gleicher Version!
  • NAT: Sicherstellen, dass auf Master und Depot alle Vorkommnisse der Host-IP in den Konfigurationsdateien unter /var/lib/opsi/config durch den richtigen, gültigen DNS-Namen ersetzt sind.
  • NAT: Die benötigten Ports sind auf den Firewalls freizuschalten. (Es müsste 4447 reichen, wir haben aber 22/tcp, 69/udp, 137/udp, 138/tcp, 138/udp, 139/tcp, 139/udp, 445/tcp und 445/udp ebenfalls offen, da wir auch entfernte Clients ohne eigens Depot haben).
  • NAT: Auf dem Master in der /etc/hosts das Depot eintragen (wenn keine Auflösung über DNS möglich).
  • NAT: Auf dem Depot in der /etc/hosts den Master eintragen (wenn keine Auflösung über DNS möglich).
  • Sicherungskopie von /etc/opsi/pckeys auf dem Master und dem Depot erstellen. Die gesicherte pckeys vom Depot auf den Master kopieren. Alle Einträge außer dem OPSI-Depot selbst (also alle Clients) in die /etc/opsi/pckeys des Masters eintragen.
  • Alle /var/lib/opsi/config/clients/*.ini vom Depot auf den Master ins clients-Verzeichnis kopieren.
  • Die Datei /var/lib/opsi/config/depots/depotservername.ini vom Depot auf den Master kopieren und auf *.bak o.ä. umbenennen, damit sie bei den nächsten Schritten nicht überschrieben wird (sie wird nachher noch gebraucht).
  • sudo opsi-set-rights ausführen.
  • sudo opsi-setup --register-depot (laut OPSI-Handbuch Kapitel 17) auf Depot ausführen. NAT: DNS-Namen bzw. statische Hostnamen und keine IP-Adressen verwenden!
  • sudo opsi-setup --cleanup-backend auf Depot ausführen
  • sudo opsi-setup –-set-rights auf Depot ausführen
  • sudo opsi-setup --cleanup-backend auf Master ausführen
  • sudo opsi-setup –-set-rights auf Master ausführen
  • Aus der zuvor kopierten und umbenannten depotservername.ini am Master alle Einträge bis auf die Sektionen [depotserver], [depotshare] und [repository] in die beim --register-depot neu erstellte depotservername.ini kopieren.
  • sudo opsi-setup --cleanup-backend auf Depot ausführen
  • sudo opsi-setup –-set-rights auf Depot ausführen
  • sudo opsi-setup --cleanup-backend auf Master ausführen
  • sudo opsi-setup –-set-rights auf Master ausführen
  • sudo service opsiconfd restart auf Master ausführen
  • sudo service opsiconfd restart auf Depot ausführen
Die Clients müssen anschließend zweimal neu gestartet werden; beim ersten Mal wird automatisch der Config-Server neu gesetzt in der opsiclientd.conf), beim zweiten Mal taucht der Client (bei NAT mit der geNATteten) neuen IP-Adresse im configed auf und müsste seine ganzen Produktstati usw. mitgenommen haben. Einzig das HW- und SW-Inventory fehlt, das kann aber ganz einfach mittels eines Laufs von hwaudit und swaudit wieder erstellt werden.

Schöne Grüße und viel Erfolg allen tapferen Nachahmern :mrgreen:
kinzi
Antworten