Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:upgrade [2017/04/29 16:50]
flacco [LDAP Authentifizierung]
+++ 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 1099: / Zeile 1100: @@
 Kopieren Sie sich alle Sicherungen auf einen USB-Stick oder ähnliches. Jetzt können Sie den Server herunterfahren und fürs erste die Festplatten der alten Installation vom Server trennen. Bauen Sie die neuen ein und installieren Sie den neuen invis-Server entsprechend der Anleitung hier im Wiki.
+==== Konfigurationen übernehmen ====
+Im Grunde sind nur wenige Konfigurationseinstellungen aus der alten Server-Installation übernommen werden. Wichtig ist natürlich die Konfiguration des SMTP Relayhosts und so sie es nutzen die DDNS-Konfiguration.
+=== Relayhost ===
+Übernehmen Sie in der Datei <file>/etc/postfix/main.cf</file> die Einstellung des Parameters "relayhost":
+<code>
+...
+relayhost = [your.smtphost.de]:587
+...
+</code>
+Kopieren Sie dann noch die beiden Dateien "sasl_passwd" und "sasl_passwd.db" aus "/etc/postfix" der alten Installation ins gleiche Verzeichnis der neuen und bewegen Sie Postfix zum erneuten Einlesen seiner Konfiguration:
+<code>
+invis:~ # postfix reload
+</code>
+=== DDNS ===
+//**Hinweis:** Mit **DDNS** ist an dieser Stelle lediglich "echtes" Dynamic DNS und nicht etwa die Nutzung von Diensten wie "dynDNS" oder vergleichbaren, auch wenn es letztlich um die gleiche Sache geht. Um echtes DDNS zu nutzen brauchen Sie Zugriff auf einen entsprechend eingerichteten DNS-Server.//
+Sie benötigen die beiden zum DDNS-Verfahren gehörenden Schlüssel-Dateien. Diese sind in invis-Server-Installationen kleiner Version 11.0 unter <file>/etc/ssl/ddns/</file> zu finden und gehören in Versionen größer 11.0 nach: <file>/etc/invis/ddns</file> Kopieren Sie die Dateien einfach aus der Sicherung des /etc-Verzeichnisses.
+Danach ist die DDNS-Funktion des invis-Servers noch zu aktivieren. Sie benötigen Dazu die fünfstellige Zahl aus dem Namen der DDNS-Schlüsseldateien.
+Die Konfiguration erfolgt in der Datei: <file>/etc/invis/invis.conf</file>
+<code>
+...
+# DDNS-Update
+# Verwenden Sie anstelle von z.B. DynDNS.org einen eigenen DNS-Server, den Sie per DDNS aktualisieren?
+# [j/n]
+ddnsOn:j
+# Adresse des Nameservers
+nameServer:dnsmain.example.de
+# Hostname (FQDN) Ihres Servers im Internet
+fqdn:invis.example.de
+# Schlüsselnummer Ihres DDNS-Keys
+keyNumber:21165
+...
+</code>
+Passen Sie Ihre Konfiguration entsprechend dem obigen Beispiel an. Testen können Sie das Setup mit folgendem Kommando:
+<code>
+invis:~ # inetcheck
+</code>
+Treten hierbei Fehler auf sollten Sie zunächst kontrollieren, ob die Systemzeit Ihres Servers korrekt ist.
 ==== Wiederherstellung des Active Directory ====
@@ Zeile 1225: / Zeile 1281: @@
   * **''/etc/postfix/r-canonical.cf''**
   * **''/etc/postfix/s-canonical.cf''**
+  * **''/etc/kopano/ldap.cfg''** (ldap_bind_passwd = )
 ==== Kopano Datenbak wiederherstellen ====
@@ Zeile 1230: / Zeile 1288: @@
 Bei der Neuinstallation des invis-Servers wurde selbstverständlich eine neue Datenbank für Kopano angelegt, Sie können diese entweder mit der Sicherung der Zarafa-Datenbank überschreiben oder eine weitere Datenbank anlegen. Ich gehe den zweiten Weg:
-Melden Sie sich dafür an der MySQL-Shell an:
+Melden Sie sich dafür an der MySQL-Shell an und erzeugen Sie eine neue Datenbank:
 <code>
@@ Zeile 1240: / Zeile 1298: @@
 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
-MariaDB [(none)]>
+MariaDB [(none)]> create database kopano2017;
 </code>
+Jetzt müssen Sie noch dem bereits existierenden Datenbank-Benutzer "kopano" alle Rechte daran gewähren und dann die MySQL-Shell wieder verlassen:
-====== invis-Classic -> invis-AD ======
+<code>
+MariaDB [(none)]> grant all privileges on kopano2017.* to kopano@localhost;
+Query OK, 0 rows affected (0.00 sec)
+MariaDB [(none)]> quit
+Bye
+invis:~ #
+</code>
-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.
+Spielen Sie jetzt die Sicherung der alten Zarafa-Datenbank in die neu angelegte Datenbank ein:
-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:~ # gunzip < zarafa.invisad.20170429.gz | mysql -u root -p kopano2017
+</code>
-Zu den zu sichernden Daten zählen:
+Jetzt ist in der Datei <file>/etc/kopano/server.cfg</file> der Datenbankname anzupassen:
-  * 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>
+...
+# Database to connect to
+mysql_database          = kopano2017
+...
+</code>
-Wie auch immer, aus eigener Erfahrung empfehle ich **immer** komplett neue Hardware für die Neuinstallation.
+Danach muss der Kopano-Server Dienst neu gestartet werden:
-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.
+<code>
+invis:~ # systemctl restart kopano-server.service
+</code>
-Nachfolgend Anleitungen und Tipps zur Bewältigung der Migration. Eine genaue Anleitung wie die oben beschriebene invisAD -> invisAD Migration wird es hier nicht geben.
+Wenn jetzt Ihre Festplatte deutliche Aktivität zeigen liegt dies daran, dass der Kopano-Search Dienst die Datenbank indiziert. Dies ist also ein gutes Zeichen.
-===== LDAP Informationen migrieren =====
+Sie können sich jetzt an der Kopano-Webapp testweise anmelden und nachsehen, ob der Datenbank import funktioniert hat. Bedenken Sie aber, dass wir die Attachements noch nicht wieder hergestellt haben. Diese liegen im Dateisystem und nicht in der Datenbank.
-Zu den LDAP-Informationen zählen Benutzerkonten, deren zugehörige Email-Konten Informationen und die Daten von DNS- und DHCP-Server.
+==== ownCloud Migration ====
-==== Benutzerkonten ====
+Die Migration einer bestehenden und umfangreich genutzten ownCloud-Installation ist leider alles Andere als einfach. Begründet liegt dies darin, dass zumindest bis ownCloud Version 9.x im Grunde der Reihe nach von der Ausgangsversion bis zur Zielversion auf alle dazwischen liegenden Versionen aktualisiert werden muss. (Einer der Schwachpunkte von ownCloud, der zukünftig aber ausgeräumt werden soll.)
-Beginnen wir mit einer ernüchternden Information. **Lassen Sie es sein!**
+Die einzelnen Migrationsschritte sollten bzw. müssen auf der alten invis-Installation vorgenommen werden. Führen Sie die Updates am besten aus den Quellpaketen aus. RPM-Pakete werden sie für alle Zwischenschritte kaum bekommen.
-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.
+Googlen Sie folgendes "owncloud upgrade" nach und Sie finden eine Reihe von Anleitungen für die verschiedenen Versionssprünge.
-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.
+Wenn Sie lediglich die Datenverzeichnisse migrieren möchten, gestaltet sich die Sache einfacher. Richten Sie die ownCloud-Neuinstallation einfach wie hier im Wiki beschrieben ein und Kopieren Sie die Daten wie im nachfolgenden Kapitel beschrieben.
-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.
+==== Daten wiederherstellen ====
-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:
+Jetzt müssen Sie zunächst die Festplatte(n) der alten invis-Installation mit dem Server verbinden.
+Hängen Sie jetzt der Reihe nach die alten Volumes ein und synchronisieren Sie Ihre Daten. Beginnen wir mit "/srv". Das nachfolgende Beispiel geht davon aus, dass die alte Installation auf LVM basierte und gemäß der Anleitung hier im Wiki aufgebaut war.
 <code>
-linux:~ # adbackup
+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 -av /mnt/zarafa/attachements/ /srv/kopano/attachements/
+</code>
+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.
+Danach sind die Besitzrechte der Attachement-Verzeichnisstruktur an Kopano anzupassen:
+<code>
+invis:~ # chown -R kopano.kopano /srv/kopano/attachements
+</code>
+=== ownCloud und Dokuwiki Datenverzeichnisse ===
+Synchronisieren Sie die Datenverzeichnisse wie bereits die Zarafa-Attachements:
+**ownCloud**
+<code>
+invis:~ # rsync -av /mnt/www/htdocs/owncloud/data/ /srv/www/htdocs/owncloud/data/
+</code>
+**Dokuwiki**
+<code>
+invis:~ # rsync -av /mnt/www/htdocs/dokuwiki/data/ /srv/www/htdocs/dokuwiki/data/
+</code>
+=== Fileserver Datenbestand ===
+Beim Wiederherstellen des File-Server Datenbestandes ist auf zwei Dinge zu achten:
+  - 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.
+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:
+<code>
+invis:~ # rsync -aHAXv /mnt/shares/profiles/ /srv/shares/profiles/
+</code>
+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".
+=== Weitere Daten ===
+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.
+Mounten Sie dazu das /var-Volume und kopieren Sie folgende Dateien:
+<code>
+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 =====