invis_server_wiki:upgrade:14.1_to_14.2 [invis-server.org]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== invis-Server Upgrade von Version 14.1 auf 14.2 ======

//**Der wichtige Hinweis vorweg:** invis-Server Version 14.2 ist sowohl unter openSUSE Leap 15.1 als auch 15.2 lauffähig. Eingeschränkt wird dies allerding dadurch, dass es noch keine offiziellen Kopano Pakete für Leap 15.2 gibt. D.h. wer eine subskribierte Kopano-Version nutzt, kann zwar auf 14.2 upgraden, muss aber bei Leap 15.1 bleiben. D.h. Das Distributions-Upgrade muss zunächst ausgelassen werden.//

===== Vorbereitung =====

Sichern Sie alle Datenbanken des Servers. Sie können dafür die Tools des invis-Servers nutzen:

**Kopano**

Führen Sie hier beide Sicherungswege durch:

<code>
invis:~ # kdbdump
...
invis:~ # kbackup
</code>

**Weitere Datenbanken**

<code>
invis:~ # alldump
</code>

**Dokuwiki**

<code>
invis:~ # dwdatasnapshot
</code>

Da mit der neuen auf MIT-Kerberos basierenden Samba-Version 4.7. die im Laufe des Upgrades installiert wird, werden überarbeitete AppArmor Profile notwendig. Um negative Effekte auf das Upgrade durch mögliche AppArmor-Blockaden vorzubereiten wird AppArmor vor dem Upgrade deaktiviert.

<code>
invis:~ # systemctl stop apparmor.service
...
invis:~ # systemctl disable apparmor.service
</code>

Im späteren Verlauf des Upgrades wird AppArmor mit neuen Profilen wieder aktiviert.

Auch der Email-Abruf sollte vor dem Upgrade deaktiviert werden:

<code>
invis:~ # systemctl stop fetchmail.service
invis:~ # systemctl disable fetchmail.service
</code>

Auch der Samba Domain-Controller wird abgeschaltet.

<code>
invis:~ # systemctl stop samba-ad-dc.service
</code>

Sichern Sie jetzt noch das ActiveDirectory:

**ActiveDirectory**

<code>
invis:~ # adbackup
</code>

===== Linux-Updates & Software-Upgrades =====

Spielen sie zunächst anstehende Sicherheits-Updates für openSUSE Leap ein:

<code>
invis:~ # zypper ref
...
invis:~ # you
...
</code>

Aktualisieren Sie anschließend entscheidende Software des Servers. Allem voran Kopano und ownCloud. Gehen Sie entsprechend der Anleitungen hier im Wiki vor.
===== Samba  & Distributions-Upgrade =====

==== Samba-Pakete aktualisieren ====

Beginnend mit Samba-Version 4.13 stellen wir für jede von uns erfolgreich getestete Samba-Version ein eigenes Sub-Repository im Stable-Zweig unserer openSUSE-Build-Server Repositiries zur Verfügung. Dies verhindert versehentliche Upgrades und ermöglicht das Upgraden von Samba weitgehend unabhängig vom Rest des invis-Servers.

D.h. vor dem Upgrade muss das Samba-Repository ausgetauscht werden. Ermitteln Sie zunächst die Nummer des vorhandenen Samba-Repositories:

<code>
invis:~ # zypper repos |grep samba
17 | spins_invis_15_stable_samba | Samba 4.10 with Heimdal Kerberos (openSUSE_Leap_15.1)                                    | Ja        | (r ) Ja         | Ja
</code>

Dieses Repository, im Beispiel Repository Nummer **17**, muss zunächst entfernt werden:

<code>
invis:~ # zypper rr 17
</code>

Fügen Sie jetzt das aktuelle Repository hinzu:

<code>
invis:~ # zypper ar https://download.opensuse.org/repositories/spins:/invis:/15:/stable:/samba:/413/openSUSE_Leap_15.1/spins:invis:15:stable:samba:413.repo
invis:~ # zypper ref
</code>

Überprüfen Sie jetzt erneut die Nummer des Samba-Repositories, gut möglich, dass das neue Repository eine andere Nummer trägt:

<code>
invis:~ # zypper repos |grep samba
16 | spins_invis_15_stable_samba_413 | Stable Samba Packages with Heimdal Kerberos V. 4.13 (openSUSE_Leap_15.1)
</code>

Jetzt können Sie die Samba Pakete upgraden:

<code>
invis:~ # zypper dup --from 16 --allow-vendor-change
</code>

Danach kann der Samba-Domain-Controller wieder gestartet werden:

<code>
invis:~ # systemctl start samba-ad-dc.service
</code>

Vermutlich wird der Samba-Domain-Controller nicht starten. Das liegt daran, dass die Pakete einen neueren Kernel erwarten als openSUSE 15.1 liefert. D.h.: Jetzt ist zunächst das Distributions-Upgrade durchzuführen. Das läuft nach bekanntem Schema ab:

==== Distributions-Upgrade 1====

Vor dem eigentlichen Upgrade ist das ownCloud-Repository auszutauschen:

Zunächst ist das vorhandene Repository zu löschen:

<code>
invis:~ # zypper repos |grep -i owncloud
 1 | ce_10.2 | Owncloud Server 10.2 (openSUSE_Leap_15.1) | Ja  | ( p) Ja  | Nein
invis:~ # zypper rr 1
</code>

Jetzt muss die neue Repository-Datei "owncloud.repo" in <file>/etc/zypp/repos.d/</file> angelegt werden:

<code>
[isv_ownCloud_server_10]
name=Latest 10.x packages (openSUSE_Leap_15.2)
type=rpm-md
baseurl=https://download.opensuse.org/repositories/isv:/ownCloud:/server:/10/openSUSE_Leap_15.2/
gpgcheck=1
gpgkey=https://download.opensuse.org/repositories/isv:/ownCloud:/server:/10/openSUSE_Leap_15.2/repodata/repomd.xml.key
enabled=1
</code>

Jetzt kann das Distributions-Upgrade durchgeführt werden.

<code>
invis:~ # sed -i 's/15\.1/15\.2/g' /etc/zypp/repos.d/*
invis:~ # zypper ref
invis:~ # zypper dup
</code>

==== Samba AD prüfen ====

Nach dem obligatorischen Reboot sollte auch Samba wieder laufen. Testen Sie einfach mit:

<code>
invis:~ # systemctl status samba-ad-dc.service
</code>

Danach prüfen Sie, ob das Active-Directory wieder zur Verfügung steht. Am einfachsten geht das indem die vorhandenen Benutzer und Gruppen abgefragt werden:

<code>
invis:~ # wbinfo -u
141-NET\administrator
141-NET\guest
141-NET\krbtgt
141-NET\dns-invis
141-NET\ldap.admin
141-NET\junk
141-NET\postmaster
141-NET\heinzb
....
invis:~ # wbinfo -g
141-NET\cert publishers
141-NET\ras and ias servers
141-NET\allowed rodc password replication group
141-NET\denied rodc password replication group
141-NET\dnsadmins
141-NET\enterprise read-only domain controllers
141-NET\domain admins
141-NET\domain users
141-NET\domain guests
141-NET\domain computers
141-NET\domain controllers
...
</code>

Liefern beide Kommandos brauchbare Ergebnisse sieht das Upgrade schon mal gut aus. Jetzt muss der sssd-Dienst neu gestartet werden:

<code>
invis:~ # systemctl restart sssd.service
</code>

In unseren Tests hat der Neustart zwar problemlos funktioniert, allerdings weigerte sich der sssd beharrlich Benutzer und Gruppen aus dem AD abzufragen. Getestet wird dies mit:

<code>
invis:~ # getent passwd
</code>

Liefert dieses Kommando auch nach einer Weile lediglich die Benutzer aus "/etc/passwd" ist ein Neustart des Servers erforderlich. Danach hat in unseren Tests alles funktioniert. "Reboot tut gut" gilt nicht nur unter Windows.

==== Distributions-Upgrade 2 ====

Funktioniert alles soweit, kann gleich auf openSUSE leap 15.3 aktualisiert werden.

<code>
invis:~ # sed -i 's/15\.2/15\.3/g' /etc/zypp/repos.d/*
invis:~ # zypper ref
invis:~ # zypper dup
</code>

Während des Upgrades ist es bei Tests zu Problemen beim Upgrade des Virtualbox-Kernel-Moduls gekommen.

<code>
(1253/1736) virtualbox-kmp-default-6.1.14_k5.3.18_lp152.41-lp152.2.5.1.x86_64  wird entfernt ..................................[fertig]
(1254/1736) Installieren: virtualbox-kmp-default-6.1.30_k5.3.18_59.34-lp153.2.15.1.x86_64 .....................................[Fehler]
Installation von virtualbox-kmp-default-6.1.30_k5.3.18_59.34-lp153.2.15.1.x86_64 fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: /var/tmp/rpm-tmp.oriK1l: line 1: /usr/lib/module-init-tools/kernel-scriptlets/kmp-pre: No such file or directory
error: %prein(virtualbox-kmp-default-6.1.30_k5.3.18_59.34-lp153.2.15.1.x86_64) scriptlet failed, exit status 127
error: virtualbox-kmp-default-6.1.30_k5.3.18_59.34-lp153.2.15.1.x86_64: install failed

Abbrechen, wiederholen, ignorieren? [a/w/i] (a): w
(1254/1736) Installieren: virtualbox-kmp-default-6.1.30_k5.3.18_59.34-lp153.2.15.1.x86_64 .....................................[Fehler]
Installation von virtualbox-kmp-default-6.1.30_k5.3.18_59.34-lp153.2.15.1.x86_64 fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: /var/tmp/rpm-tmp.XGQQgs: line 1: /usr/lib/module-init-tools/kernel-scriptlets/kmp-pre: No such file or directory
error: %prein(virtualbox-kmp-default-6.1.30_k5.3.18_59.34-lp153.2.15.1.x86_64) scriptlet failed, exit status 127
error: virtualbox-kmp-default-6.1.30_k5.3.18_59.34-lp153.2.15.1.x86_64: install failed

Abbrechen, wiederholen, ignorieren? [a/w/i] (a): i
(1255/1736) kernel-preempt-5.3.18-lp152.106.1.x86_64  wird entfernt ...........................................................[Fehler]
Entfernen von (95424)kernel-preempt-5.3.18-lp152.106.1.x86_64(@System) fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: /var/tmp/rpm-tmp.jupqM9: line 1: /usr/lib/module-init-tools/kernel-scriptlets/rpm-preun: No such file or directory
error: %preun(kernel-preempt-5.3.18-lp152.106.1.x86_64) scriptlet failed, exit status 127
error: kernel-preempt-5.3.18-lp152.106.1.x86_64: erase failed
</code>

Wählen Sie zunächst jeweils die Option **i** für ignorieren. 

Im Anschluss an das Upgrade und den erforderlichen Neustart lassen sich die fehlenden Pakete "virtualbox-kmp-default" und "virtualbox-kmp-preempt" einfach nachinstallieren:

<code>
invis:~ # zypper in virtualbox-kmp-default virtualbox-kmp-preempt
</code>