Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:upgrade [2017/04/30 09:54]
flacco [invis-Server Upgrade]
+++ invis_server_wiki:upgrade [2019/02/21 08:45]
flacco [Weitere Anleitungen]
@@ Zeile 3: / Zeile 3: @@
 In dieser Rubrik wird es Anleitungen, Tipps & Tricks sowie Hintergrundwissen zum Thema "Upgrade" geben. Anders als bei einem Update geht es beim Upgrade immer um den Umstieg auf neuere Versionen einer Software oder eines Gesamt-Produktes.
-Für den invis-Server sind dabei folgende Themen von Interesse:
+Mit Einführung des invis-Servers Version 11.0 haben wir ein neueres Nummerierungsschema eingeführt. Dabei bedeutet ein Sprung der Major-Release-Nummer vor dem Punkt immer eine große strukturelle Neuerung, bei der ein einfacher Update-Prozess nicht genügt um alle neuen Features des invis-Servers in eine bestehende Installation aufzunehmen. Bei Sprüngen der Minor-Release-Nummer hinter dem Punkt ist dies in der Regel möglich.
-  - [[invis_server_wiki:upgrade:classic-to-ad|Upgrade von invis-Classic auf invis-AD]]
+Soll eine bestehende Installation lediglich mit Sicherheits-Updates versorgt oder auf eine aktuelle openSUSE Leap Version angehoben werden, ist in der Regel keine Neuinstallation des invis-Servers nötig. Mit Einführung von openSUSE Leap hat sich der Update- und Distributions-Upgrade-Prozesse so deutlich verbessert, dass dies auch mit bestehenden invis-Server Installationen möglich ist ohne dessen Funktion zu beeinträchtigen. Datensicherungen bzw. evtl. der Tausch einer Platte aus einem RAID-1 Verbund sind vorab trotzdem empfehlenswert.
-  - [[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]]
-  - [[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]]
+Ein Upgrade auf eine neuere invis-Server Major-Release lässt sich hingegen je nach dem wie groß der Abstand ist besser durch eine Neuinstallation mit anschließender Datenmigration realisieren.
-===== invis-AD 10.3 unter openSUSE 13.1 -> invis-AD ab 10.4 unter openSUSE Leap =====
+Die nachfolgenden Beschreibungen stellen keine eins zu eins umsetzbaren Anleitungen für alle denkbaren Szenarien dar, sondern beschreiben Fälle, die in unserer eigenen Praxis vorgekommen sind. Um eigene Upgrades durchzuführen suchen Sie sich den Punkt aus, der Ihrem Szenario am nächsten kommt. Sie sollten aber auch die anderen Beschreibungen ggf. anschauen, evtl. finden Sie darin für Sie nützliche Tipps.
-Der Weg von einem frühen invis-AD hin zu einer aktuellen Version ist vor allem deshalb von Interesse, da sich openSUSE 13.1 bereits in der "Evergreen" Phase befindet, also den regulären Maintenance Zyklus bereits hinter sich hat. Aber auch die Evergreen-Phase dauert nicht ewig, angedacht ist als deren Ende bereits der November 2016.
+//**Hinweis:** Es ist nie ein Fehler, wenn Sie Ihren invis-Server im Rahmen der regulären Online-Updates vor einem Upgrade auf den aktuellen Patch-Stand bringen. Am einfachsten klappt das mit SUSEs //**you**// (YaST Online Update). Auch das Durchaktualisieren von ownCloud und Kopano auf die aktuellsten Versionen, wie nachfolgend Beschrieben ist sinnvoll.//
-Die folgenden Anleitungen sind natürlich eine Momentaufnahme zum Zeitpunkt des Tests. Dinge ändern sich und nicht alle Systeme sind gleich. D.h. es kann beim Nachvollziehen dieser Anleitung zu Problemen kommen, die bei mir nicht aufgetaucht sind. In solchen Fällen ist natürlich nicht alles verloren, sondern es gilt sich Logfiles genau anzuschauen und die Situation zu analysieren. Es sollte selbstverständlich sein, dass ein solches Unterfangen nicht ohne vorherige **vollständige** Datensicherung gestartet werden sollte. Ist Ihr System auf Basis von **RAID1** aufgebaut ist es einfach sich durch auftrennen der RAID-Verbünde einen doppelten Boden zu erhalten. Einfach eine Platte aus dem System nehmen, auf die Seite legen und das Upgrade nur auf der verbliebenen Platte durchführen.
+===== Gesamten Server Upgraden=====
+  - [[invis_server_wiki:upgrade:classic-to-ad|Upgrade von invis-Classic auf invis-AD]]
-Trotz bestehender Risiken sollten die nachfolgenden Beschreibungen eine gute Basis für ein umfangreiches Upgrade liefern.
+  - [[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]]
+  - [[invis_server_wiki:upgrade:10.4_leap-to-11.0|Manuelles Upgrade von 10.4 zu neueren Versionen ab 11.0]]
-Dieser Weg schließt reguläre Updates das Upgrade auf eine aktuelle Zarafa-Version sowie eine aktuelle Sernet-Samba-Version ein. In ersten Tests hat sich gezeigt, dass es unbedingt notwendig ist zunächst Zarafa auf einen aktuellen Stand zu heben. Dieser Schritt **muss** aufgrund eines Problems in unseren invis-Server Software-Repositories auch vor einem einfachen Update erfolgen.
+  - [[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:11.x-to-12.x|Upgrade von invis-AD 11.x nach invis-AD Version 12.x bzw. 13.x]]
-==== Zarafa Upgrade von Version 7.2.0 auf 7.2.2 ====
+  - [[invis_server_wiki:upgrade:132_to_135|Upgrade von invisAD 13.2 auf 13.5]]
+  - [[invis_server_wiki:upgrade:13.5_to_14.0|Upgrade von invisAD 13.5 auf 14.0]]
-**Dauer:** ca 1 bis 1,5 Stunden
-//**Hinweis:** Die nachfolgende Anleitung gilt auch für ein Upgrade auf neueren invis-AD unter openSUSE Leap.//
-Mit Einführung von Zarafa 7.2.2 hat sich die Struktur der Software-Pakete deutlich geändert, es haben sich Pfade geändert, die Zarafa Dienste werden nicht mehr mit "root" Rechten ausgeführt und Zarafa beherrscht jetzt STARTTLS sowie "Perfect Forward Secrecy". Kurz es wird ein einfaches Upgrade der Pakete.
-Die Schritte im einzelnen:
-Sichern Sie zunächst Ihre Zarafa-Datenbank:
-<code>
-linux:~ # zdbdump
-</code>
-Wenn Sie die invis-Server Zarafa Erweiterungen installiert haben können Sie zusätzlich noch alle Stores manuell sichern:
-<code>
-linux:~ # zdbackup
-</code>
-Stoppen Sie jetzt alle Zarafa-Dienste:
-<code>
-linux:~ # runzarafa stop
-</code>
-Deinstallieren Sie den alten Webaccess:
-<code>
-linux:~ # zypper rm zarafa-webaccess
-</code>
-Dabei werden alle Webacces-Plugin-Pakete ebenfalls deinstalliert.
-Installieren Sie jetzt das neue Zarafa-Metapaket:
-<code>
-linux:~ # zypper ref
-linux:~ # zypper in zarafa-server-packages
-</code>
-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.
-Dabei wird sich YaST immer wieder wegen scheinbarer Abhängigkeitsprobleme beschweren. Brechen Sie das Fenster mit den Lösungsvorschlägen immer wieder ab und gehen Sie alle alten Pakete durch.
-//**Hinweis:** Sie wählen in YaST ein Paket zur Deinstallation, Installation oder Aktualisierung immer mit der Leertaste aus. Dabei will YaST, wenn ein Paket installiert ist dieses beim ersten Klick auf die Leertaste "aktualisieren" und meckert ggf. Abhängigkeitsprobleme an. Erst beim zweiten drücken der Leertaste wird ein Paket zur Deinstallation markiert. Erkennbar am "-" Minuszeichen vor dem Paket. Alle zu deinstallierenden Pakete müssen also in der Liste mit dem "-" gekennzeichnet sein. Ab dann gibt es auch keine Abhängigkeitsprobleme mehr.//
-Passen Sie jetzt die Rechte auf die Konfigurationsdateien, das Attachement-Verzeichnis und die Logfiles an den neuen Benutzer bzw. die neue Gruppe an unter der Zarafa betrieben wird. Achten Sie darauf, dass der Pfad zum Zarafa-Attachements-Verzeichnis auf invis-Servern <file>/srv/zarafa/attachements</file> ist und somit von der Vorgabe abweicht.
-<code>
-linux:~ # chown -R zarafa.zarafa /srv/zarafa/
-linux:~ # chown -R zarafa.zarafa /var/log/zarafa/
-linux:~ # chown -R .zarafa /etc/zarafa/*
-linux:~ # chown -R zarafa.zarafa /var/lib/zarafa/
-</code>
-//**Hinweis:** Es kann auch nicht schaden, wenn Sie das Zarafa-Upgrade als Anlass nehmen, den Suchindex neu aufzubauen. Löschen Sie dazu einfach den gesamten Inhalt des Verzeichnisses: "/var/lib/zarafa/search"//
-Jetzt müssen die Konfigurationen einzelner Dienste angepasst werden. Wichtig sind dabei vor allem "zarafa-ical", "zarafa-gateway" und der "zarafa-server" selbst, da sich deren Konfigurationsdateien teils deutlich geändert haben und die neuen Dateien mit der Endung ".rpmnew" in <file>/etc/zarafa</file> abgelegt wurden.
-Sichern Sie jeweils die alte Datei unter einem neuen Namen und aktivieren die jeweils neue Datei:
-<code>
-linux:/etc/zarafa # cp ical.cfg ical.cfg.old
-linux:/etc/zarafa # cp ical.cfg.rpmnew ical.cfg
-</code>
-Wiederholen Sie dies für die Dateien "gateway.cfg" und "server.cfg".
-Mit Hilfe des Tools //**diff**// können Sie sich jetzt einen Überblick über die Veränderungen schaffen:
-<code>
-linux:/etc/zarafa # diff -u ical.cfg.old ical.cfg
-</code>
-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**
-<code>
-...
-# wether ssl connections can be made to the ical server
-icals_enable = yes
-...
-# File with RSA key for SSL
-ssl_private_key_file = /etc/ssl/private/ldap-key.pem
-# File with certificate for SSL
-ssl_certificate_file = /etc/ssl/certs/ldap-cert.pem
-...
-# SSL protocols to use, set to '!SSLv2' for 'ssl_enable_v2 = no'
-ssl_protocols = !SSLv2 !SSLv3
-# SSL ciphers to use, set to 'ALL' for backward compatibility
-ssl_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL
-# Prefer the server's order of SSL ciphers over client's
-ssl_prefer_server_ciphers = yes
-##############################################################
-# OTHER ICAL SETTINGS
-# The timezone of the system clock
-server_timezone = Europe/Berlin
-</code>
-Wiedergegeben sind nur die Teile der Datei, in der Anpassungen vorgenommen wurden.
-**gateway.cfg**
-<code>
-...
-# enable/disable POP3, and POP3 listen port
-pop3_enable     =       no
-pop3_port       =       110
-...
-# enable/disable Secure IMAP, and Secure IMAP listen port
-imaps_enable    =       yes
-imaps_port      =       993
-...
-# File with RSA key for SSL
-ssl_private_key_file    =       /etc/ssl/private/mail-key.pem
-#File with certificate for SSL
-ssl_certificate_file    =       /etc/ssl/certs/mail-cert.pem
-...
-# SSL protocols to use, set to '!SSLv2' for 'ssl_enable_v2 = no'
-ssl_protocols = !SSLv2 !SSLv3
-# SSL ciphers to use, set to 'ALL' for backward compatibility
-ssl_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL
-# Prefer the server's order of SSL ciphers over client's
-ssl_prefer_server_ciphers = yes
-</code>
-**server.cfg**
-<code>
-...
-# e-mail address of the Zarafa System user
-system_email_address    = administrator@yourdomain.tld
-...
-# The user under which we connect with MySQL
-mysql_user              = zarafa
-# The password for the user (leave empty for no password)
-mysql_password          = your-secret
-...
-# When attachment_storage is 'files', use this path to store the files
-attachment_path         = /srv/zarafa/attachments
-...
-# enable SSL support in server
-server_ssl_enabled      = yes
-# Listen for SSL connections on this port
-server_ssl_port         = 237
-# Required Server certificate, contains the certificate and the private key parts
-server_ssl_key_file     = /etc/ssl/private/zarafa.pem
-# Password of Server certificate
-server_ssl_key_pass     = replace-with-server-cert-password
-# Required Certificate Authority of server
-server_ssl_ca_file      = /etc/ssl/CA/cacert.pem
-# Path with CA certificates, e.g. /etc/ssl/certs
-server_ssl_ca_path      =
-# SSL protocols to use, set to '!SSLv2' for 'server_ssl_enable_v2 = no'
-server_ssl_protocols = !SSLv2 !SSLv3
-# SSL ciphers to use, set to 'ALL' for backward compatibility
-server_ssl_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL
-# Prefer the server's order of SSL ciphers over client's
-server_ssl_prefer_server_ciphers = yes
-...
-# Name of the plugin that handles users
-# Required, default = db
-# Values: ldap, unix, db, ldapms (available in enterprise license)
-user_plugin             = ldap
-...
-# location of the zarafa plugins
-# if you have a 64bit distribution, this probably should be changed to /usr/lib64/zarafa
-plugin_path             = /usr/lib64/zarafa
-...
-# Disable features for users. Default all features are disabled. This
-# list is space separated. Currently valid values: imap
-disabled_features = pop3
-</code>
-Passen Sie hier auch die Einstellungen des Abschnitts
-<code>
-# CACHE SETTINGS
-</code>
-gemäß Ihrer alten Konfiguration an.
-In den obigen Dateien wurde das SSL-Setup immer gemäß aktuellem Standard angepasst. Sie können dementsprechend auch alle weiteren Konfigurationsdateien der Zarafa-Dienste kontrollieren und anpassen.
-Bleibt abschließend noch das Aktualisieren der Webapp:
-<code>
-linux:~ # zypper up zarafa-webapp
-</code>
-Auch hier sind an der Konfiguration geringfügige Anpassungen notwendig. Zu finden ist die Konfigurationsdatei unter: <file>/etc/zarafa/webapp/config.php</file>
-**config.php**
-<code>
-...
-        // Default Zarafa server to connect to.
-        #define("DEFAULT_SERVER","file://\\\\.\\pipe\\zarafa");
-        #define("DEFAULT_SERVER","http://localhost:236/zarafa");
-        define("DEFAULT_SERVER","file:///var/run/zarafad/server.sock");
-...
-        // Defines the default interface language. This can be overriden by the user.
-        // This language is also used on the login page
-        if (isset($_ENV['LANG']) && $_ENV['LANG']!="C"){
-                define('LANG', $_ENV["LANG"]); // This means the server environment language determines the web client language.
-        }else{
-                define('LANG', 'de_DE.UTF-8'); // default fallback language
-        }
-...
-        // Defines the default time zone, change e.g. to "Europe/London" when needed
-        if(function_exists("date_default_timezone_set")) {
-                if(!ini_get('date.timezone')) {
-                        date_default_timezone_set('Europe/Berlin');
-                }
-        }
-</code>
-Auch hier sind nur die Anpassungen aufgeführt. Die wichtigste Änderung ist die Tatsache, dass sich der Pfad zum Zarafa-Socket geändert hat.
-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. 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 ====
-**Dauer:** ca 0,5h
-Das kleine Update unter Verwendung des //**invis-updater**// Scripts zählt eigentlich zu den regelmäßigen Wartungsarbeiten am System. Von uns wirde das genannte Script einzig zu dem Zweck entwickelt unkritische Sicherheitsaktualisierungen automatisiert und unbeaufsichtigt durchführen zu können.
-//**Achtung:** im hier geschilderten Testfall hat die Anwendung des //**invis-updater**// Scripts vor dem oben beschriebenen Zarafa-Upgrade zu einem nicht mehr funktionierenden Zarafa geführt. Die Ursache hierfür lag an der Art und Weise wie wir Zarafa in unseren Repositories pflegen. Wir sind gerade dabei alles so umzustellen, dass dies zukünftig nicht mehr vorkommen kann. Aber auch in diesem Fall wäre es möglich gewesen das Zarafa-Upgrade nachträglich durchzuführen.//
-Die Verwendung des Scripts ist denkbar einfach:
-<code>
-linux:~ # invis-updater
-</code>
-Das Script sucht alle anstehenden Updates, streicht solche von denen ein Risiko für die Funktionalität des Systems ausgehen können und solche die einen Reboot erfordern heraus, installiert die verbleibenden, startet (soweit möglich) alle betroffenen Dienste neu und wendet das invis-eigene //**afterup**// Script an.
-Ein anschließender Reboot ist nicht notwendig, kann aber helfen evtl. auftretende Probleme zu lokalisieren.
-Nach einem solchen Update ist zu über prüfen, ob ein evtl. enthaltenes invisAD-setup Update neue invis-Konfigurationsdateien geliefert hat. Diese liegen in <file>/etc/invis</file> und Unterverzeichnissen. Sie sind an der Endung ".dist" zu erkennen. Ist das der Fall, sind die neuen Dateien mit den vorhandenen zu vergleichen und Neuerungen mit Copy & Paste in die eigenen Dateien zu übernehmen.
-Wurde auch das Paket z-push erneuert, so ist in der Regel in dessen Konfigurationsdatei: <file>/srv/www/htdocs/z-push2/config.php</file> wieder die korrekte Zeitzone einzutragen:
-<code>
-...
-    // Defines the default time zone, change e.g. to "Europe/London" if necessary
-    define('TIMEZONE', 'Europe/Berlin');
-...
-</code>
-//**Hinweis:** Verwenden Sie für die Zeitzone keines der bekannten Kürzel wie "MET", "CEST" usw. Dies kann zu Problemen führen.//
-Damit ist auch dieser Schritt erledigt.
-==== reguläres Update mit zypper ====
-**Dauer:** ca. 0,5h
-Bei dieser Methode des Updates werden auch neue Software-Versionen kritischer Programme installiert. Genaugenommen sind es also teilweise "Upgrades". Dies betrifft Software, die wir aus unseren invis-Server Repositories ausrollen, aber auch die Pakete aus dem Sernet-Samba-Respositories und des VirtualBox Repos.
-Ist Virtualbox installiert sollten zunächst alle virtuellen Maschinen heruntergefahren und der vboxweb-Service beendet werden. Letzteres ist je nach Version nur mittels //**kill**// möglich.
-<code>
-linux:~ # /etc/init.d/vboxweb-service stop
-linux:~ # ps ax|grep vbox
-</code>
-Sollte die //**ps**// Kommandozeile einen laufenden Prozess finden ist dieser mit:
-<code>
-linux:~ # kill -9 pid-number
-</code>
-abzuschießen.
-Je nachdem wann Sie Ihren invis-Server installiert haben, kann es sein, dass Ihre Virtualbox-Repository veraltet ist. Ändern Sie die Datei <file>/etc/zypp/repos.d/virtualbox.repo</file> wie folgt ab:
-<code>
-[virtualbox]
-name=VirtualBox for openSUSE 13.1
-baseurl=http://download.virtualbox.org/virtualbox/rpm/opensuse/13.1
-type=yum
-enabled=1
-priority=120
-autorefresh=1
-gpgcheck=1
-gpgkey=https://www.virtualbox.org/download/oracle_vbox.asc
-keeppackages=0
-</code>
-In der falschen Datei wurde auf das Repository der Vorgängerversion openSUSE 12.3 verwiesen.
-Jetzt kann mit dem regulären Update begonnen werden.
-<code>
-linux:~ # zypper ref
-linux:~ # zypper up
-</code>
-Im Verlauf des Updates wird ein neuer Kernel installiert. Dabei handelt es sich um Version 3.12 aus SLES 12, welche über das openSUSE Evergreen Projekt bereit gestellt wird. Hier gibt es gelegentlich ein Problem mit UDEV-Regeln bei der Erkennung von USB-Festplatten. Das kann also ein "invis-backup" beeinflussen. Eine Lösung dafür gibt es schon, muss ich nur wie finden ;-)
-Nach dem Update müssen noch einmal die VirtualBox Kernel-Module erneuert werden. Mit dem Update der VirtuaBox Version wurde auch hier der Umstieg auf "systemd" Volzogen, d.h. es existieren keine "init-Scripts" mehr. Zum Erneuern der Kernel-Module bringt VirtualBox allerdings ein Shell-Script mit:
-<code>
-linux:~ # /usr/lib/virtualbox/vboxdrv.sh setup
-</code>
-Ist dies erfolgreich durchgelaufen können ggf. vorhandene virtuelle Maschinen wieder gestartet werden.
-Damit ist auch dieser Schritt beendet.
-==== Upgrade auf aktuelle Versionen von Sernet-Samba, SSSD  und Clamav====
-**Dauer:** ca. 45 Minuten
-Im vorangegangenen Schritt hat //**zypper**// einige Pakete ausgelassen, wie die folgende Ausgabe zeigt:
-<code>
-The following 25 package updates will NOT be installed:
-  clamav grub2 grub2-i386-pc grub2-x86_64-efi libudev-mini1 ntop php5-pear-Mail python-sssd-config sernet-samba sernet-samba-ad sernet-samba-client sernet-samba-common
-  sernet-samba-libs sernet-samba-libs-32bit sernet-samba-libsmbclient0 sernet-samba-winbind sssd sssd-ad sssd-krb5 sssd-krb5-common sssd-ldap sssd-tools systemd systemd-sysvinit
-  udev-mini
-</code>
-Darunter befinden sich alle Sernet-Samba-Pakete, die aktuellen Pakete des SSSD-Dienstes sowie ein aktualisiertes Clamav Paket. Diese Pakete werden nachfolgend manuell aktualisiert.
-=== Sernet Samba ===
-Legen Sie zunächst ein Backup des gesamten Active-Direcoties an:
-<code>
-linux:~ # adbackup
-</code>
-Sie finden die Sicherung unter <file>/srv/shares/archiv/sicherungen/vollsicherungen/ad/</file>
-Die Ausgangssituation für meinen Test war ein Sernet-Samba 4.2.4, zur Verfügung stand Version 4.2.9. Mit Version 4.2.8 haben dei Sernet-Paketbauer einiges an den Paketabhängigkeiten optimiert. Probleme, gerade im Zusammenspiel mit dem SSSD können dennoch auftreten.
-Entsprechend wird die Sache ab hier etwas kniffliger. Der Versuch alle Sernet-Pakete zu aktualisieren lieferte bei meinem Test eine nicht aufzulösende Abhängigkeit zu einer Bibliothek "libarchive.so.2" die definitiv nicht zur Verfügung steht. Da sie auch unter openSUSE Leap nicht zur Verfügung steht und Sernet-Samba 4.2.9 dort ohne ein solches Problem installiert wird, habe ich beschlossen es zu ignorieren.
-<code>
-linux:~ # zypper up sernet-samba sernet-samba-ad sernet-samba-client sernet-samba-common sernet-samba-libs sernet-samba-libs-32bit sernet-samba-libsmbclient0 sernet-samba-winbind
-</code>
-Zur Installation aller Pakete habe ich die bemängelten Abhängigkeitsprobleme immer durch "Lösung 2":
-<code>
-Lösung 2: sernet-samba-client-99:4.2.9-19.suse121.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten
-</code>
-"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:
-<code>
-linux:~ # afterup
-</code>
-Sind alle Sernet-Paket aktualisiert, ist ein Neustart des Systems sehr hilfreich. Bei meinem Test war es vorher nicht möglich Auf den Fileserver zuzugreifen oder der Domäne beizutreten. Nach dem Neustart klappte alles.
-=== SSSD ===
-Ebenfalls Probleme aufgrund von Abhängigkeiten gab es beim SSSD. Das Update wurde beim regulären Update zurück gehalten, da es mit den Paketen "libudev-mini1-210.40" kollidierte.
-<code>
-linux:~ # zypper up sssd
-Daten des Repositories laden ...
-Installierte Pakete lesen ...
-Paketabhängigkeiten auflösen ...
-Problem: this-is-only-for-build-envs, benötigt von libudev-mini1-210-40.1.x86_64, wird von keinem Repository angeboten
-Lösung 1: Folgende Aktionen werden ausgeführt:
-  Deinstallation von libudev-mini1-208-35.1.x86_64
-  Deinstallation von udev-mini-208-35.1.x86_64
-Lösung 2: sssd-1.13.3-181.7.x86_64 nicht installieren
-Lösung 3: sssd-1.13.3-181.7.x86_64 nicht installieren
-Lösung 4: libudev-mini1-210-40.1.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten
-</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. Sollte ein weiterer, ähnlicher Konflikt folgen, kann dieser auch durch Lösung 1 behoben werden.
-Sie können sich jetzt mit
-<code>
-linux:~ # zypper ps
-</code>
-alle vom Update betroffenen Dienste anzeigen lassen oder gleich das System neu starten. Letzteres ist keine schlechte Idee, da der systemd ja bekanntlich für den Start eines System verantwortlich ist.
-Nach erfolgreichem Neustart sollten Sie sich mit
-<code>
-linux:~ # getent passwd
-</code>
-alle Benutzer Ihres Systems anzeigen lassen. Werden dabei die Benutzerkonten aus dem Active Directory angezeigt hat alles funktioniert.
-=== Clamav ===
-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 dann folgenden Hinweis:
-<code>
-linux:~ # zypper up clamav
-Daten des Repositories laden ...
-Installierte Pakete lesen ...
-Es gibt einen Aktualisierungskandidaten für 'clamav', aber er ist von einem anderen Anbieter. Verwenden Sie 'zypper install clamav-0.99.1-139.4.x86_64' um diesen Kandidaten zu installieren.
-Paketabhängigkeiten auflösen ...
-Keine auszuführenden Aktionen.
-</code>
-Wird dies nicht angezeigt, wurde bereits eine aktuelle Version installiert.
-Entsprechend obigem Hinweis sieht dann das Upgrade aus:
-<code>
-linux:~ # zypper in clamav-0.99.1-139.4.x86_64
-</code>
-Danach kann der der Clam-Daemon neu gestartet werden:
-<code>
-linux:~ # systemctl restart clamd.service
-linux:~ # systemctl restart freshclam.service
-</code>
-Damit ist auch dieser Schritt abgeschlossen und Ihr System auf Basis von openSUSE 13.1 auf dem neuesten Stand.
-==== 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!
-Voraussetzung für alles Weitere ist auf jeden Fall, dass alle zuvor beschriebenen Schritte erfolgreich beendet wurden und Ihr System in einem funktionierenden Zustand ist.
-=== Vorbereitung ===
-Im ersten Schritt sind die genutzten Repositories auf den Stand der Ziel-Release umzustellen. Dazu lassen wir uns zunächst einmal alle vorhandenen Repositories anzeigen:
-<code>
-linux:~ # zypper lr
-#  | Alias                              | Name                                                                  | Aktiviert | Aktualisieren
----+------------------------------------+-----------------------------------------------------------------------+-----------+--------------
-| download.opensuse.org-13.1-non-oss | Aktualisierungs-Repository (Nicht-Open-Source-Software)               | Ja        | Ja
-| download.opensuse.org-non-oss      | Haupt-Repository (NON-OSS)                                            | Ja        | Ja
-| download.opensuse.org-oss          | Haupt-Repository (OSS)                                                | Ja        | Ja
-| download.opensuse.org-update       | Hauptaktualisierungs-Repository                                       | Ja        | Ja
-| openSUSE-13.1-1.10                 | openSUSE-13.1-1.10                                                    | Ja        | Ja
-| repo-debug                         | openSUSE-13.1-Debug                                                   | Nein      | Ja
-| repo-debug-update                  | openSUSE-13.1-Update-Debug                                            | Nein      | Ja
-| repo-debug-update-non-oss          | openSUSE-13.1-Update-Debug-Non-Oss                                    | Nein      | Ja
-| repo-source                        | openSUSE-13.1-Source                                                  | Nein      | Ja
-| sernet-samba-4.2                   | SerNet Samba 4.2 Packages (suse-13.1)                                 | Ja        | Nein
-| spins_invis_common                 | Common packages for invis-Server stable & unstable (openSUSE_13.1)    | Ja        | Ja
-| spins_invis_stable                 | Production Project for the openSUSE invis-Server Spin (openSUSE_13.1) | Ja        | Nein
-| virtualbox                         | VirtualBox for openSUSE 13.1                                          | Ja        | Ja
-</code>
-Darunter befinden sich mit den Repositories 10 (Sernet Samba) und 13 (VirtualBox) zwei Fremd-Repositories und mit 11 & 12 die Repositories des invis-Server Projektes. Alle Anderen sind Standard-Repos von openSUSE.
-Erstellen wir zunächst eine Sicherheitskopie des Repo-Verzeichnisses:
-<code>
-linux:~ # cp -R /etc/zypp/repos.d /etc/zypp/repos.d.bak
-</code>
-VirtualBox stellt ein fertiges Repository für openSUSE Leap (und 13.2 in Kombination) zur Verfügung, d.h. es ist am einfachsten das vorhandene zu löschen und das neue hinzuzufügen:
-<code>
-linux:~ # zypper rr 13
-Repository 'VirtualBox for openSUSE 13.1' wird entfernt ........................................................................................................................[fertig]
-Repository 'VirtualBox for openSUSE 13.1' wurde entfernt.
-linux:~ # zypper ar http://download.virtualbox.org/virtualbox/rpm/opensuse/13.2/virtualbox.repo
-Repository 'VirtualBox for openSUSE 13.2 / Leap 42.1' wird hinzugefügt .........................................................................................................[fertig]
-Repository 'VirtualBox for openSUSE 13.2 / Leap 42.1' erfolgreich hinzugefügt
-Aktiviert: Ja
-Autoaktualisierung: Nein
-GPG-Überprüfung: Ja
-URI: http://download.virtualbox.org/virtualbox/rpm/opensuse/13.2
-</code>
-In Bezug auf Sernet-Samba haben wir die Qual der Wahl. Es wird kein Repository explizit für openSUSE Leap 42.1 zur Verfügung gestellt, allerdings je eines für SLES12 und eines für openSUSE 13.2. openSUSE Leap 42.1 hegt verwandtschaftliche Beziehungen zu beiden.
-Bei Neuinstallationen verwenden wir das Repository für SLES12, also sollte das auch hier keine falsche Entscheidung sein. Da hier in der Repository-Datei Zugangsdaten für das Repository enthalten sind ist es einfacher die Datei selbst zu editieren, statt sie zu ersetzen. Öffnen Sie dazu <file>/etc/zypp/repos.d/sernet-samba4.repo</file> und passen Sie die Pfade und Bezeichnungen wie folgt an:
-<code>
-[sernet-samba-4.2]
-name=SerNet Samba 4.2 Packages (SLES 12)
-type=rpm-md
-baseurl=https://sernet-samba-public:Noo1oxe4zo@download.sernet.de/packages/samba/4.2/sles/12/
-gpgcheck=1
-gpgkey=https://sernet-samba-public:Noo1oxe4zo@download.sernet.de/packages/samba/4.2/sles/12/repodata/repomd.xml.key
-enabled=1
-</code>
-Alle weiteren Repositories bearbeiten wir bezüglich der Versionsnummer in einem Rutsch unter Verwendung von //**sed**//
-<code>
-linux:~ # sed -i 's/13\.1/42\.1/g' /etc/zypp/repos.d/*
-</code>
-Leider haben sich mit openSUSE leap auch die Pfade geändert. In allen openSUSE Repositories ist in der Zeile "baseurl" nach "distribution" oder "update" und vor der Versionsnummer das Unterverzeichnis "leap" einzufügen. Auch hier hilft //**sed**//:
-<code>
-linux:~ # sed -i 's%distribution\/%distribution\/leap\/%g' /etc/zypp/repos.d/*
-linux:~ # sed -i 's%update\/%update\/leap\/%g' /etc/zypp/repos.d/*
-</code>
-In den beiden Update-Repositories ergeben sich noch ein paar händisch zu beseitigende Ungereimtheiten. Ändern Sie:
-<file>download.opensuse.org-13.1-non-oss.repo</file>
-<code>
-[download.opensuse.org-42.1-non-oss]
-name=Aktualisierungs-Repository (Nicht-Open-Source-Software)
-enabled=1
-autorefresh=1
-baseurl=http://download.opensuse.org/update/leap/42.1/non-oss/
-path=/
-type=rpm-md
-keeppackages=0
-</code>
-Hierin muss in der "baseurl" Zeile "42.1-non-oss" in "42.1/non-oss" geändert werden.
-<file>download.opensuse.org-update.repo</file>
-<code>
-[download.opensuse.org-update]
-name=Hauptaktualisierungs-Repository
-enabled=1
-autorefresh=1
-baseurl=http://download.opensuse.org/update/leap/42.1/oss
-path=/
-type=rpm-md
-keeppackages=0
-</code>
-Hierin musste am Ende der URL das Unterverzeichnis "/oss" angefügt werden.
-Damit sind alle Repositories angepasst.
-=== Upgrade ===
-Damit sind wir am "point of no return" angelangt. Bevor es los geht noch eine wichtige Warnung:
-//**Achtung:** Sollten Sie Ihren invis-Server unter Verwendung einer grafischen Oberfläche betreiben, sollten Sie das nachfolgende Upgrade auf KEINEN Fall in Runlevel 5 durchführen, sondern auf RL3 in einer Konsole! ...auch von einem Upgrade via SSH würde ich absehen.//
-Die Durchführung des Upgrades ist relativ simpel. Bereinigen Sie zunächst die Repository-Caches und frischen Sie sie auf:
-<code>
-linux:~ # zypper clean
-linux:~ # zypper ref
-</code>
-Sollten dabei Fehler auftreten, kontrollieren Sie noch einmal die Pfadangaben in den Repository-Dateien.
-Das eigentliche Upgrade erfolgt dann mit:
-<code>
-linux:~ # zypper dup
-</code>
-Das Ganze beginnt mit Abhängigkeitsproblemen, was nicht weiter verwunderlich ist. Verschiedene Sernet-Samba-Pakete sind abhängig von einem Paket namens "insserv-compat":
-**Konflikte**
-<code>
-Problem: sernet-samba-99:4.2.9-19.suse132.x86_64 benötigt /lib/lsb/init-functions, was aber nicht angeboten werden kann
-  Gelöschte Anbieter: insserv-compat-0.1-8.1.2.x86_64
-Lösung 1: veraltetes insserv-compat-0.1-8.1.2.x86_64 behalten
-Lösung 2: Deinstallation von sernet-samba-99:4.2.9-19.suse121.x86_64
-Lösung 3: sernet-samba-99:4.2.9-19.suse132.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten
-Wählen Sie aus den obigen Lösungen mittels Nummer oder brechen Sie a(b). [1/2/3/b] (b): 3
-</code>
-Das passiert genau drei mal. Ich habe mich jeweils für Lösung 3 entschieden und scheine damit richtig gelegen zu haben, da im Laufe der Installation ein neueres "insserv-compat" Paket installiert wurde.
-Aufmerksam haben mich auch einige der angezeigten Vendor-Changes gemacht:
-**Vendor changes**
-<code>
-The following 10 packages are going to change vendor:
-  grub2             openSUSE -> obs://build.opensuse.org/spins:invis
-  grub2-i386-pc     openSUSE -> obs://build.opensuse.org/spins:invis
-  grub2-x86_64-efi  openSUSE -> obs://build.opensuse.org/spins:invis
-  ipcalc            obs://build.opensuse.org/spins:invis -> openSUSE
-  libgsoap-2_8      obs://build.opensuse.org/spins:invis -> openSUSE
-  liblzma5-32bit    obs://build.opensuse.org/spins:invis -> openSUSE
-  ntop              openSUSE -> obs://build.opensuse.org/spins:invis
-  php5-pear-Mail    obs://build.opensuse.org/spins:invis -> openSUSE
-  postfix           obs://build.opensuse.org/spins:invis -> openSUSE
-  postfix-mysql     obs://build.opensuse.org/spins:invis -> openSUSE
-</code>
-Mir war vorher gar nicht bewusst, dass wir Grub im eigenen Repository pflegen. Ich muss wohl mal im Team fragen warum das so ist. Im Moment kann man das nur so hinnehmen und alles mit "y" akzeptieren.
-Gegen Ende des Upgrades traten die bekannten Fehler mit VirtualBox-Upgrades auf. Das aktuelle Paket brach bei der Installation ab. Gelöst habe ich es in dem ich nach ein paar Minuten auf "r" für Retry gedrückt habe. Danach wurde das Paket ohne Probleme installiert.
-Das Upgrade lief etwa eine Stunde. Obwohl ich vermutet hatte, dass es mit Grub Probleme geben würde, habe ich mich zu einem direkten Reboot entschieden und mein System startete nicht mehr.
-Um das zu beheben habe ich zur "Super-Grub-Disk" gegriffen **[[https://www.youtube.com/watch?v=CDqQWXYD2RI|(und das ist an einem 1. April ein ECHTER Spaß)]]** und mein System gestartet, was ebenfalls problemlos funktionierte.
-Zum Beheben der Probleme genügte es Grub neu in die MBRs aller Festplatten zu installieren:
-<code>
-linux:~ # grub2-install /dev/sda
-linux:~ # grub2-install /dev/sdb
-</code>
-Der nächste Reboot funktioniert dann ohne Super-Grub-Disk (hätte man auch vorher erledigen können), allerdings ohne unser invis-Grub-Theme. Das wiederherzustellen ist aber allenfalls Kosmetik und fällt in die Rubrik Nacharbeit.
-...und Nacharbeit gibt es, wäre ja auch ein bisschen zu viel des Guten, wenn ein System nach Neuinstallation von mehr als 1300 Paketen Problemlos funktioniert.
-=== Nacharbeit ===
-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.
-==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:
-<code>
-linux:~ # cp /etc/ssl/certs.rpmsave/ldap-cert.pem /etc/ssl/certs
-linux:~ # cp /etc/ssl/certs.rpmsave/mail-cert.pem /etc/ssl/certs
-</code>
-Aber auch danach funktionierte der Samba-Neustart zunächst nicht. Ich konnte dafür zwei Ursachen ausmachen:
-  - Ein Problem bei Nutzung auf die Libraries, die für den Zugriff auf LDB-Dateien notwendig sind. Hier bringt Sernet-Samba eigene Libraries mit.
-  - Unter openSUSE Leap läuft üblicherweise Apparmor. Dieses Problem ist hier im Wiki bereits als Bug beschrieben.
-Zur Lösung von Problem ein habe ich ohne viel herumzuprobieren einfach alle Sernet-Pakete noch einmal installiert. Problem Nummer zwei wird einfach mit der Deaktivierung von Apparmor behoben.
-<code>
-linux:~ # chkconfig -d boot.apparmor
-linux:~ # rcapparmor stop
-</code>
-//**Hinweis:** ich habe hier bewusst auf die klassischen Befehle zurückgegriffen, da in diesem Fall das klassische init-Script des Apparmor Dienstes erhalten geblieben ist und "systemctl" das scheinbar nicht bemerkt.//
-Danach Samba starten:
-<code>
-linux:~ # systemctl start sernet-samba-ad.service
-</code>
-..und überprüfen:
-<code>
-linux:~ # systemctl status sernet-samba-ad.service
-</code>
-==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>
-Das erledigt unser //**afterup**// Script:
-<code>
-linux:~ # afterup
-</code>
-Dann den Nameserver starten:
-<code>
-linux:~ # systemctl start named.service
-</code>
-und natürlich überprüfen.
-==DHCP==
-Da Samba nicht lief, konnte auch der DHCP-Server nicht starten. Das lässt sich jetzt nachholen:
-<code>
-linux:~ # systemctl start dhcpd.service
-</code>
-und natürlich überprüfen.
-==Webserver==
-Auch Apache verweigert nach dem Upgrade den Start. Eine Status-Abfrage des Dienstes liefert das Problem. Der folgende Fehler:
-<code>
-Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration
-</code>
-wurde gleich mehreren Konfigurationsdateien festgestellt:
-<code>
-...
-AH00526: Syntax error on line 8 of /etc/apache2/conf.d/zarafa-webaccess-mobile.conf
-...
-AH00526: Syntax error on line 8 of /etc/apache2/conf.d/zarafa-webaccess.conf
-...
-AH00526: Syntax error on line 29 of /etc/apache2/vhosts.d/invis-sslvh.conf
-...
-AH00526: Syntax error on line 22 of /etc/apache2/vhosts.d/invis-vh.conf
-...
-AH00526: Syntax error on line 22 of /etc/apache2/vhosts.d/z-push_vh.conf
-</code>
-Es haben sich eine Konfigurationsdateien eingeschlichen, die noch nicht mit Apache 2.4 kompatibel ist. Übeltäter ist zum einen der Zarafa-Webaccess. Ich neige dazu auf das etwas antiquierte Stück Software zugunsten der modernen Zarafa-Webapp zu verzichten und zum anderen drei Konfigurationsdateien des invis-Servers selbst.
-Beheben wir zunächst das Problem der Webacces-Dateien händisch. Da beide Dateien im Prinzip identisch sind hier nur ein Beispiel.
-Aus:
-<code>
-Order Allow,Deny
-Allow from all
-</code>
-wird:
-<code>
-Require all granted
-</code>
-Für die Dateien des invis-Servers empfiehlt es sich diese aus den mitgelieferten Beispieldateien neu zu erstellen. Die Beispiele sind unter <file>/usr/share/doc/packages/invisAD-setup/examples/webserver</file> zu finden.
-Erstellen Sie von der alten Datei eine Sicherheitskopie und entnehmen Sie ihr bitte folgende Informationen:
-  * Den Port des SSL-vHosts
-  * Den Server-Namen (DDNS-Name)
-  * Den lokalen Server-Namen
-und tragen Sie die Informationen in die neue Datei aus dem Beispielverzeichnis ein:
-<code>
-....
-<VirtualHost *:httpsport>
-    DocumentRoot "/srv/www/htdocs/portal"
-    ServerName your.ddns-domain.net
-...
-# Deeplinks verhindern
-    SetEnvIfNoCase Referer "^http://invis.invis-net.loc" dontblock
-    SetEnvIfNoCase Referer "^https://your.ddns-domain.net" dontblock
-...
-</code>
-Das Ergebnis könnte so aussehen:
-<code>
-....
-<VirtualHost *:53532>
-    DocumentRoot "/srv/www/htdocs/portal"
-    ServerName meinefirma.dyndns.net
-...
-# Deeplinks verhindern
-    SetEnvIfNoCase Referer "^http://invis.firma-net.loc" dontblock
-    SetEnvIfNoCase Referer "^https://meinefirma.dyndns.net" dontblock
-...
-</code>
-Kopieren Sie die neue Datei nach: <file>/etc/apache2/vHosts.d</file>
-Verfahren Sie mit den weiteren Dateien auf die gleiche Weise. In der vHost Konfiguration des z-Push Dienstes hat sich noch ein Bug eingeschlichen, den Sie jetzt gleich mit beheben können. Es wurden darin für Access- und Erro-Log die gleiche Datei angegeben. Benennen Sie die Datei für das Zugriffsprotokoll einfach um:
-<code>
-    ServerName meinefirma.dyndns.net
-    SSLEngine On
-    ErrorLog /var/log/apache2/z-push-error.log
-    CustomLog /var/log/apache2/z-push-access.log common
-</code>
-In dieser und der Datei des Standard-vHosts ist jeweils nur der "ServerName" ist lediglich anzupassen. Achten Sie darauf, dass bei Standard-vHost (invis-vh.conf) als ServerName der interne Hostname Ihres invis-Servers angegeben werden muss.
-Ist alles erledigt, steht auch dem Start des Apache-Webservers nichts mehr im Wege.
-==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-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".
-=== 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.
-====== 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
+===== Spezielle Software Upgrades =====
-===== Konfigurationen migrieren =====
+  - [[invis_server_wiki:upgrade:sernetsamba2ownsamba|Umstieg von Sernet Samba 4.2.x auf Samba 4.5.x Pakete aus dem OBS]]
+  - [[invis_server_wiki:upgrade:owncloudupgrade|ownCloud Upgrade]]
+  - [[invis_server_wiki:upgrade:kopano|Kopano Upgrade 8.4.x -> 8.5.x -> 8.6.x]]
+  - [[invis_server_wiki:upgrade:dehydrated|Let's Encrypt Client dehydrated aktualisieren]]
-===== Datenbanken migrieren =====
+===== Weitere Anleitungen =====
+  - [[invis_server_wiki:upgrade:rescuead|Rettung eines ActiveDirectories]]
+  - [[invis_server_wiki:upgrade:imap-migration|Migration von IMAP Mailkonten]]
-===== Email Bestand migrieren =====
-===== Fileserver-Datenbestand migrieren =====