Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:upgrade [2017/04/30 08:04]
flacco [Daten wiederherstellen]
+++ invis_server_wiki:upgrade [2017/04/30 09:56]
flacco
@@ Zeile 5: / Zeile 5: @@
 Für den invis-Server sind dabei folgende Themen von Interesse:
-  - Upgrade von invis-Classic auf invis-AD
+  - [[invis_server_wiki:upgrade:classic-to-ad|Upgrade von invis-Classic auf invis-AD]]
-  - Upgrade von invis-AD 10.3 auf Basis von openSUSE 13.1 auf eine neuere invis-AD Version unter openSUSE Leap
+  - [[invis_server_wiki:upgrade:10.3_13.1-to-10.4_leap|Upgrade von invis-AD 10.3 auf Basis von openSUSE 13.1 auf eine neuere invis-AD Version unter openSUSE Leap]]
-  - Weiterhin von Bedeutung sind Upgrades relevanter Software-Komponenten wie etwa Zarafa oder Sernet-Samba
+  - [[invis_server_wiki:upgrade:10.x-to-12.x|Upgrade von invis-AD 10.x nach invis-AD Version 12.x]]
+  - [[invis_server_wiki:upgrade:komponents|Weiterhin von Bedeutung sind Upgrades relevanter Software-Komponenten wie etwa Zarafa oder Sernet-Samba]]
-An dieser Stelle sollte von vorne herein klar sein, dass es kein direktes Upgrade von einem invis-Classic auf einen invis-AD gibt und geben kann. Es gibt aber eine Reihe von Möglichkeiten Daten aus einer alten in eine neue Installation zu migrieren.
-Die nachfolgenden Beschreibungen beschreiben die ersten beiden Punkte der vorangegangenen Liste. Punkt 3 der Liste ist dabei Teil des nachfolgenden Kapitels.
 ===== invis-AD 10.3 unter openSUSE 13.1 -> invis-AD ab 10.4 unter openSUSE Leap =====
@@ Zeile 1043: / Zeile 1042: @@
 Die beste Möglichkeit eines Upgrades stellt eine Neuinstallation eines aktuellen invis-Servers mit anschließender Datenmigration dar.
+//**Achtung:** Ändern Sie bei der Neuinstallation auf keinen Fall etwas an der Namensgebung des Servers oder der Domäne und genauso wenig an der IP-Addressierung! Behalten Sie alle entsprechenden Einstellungen der ursprünglichen Installation bei.//
 //**Hinweis:** Sie sollten sich auf jeden Fall eine lauffähige Version Ihres bestehenden invis-Server erhalten. Installieren Sie also am besten auf neue Festplatten.//
@@ Zeile 1354: / Zeile 1355: @@
 invis:~ # mount /dev/system/srv /mnt
 </code>
+=== Zarafa Attachements ===
 Zunächst sollten die Attachements der alten Zarafa Installation synchronisiert werden. Mittel der Wahl ist das Tool //**rsync**//:
 <code>
-invis:~ # rsync -ar /mnt/zarafa/attachements/ /srv/kopano/attachements/
+invis:~ # rsync -av /mnt/zarafa/attachements/ /srv/kopano/attachements/
 </code>
-Achten Sie darauf, dass beide Pfadangaben mit einem Slash abgeschlossen werden.
+Achten Sie darauf, dass beide Pfadangaben mit einem Slash abgeschlossen werden. Die Option "-a" (Archiv) sorgt dafür, dass klassische Zugriffsrechte erhalten bleiben und rekursiv in die zu synchronisierende Verzeichnisstruktur eingetaucht wird.
-Beim Wiederherstellen des File-Server Datenbestandes ist auf zwei Dinge zu achten:
+Danach sind die Besitzrechte der Attachement-Verzeichnisstruktur an Kopano anzupassen:
-  - Die Freigabe "projekte" wurde im Zuge der invis-Server Weiterentwicklung entfernt. Als Ersatz kommt entweder Die Freigabe "aktuell" in Frage oder Sie legen über das invis-Portal eine Gruppe Namens "projekte" an. Dabei wird unter "/srv/shares/gruppen" ein Arbeitsverzeichnis namens "projekte" angelegt, welches als Ersatz in Frage kommt. Dabei ist zu beachten, dass alle Benutzer die damit arbeiten sollen auch Mitglied der Gruppe "projekte" sein müssen.
+<code>
-  - Je nach dem wie Sie vorher gearbeitet haben, sind zusätzlich zu den klassichen Unix Besitz- und Zugriffsrechten auch sogenannte POSIX-ACLs gesetzt. Diese dürfen bei der Datenübertragung nicht verloren gehen.
+invis:~ # chown -R kopano.kopano /srv/kopano/attachements
+</code>
+=== ownCloud und Dokuwiki Datenverzeichnisse ===
-====== invis-Classic -> invis-AD ======
+Synchronisieren Sie die Datenverzeichnisse wie bereits die Zarafa-Attachements:
-Aufgrund der immensen Unterschiede zwischen beiden Systemen gibt es hier schlicht keinen Migrationsweg. Vielmehr geht es darum Daten und Informationen aus einem klassischen invis-Server auf einen invisAD zu migrieren.
+**ownCloud**
-Im Idealfall wird ein neuer invisAD auf neuer Hardware aufgebaut. Möglich aber um Längen aufwändiger ist die Neuinstallation auf gleicher Hardware. In letzterem Fall müssen zuvor alle relevanten Daten der alten Installation gesichert werden.
+<code>
+invis:~ # rsync -av /mnt/www/htdocs/owncloud/data/ /srv/www/htdocs/owncloud/data/
+</code>
-Zu den zu sichernden Daten zählen:
+**Dokuwiki**
-  * Das vollständige LDAP Verzeichnis in Form eines LDIF-Dumps
-  * Das gesamte "/etc" Verzeichnis
-  * Alle Datenbanken inklusive der Dokuwiki Daten
-  * Alle Nutzdaten des Fileservers
-  * Den gesamten Mailbestand.
-Alleine für die Sicherung müssen Sie je nach Datenmenge mit vielen Stunden Arbeit und vor allem Wartezeit rechnen. Da ist es eher ratsam sich für die Neuinstallation wenigstens neue Festplatten zu gönnen und die Platten des alten Servers für die Dauer die Migration in einen anderen PC einzubauen.
+<code>
+invis:~ # rsync -av /mnt/www/htdocs/dokuwiki/data/ /srv/www/htdocs/dokuwiki/data/
+</code>
-Wie auch immer, aus eigener Erfahrung empfehle ich **immer** komplett neue Hardware für die Neuinstallation.
+=== Fileserver Datenbestand ===
+Beim Wiederherstellen des File-Server Datenbestandes ist auf zwei Dinge zu achten:
-Es gilt vorab eine weitere grundsätzliche Entscheidung zu fällen. Der Aufwand LDAP-Informationen aus einem OpenLDAP Dump zu extrahieren und für den Import in ein AD umzubauen ist mühsam und fehleranfällig. Wenn es sich beim zu migrierenden invis-Server um eine Installation mit nur wenigen Benutzern und überschaubarem Umfang an IP-Geräten im Netz handelt, ist es einfacher und schneller die Daten in der Neuinstallation über das invis-Portal neu einzugeben. Die Grenze würde ich bei ca. 20 Benutzern ziehen.
+  - Die Freigabe "projekte" wurde im Zuge der invis-Server Weiterentwicklung entfernt. Als Ersatz kommt entweder Die Freigabe "aktuell" in Frage oder Sie legen über das invis-Portal eine Gruppe Namens "projekte" an. Dabei wird unter "/srv/shares/gruppen" ein Arbeitsverzeichnis namens "projekte" angelegt, welches als Ersatz in Frage kommt. Dabei ist zu beachten, dass alle Benutzer die damit arbeiten sollen auch Mitglied der Gruppe "projekte" sein müssen.
+  - Je nach dem wie Sie vorher gearbeitet haben, sind zusätzlich zu den klassischen Unix Besitz- und Zugriffsrechten auch sogenannte POSIX-ACLs gesetzt. Diese dürfen bei der Datenübertragung nicht verloren gehen. Bei den Windows-Benutzer-Profilen beispielsweise sind definitiv POSIX-ACLs gesetzt.
-Nachfolgend Anleitungen und Tipps zur Bewältigung der Migration. Eine genaue Anleitung wie die oben beschriebene invisAD -> invisAD Migration wird es hier nicht geben.
+Das Kopieren der Daten können Sie entweder bequem mit dem //Midnight Commander// (//**mc**//) oder besser mit //**rsync**// vornehmen. Dabei beherrscht //**rsync**// auch den fehlerfreien Umgang mit POSIX-ACLs. Das nachfolgende Beispiel zeigt die Datenmigration anhand der Profilverzeichnisse:
-===== LDAP Informationen migrieren =====
+<code>
+invis:~ # rsync -aHAXv /mnt/shares/profiles/ /srv/shares/profiles/
+</code>
-Zu den LDAP-Informationen zählen Benutzerkonten, deren zugehörige Email-Konten Informationen und die Daten von DNS- und DHCP-Server.
+Die Optionen "HAX" erhalten dabei Hardlinks, ACLs und erweiterte Dateiattribute. Gehen Sie auf gleiche Weise mit allen anderen Verzeichnissen Ihres Datenbestandes vor. Gleiches gilt für die Home-Verzeichnisse der alten Installation. Diese befinden sich, wenn Sie entsprechend der Anleitungen hier im Wiki installiert haben im Logical-Volume "/dev/system/home".
-==== Benutzerkonten ====
+=== Weitere Daten ===
-Beginnen wir mit einer ernüchternden Information. **Lassen Sie es sein!**
+Aus dem Volume des /var-Verzeichnisses können Sie noch die Daten des Email-Abrufs synchronisieren. Die Daten sind zwar auch im Active-Directory enthalten, jedoch müssten alle Benutzer manuell wieder auf "Anwesend" gesetzt werden. Ein Kopieren der Daten erübrigt dies.
-Samba bietet mit der Funktion **classic-upgrade** eine Möglichkeit eine Windows-Domäne auf Basis von Samba3 (NTLM Domäne) unabhängig vom verwendeten Backend (ldap, tdbsam usw.) in eine AD-Domäne zu migrieren. Diesen Weg habe ich bereits einmal erfolgreich beschritten. Ziel der damaligen Migration war allerdings kein invis-Server sondern ein alleinstehender Active-Directory Domain-Controller.
+Mounten Sie dazu das /var-Volume und kopieren Sie folgende Dateien:
-invis-Server nutzen OpenLDAP (Classic) bzw. den LDAP-Dienst eines Active-Directories für weit mehr als nur die Speicherung von Benutzerinformationen. Einerseits erweitern wir das AD mit zahlreichen Schema-Erweiterungen, diese müssten nach einem Classic-Upgrade alle händisch eingepflegt werden. Andererseits muss man sich der Tatsache bewusst sein, dass die Benutzerverwaltung mit AD gänzlich anders aufgebaut ist als auf dem klassichen Server. Ein invis-Classic legt grundsätzlich POSIX-kompatible Benutzerkonten an, die um Windows-Attribute erweitert wurden. Ein invisAD hingegen legt Windows-Benutzerkonten an, die um POSIX-Attribute erweitert werden. Auf einem invisAD Server nutzen wir gänzlich andere UID- und GID-Bereiche als auf dem invis-Classic. Daraus können sich nach einer solchen Migration Probleme im laufenden Betrieb ergeben.
-Wer dennoch diesen Weg beschreiten möchte findet im [[https://wiki.samba.org/index.php/Migrating_a_Samba_NT4_domain_to_a_Samba_AD_domain_%28classic_upgrade%29|Samba Wiki]] eine Anleitung für den Upgrade-Prozess.
-Vorbereitend müssen Sie dennoch eine volle invisAD-Installation durchführen. Stoppen Sie vor dem Classic-Upgrade den Samba-Dienst, sichern Sie die Samba-Konfiguration unter <file>/etc/samba</file> und erstellen Sie ein Backup des neuen leeren ADs:
 <code>
-linux:~ # adbackup
+invis:~ # cp /mnt/lib/cornaz/build/.fetchmailrc /var/lib/cornaz/build/
+invis:~ # cp /mnt/lib/cornaz/inuse/.fetchmailrc /var/lib/cornaz/inuse/
 </code>
-Ist die Migration per Classic-Upgrade gelungen, müssen Sie alle Daten- und Schema-Erweiterungen händisch ins neue AD integrieren. Auch das habe ich bereits einmal durchgeführt, die entsprechende Anleitung folgt.
+==== Abschluss ====
-Früher oder später wird der invisAD-Server auch ein Script zum massenhaften anlegen neuer Benutzerkonten mitbringen, was dann auch eine gewisse Erleichterung darstellt.
+Damit ist die Migration abgeschlossen. Das einzige was zu tun bleibt ist die Festplatten der alten Installation vom Server zu trennen und idealerweise als Langzeit-Archiv im Tresor zu verstauen.
-Der Vorteil dieser mühsamen Methode sollte allerdings nicht unerwähnt bleiben. Die Benutzerprofile der Domänenbenutzer funktionieren auch nach der Migration noch, da sich die Dmomain-SID hierbei nicht ändert. Eine vollständige Neuinstallation bedeutet neue Benutzer-Konten auch wenn sich Benutzernamen und Passwörter nicht ändern. Das bedeutet, dass alle Client-PCs der Domäne neu beitreten und alle Benutzerprofile neu aufgebaut werden müssen. Ein wenig googlen fördert zwar auch Tools zur Profilmigration zu Tage, allerdings kann ein wenig "Tabula Rasa" manchmal nicht schaden.
+Viel Spaß mit Ihrem neuen invis-Server.
-... to be continued
-===== Konfigurationen migrieren =====
-===== Datenbanken migrieren =====
-===== Email Bestand migrieren =====
-===== Fileserver-Datenbestand migrieren =====