Bestehenden PDC ersetzen - wie?

german

#1

Hallo zusammen,

ich setze UCS 4.1 privat als Familienserver ein (komme von Zentyal, davor komplett “homebrew”). Der Server ist dabei PDC und beherbergt via UVMM eine virtuelle Zentyal-Maschine für kleinere Aufgaben, außerdem laufen darauf ein paar Websites inkl. UCS-Owncloud und andere Dienste.

Jetzt möchte ich den PDC auf neuer Hardware neu aufsetzen und frage mich, was das beste Vorgehen dafür ist. Wenn ich es recht verstanden habe, habe ich die folgenden Möglichkeiten:
[ul][li] “Katastrophen-Recovery” wie hier beschrieben: http://sdb.univention.de/1184.[/li]
[li] Installation from scratch und alle EInstellungen neu machen bzw. vom alten PDC kopieren.[/li]
[li] Installation Backup-PDC mit anschließender Heraufstufung zum PDC.[/li][/ul]
Das Katastrophen-Recovery reizt mich, weil ich (theoretisch) alles 1:1 übernehmen kann. Nach meiner Erfahrung mit dem guten Herrn Murphy bisher wird es jedoch an einigen Stellen haken, so dass ich letztlich tagelang damit beschäftigt bin und in der Zeit ggfs. keinen Domain Controller habe (meine Familie, allen voran die Frau, dreht durch ohne ihre Dateien etc.).

Installation from scratch reizt mich sogar noch mehr, da es die sauberste Lösung ist. Problem: Ich möchte weder den Namen meiner Domäne noch den Rechnernamen ändern und vermute mal, dass es zu ganz komischen Effekten kommt, wenn ich einen zweiten PDC mit selbem Namen für die selbe Domäne im selben Netz aufsetze. Ich könnte hier natürlich (sub)netten und/oder natten, aber da das nicht mein Spezialgebiet ist, scheue ich den Aufwand.

Also die vermutlich “richtigste” Lösung: Ich erstelle einen Backup-PDC und stufe den später herauf. Das wirft (für mich) folgende, äh, Effekte auf:
[ul][li] Der neue PDC soll die selbe IP-Adresse erhalten wie der alte. Würde ich lösen, indem ich die Adressen der beiden Systeme kurz vor oder nach der Umstellung ändere. Keine Probleme, oder?[/li]
[li] Der Rechnername sollte am Liebsten auch gleich bleiben, da der neue PDC ja alle Services des alten übernehmen muss. Kann das irgendwie funktionieren?[/li]
[li] Um alle Dienste umzuziehen ist sehr viel Popelarbeit notwendig - aber das habe ich auch, wenn ich alles neu baue. Hrrrrm…[/li]
[li] Kann es noch andere Seiteneffekte geben, ggfs. auch erst später, weil irgendetwas nicht (mehr) administrierbar ist oder andere (bekannte) merkwürdige Dinge?[/li][/ul]
Kann mir hier jemand zu einem Vorgehen raten? Oder meine Ansprüche gleich eindampfen, weil es so gar nicht klappen wird?

Schonmal besten Dank im Voraus
Holle H.


#2

Hallo,

für Ihr beschriebenes Szenario bietet sich das univention-backup2master Skript an, welches hier im Handbuch beschrieben ist. Grob skizziert würde sich damit der folgende Migrationspfad ergeben:
[ul]
[li] Aufsetzen eines UCS Backup auf der neuen Hardware.[/li]
[li] Installation der Dienste wie Owncloud + UVMM auf dem Backup.[/li]
[li] Daten-Migration der Dienste:
[list]
[] Für Owncloud siehe Owncloud-Handbuch.[/li]
[li] Für UVMM können die libvirt-Daten nachdem die VM-Instanzen gestoppt wurden via rsync auf den Backup übertragen werden, also in etwa via: libvirtd stop && rsync /etc/libvirt/ $BACKUP:/etc/libvirt && rsync /var/lib/libvirt/ $BACKUP:/var/lib/libvirt && libvirtd start[/li][/ul][/
:m]
[li] Danach kann der Master herunter gefahren und univention-backup2master auf dem Backup gestartet werden, womit auch die DNS-Einträge des Masters übernommen werden können.[/li]
[li] Über das Modul Netzwerk-Einstellungen könnte dann zusätzlich noch die IP-Adresse des alten Masters nachgetragen werden, um die Auflösung der alten IP-Adresse zu gewährleisten.[/li][/list:u]

Nachdem der Backup als Master hochgestuft wurde, sollte der alte Master nicht mehr (oder höchstens vom Netzwerk isoliert) hochgefahren werden.

Ich hoffe die Schritte helfen als grober Leitfaden. Gerne stehen wir bei speziellen Nachfragen zu einzelnen Schritten zur Verfügung und würden uns über eine Rückmeldung nach der Migration sehr freuen.

Viele Grüße
Dr. Alexander Kläser


#3

Hallo,

erstmal danke für die ausführliche Antwort mit den konkreten Vorschlägen zur Dienste-Migration. Gut zu wissen, dass es für die beiden “großen” schon mal Lösungen gibt - hier bin ich gar nicht auf die Idee gekommen, nach Migration zu googlen :-/ . Ist aber eine gute Anregung, bei dem ganzen Kleinkram ggfs. ähnlich verfahren zu können!

Ich werde das Projekt zwischen den Jahren angehen und meine Erfahrungen sehr gerne teilen!

Viele Grüße
Holle H.


#4

Hallo,

wunderbar, dann freuen wir uns über einen Erfahrungsbericht und helfen gerne bei einzelnen Schritten weiter.

Der Interesse wegen, nach welchen Stichwörtern hatten Sie zu diesem Thema gesucht?

Viele Grüße
Dr. Alexander Kläser


#5

Ich habe zur Migration der einzelnen Dienste gar nicht gegoogled, nur zur Migration des PDC. Dann nach Suchbegriffen wie

  • univention pdf wiederherstellen
  • univention hardware tausch
    … u.ä.

MfG
Holle H.


#6

Sooooo, mit GANZ GANZ leichter Verspätung liegt meine Umstellung nun in den letzten Zügen. Rekapitulation bisher:
[ul][li] BDC installieren: Check, easy. Halt ein neuer Hostname.[/li]
[li] Einbinden der für mich wichtigen Verzeichnisse vom alten PDC (u.a. /srv) via NFS. Die Platten baue ich erst kurz vor Schluss um.[/li]
[li] Websites umziehen: Händische Übernahme der Apache-Config vom alten Server, done.[/li]
[li] Non-UCS-Serverdienste umziehen: Schrittweise, händische Neuinstallation auf dem neuen mit gleichzeitigem Abschalten auf dem alten PDC. Hint: wer eigene Init-Scripts erstellt hat, nicht vergessen, die mit update-rc.d -f remove am Besten gleich rauszuschmeißen, sonst gibts nach dem nächsten Reboot manche Services redundant. Ist lästig bis schlecht, je nach Dienst. Auf jeden Fall orgt’s für Verwirrung.[/li]
[li] Bareos umziehen: Installation via App Center auf BDC. Setzen Variable für filestorage: bareos/filestorage und händische Übernahme der Konfigurationsdateien vom alten Server, done.[/li]
[li] Migration der VMs: Alle VMs herunterfahren, über UMC auf den neuen Server “Migrieren”. Anschließend nur die Images händisch rsyncen (/var/lib/libvirt/Images/*). Achtung, vor dem Starten die Netzwerkschnittstellen checken, dass da alle passt (ich hatte bspw. auf dem neuen Server kein bridge device).[/li]
[li] Installation von Owncloud: Über App Center kein Problem, vorher die UCR-Variable “owncloud/directory/data” auf das bestehende NFS-Mount gelegt.[/li]
[li] Eigene Scripts umziehen: Unter /usr/local sowie /opt lagen noch kleinere Scripts, die habe ich ge-rsynced.[/li][/ul]

Jetzt gibts gleich…:
[ul][li] Platten umbauen: Ich gehe den folgenden, ggfs. etwas umständlichen Weg: Alle Freigaben des alten Servers in der UMC löschen. /etc/fstab des neuen gleich mit UUIDs fertigmachen. Runterfahren, umbauen, starten, beten. Freigaben neu einrichten (ja, ich habe Screenshots von der alten Konfiguration gemacht :wink: ).[/li]
[li] Was mir noch unklar ist, ist, was mit den User Homes passiert. Die liegen in dem RAID, was ich im Schritt vorher in den neuen Server übernehme. Es gibt die UCR-Variable samba/homedirserver, ich vermute jedoch, dass das bei Ausführung von dcpromo, pardon: univention-backup2master geändert wird…?! Das lasse ich jetzt auf mich zukommen.[/li]
[li] univention-backup2master[/li][/ul]

Ich berichte weiter.

VG
HolleH


#7

Juhu, geschafft!

Plattenumbau und backup2master hat prima funktioniert!

Achtung, nützlicher Hinweis (für Admins, die genau so schlecht lesen wie ich): Nach dem Promovieren des BDC zum PDC haben die Freigaben und der DHCP-Server nicht mehr funktioniert. Nach einigem Herumprobieren kam es mir dann. Im Handbuch wird das bei der Beschreibung vom backup2master-Script kurz erwähnt, ist in meinem Kopf aber irgendwo andere Wege gegangen: Sämtliche Software-Pakete, die auf dem alten PDC installiert waren, müssen auf dem neuen auch von Hand installiert werden. Das habe ich nachgeholt mit dem DHCPD.

Was allerdingsin meinen Augen dokumentationswert ist, ist dass ich auf dem zu promovierenden Server das UCS-Paket “AD-kompatibler Domaincontroller” händisch installieren muss. Das, so hätte ich vermutet, passiert bei backup2master automatisch. Jedenfalls ist somit die Frage nach den User Homes beantwortet.

Das einzige, wo noch irgendwas im Argen liegt, ist der Samba-Server: Ich bekomme keine SMB-Verbindung, sondern - bei bestehenden sowie neu angelegten Benutzern immer nur session setup failed: NT_STATUS_INVALID_SID. Werde dazu gleich mal ein neues Topic aufmachen.

Soweit mein Erfahrungsbericht.

VG
HolleH


AD irgendwie zerschossen nach backup2master-Migration
#8

Herzlichen Dank für den ausführlichen Bericht :slight_smile: !

Viele Grüße
Dr. Alexander Kläser