Derzeit ist keine selbständige Registrierung möglich.

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
invis_server_wiki:upgrade:13.5_to_14.1 [2019/08/15 06:29]
flacco [Samba Upgrade]
invis_server_wiki:upgrade:13.5_to_14.1 [2019/08/31 09:13] (aktuell)
flacco [Distributions-Upgrade Sprung 1]
Zeile 3: Zeile 3:
 Richtig gelesen, wir lassen invis-Server Version 14.0 aus. Begründet liegt dies in den unverhofft aufgetretenen Probleme mit den in openSUSE Leap enthaltenen Samba-Paketen. Zum Hintergrund. Mit openSUSE Leap 15.0 wurden seitens openSUSE Samba-Pakete mit ActiveDirectory-Domain-Controller Funktion ausgeliefert. Darauf haben wir lange gewartet. Diese nutzen jedoch statt der von den Samba-Entwicklern integrierten Kerberos-Implementation Heimdal, den aus der Distribution stammenden MIT-Kerberos-Server. Richtig gelesen, wir lassen invis-Server Version 14.0 aus. Begründet liegt dies in den unverhofft aufgetretenen Probleme mit den in openSUSE Leap enthaltenen Samba-Paketen. Zum Hintergrund. Mit openSUSE Leap 15.0 wurden seitens openSUSE Samba-Pakete mit ActiveDirectory-Domain-Controller Funktion ausgeliefert. Darauf haben wir lange gewartet. Diese nutzen jedoch statt der von den Samba-Entwicklern integrierten Kerberos-Implementation Heimdal, den aus der Distribution stammenden MIT-Kerberos-Server.
  
-Wie sich in der Praxis herausstellte,​ war das ein riesiges Problem, das Kerberos damit einfach nicht korrekt ​funktioniert. Kurz wir haben in den sauren Apfel gebissen und begonnen wieder eigene Samba-Pakete mit Heimdal-Kerberos zu bauen. Lesen Sie dazu auch unseren Blog-Beitrag **[[https://​blog.invis-server.org/​rolle-rueckwaerts/​|Rolle Rückwärts]]** um die lange Geschichte zu erfahren.+Wie sich in der Praxis herausstellte,​ war das ein riesiges ProblemKerberos ​funktioniert ​damit einfach nicht korrekt. Kurz wir haben in den sauren Apfel gebissen und begonnen wieder eigene Samba-Pakete mit Heimdal-Kerberos zu bauen. Lesen Sie dazu auch unseren Blog-Beitrag **[[https://​blog.invis-server.org/​rolle-rueckwaerts/​|Rolle Rückwärts]]** um die lange Geschichte zu erfahren.
  
 Weiterhin basiert invis-Server 14.1 bereits auf openSUSE Leap 15.1, d.h. es müssen 2 Distributionsupgrades in Folge gemacht werden. Weiterhin basiert invis-Server 14.1 bereits auf openSUSE Leap 15.1, d.h. es müssen 2 Distributionsupgrades in Folge gemacht werden.
  
-//​**Hinweis:​** Die folgende Anleitung setzt voraus, dass Ihr Server definitiv auf dem Stand von Version 13.5 ist, also bereits PHP7 und ownCloud 10.x verwendet. Ist das nicht der Fall müssen Sie zunächst auf Version 13.5 aktualisieren. Eine Anleitung dazu finden Sie hier.//+//​**Hinweis:​** Die folgende Anleitung setzt voraus, dass Ihr Server ​__**definitiv**__ auf dem Stand von Version 13.5 ist, also bereits PHP7 und ownCloud 10.x verwendet. Ist das nicht der Fall müssen Sie zunächst auf Version 13.5 aktualisieren. Eine Anleitung dazu finden Sie **[[https://​wiki.invis-server.org/​doku.php/​invis_server_wiki:​upgrade:​13.5_to_14.1|hier]]**.//
  
 ===== Vorbereitung ===== ===== Vorbereitung =====
Zeile 69: Zeile 69:
  
 Beginnen wir mit dem Herz des Servers, dem ActiveDirectory. ​ Beginnen wir mit dem Herz des Servers, dem ActiveDirectory. ​
 +
 +//​**Achtung:​** Stellen Sie sicher, dass alle Client-PCs bevor Sie beginnen herunter gefahren sind!//
  
 Entfernen Sie zunächst das bisherige Samba-Repository. Ermitteln Sie dazu die Nummer des Repositories:​ Entfernen Sie zunächst das bisherige Samba-Repository. Ermitteln Sie dazu die Nummer des Repositories:​
Zeile 84: Zeile 86:
 </​code>​ </​code>​
  
-Jetzt können Sie das neue Samba-Repository hinzufügen und den Repository-Cache auffrischen:​+Speziell für das Upgrade haben wir eigens ein Samba-Repository erzeugt, welches aktuelle Samba-Pakete auch für openSUSE Leap 42.3 bereit stellt. Die darin enthaltenen Pakete sind nicht für den Dauerbetrieb gedacht, da es kompatibilitätsprobleme mit dem SSSD-Dienst gibt. Die Pakete darin ermöglichen lediglich das Upgrade von Samba auf die Version, die auch von invis-Server 14.1 genutzt wird. 
 + 
 +Jetzt können Sie das neue "​temporäre" ​Samba-Repository hinzufügen und den Repository-Cache auffrischen:​
  
 <​code>​ <​code>​
-invis:~ # zypper ar https://​download.opensuse.org/​repositories/​spins:/​invis:/​15:/stable:/​samba/​openSUSE_Leap_42.3/​spins:​invis:​15:stable:samba.repo+invis:~ # zypper ar https://​download.opensuse.org/​repositories/​spins:/​invis:/​13.5:/​samba/​openSUSE_Leap_42.3/​spins:​invis:​13.5:samba.repo
 invis:~ # zypper ref invis:~ # zypper ref
 </​code>​ </​code>​
Zeile 97: Zeile 101:
 <​code>​ <​code>​
 invis:~ # zypper repos | grep samba invis:~ # zypper repos | grep samba
-20 | spins_invis_15_stable_samba ​    | Samba 4.10 with Heimdal Kerberos ​ (openSUSE_Leap_42.3) ​            | Ja        | (r ) Ja         | Nein+20 | spins_invis_13.5_samba ​    | Samba 4.10 with Heimdal Kerberos ​ (openSUSE_Leap_42.3) ​            | Ja        | (r ) Ja         | Nein
 invis:~ #  invis:~ # 
 </​code>​ </​code>​
Zeile 141: Zeile 145:
 </​code>​ </​code>​
  
-... to be continued+Sind alle Pakete installiert,​ darf Samba noch **nicht** wieder gestartet werdenMit Samba 4.10hat sich die Verzeichnisstruktur unter <​file>/​var/​lib/​samba</​file>​ moderat geändert. D.h. die zuvor angelegte Datensicherung muss in die neue Verzeichnisstruktur wiederhergestellt werden. Für diesen Zweck haben wir ein Script entwickelt. Zwar ist dieses Script im aktuellen invisAD Setup Paket enthalten, leider stehen dieses Paket erst nach Umstrukturierung der Software-Repositories wie nachfolgend beschrieben zur Verfügung. Um das Samba-Upgrade jetzt dennoch abschließen zu können stellen wir das Script auch hier zum direkten Download zur Verfügung. Laden Sie die Datei wie folgt auf Ihren Server herunter: 
 + 
 +<​code>​ 
 +invis:~ # wget -O upgradead.gz http://​wiki.invis-server.org/​lib/​exe/​fetch.php/​invis_server_wiki:​upgradead.gz 
 +</​code>​ 
 + 
 +Entzippen Sie die Datei: 
 + 
 +<​code>​ 
 +invis:~ # gunzip upgradead.gz 
 +</​code>​ 
 + 
 +...und machen Sie sie ausführbar:​ 
 + 
 +<​code>​ 
 +invis:~ # chmod +x upgradead 
 +</​code>​ 
 + 
 +Jetzt können Sie damit Ihr AD wiederherstellen. Sie benötigen dazu den Pfad zur AD-Sicherung. Sie finden die Sicherungen und <​file>/​srv/​shares/​archiv/​sicherungen/​vollsicherungen/​ad/</​file>​ Sie benötigen von dort die aktuellste Datei, was anhand des Datums im Dateinamen leicht zu erkennen ist. Führen Sie das Script wie folgt aus: 
 + 
 +<​code>​ 
 +invis:~ # ./upgradead /​srv/​shares/​archiv/​sicherungen/​vollsicherungen/​ad/​Samba_20190815-075033.tar.gz 
 +</​code>​ 
 + 
 +Zur Fehlervermeidung stellt das Script nach der Ausführung eine "Sind Sie sicher?"​ Abfrage, die zu bejahen ist. Das Script startet den Samba-AD-DC Dienst automatisch wieder. Sie können jetzt verschiedene Tests durchführen. Z.B.: Anmelden an einem Windows-PC, Anmelden am invis-Portal,​ DNS-Abfragen mit //**dig**// usw. 
 + 
 +Klappt alles ist das Samba-Upgrade muss der neue Samba-Domain-Controller Dienst zum automatischen Start vorgesehen werden. 
 + 
 +<​code>​ 
 +invis:~ # systemctl enable samba-ad-dc.service 
 +</​code>​ 
 + 
 +Damit ist das Samba-Upgrade abgeschlossen. 
 + 
 +===== Distributions-Upgrade Sprung 1 ===== 
 + 
 +Mit dem Sprung auf invis-Server 14.0 muss auf openSUSE Leap 15.0 aktualisiert werden. Die Vorgehensweise dazu ist denkbar einfach. Zunächst müssen Sie Ihre Software-Repositories daran anpassen. Es kann auch nicht schaden zunächst mal alles zu sichern, so wie es ist: 
 + 
 +<​code>​ 
 +invis:~ # cp -R /​etc/​zypp/​repos.d /​etc/​zypp/​repos.d.bak 
 +</​code>​ 
 + 
 +Prüfen wir jetzt, ob ein CD/DVD Repository bei der Installation verwendet wurde. Ist das der Fall, kann es gelöscht werden: 
 + 
 +<​code>​ 
 +invis:~ # grep "​cd://"​ /​etc/​zypp/​repos.d/​* 
 +/​etc/​zypp/​repos.d/​openSUSE-42.3-0.repo:​baseurl=cd:///?​devices=/​dev/​disk/​by-id/​ata-TSSTcorp_CDDVDW_SH-224BB_R8WS68BCB00TYX 
 +invis:~ # rm /​etc/​zypp/​repos.d/​openSUSE-42.3-0.repo 
 +</​code>​ 
 + 
 +Weiterhin verfügt Ihr invis-Server über zwei weitere Repositories unseres Projektes. Da wir für Version 14.x des invis-Servers eine neue Repository-Struktur aufgebaut haben, können diese beiden Repositories entfernt und dann durch die neuen Repositories ersetzt werden: 
 + 
 +<​code>​ 
 +invis:~ # zypper repos |grep spins_invis 
 +20 | spins_invis_13.5_samba ​    | Samba 4.10 with Heimdal Kerberos ​ (openSUSE_Leap_42.3) ​            | Ja        | (r ) Ja         | Nein           
 +21 | spins_invis_common ​             | Common packages for invis-Server stable & unstable (openSUSE_42.3) | Ja        | (r ) Ja         | Ja             
 +22 | spins_invis_stable ​             | Stable Packages for invis-servers (openSUSE_Leap_42.3) ​            | Ja        | (r ) Ja         | Ja 
 +</​code>​ 
 + 
 +Zu entfernen sind also die Repositories Nr. 21 und 22: 
 + 
 +<​code>​ 
 +invis:~ # zypper rr 22 
 +Repository '​Production Project for the openSUSE invis-Server Spin (openSUSE_Leap_42.3)'​ entfernen .....................................[fertig] 
 +Repository '​Production Project for the openSUSE invis-Server Spin (openSUSE_Leap_42.3)'​ wurde entfernt. 
 +invis:~ # zypper rr 21 
 +Repository '​Common packages for invis-Server stable & unstable (openSUSE_42.3)'​ entfernen .............................................[fertig] 
 +Repository '​Common packages for invis-Server stable & unstable (openSUSE_42.3)'​ wurde entfernt. 
 +invis:~ # zypper rr 20 
 +Repository 'Samba 4.10 with Heimdal Kerberos ​ (openSUSE_Leap_42.3)'​ entfernen .............................................[fertig] 
 +Repository 'Samba 4.10 with Heimdal Kerberos ​ (openSUSE_Leap_42.3)'​ wurde entfernt. 
 + 
 +invis:~ # 
 +</​code>​ 
 + 
 +Fügen wir jetzt die neuen Repositories hinzu: 
 + 
 +<​code>​ 
 +invis:~ # zypper ar https://​download.opensuse.org/​repositories/​spins:/​invis:/​15:/​common/​openSUSE_Leap_15.0/​spins:​invis:​15:​common.repo 
 +... 
 +invis:~ # zypper ar https://​download.opensuse.org/​repositories/​spins:/​invis:/​15:/​stable/​openSUSE_Leap_15.0/​spins:​invis:​15:​stable.repo 
 +... 
 +invis:~ # zypper ar https://​download.opensuse.org/​repositories/​spins:/​invis:/​15:/​stable:/​samba/​openSUSE_Leap_15.0/​spins:​invis:​15:​stable:​samba.repo 
 +</​code>​ 
 + 
 +Wenn Sie Kopano auf Basis einer offiziellen Kopano-Subskription einsetzen müssen Sie eine der Repository-Dateien manuell anpassen. Editieren Sie die Datei: <​file>/​etc/​zypp/​repos.d/​Kopano-openSUSE_limited.repo</​file>,​ indem Sie die mit "​baseurl="​ beginnende Zeile auf folgende URL abändern:​ 
 + 
 +<​code>​ 
 +[Kopano-openSUSE-15.0_limited] 
 +name=Kopano-openSUSE-15.0_limited 
 +enabled=1 
 +autorefresh=1 
 +baseurl=https://​download.kopano.io/​limited/​core:/​final/​openSUSE_Leap_15.0 
 +path=/ 
 +type=rpm-md 
 +keeppackages=0 
 +</​code>​ 
 + 
 +Dieses Kopano-Repository verlangt Zugangsdaten,​ diese wurden während des Server-Setups eingegeben und in <​file>/​root/​.zypp/​credentials.cat</​file>​ hinterlegt. Sie können in dieser Datei ebenfalls die URL zum Repository anpassen oder die Zugangsdaten beim nächsten **//zypper ref//** Kommando erneut eingeben. In der genannten Datei muss die erste Zeile geändert werden: 
 + 
 +<​code>​ 
 +[https://​download.kopano.io/​limited/​core:/​final/​openSUSE_Leap_15.0/​]] 
 +username = FSP Computer und Netzwerke 
 +password = supergeheim 
 +... 
 +</​code>​ 
 + 
 +Abschließend sind noch die openSUSE Versionsnummern in den verbleibenden Repository-Dateien zu ersetzen: 
 + 
 +<​code>​ 
 +invis:~ # sed -i '​s/​42\.3/​15\.0/​g'​ /​etc/​zypp/​repos.d/​* 
 +</​code>​ 
 + 
 +Jetzt kann das Distributions-Upgrade durchgeführt werden: 
 + 
 +<​code>​ 
 +invis:~ # zypper ref 
 +... 
 +invis:~ # zypper dup 
 +</​code>​ 
 + 
 +Stimmen Sie dem Vorschlag den //**zypper dup**// macht zu, danach beginnt das Paket-Upgrade. 
 + 
 +//​**Hinweis:​** Je nach Stand Ihrer Kopano-Installation,​ kann es sein, dass das Upgrade einige Paketkonflikte mit sich bringt. Lösen Sie diese Pakete in dem Sie jeweils die Deinstallation der älteren Pakete (vermutlich Version 8.6.9) als Lösung auswählen. In unseren Tests war dies in der Regel Lösung 2.// 
 + 
 +//​**Hinweis:​** Weiterhin wird **zypper** einige Dateikonflikte melden. Erlauben Sie das Ersetzen der Dateien mit "​ja"​ um das Distributionsupgrade abzuschließen.//​ 
 + 
 +Mit dem Distributionsupgrade wird eine aktuelle Version von MariaDB installiert,​ was ein Upgrade der Tabellenstrukturen erfordert. Normalerweise geschieht dies mit einem Neustart des Dienstes automatisch. Je nach Datenbankgröße kann dies aber so lange dauern, dass systemd die Geduld verliert und in einen Timeout läuft. Daher sollte das Upgrade manuell durchgeführt werden:  
 + 
 +<​code>​ 
 +invis:~ # /​usr/​lib/​mysql/​mysql-systemd-helper upgrade 
 +</​code>​ 
 + 
 +Starten Sie den Server jetzt neu. 
 + 
 +===== Distributions-Upgrade Sprung 2 ===== 
 + 
 +Der Sprung von openSUSE Leap 15.0 nach 15.1 ist deutlich unkomplizierter als der vorherige Schritt. Passen Sie zunächst die Repositories an: 
 + 
 +<​code>​ 
 +invis:~ # sed -i '​s/​15\.0/​15\.1/​g'​ /​etc/​zypp/​repos.d/​* 
 +</​code>​ 
 + 
 +Dabei werden auch die Kopano Repositories aktualisiert,​ leider stehen derzeit noch keine Repositories für Leap 15.1 zur Verfügung, entsprechend müssen hier die Änderungen wieder zurück genommen werden. 
 + 
 +Ändern Sie in der Datei <​file>/​etc/​zypp/​repos.d/​Kopano-openSUSE_limited.repo</​file>​ die openSUSE Versionsnummer wieder auf 15.0 zurück: 
 + 
 +<​code>​ 
 +invis:~ # sed -i '​s/​15\.1/​15\.0/​g'​ /​etc/​zypp/​repos.d/​Kopano-openSUSE_limited.repo 
 +</​code>​ 
 + 
 +Jetzt kann das Upgrade gestartet werden: 
 + 
 +<​code>​ 
 +invis:~ # zypper ref 
 +... 
 +invis:~ # zypper dup 
 +</​code>​ 
 + 
 +Diesmal treten keine Paketkonflikte auf, ggf. aber wieder Dateikonflikte. Erlauben Sie das überschreiben der alten Dateien mit "​ja"​. Danach starten Sie das System neu. 
 + 
 +===== invis-Setup aktualisieren ===== 
 + 
 +Durch den Wechsel der Repository-Struktur für invis-Server ab Version 14.0 wird beim Distributionsupgrade das invis-Server Setup-Paket gelöscht. Dies ist jetzt neu zu installieren:​ 
 + 
 +<​code>​ 
 +invis:~ # zypper in invisAD-setup-14 
 +</​code>​ 
 + 
 +Nach der Installation sind zunächst ein paar Anpassungen der Konfiguration erforderlich,​ zunächst sind allerdings die vorherigen Konfigurationen wieder herzustellen:​ 
 + 
 +<​code>​ 
 +invis:~ # old /​etc/​invis/​invis.conf 
 +invis:~ # cp /​etc/​invis/​invis.conf.rpmsave /​etc/​invis/​invis.conf 
 +... 
 +invis:~ # old /​etc/​invis/​invis-pws.conf 
 +invis:~ # cp /​etc/​invis/​invis-pws.conf.rpmsave /​etc/​invis/​invis-pws.conf 
 +</​code>​ 
 + 
 +Für die neue Version des Samba-Servers haben wir neue Apparmor-Profile erstellt, die Sie installieren müssen: 
 + 
 +<​code>​ 
 +invis:~ # cp /​usr/​share/​sine/​templates/​samba_ad/​apparmor/​* /​etc/​apparmor.d/​ 
 +</​code>​ 
 + 
 +Starten Sie Apparmor jetzt neu: 
 + 
 +<​code>​ 
 +invis:~ # systemctl restart apparmor.service 
 +</​code>​ 
 + 
 +==== Konfigurationsanpassung invis Server ==== 
 + 
 +Passen Sie jetzt in der Haupkonfigurationsdatei <​file>/​etc/​invis/​invis.conf</​file>​ die Versionsnummer des invis-Server-Setups an: 
 + 
 +<​code>​ 
 +#​invis-server Version 
 +invisVersion:​14.1 
 +</​code>​ 
 + 
 +Suchen Sie jetzt in der genannten Datei nach einer mit der Direktive "​avCheck"​ beginnenden Zeile und ändern Sie sie wie folgt ab: 
 + 
 +<​code>​ 
 +# [all|profiles|none] 
 +avCheck:​none 
 +</​code>​ 
 + 
 +Statt nur "​ja"​ oder "​nein"​ bezogen auf regelmäßige Virenprüfungen im Fileserver, können Sie jetzt entscheiden,​ ob alles, nichts oder lediglich die Benutzerprofile geprüft werden.  
 + 
 +Gehen Sie an eine regelmäßigen Virenprüfung vorsichtig heran. Je nach Datenmenge laufen diese Prüfungen sehr lange und erzeugen hohe Systemauslastungen. Wir nutzten dieses Feature in der Praxis oft gar nicht, viel wichtiger sind aktuelle und aktive Virenscanner auf den Clients. 
 + 
 +Jetzt ist die Datei noch mit neuen Konfigurationen zu ergänzen. Fügen Sie folgende Blöcke hinzu: 
 + 
 +<​code>​ 
 +# Disk Warranty Time - Garantiezeitraum der eingesetzten Festplatten 
 +# 5 Jahre = 43800 Stunden (Gilt für die meisten 24/7 Festplatten) 
 +# 3 Jahre = 26280 Stunden (Gilt für gute Consumer Festplatten) 
 +# 1 Jahr = 14140 Stunde (Gilt für Low-Budged Festplatten) 
 +diskWarrantyTime:​43800 
 +</​code>​ 
 + 
 +Das regelmäßig laufende Tool //​**diskchecker**//​ überprüft jetzt auch die absolvierten Betriebsstunden der eingesetzten Festplatten und setzt diese mit der vom Hersteller garantierten Laufzeit in Beziehung. Passen Sie die Konfiguration entsprechend den von Ihnen eingesetzten Festplatten an. 
 + 
 +<​code>​ 
 +# Pfad zu den Verzeichnisvorlagen der Gruppenverzeichnisse 
 +groupDirTemplatePath:/​srv/​shares/​media/​portal/​verzeichnisvorlagen 
 +</​code>​ 
 + 
 +Hier müssen Sie nichts weiter unternehmen. Beim Anlegen von Gruppen mit Gruppenarbeitsverzeichnissen,​ können diese jetzt auf Basis von Verzeichnisvorlagen erzeugt werden. 
 + 
 +==== Konfigurationsanpassung invis Portal ==== 
 + 
 +Die Anpassungen der invis-Portal Konfiguration sind zwar nicht zwingend, sollten aber dennoch durchgeführt werden. Anzupassen ist die Datei <​file>/​etc/​invis/​portal/​config.php</​file>​ 
 + 
 +Passen Sie zunächst die Versionsnummern am Anfang der Datei an: 
 + 
 +<​code>​ 
 +... 
 +$GROUPWARE = '​kopano';​ 
 +$INVISVERSION = '​14.1';​ 
 +$OPENSUSEVERSION = '​15.1';​ 
 +... 
 +</​code>​ 
 + 
 +Jetzt sind auch hier ein paar neue Konfigurationen hinzuzufügen. Nachfolgend sind die Zeilen immer mit der bereits vorhandenen vorhergehenden Zeile gezeigt: 
 + 
 +<​code>​ 
 +... 
 + ​$SFU_GUID_BASE = '​20000';​ 
 + ​$GROUP_DIR_TEMPLATE_PATH = '/​srv/​shares/​media/​portal/​verzeichnisvorlagen';​ 
 +... 
 +</​code>​ 
 + 
 +In der bereits vorhandenen Konfigurationsdirektive "​$SMB_GROUPSTOEXTEND"​ ist der Wert "​diradmins"​ hinzuzufügen:​ 
 + 
 +<​code>​ 
 +... 
 +$SMB_GROUPSTOEXTEND = array("​Domain Users",​ "​Domain Admins",​ "​Domain Guests",​ "​Archiv",​ "​Verwaltung",​ "​diradmins"​);​ 
 +... 
 +</​code>​ 
 + 
 +Am Ende des SMB-Blocks ist folgende Zeile zu ergänzen:​ 
 + 
 +<​code>​ 
 +... 
 + ​$SMB_FILESERVER = strtoupper("​null"​);​ 
 + ​$SMB_DEFAULT_LOGON_SCRIPT = ("​user.cmd"​);​ 
 +... 
 +</​code>​ 
 + 
 +In der Liste der via invis-Portal zu verwaltenden Dienste ist der neue Firewall-Daemon einzufügen:​ 
 + 
 +<​code>​ 
 +... 
 +        array('​fetchmail','​Emails abholen'​),​ 
 +        array('​firewalld','​Firewall'​),​ 
 +        array('​freshclam',​ '​Virenscanner Updater'​) 
 +... 
 +</​code>​ 
 + 
 +Weiterhin hat sich der Name des Domaincontroller-Daemons geändert. Aus: 
 + 
 +<​code>​ 
 +... 
 +        array('​samba',​ '​Active Directory'​),​ 
 +... 
 +</​code>​ 
 + 
 +wird: 
 + 
 +<​code>​ 
 +... 
 +        array('​samba-ad-dc',​ '​Active Directory'​),​ 
 +... 
 +</​code>​ 
 + 
 +Damit ist auch die Konfiguration des invis-Portals auf Stand. 
 + 
 +Legen Sie abschließend im Administrationsbereich des invis-Portals die Gruppe "​diradmins"​ an, sie benötigt **kein** Gruppenarbeitsverzeichnis und sollte vom Typ "​Team"​ sein. 
 + 
 +Mitglieder der Gruppe haben die Berechtigung Verzeichnisvorlagen für die Gruppenarbeitsverzeichnisse anzulegen und zu bearbeiten. 
 +==== Zugriffsrechte der Netzwerkfreigaben wiederherstellen ==== 
 + 
 +Dieser Schritt wird ainfach mit dem Toolbox-Script //​**afterup**//​ erledigt: 
 + 
 +<​code>​ 
 +invis:~ # afterup 
 +</​code>​ 
 + 
 +Damit ist das invis-Server Setup auf aktuellem Stand. 
 + 
 +===== Inbetriebnahme des Firewall-Daemons (firewalld) ===== 
 + 
 +Mit Erscheinen der openSUSE Leap Version 15.0 ist SUSE vom jahrelang selbst entwickelten Firewall-System "​**SuSEfirewall2**"​ auf den von RedHat entwickelten "​**firewalld**"​ umgestiegen. Diesen Umstieg müssen Sie mit Hilfe von //​**sine2**//​ vollziehen. 
 + 
 +Bevor es los geht, sollten Sie dafür sorgen, dass die SuSEfirewall2 nach einem Reboot nicht mehr gestartet wird: 
 + 
 +<​code>​ 
 +invis:~ # systemctl disable SuSEfirewall2.service 
 +</​code>​ 
 + 
 +...und deaktivieren Sie sie: 
 + 
 +<​code>​ 
 +invis:~ # systemctl disable SuSEfirewall2.service 
 +</​code>​ 
 + 
 +Um das sine2-Firewall-Modul aufrufen zu können bedarf es eines Tricks. Normalerweise ist dieses Modul kein optionales Modul, kann also nicht einzeln aufgerufen werden. Genau das muss für den nächsten Schritt geändert werden. Öffnen Sie dazu in Ihrem Editor folgende Datei: <​file>/​usr/​share/​sine/​registered-modules.txt</​file>​ 
 + 
 +Ändern Sie darin die Zeile: 
 + 
 +<​code>​ 
 +... 
 +13:​d:​firewall 
 +... 
 +</​code>​ 
 + 
 +auf 
 + 
 +<​code>​ 
 +... 
 +13:​o:​firewall 
 +... 
 +</​code>​ 
 + 
 +ab. 
 + 
 +Jetzt können Sie das Firewall-Modul direkt aufrufen. Es kümmert sich um alles weitere: 
 + 
 +<​code>​ 
 +invis:~ # sine2 firewall 
 +</​code>​ 
 + 
 +Damit ist auch der neue Firewall-Daemon in Betrieb genommen. 
 +===== Kopano wieder in Betrieb nehmen ===== 
 + 
 +Stoppen Sie zunächst ggf. laufende Kopano-Dienste:​ 
 + 
 +<​code>​ 
 +invis:~ # runkopano stop 
 +</​code>​ 
 + 
 +Nach den verschiedenen Upgrades fehlt Kopano unter Umständen das Recht auf seine Schlüsseldatei <​file>/​etc/​invis/​certs/​kopano.pem</​file>​ zuzugreifen. Evtl. befindet sich in der Konfiguration des Serverdienstes noch ein falscher Pfad, der Systembenutzer "​kopano"​ muss mittlerweile Mitglied der Gruppe "​pkeys"​ sein und die Datei "​kopano.pem"​ befindet ​ sich noch gar nicht am genannten Ort. Abhängig ist dies vom Ausgangspunkt des Upgrades. 
 + 
 +Letzteres lässt sich einfach beheben: 
 + 
 +<​code>​ 
 +invis:~ # mkkopanokey 
 +</​code>​ 
 + 
 +Diesen Befehl können Sie einfach auf Verdacht ausführen, er richtet keinen Schaden an. 
 + 
 +Um Kopano in die Gruppe "​pkeys"​ aufzunehmen bearbeiten Sie die Datei <​file>/​etc/​groups</​file>​ unter Verwendung des Kommandos //​**vigr**//​ (vi Kenntnisse vorausgesetzt!). Suchen Sie die Zeile "​pkeys"​ und ergänzen Sie sie wie folgt: 
 + 
 +<​code>​ 
 +... 
 +pkeys:​x:​998:​wwwrun,​kopano 
 +... 
 +</​code>​ 
 + 
 +Kontrollieren Sie jetzt noch in <​file>/​etc/​kopano/​server.cfg</​file>​ in Zeile (ca.) 195 ob der korrekte Pfad (siehe oben) angegeben ist. 
 + 
 +Testen Sie jetzt, ob sich der Kopano-Serverdienst starten lässt: 
 + 
 +<​code>​ 
 +invis:~ # systemctl start kopano-server.service 
 +</​code>​ 
 + 
 +Kontrollieren Sie dies einfach mit: 
 + 
 +<​code>​ 
 +invis:~ # systemctl status kopano-server.service 
 +</​code>​ 
 + 
 +Läuft der Server-Dienst,​ müssen Anpassungen an der Datenbank vorgenommen werden. Dies erledigt das Kommando: 
 + 
 +<​code>​ 
 +invis:~ # kopano-dbadm usmp 
 +</​code>​ 
 + 
 +Je nach Datenbankgröße kann das eine ganze Weile dauern. Starten Sie im Anschluss daran den Kopano-Server-Dienst neu: 
 + 
 +<​code>​ 
 +invis:~ # systemctl restart kopano-server.service 
 +</​code>​ 
 + 
 +Kontrollieren Sie das Ende der Kopano-Server Logdatei auf Fehler: 
 + 
 +<​code>​ 
 +invis:~ # less /​var/​log/​kopano/​server.log 
 +</​code>​ 
 + 
 +Im Idealfall ist alles OK. 
 + 
 +Nach dem Upgrade fehlt für den Kopano-Search Dienst ein Python3 Paket, installieren Sie es wie folgt nach: 
 + 
 +<​code>​ 
 +invis:~ # zypper in python3-magic 
 +</​code>​ 
 + 
 +Danach sollte sich auch dieser Dienst starten lassen: 
 + 
 +<​code>​ 
 +invis:~ # systemctl start kopano-search.service 
 +</​code>​ 
 + 
 +Auch dies sollten Sie überprüfen:​ 
 + 
 +<​code>​ 
 +invis:~ # systemctl status kopano-search.service 
 +</​code>​ 
 + 
 +Der Kopano-Gateway Dienst benötigt eine neue Konfigurationsdatei. Hier können Sie einfach unsere Vorlage aus dem invis-Setup-Paket nutzen. Sichern Sie zuvor vorsichtshalber die bestehende Datei: 
 + 
 +<​code>​ 
 +invis:~ # old /​etc/​kopano/​gateway.cfg  
 +moving /​etc/​kopano/​gateway.cfg ​to /​etc/​kopano/​gateway.cfg-20190829 
 +invis:~ # cp /​usr/​share/​sine/​templates/​groupware/​kopano/​gateway.cfg /​etc/​kopano/​ 
 +</​code>​ 
 + 
 +Starten Sie jetzt den Gateway-Dienst und kontrollieren Sie ihn: 
 + 
 +<​code>​ 
 +invis:~ # systemctl start kopano-gateway.service 
 +</​code>​ 
 + 
 +Auch dies sollten Sie überprüfen:​ 
 + 
 +<​code>​ 
 +invis:~ # systemctl status kopano-gateway.service 
 +</​code>​ 
 + 
 +Auch dabei ist bei unseren Tests nichts schief gegangen. 
 + 
 +Gehen Sie identisch beim Kopano-ical Dienst vor: 
 + 
 +<​code>​ 
 +invis:~ # old /​etc/​kopano/​ical.cfg  
 +moving /​etc/​kopano/​ical.cfg to /​etc/​kopano/​ical.cfg-20190829 
 +invis:~ # cp /​usr/​share/​sine/​templates/​groupware/​kopano/​ical.cfg /​etc/​kopano/​ 
 +</​code>​ 
 + 
 +<​code>​ 
 +invis:~ # systemctl start kopano-ical.service 
 +</​code>​ 
 + 
 +Auch dies sollten Sie überprüfen:​ 
 + 
 +<​code>​ 
 +invis:~ # systemctl status kopano-ical.service 
 +</​code>​ 
 + 
 +Zu guter Letzt fehlt noch eine zusätzliche Konfigurationsdatei,​ die Sie ebenfalls aus unseren Vorlagen beziehen können: 
 + 
 +<​code>​ 
 +invis:~ # cp /​usr/​share/​sine/​templates/​groupware/​kopano/​admin.cfg /​etc/​kopano/​ 
 +</​code>​ 
 + 
 +Sollten Sie die kommerzielle Kopano-Erweiterung "​Files"​ installiert haben müssen Sie noch ein PHP-Paket austauschen:​ 
 + 
 +<​code>​ 
 +invis:~ # zypper in php7-smbclient 
 +</​code>​ 
 + 
 +Das zu ersetzende Paket wird dabei automatisch deinstalliert. Starten Sie anschließend den Apache-Webserver neu: 
 + 
 +<​code>​ 
 +invis:~ # systemctl restart apache2.service 
 +</​code>​ 
 + 
 +Sie können jetzt noch einmal alle Kopano-Dienste im Block, stoppen, starten und überprüfen:​ 
 + 
 +<​code>​ 
 +invis:~ # runkopano stop 
 +invis:~ # runkopano start 
 +invis:~ # runkopano status 
 +</​code>​ 
 + 
 +Laufen alle Dienst, ist auch das Kopano Upgrade abgeschlossen. 
 + 
 +===== Kimai aktualisieren ===== 
 + 
 +Wenn Sie die Zeiterfassungssoftware Kimai auf dem invis-Server nutzen, muss dessen Datenbank an die während des Upgrades installierte neue Kimai-Version angepasst werden. Dieser Vorgang läuft völlig automatisch ab. Öffnen Sie Kimai einfach wie gewohnt und folgen Sie den Anweisungen. 
 + 
 +===== ownCloud aktualisieren ===== 
 + 
 +Zur Aktualisierung von ownCloud (falls erforderlich) finden Sie hier im Wiki einen eigenen [[https://​wiki.invis-server.org/​doku.php/​invis_server_wiki:​upgrade:​owncloudupgrade|Artikel]]. 
 + 
 +Normalerweise sollten aber folgende Kommandos ausreichen um ownCloud auf Stand zu bringen: 
 + 
 +<​code>​ 
 +invis:~ # sudo -u wwwrun /​srv/​www/​htdocs/​owncloud/​occ upgrade 
 +... 
 +invis:~ # sudo -u wwwrun /​srv/​www/​htdocs/​owncloud/​occ maintenance:​mode --off 
 +</​code>​ 
 + 
 +**Bleibt nur noch: Viel Spaß mit Ihrem invis-Server 14.1!**

QR-Code
QR-Code invis_server_wiki:upgrade:13.5_to_14.1 (erstellt für aktuelle Seite)