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.
Bestehenden OPSI-Server inkl. Clients an einen Master hängen
Re: Bestehenden OPSI-Server inkl. Clients an einen Master hä
Hat denn echt niemand eine Idee dazu?
Re: Bestehenden OPSI-Server inkl. Clients an einen Master hä
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 )
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.
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 )
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
For productive opsi installations we recommend support contracts.
http://www.uib.de
Re: Bestehenden OPSI-Server inkl. Clients an einen Master hä
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
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
Re: Bestehenden OPSI-Server inkl. Clients an einen Master hängen
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. 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".
Schöne Grüße und viel Erfolg allen tapferen Nachahmern
kinzi
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
Schöne Grüße und viel Erfolg allen tapferen Nachahmern
kinzi