Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
invis_server_wiki:upgrade [2017/04/29 18:38] flacco [DDNS] |
invis_server_wiki:upgrade [2017/04/30 09:53] flacco [invis-Server Upgrade] |
||
---|---|---|---|
Zeile 5: | Zeile 5: | ||
Für den invis-Server sind dabei folgende Themen von Interesse: | 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. | 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. | ||
Zeile 1043: | Zeile 1044: | ||
Die beste Möglichkeit eines Upgrades stellt eine Neuinstallation eines aktuellen invis-Servers mit anschließender Datenmigration dar. | 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:** Sie sollten sich auf jeden Fall eine lauffähige Version Ihres bestehenden invis-Server erhalten. Installieren Sie also am besten auf neue Festplatten.// | ||
Zeile 1147: | Zeile 1150: | ||
</code> | </code> | ||
- | Passen Sie Ihre Konfiguration entsprechend dem obigen Beispiel an. | + | 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 ==== | ==== Wiederherstellung des Active Directory ==== | ||
Zeile 1340: | Zeile 1349: | ||
==== Daten wiederherstellen ==== | ==== 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". | ||
+ | |||
+ | === 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> | ||
+ | |||
+ | ==== Abschluss ==== | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Viel Spaß mit Ihrem neuen invis-Server. | ||
+ | |||