invis_server_wiki:upgrade

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Nächste Überarbeitung Beide Seiten der Revision
invis_server_wiki:upgrade [2016/04/01 11:52]
flacco [Nacharbeit]
invis_server_wiki:upgrade [2017/04/30 10:02]
flacco [invis-Server Upgrade]
Zeile 5: Zeile 5:
 Für den invis-Server sind dabei folgende Themen von Interesse: Für den invis-Server sind dabei folgende Themen von Interesse:
  
-  - Upgrade von invis-Classic auf invis-AD +  - [[invis_server_wiki:​upgrade:​classic-to-ad|Upgrade von invis-Classic auf invis-AD]] 
-  - Upgrade von invis-AD 10.3 auf Basis von openSUSE 13.1 auf eine neuere invis-AD Version unter openSUSE Leap +  - [[invis_server_wiki:​upgrade:​10.3_13.1-to-10.4_leap|Upgrade von invis-AD 10.3 auf Basis von openSUSE 13.1 auf eine neuere invis-AD Version unter openSUSE Leap]] 
-  - Weiterhin ​von Bedeutung sind Upgrades relevanter Software-Komponenten wie etwa Zarafa oder Sernet-Samba+  - [[invis_server_wiki:​upgrade:​10.4_leap-to-11.0|Manuelles Upgrade ​von 10.4 zu neueren Versionen ab 11.0]] 
 +  ​[[invis_server_wiki:​upgrade:​10.x-to-12.x|Upgrade von invis-AD 10.x nach invis-AD Version 12.x]] 
  
-An dieser Stelle sollte von vorne herein klar sein, dass es kein direktes Upgrade von einem invis-Classic auf einen invis-AD gibt und geben kann. Es gibt aber eine Reihe von Möglichkeiten Daten aus einer alten in eine neue Installation zu migrieren. 
-Die nachfolgenden Beschreibungen beschreiben die ersten beiden Punkte der vorangegangenen Liste. Punkt 3 der Liste ist dabei Teil des nachfolgenden Kapitels. 
  
 ===== invis-AD 10.3 unter openSUSE 13.1 -> invis-AD ab 10.4 unter openSUSE Leap ===== ===== invis-AD 10.3 unter openSUSE 13.1 -> invis-AD ab 10.4 unter openSUSE Leap =====
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. 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. 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 /​srv/​zarafa/​
 linux:~ # chown -R zarafa.zarafa /​var/​log/​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>​ </​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. 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.
Zeile 98: Zeile 107:
 </​code>​ </​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** **ical.cfg**
Zeile 263: Zeile 276:
 Damit sind alle Änderungen vorgenommen und Zarafa ist auf Version 7.2.2 angehoben. ​ 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 ==== ==== "​kleines Update"​ mit dem invis-updater Script ====
  
Zeile 392: Zeile 423:
  
 "​gelöst"​. "​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: Führen Sie jetzt das Script //​**afterup**//​ aus:
Zeile 420: Zeile 461:
 </​code>​ </​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 Sie können sich jetzt mit
Zeile 438: Zeile 479:
 === Clamav === === 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 wurdeliegt 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>​ <​code>​
Zeile 452: Zeile 493:
 </​code>​ </​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>​ <​code>​
Zeile 468: Zeile 511:
  
 ==== Distribution Upgrade openSUSE 13.1 auf openSUSE leap 42.1 ==== ==== Distribution Upgrade openSUSE 13.1 auf openSUSE leap 42.1 ====
 +
 +**Dauer:** ca. 4h (wenn keine Katastrophen eintreten)
  
 An dieser Stelle möchte ich noch einmal an die eingangs erwähnte Datensicherung oder das beiseite Legen einer Festplatte aus einem RAID Verbund erinnern. Ab hier wird es riskant! Erhöht wird das Risiko noch einmal dadurch, dass wir mit openSUSE 13.2 eine Release überspringen,​ die wir für invis-Server nie unterstützt haben. openSUSE selbst erwähnt in den Anleitungen des Projekts immer, dass nur das Upgrade von einer Release zur nächsten unterstützt wird. Hoffen wir also das Beste! An dieser Stelle möchte ich noch einmal an die eingangs erwähnte Datensicherung oder das beiseite Legen einer Festplatte aus einem RAID Verbund erinnern. Ab hier wird es riskant! Erhöht wird das Risiko noch einmal dadurch, dass wir mit openSUSE 13.2 eine Release überspringen,​ die wir für invis-Server nie unterstützt haben. openSUSE selbst erwähnt in den Anleitungen des Projekts immer, dass nur das Upgrade von einer Release zur nächsten unterstützt wird. Hoffen wir also das Beste!
Zeile 639: Zeile 684:
 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. 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 **(und das ist an einem 1. April ein ECHTER Spaß)** und mein System gestartet, was ebenfalls problemlos funktionierte.+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:​ Zum Beheben der Probleme genügte es Grub neu in die MBRs aller Festplatten zu installieren:​
Zeile 650: Zeile 695:
 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. 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 ​zuviel ​des Guten, wenn ein System nach Neuinstallation von mehr als 1300 Paketen Problemlos funktioniert.+...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 === === Nacharbeit ===
Zeile 836: Zeile 881:
 ==Zarafa== ==Zarafa==
  
-Für Zarafa ​ergeben ​sich ebenfalls ​kleinere Probleme.  +Für Zarafa ​ergibt ​sich ebenfalls ​ein kleines ProblemWä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: 
-====== invis-Classic ​-> invis-AD ======+ 
 +<​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** 
 + 
 + 
 + 
 + 
 + 
  
  • invis_server_wiki/upgrade.txt
  • Zuletzt geändert: 2024/07/05 10:52
  • von flacco