Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:upgrade [2016/04/01 11:35]
flacco [Nacharbeit]
+++ invis_server_wiki:upgrade [2016/07/23 06:27]
flacco [Clamav]
@@ Zeile 66: / Zeile 66: @@
 Dabei stößt //**zypper**// auf einen Paketkonflikt mit dem Paket "php5-mapi-7.2.0". Wählen Sie hier Lösung 1, die Installation des erwähnten Paketes. Daraus resultiert kein weiteres Problem, da das Paket durch ein neues geringfügig anders benanntes Paket ersetzt wird.
+Installiert werden muss auch das Paket "zarafa-compat":
+<code>
+linux:~ # zypper in zarafa-compat
+</code>
 Ist die Installation der neuen Pakete abgeschlossen, müssen manuell alle Reste der alten Paket-Struktur entfernt werden. Das lässt sich am besten per YaST erledigen. Suchen Sie hier in der Software-Verwaltung nach "zarafa" und entfernen Sie alle Pakete die "7.2.0" im Namen oder als Versionsnummer tragen.
@@ Zeile 78: / Zeile 84: @@
 linux:~ # chown -R zarafa.zarafa /srv/zarafa/
 linux:~ # chown -R zarafa.zarafa /var/log/zarafa/
-linux:~ # choen -R .zarafa /etc/zarafa/*
+linux:~ # chown -R .zarafa /etc/zarafa/*
+linux:~ # chown -R zarafa.zarafa /var/lib/zarafa/
 </code>
@@ Zeile 98: / Zeile 105: @@
 </code>
-Sie müssen jetzt Ihre individuellen Konfigurationen in die neue Datei übernehmen. Die wichtigen Anpassungen im Einzelnen:
+Sie müssen jetzt Ihre individuellen Konfigurationen in die neue Datei übernehmen.
+//**Hinweis:** Auf Systemen, die sowohl IPv4 als auch IPv6 unterstützen müssen Sie in allen Konfigurationstateien, in denen URLs genannt sind, die "localhost" enthalten, dies auf die IP-Adresse "127.0.0.1" ändern. Ansonsten wird der Name "localhost" in die IPv6 Adresse "::1" aufgelöst, womit Zarafa (derzeit) nicht umgehen kann.//
+Alle weiteren wichtigen Anpassungen im Einzelnen:
 **ical.cfg**
@@ Zeile 263: / Zeile 274: @@
 Damit sind alle Änderungen vorgenommen und Zarafa ist auf Version 7.2.2 angehoben.
-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. Wer keinen Zugriff auf "supportete" Pakete hat kann den Lizenz-Dienst auch aus den Zarafa Community-Pakten heraus installieren. Zu finden sind die Pakete hier:
+**{{https://download.zarafa.com/community/final/7.2/|Zarafa-Pakete ohne Support}}**
+//**Achtung:** Nicht enthalten ist der Lizenz-Dienst in den Open-Source Paketen.//
+Auch an der Konfiguration des License-Daemons muss der Pfad zum Zarafa-Socket an das neue Setup angepasst werden.
+**licensed.cfg**
+<code>
+...
+# The URL on which we can contact zarafa-server
+# default: file:///var/run/zarafa
+server_socket = file:///var/run/zarafad/prio.sock
+...
+</code>
+//**Achtung:** Beobachten Sie nach dem Upgrade die Logfiles des Zarafa-Servers, stellen Sie notfalls die Log-Level der einzelnen Dienste vorübergehend hoch. Testen Sie jetzt alles aus. Sollten Fehler auftauchen (davon gab es bei meinen Upgrades reichlich), hat es sich als rettende Maßnahme erwiesen im Zweifel alle Zarafa-Pakete per YaST einfach noch einmal "drüber" zu installieren. Danach müssen erneut die Rechte an den Zarafa-Konfigurationsdateien wie eingangs beschrieben gesetzt werden.//
 ==== "kleines Update" mit dem invis-updater Script ====
@@ Zeile 392: / Zeile 421: @@
 "gelöst".
+Fügen Sie jetzt als vorübergehenden Workaround für eine mit Version 4.2.9 eingeführte Sicherheitseinstellung folgende Zeile in <file>/etc/samba/smb.invis.conf</file> ein:
+<code>
+...
+ldap server require strong auth = no
+...
+</code>
+//**Hinweis:**Diese Einstellung verhindert, dass Sambas LDAP Dienst eine verschlüsselte Verbindung oder eine Kerberos-Authentifizierung erfordert. Die "starke" Authentifizierung erhöht die Sicherheit des LDAP-Dienstes deutlich, leider unterstützen einige Komponenten des invis-Servers bis einschließlich Version 10.4 noch nicht. Da auf einem invis-Server die Anmeldungen am LDAP-Dienst in der Regel nur über "localhost" erfolgen erwächst daraus kein erhöhtes Sicherheitsrisiko. Ab invis-Server Version 11.0 kann diese Einstellung wieder entfernt werden.//
 Führen Sie jetzt das Script //**afterup**// aus:
@@ Zeile 420: / Zeile 459: @@
 </code>
-Durch Auswahl von "Lösung 1" lies sich das Problem beheben. Da sie auch die Blockade eines "systemd" Updates verursachte wird auch diese Update gleich mit erledigt.
+Durch Auswahl von "Lösung 1" lies sich das Problem beheben. Da sie auch die Blockade eines "systemd" Updates verursachte wird auch diese Update gleich mit erledigt. Sollte ein weiterer, ähnlicher Konflikt folgen, kann dieser auch durch Lösung 1 behoben werden.
 Sie können sich jetzt mit
@@ Zeile 438: / Zeile 477: @@
 === Clamav ===
-Das Clamav beim regulären Update nicht vollständig aktualisiert wurde liegt daran, dass für openSUSE 13.1 lediglich Version 0.99 zur Verfügung steht. Das Bugfix-Release 0.99.1 stellen wir über unser invis-common Repository zur Verfügung. D.h. Das Upgrade erfordert also einen Anbieter-Wechsel.
+Wenn Clamav beim regulären Update nicht vollständig aktualisiert wurde, liegt daran, dass für openSUSE 13.1 keine aktuelle Clamav Version zur Verfügung steht. Alternativ stellen wir aktuelle Bugfix-Releases über unser invis-common Repository zur Verfügung. D.h. Das Upgrade erfordert also einen Anbieter-Wechsel.
-Der Versuch Clamav zu aktualisieren liefert folgenden Hinweis:
+Der Versuch Clamav zu aktualisieren liefert dann folgenden Hinweis:
 <code>
@@ Zeile 452: / Zeile 491: @@
 </code>
-Entsprechend dem Hinweis sieht dann das Upgrade aus:
+Wird dies nicht angezeigt, wurde bereits eine aktuelle Version installiert.
+Entsprechend obigem Hinweis sieht dann das Upgrade aus:
 <code>
@@ Zeile 468: / Zeile 509: @@
 ==== 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!
@@ Zeile 654: / Zeile 697: @@
 === Nacharbeit ===
-Nach dem Neustart laufen einige (von einander mehr oder minder abhängige) Dienste nicht.
+Nach dem Neustart laufen einige (von einander mehr oder minder abhängige) Dienste nicht. Bevor wie dies beheben werfen wir einen Blick auf die Konfigurationsdateien des invis-Servers selbst. Darin haben sich auch ein paar Dinge geändert.
-**Samba**
+==invis-Server Konfiguration==
+Im Verzeichnis <file>/etc/invis</file> ist nach dem Upgrade eine auf ".rpmnew" endende Datei zu finden. Sie enthält einige Konfigurationen der jetzt aktualisierten invis-Version die in der alten Datei noch nicht vorhanden waren. Diese sind händisch in die genutzte Datei "invis.conf" zu übertragen.
+Hier die entsprechenden Einträge, die Sie beim Übernehmen natürlich an Ihre Installation anpassen müssen:
+<code>
+...
+# DNS Infos
+domain:invis-net.loc
+revDomain:220.168.192.in-addr.arpa
+...
+# Wenn einzelne Zarafa-Dienste nicht benötigt werden, koennen diese aus dem nachfolgenden Array entfernt werden.
+zServices:licensed server search spooler dagent gateway ical monitor
+</code>
+//**Hinweis:** Der Eintrag hinter zServices ist in Klammern gesetzt. Das ist ein Bug, die Klammern müssen entfernt werden. Statt dessen müssen Sie im Script "runzarafa" hinzugefügt werden://
+Verändern Sie Zeile 31 im Script <file>/usr/bin/runzarafa</file> wie folgt:
+<code>
+services=(`getconfdata $conffile "zServices" "2"`)
+</code>
+==Samba==
 Allem voran Sernet-Samba. Problem Nr. 1 wird dadurch verursacht, dass Samba nicht auf sein Sicherheitszertifikat zugreifen kann. Ursache hierfür ist, dass während des Upgrades ein neues Verzeichnis <file>/etc/ssl/certs</file> angelegt wurde. Darin befanden sich die alten Zertifikate. Da während des Upgrades allerdings eine Kopie des alten Verzeichnisses gesichert wurde ist das schon mal kein großes Problem. Einfach die Zertifikate aus der Sicherung wieder an den richtigen Ort kopieren:
@@ Zeile 690: / Zeile 757: @@
 </code>
-**DNS**
+==DNS==
 Zweites Problem, der DNS-Server startete nicht. Auch das ist ein alt bekanntes Problem, **bind** hat einfach keinen Zugriff auf auf das Verzeichnis: <file>/var/lib/samba/private</file>
@@ Zeile 708: / Zeile 775: @@
 und natürlich überprüfen.
-**DHCP**
+==DHCP==
 Da Samba nicht lief, konnte auch der DHCP-Server nicht starten. Das lässt sich jetzt nachholen:
@@ Zeile 718: / Zeile 785: @@
 und natürlich überprüfen.
-**Webserver**
+==Webserver==
 Auch Apache verweigert nach dem Upgrade den Start. Eine Status-Abfrage des Dienstes liefert das Problem. Der folgende Fehler:
@@ Zeile 811: / Zeile 878: @@
 ==Zarafa==
+Für Zarafa ergibt sich ebenfalls ein kleines Problem. Während des Upgrades wurden neue Konfigurationsdateien in <file>/etc/zarafa</file> abgelegt, auf die Zarafa unter der Benutzerkennung "zarafa" bzw. der Gruppe "zarafa" nicht zugreifen kann. Dies lässt sich beheben mit:
+<code>
+linux:~ # chown -R .zarafa /etc/zarafa
+linux:~ # runzarafa stop
+linux:~ # runzarafa start
+</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**
+===== 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-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 =====