Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:upgrade [2017/04/30 09:25]
flacco [invis-AD 10.x auf invisAD 12.x]
+++ invis_server_wiki:upgrade [2017/04/30 10:02]
flacco [invis-Server Upgrade]
@@ 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.4_leap-to-11.0|Manuelles Upgrade von 10.4 zu neueren Versionen ab 11.0]]
+  - [[invis_server_wiki:upgrade:10.x-to-12.x|Upgrade von invis-AD 10.x nach invis-AD Version 12.x]]
-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 915: / Zeile 915: @@
 Ansonsten gilt: **Wilkommen zu Ihrem aktuellen invis-Server**
-===== invisAD 10.4 -> invisAD 11.0 =====
-Mit Version 11.0 des invis-Servers ergeben sich ein paar strukturelle Unterschiede. Allem voran geht dabei die Umstellung der "Public Key Infrastructure", also die Organisation von Schlüsseln und Zertifikaten für die verschiedenen Verschlüsselungsaufgaben.
-Bisher wurden zwei sogenannte Zertifizierungsstellen (CA) erstellt, davon diente eine zur Verwaltung der Schlüssel und Zertifikate für die verschiedenen Serverdienste (LDAP, Mail, Web) und eine zweite ausschließlich für openVPN. Zur Pflege der Schlüssel- und Zertifikate wurde das Toolkit "easy-rsa" in Version 2.0 verwendet, der Rest direkt mit //**openssl**// und eigenen Scripten.
-Das Toolkit **"easy-rsa"** liegt inzwischen in Version 3.0 vor und wurde im Zuge der Weiterentwicklung deutlich verbessert. Nach ersten Tests damit war klar, dass easy-rsa 3.0 ideal zur Verwaltung aller Schlüssel- und Zertifikaten eines invis-Servers ist. Kurzum ab Version 11.0 verfügen invis-Server nur noch über eine mit **easy-rsa** erstellte Zertifizierungsstelle.
-Aus dem bisherigen Script //**serverkeys**// zur Generierung  von Serverzertifikaten wurde //**inviscerts**//. Die Handhabung des Scripts wird im Abschnitt "invis Administration" erläutert.
-Beim Upgrade von 10.4 auf 11.0 müssen die Schritte zum Aufbau einer PKI die //**sine**// während des Setups erledigt manuell vorgenommen werden.
-==== Aufbau einer Public Key Infrastruktur mit easy-rsa ====
-Unter anderem zur Nutzung im invis-Server wurde ein easy-rsa 3.x RPM im Repository "spins:invis:common" gebaut. Die nachfolgende Anleitung beschreibt, wie mit easy-rsa eine PKI manuell aufgebaut wird. Die spätere Verwaltung von Zertifikaten übernimmt auf invis-Servern das Script //**inviscerts**//.
-Ab Version 3.0 stellt easy-rsa nur noch ein einziges Script //**easyrsa**// für alle Aufgaben zur Verfügung. Sämtliche Konfigurationsdateien liegen in: <file>/etc/easy-rsa</file>
-Vor dem Aufbau einer PKI muss im genannten Verzeichnis die Datei "vars" an die eigenen Bedürfnisse angepasst werden. Es ist im Unterschied zu älteren easy-rsa Versionen nicht mehr notwendig die Variablen in dieser Datei manuell mittels //**source**// in die aktuelle Shell Umgebung zu laden. Dies erledigt //**easyrsa**//  selbsttätig.
-=== Vorbereitung ===
-Angepasst werden müssen zumindest folgende Zeilen:
-Name der PKI:\\
-(Zeile 65)
-<code>
-...
-set_var EASYRSA_PKI             "$EASYRSA/fsp-net.loc"
-...
-</code>
-PKI individualisieren:\\
-(Ab Zeile 84)
-<code>
-...
-set_var EASYRSA_REQ_COUNTRY     "DE"
-set_var EASYRSA_REQ_PROVINCE    "Hessen"
-set_var EASYRSA_REQ_CITY        "Schotten"
-set_var EASYRSA_REQ_ORG         "FSP Computer und Netzwerke"
-set_var EASYRSA_REQ_EMAIL       "stefan@invis-server.org"
-set_var EASYRSA_REQ_OU          "invis-Server.org"
-...
-</code>
-Die vorgegebene Länge der DH-Parameter ist auf 2048 Bit eingestellt, dies reicht nach gegenwärtigem Stand der Technik aus. Eine Erhöhung auf 4096 Bits verlängert den Bau der DH-Datei immens (Die Rede ist hier von Stunden).
-Voreingestellt sind Gültigkeitsdauern für CA und damit signierte Zertifikate von 10 Jahren. Kann man lassen, die Lebensdauer der Zertifikate im Vergleich zur CA zu verkürzen ist auch OK.
-Jetzt kann die PKI vorbereitet werden:
-<code>
-linux:~ # easyrsa init-pki
-</code>
-Damit wird unter "/etc/easy-rsa" eine Verzeichnisstruktur für die neue PKI angelegt und die Vorbereitungen sind abgeschlossen.
-=== PKI erzeugen ===
-Benötigt werden folgende Komponenten:
-  - Eine CA zum signieren von Server und Client Zertifikaten
-  - Eine Diffie-Hellman Parameter Datei für sicheren Schlüsselaustausch
-  - Eine CRL Datei um Zertifikate zurückzuziehen
-**CA erstellen:**
-Auch hier genügt ein einziger Befehl:
-<code>
-linux:~ # easyrsa build-ca
-</code>
-Beim Bau der CA wird ein Passwort erfragt, dieses Passwort wird später beim signieren von Zertifikaten benötigt. Dieses Passwort darf nicht in falsche Hände gelangen.
-**Diffie-Hellman Parameter erstellen:**
-<code>
-linux:~ # openssl gendh -out $path/$domain/dh.pem -2 2048
-linux:~ # openssl gendh -out $path/$domain/dh_512.pem -2 512
-</code>
-Die Diffie-Hellman Parameter-Dateien werden bewusst direkt mit //**openssl**// erstellt, da das Script //**easyrsa**// immer die in der Konfiguration vorgegebene Schlüssellänge verwendet. Diese sollte auf 4096Bit eingestellt sein. Der Bau einer 4096 Bit großen DH-Parameterdatei dauert allerdings je nach System mehrere Stunden. Außerdem wird für die überarbeitete Postfix-Konfiguration noch eine 512Bit lange Datei benötigt.
-**CRL erzeugen**
-<code>
-linux:~ # easyrsa gen-crl
-</code>
-Hierfür wird wieder das CA-Passwort benötigt.
-=== Aufbau der invis-Server Verzeichnisstruktur ===
-Es sind drei neue Verzeichnisse anzulegen:
-<code>
-linux:~ # mkdir /etc/invis/certs
-linux:~ # mkdir /etc/invis/private
-linux:~ # mkdir /etc/openvpn/keys
-</code>
-Jetzt muss das Stammzertifikat der Zertifizierungsstelle "verteilt" werden:
-<code>
-linux:~ # cp /etc/easy-rsa/yourdomain.tld/ca.crt /etc/invis/certs/
-linux:~ # cp /etc/easy-rsa/yourdomain.tld/ca.crt /etc/openvpn/keys/
-</code>
-Ebenfalls zu kopieren sind die CRL, sowie die Diffie-Hellman-Parameter Dateien
-<code>
-linux:~ # cp /etc/easy-rsa/yourdomain.tld/dh.pem /etc/openvpn/keys/
-linux:~ # cp /etc/easy-rsa/yourdomain.tld/crl.pem /etc/openvpn/keys/
-linux:~ # cp /etc/easy-rsa/yourdomain.tld/dh*.pem /etc/postfix/
-</code>
-Jetzt können wie im Abschnitt "invis Administration" beschrieben Schlüssel und Zertifikate für den Server erstellt werden.
-Um die Umstellung zu komplettieren, müssen die Pfade zu Schlüsseln- und Zertifikaten in den Konfigurationsdateien des Apache-Webservers, von Postfix und ggf. Dovecot, von Samba und openVPN an die neuen Verzeichnisse und Dateinamen anzupassen.
-Eine detaillierte Anleitung dafür folgt.
-===== invis-AD 10.x auf invisAD 12.x =====
-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.//
-//**Hinweis:** Wenn Sie genau wie ich auf Logical-Volume-Management setzen sollten sie der VolumeGroup der Neuinstallation einen anderen Namen geben als die der alten Installation. Nur auf diese Weise können Sie die Festplatten beider Installationen gleichzeitig in einem Server eingebaut haben und Daten ohne Umweg über eine externe Platte von der alten auf die neue Installation migrieren.//
-Die nachfolgenden Anleitungen gehen davon aus, dass Zarafa als Groupware eingesetzt wurde und auf der Neuinstallation dessen Nachfolger Kopano zum Einsatz kommt.
-==== Vorbereitung ====
-Im ersten Schritt sind wichtige Dienste in der alten Installation zu stoppen, sie sollten auch aus dem Boot-Konzept des Server entfernt werden. Allem voran "fetchmail"
-**fetchmail**
-<code>
-invis:~ # systemctl disable fetchmail.service
-invis:~ # systemctl stop fetchmail.service
-</code>
-**Samba**
-<code>
-invis:~ # rcsernet-samba-ad stop
-invis:~ # chkconfig -d /etc/init.d/sernet-samba-ad
-</code>
-**Zarafa**
-<code>
-invis:~ # runzarafa stop
-invis:~ # chkconfig -d /etc/init.d/zarafa-server
-</code>
-Sichern Sie zunächst in der alten Installation die das Active-Directory, die Zarafa-Datenbank und das gesamte "/etc" Verzeichnis.
-**Active Directory**
-<code>
-invis:~ # adbackup
-</code>
-Die Sicherung finden Sie unter <file>/srv/shares/archiv/sicherungen/ad/</file>
-<code>
-invis:~ # zdbdump
-</code>
-Die Sicherung der Zarafa-Datenbank ist unter <file>/srv/shares/archiv/sicherungen/datenbanken/</file> zu finden. Für die Zarafa Sicherungen werden dort Unterverzeichnisse benannt nach dem Sicherungsdatum angelegt.
-Packen Sie jetzt noch das /etc-Verzeichnis in ein Tar-Archiv:
-<code>
-invis:~ # tar -czf etc.tar.gz /etc
-</code>
-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 ====
-Am besten sichern Sie in der neuen Installation das noch jungfräuliche Active Directory auf die gleiche Weise wie zuvor in der alten Installation, wer weiss wozu es gut ist.
-Zwischen invisAD Version 10.x und 12.x hat sich die verwendete Samba-Version grundlegend geändert. Zum einen kommt statt Version 4.2.x jetzt 4.5.x zum Einsatz und zum anderen setzen wir jetzt statt der Pakete von Sernet jetzt eigene Pakete ein.
-Stoppen Sie im ersten Schritt Samba und den sssd-Dienst:
-<code>
-invis:~ # systemctl stop sssd.service
-invis:~ # systemctl stop samba.service
-</code>
-Löschen Sie jetzt den gesamten Inhalt des Verzeichnisses: <file>/var/lib/samba/</file>
-Entpacken Sie jetzt die Sicherung der Active-Directory Sicherung des alten Servers:
-<code>
-invis:~ # tar -xzf Samba_20170429.tar.gz
-</code>
-Im Verzeichnis der entpackten Sicherung finden Sie zwei gesicherte Verzeichnisse "var/cache/samba" und "var/lib/samba". Sie benötigen nur letzteres. Kopieren Sie den Inhalt von "var/lib/samba" nach "/var/lib/samba" und starten Sie Samba wieder:
-<code>
-invis:~ # cp -r Samba_20170429/var/lib/samba/ /var/lib/samba
-invis:~ # systemctl start samba
-</code>
-Innherhalb des Active Directory hat sich durch die Aktualisierung der Version strukturell einiges geändert. Diese Teile werden jetzt von Samba als fehlerhaft angesehen und müssen repariert werden:
-<code>
-invis:~ # samba-tool dbcheck --fix --yes
-</code>
-Lassen Sie sich nicht von der Menge der Fehler erschrecken, das ist vollkommen normal und stellt kein Problem dar.
-Jetzt müssen Sie aus der Sicherung des /etc-Verzeichnisses aus der alten Installation die Kerberos-Keytab wiederherstellen. Kopieren Sie einfach die Datei **''krb5.keytab''** aus der Sicherung direkt ins /etc-Verzeichnis der Neuinstallation. Danach können Sie auch den sssd-Dienst wieder starten.
-<code>
-invis:~ # systemctl start sssd.service
-</code>
-Prüfen Sie wie folgt, ob dem System alle Benutzer der alten Installation bekannt sind:
-<code>
-invis:~ # getent passwd
-</code>
-Ist das nicht der Fall führen Sie folgendes Script aus:
-<code>
-invis:~ # delssscache
-</code>
-Jetzt sollten, ggf. nach einer kurzen Wartezeit, alle Benutzer angezeigt werden können.
-==== invis-Portal Einträge anpassen und Portal wiederherstellen ====
-Mit der Weiterentwicklung des invis-Servers haben sich auch ein paar Veränderungen im invis-Portal ergeben. Nicht zuletzt die Änderung von "Zarafa" zu "Kopano" hat zur Folge, das der "Groupware" Link im Portal ins Leere zeigt. Gleiches gilt beispielsweise für die Zeiterfassungssoftware Kimai, die erst seit Kurzem in den invis-Server integriert ist.
-In der Datei <file>/var/lib/sine/ldif/04_iportal-initial.ldif</file> sind alle Portal-Einträge im LDIF-Format enthalten und können einzeln oder zu mehreren importiert werden. Nachfolgend wird beispielhaft der Kopano-Link gezeigt:
-<code>
-# Groupware KopanoApp
-dn: cn=KopanoApp,cn=invis-Portal,cn=Informationen,cn=invis-server,DC=afe-net,DC=loc
-objectClass: top
-objectClass: iPortEntry
-iPortEntryName: KopanoApp
-cn: KopanoApp
-iPortEntrySSL: FALSE
-iPortEntryURL: [servername]/webapp
-iPortEntryDescription: Die moderne Webapp der Groupware "Kopano" bietet Zugriff auf E-Mails, Terminkalender, Aufgabenverwaltung und Notizen in frischem "Look & Feel".
-iPortEntryActive: FALSE
-iPortEntryPosition: Lokal
-iPortEntryButton: Groupware
-iPortEntryPriv: user
-</code>
-Suchen Sie sich in dieser Datei alle für Ihre Installation fehlenden Links und kopieren Sie diese in eine neue LDIF-Datei.
-Die auf diese Weise generierte LDIF-Datei kann wie folgt ins Activ-Directory integriert werden:
-<code>
-invis:~ # ldbadd -v -H /var/lib/samba/private/sam.ldb kopano.ldif
-</code>
-Danach können die gewünschten Portal-Einträge aktiviert, bzw. unerwünschte deaktiviert werden. Hier wieder am Beispiel Zarafa/Kopano. Zunächst den alten Portaleintrag deaktivieren:
-<code>
-invis:~ # swpestat ZarafaApp FALSE
-</code>
-Jetzt den neuen Kopano-Link aktivieren:
-<code>
-invis:~ # swpestat KopanoApp TRUE
-</code>
-Sie können sich den aktuellen Status der Portal-Einträge anzeigen lassen:
-<code>
-invis:~ # swpestat status
-</code>
-Das invis-Portal muss sich am LDAP-Dienst des Active Directory anmelden. Durch den Import des alten Active Directory stimmen die Zugangsdaten in der Portal-Konfiguration nicht mehr. Geändert hat sich das Passwort des Benutzers "ldap.admin". Sie finden dessen Passwort aus der alten Installation in der Datei <file>/etc/invis/invis-pws.conf</file> in der Sicherung des alten /etc-Verzeichnisses.
-Tragen Sie das Passwort in die Datei <file>/etc/invis/portal/config.php</file> in folgende Zeile ein:
-<code>
-...
-$LDAP_BIND_PW = 'iX9inbrgfh';
-...
-</code>
-Jetzt müsste sich das Portal im Browser wieder öffnen lassen.
-==== LDAP Authentifizierung ====
-Neben dem Portal müssen sich noch eine Reihe anderer Dienste oder Scripts mit den gleichen Zugangsdaten am LDAP-Dienst des Active Directory anmelden. Nachfolgend die Liste der Dateien, in denen das Passwort angepasst werden muss:
-  * **''/etc/invis/invis-pws.conf''**
-  * **''/etc/postfix/ldap-users.cf''**
-  * **''/etc/postfix/ldap-users2.cf''**
-  * **''/etc/postfix/groups.cf''**
-  * **''/etc/postfix/r-canonical.cf''**
-  * **''/etc/postfix/s-canonical.cf''**
-  * **''/etc/kopano/ldap.cfg''** (ldap_bind_passwd = )
-==== Kopano Datenbak wiederherstellen ====
-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 und erzeugen Sie eine neue Datenbank:
-<code>
-invis:~ # mysql -u root -p
-Server version: 10.0.29-MariaDB SLE 12 SP1 package
-Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
-Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
-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:
-<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>
-Spielen Sie jetzt die Sicherung der alten Zarafa-Datenbank in die neu angelegte Datenbank ein:
-<code>
-invis:~ # gunzip < zarafa.invisad.20170429.gz | mysql -u root -p kopano2017
-</code>
-Jetzt ist in der Datei <file>/etc/kopano/server.cfg</file> der Datenbankname anzupassen:
-<code>
-...
-# Database to connect to
-mysql_database          = kopano2017
-...
-</code>
-Danach muss der Kopano-Server Dienst neu gestartet werden:
-<code>
-invis:~ # systemctl restart kopano-server.service
-</code>
-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.
-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.
-==== ownCloud Migration ====
-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.)
-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.
-Googlen Sie folgendes "owncloud upgrade" nach und Sie finden eine Reihe von Anleitungen für die verschiedenen Versionssprünge.
-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.
-==== Daten wiederherstellen ====
-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>
-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".
-====== invis-Classic -> invis-AD ======
-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.
-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.
-Zu den zu sichernden Daten zählen:
-  * 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.
-Wie auch immer, aus eigener Erfahrung empfehle ich **immer** komplett neue Hardware für die Neuinstallation.
-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.
-Nachfolgend Anleitungen und Tipps zur Bewältigung der Migration. Eine genaue Anleitung wie die oben beschriebene invisAD -> invisAD Migration wird es hier nicht geben.
-===== LDAP Informationen migrieren =====
-Zu den LDAP-Informationen zählen Benutzerkonten, deren zugehörige Email-Konten Informationen und die Daten von DNS- und DHCP-Server.
-==== Benutzerkonten ====
-Beginnen wir mit einer ernüchternden Information. **Lassen Sie es sein!**
-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.
-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
-</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.
-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.
-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.
-... to be continued
-===== Konfigurationen migrieren =====
-===== Datenbanken migrieren =====
-===== Email Bestand migrieren =====
-===== Fileserver-Datenbestand migrieren =====