invis_server_wiki:upgrade

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Nächste Überarbeitung Beide Seiten der Revision
invis_server_wiki:upgrade [2016/04/01 11:56]
flacco [Nacharbeit]
invis_server_wiki:upgrade [2016/04/08 15:50]
flacco [Zarafa Upgrade von Version 7.2.0 auf 7.2.2]
Zeile 264: Zeile 264:
  
 Abschließend noch der Hinweis für all diejenigen, die unsere invis-Server Zarafa-Erweiterungen nutzen. Diese Erweiterung enthält die Komponenten Zarafa-Backup und den Zarafa Lizenz Dienst. Wir werden dieses Erweiterungspack nicht mehr aktualisieren. Wer ohnehin eine Subskription erworben hat, bekommt auch die von Zarafa unterstützten Pakete. Aus diesen Paketen in der Version für SUSE Linux Enterprise 12 heraus lassen sich die RPMs für Zarafa-Backup und Lizenz-Dienst auch unter openSUSE betreiben. Abschließend noch der Hinweis für all diejenigen, die unsere invis-Server Zarafa-Erweiterungen nutzen. Diese Erweiterung enthält die Komponenten Zarafa-Backup und den Zarafa Lizenz Dienst. Wir werden dieses Erweiterungspack nicht mehr aktualisieren. Wer ohnehin eine Subskription erworben hat, bekommt auch die von Zarafa unterstützten Pakete. Aus diesen Paketen in der Version für SUSE Linux Enterprise 12 heraus lassen sich die RPMs für Zarafa-Backup und Lizenz-Dienst auch unter openSUSE betreiben.
 +
 +Erläuterung zu nachfolgendem Codeblock folgt....
 +
 +<​code>​
 +# SERVER SETTINGS
 +
 +# The socket that the license server will run on
 +# default: /​var/​run/​zarafa-licensed
 +#​server_pipe_name = /​var/​run/​zarafa-licensed
 +server_pipe_name = /​var/​run/​zarafad/​licensed.sock
 +
 +# The URL on which we can contact zarafa-server
 +# default: file:///​var/​run/​zarafa
 +#​server_socket = file:///​var/​run/​zarafa-prio
 +server_socket = file:///​var/​run/​zarafad/​prio.sock
 +
 +# Login to the Zarafa server using this SSL Key
 +#​sslkey_file ​        = /​etc/​zarafa/​ssl/​licensed.pem
 +
 +# The password of the SSL Key
 +#​sslkey_pass ​        = replace-with-server-cert-password
 +
 +# License path (should contain '​base'​ and CALs in other files)
 +license_path ​           = /​etc/​zarafa/​license
 +
 +# drop privileges and run the process as this user
 +run_as_user ​            = zarafa
 +
 +# drop privileges and run the process as this group
 +run_as_group ​           = zarafa
 +</​code>​
 ==== "​kleines Update"​ mit dem invis-updater Script ==== ==== "​kleines Update"​ mit dem invis-updater Script ====
  
Zeile 468: Zeile 499:
  
 ==== Distribution Upgrade openSUSE 13.1 auf openSUSE leap 42.1 ==== ==== Distribution Upgrade openSUSE 13.1 auf openSUSE leap 42.1 ====
 +
 +**Dauer:** ca. 4h (wenn keine Katastrophen eintreten)
  
 An dieser Stelle möchte ich noch einmal an die eingangs erwähnte Datensicherung oder das beiseite Legen einer Festplatte aus einem RAID Verbund erinnern. Ab hier wird es riskant! Erhöht wird das Risiko noch einmal dadurch, dass wir mit openSUSE 13.2 eine Release überspringen,​ die wir für invis-Server nie unterstützt haben. openSUSE selbst erwähnt in den Anleitungen des Projekts immer, dass nur das Upgrade von einer Release zur nächsten unterstützt wird. Hoffen wir also das Beste! An dieser Stelle möchte ich noch einmal an die eingangs erwähnte Datensicherung oder das beiseite Legen einer Festplatte aus einem RAID Verbund erinnern. Ab hier wird es riskant! Erhöht wird das Risiko noch einmal dadurch, dass wir mit openSUSE 13.2 eine Release überspringen,​ die wir für invis-Server nie unterstützt haben. openSUSE selbst erwähnt in den Anleitungen des Projekts immer, dass nur das Upgrade von einer Release zur nächsten unterstützt wird. Hoffen wir also das Beste!
Zeile 843: Zeile 876:
 linux:~ # runzarafa start linux:~ # runzarafa start
 </​code>​ </​code>​
 +
 +==Kosmetik==
 +
 +Färben wir zum Schluss noch Grub wieder in invis-Orange ein. Dazu ist zunächst das invis-Theme zu installieren:​
 +
 +<​code>​
 +linux:~ # tar -xf /​usr/​share/​doc/​packages/​invisAD-setup/​examples/​grub/​invis8.tar.gz -C /​boot/​grub2/​themes/​
 +</​code>​
 +
 +Jetzt noch die Konfigurationsdatei platzieren:
 +
 +<​code>​
 +linux:~ # cp /​usr/​share/​doc/​packages/​invisAD-setup/​examples/​grub/​grub /​etc/​default/​
 +</​code>​
 +
 +Abschließend muss eine Grub-Bootloader Konfiguration erzeugt werden:
 +
 +<​code>​
 +linux:~ # grub2-mkconfig -o /​boot/​grub2/​grub.cfg
 +</​code>​
 +
 +Ein Reboot sollte jetzt die Korrekte invis-Version vor orangem Hintergrund zeigen.
 +
 +Wer möchte kann jetzt noch die Konfigurationsdateien wichtiger Dienste wie z.B. Postfix mit den neuen Vorlagen in <​file>/​usr/​share/​doc/​packages/​invisAD-setup/​examples/</​file>​ abgleichen und ein letztes reguläres Update laufen lassen.
 +
 +Ansonsten gilt: **Wilkommen zu Ihrem aktuellen invis-Server**
 ====== invis-Classic -> invis-AD ====== ====== 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 =====
  
  • invis_server_wiki/upgrade.txt
  • Zuletzt geändert: 2024/07/05 10:52
  • von flacco