Das Copyright an diesem Handbuch liegt bei der uib gmbh in Mainz.

Dieses Handbuch ist veröffentlicht unter der creative commons Lizenz
'Namensnennung - Weitergabe unter gleichen Bedingungen' (by-sa).

CC by sa

Eine Beschreibung der Lizenz finden Sie hier:
https://creativecommons.org/licenses/by-sa/3.0/de/

Der rechtsverbindliche Text der Lizenz ist hier:
https://creativecommons.org/licenses/by-sa/3.0/de/legalcode

Die Software von opsi ist in weiten Teilen Open Source.
Nicht Open Source sind die Teile des Quellcodes, die neue Erweiterungen enthalten, welche noch unter Kofinanzierung stehen, also noch nicht bezahlt sind.
siehe auch: opsi-Erweiterungen als Kofinanzierungsprojekte

Der restliche Quellcode ist veröffentlicht unter der AGPLv3:

agplv3

Der rechtsverbindliche Text der AGPLv3 Lizenz ist hier:
http://www.gnu.org/licenses/agpl-3.0-standalone.html

Deutsche Infos zur AGPL: http://www.gnu.org/licenses/agpl-3.0.de.html

Für Lizenzen zur Nutzung von opsi im Zusammenhang mit Closed Source Software kontaktieren Sie bitte die uib gmbh.

Die Namen 'opsi', 'opsi.org', 'open pc server integration' und das opsi-logo sind eingetragene Marken der uib gmbh.

2. opsi Version 4.2 Release Notes

2.1. Überblick über neue Features

Schwerpunkte in diesem Release:

  • Wechsel zu Python 3

  • Alle Python Applikationen werden als ausführbare Binärdateien verteilt

  • opsi-python Interpreter für eigene Skripte

  • opsi server

    • Komplette Neuimplementierung des opsiconfd mit Schwerpunkt auf Performance und Scalability

    • opsiconfd ist nun auch in einem docker Container lauffähig

    • Neue Abhängigkeit zu Redis Server >= 5 inklusive dem RedisTimeSeries Modul

    • Nutzung von Grafana zur Visualisierung von Performancedaten

    • Neue Default-ACLs für den API-Zugriff

2.2. Wichtige Hinweise - bitte beachten

opsi 4.2 ist ein eigenständiges Release und hat seine eigenen Repositories. Diese neuen Repositories müssen dem System hinzugefügt und die Repositories der Vorgängerversion entfernt werden. Erst danach kann die Installation / das Upgrade durchgeführt werden.

Für ein Upgrade von opsi 4.1 müssen die installierten Pakete auf dem letzten opsi 4.1 stable Stand sein. Andere Pakete - wie z.B. MySQL server - sollten ebenfalls aktuell sein. Andernfalls kann es zu Fehlern im Upgrade-Prozess kommen.

Es wird ebenfalls dringend empfohlen vor dem Upgrade die Pakete 'opsi-winst', 'opsi-client-agent' bzw. 'opsi-linux-client-agent' auf allen Clients auf die aktuellsten opsi 4.1-Versionen zu aktualisieren.

2.2.1. Python 3

opsi 4.2 basiert nun komplett auf Python 3. Weiterhin werden nun alle Python-basierten Pakete als ausführbare Binärdateien verteilt. Das Paket 'python-opsi' wird nicht mehr als installierbares Paket zur Verfügung gestellt. Deshalb ist es wichtig folgende Punkte zu beachten:

Opsi-Pakete die Server-seitige Python Skripte enthalten

Bitte nutzen Sie nach dem Upgrade des Servers auf opsi 4.2 den 'opsi-package-manager' um opsi-Pakete neu zu installieren, die Python-Skripte für die Ausführung auf dem Server enthalten:

  • opsi-client-agent: opsi-deploy-client-agent

  • win*: create_driver_links.py, show_drivers.py

Das postinst Skript korrigiert dabei automatisch diese Skripte und setzt den neuen Interpreter opsi-python.

Alternativ dazu kann man die Python Skripte auch manuell korrigieren. Hierfür muss der Interpreter auf opsi-python (Eintragung von #!/usr/bin/opsi-python als 'shebang') gesetzt werden.

Eigene Python-Skripte die python-opsi nutzen (import OPSI)

Sollten Skripte eingesetzt werden, die von python-opsi abhängen, müssen folgende Schritte ausgeführt werden: * Konvertieren der Skripte auf Python 3 (dazu kann das Python-eigene 2to3 genutzt werden). * Umstellung auf den Interpreter opsi-python, der python-opsi (import OPSI) zur Verfügung stellt (Eintragen von #!/usr/bin/opsi-python als 'shebang').

Backend Erweiterungen (/etc/opsi/backendManager/extend.d)

Sollten Sie die Konfigurationsdateien von /etc/opsi/backendManager/extend.d modifiziert oder neue hinzugefügt haben, müssen diese Änderung auf Python 3-Kompatibilität geprüft und gegebenfalls angepasst werden.

2.2.2. Datei-Admin-Gruppe pcpatch / opsifileadmins

Mit opsi 4.2 wurde der Standard-Name für die opsi-Datei-Admin-Gruppe von 'pcpatch' in 'opsifileadmins' geändert. Bei einem Upgrade von opsi 4.1 wird jedoch der bisher verwendete Name weiterverwendet. Der Name kann in der Konfigurations-Datei /etc/opsi/opsi.conf über Option fileadmingroup der Sektion groups angepasst werden. Bei einem Wechsel auf die Gruppe 'opsifileadmins' ist zu beachten, dass auch der Benutzer 'pcpatch' dieser Gruppe hinzugefügt werden muss.

2.2.3. opsiconfd Konfiguration und Logs

Es gibt einige Änderung bei der Konfiguration und den Logs des 'opsiconfd'.

  • Alle Konfigurationsoptionen sind im Hilfetext des opsiconfd dokumentiert ('opsiconfd --help').

  • Diese Kommandozeilenparameter können auch in der Konfigurations-Datei opsiconfd.conf verwendet werden (ohne '--').

  • Der opsiconfd hat nun eine eingebaute Log-Rotation. Diese kann mit den Optionen 'max-log-size' und 'keep-rotated-logs' konfiguriert werden.

  • Die Logdatei 'package.log' ist nun Bestandteil der 'opsiconfd.log'.

  • Die Logs beinhalten nun einen Kontext, welche für die Filterung der Logs genutzt werden können. Zum Beispiel kann man mit 'grep' nach diesen filtern oder dem opsiconfd beim Start die Option '--log-filter LOG_FILTER' mitgeben:

opsiconfd --log-filter instance=package_install
[6] [2020-09-07 14:41:17.864] [package_install] Running postinst script   (Depotserver.py:235)
[5] [2020-09-07 14:41:17.865] [package_install] Running package script 'postinst'   (Product.py:477)
...
opsiconfd --log-filter client_addr=10.100.7.5
[6] [2020-09-07 14:25:16.966] [10.100.7.5     ] Filtering objects by acls   (AccessControl.py:475)
...

2.2.4. Verifizierung der Server-Identität

Seit opsi 4.2 kann die Vertrauenswürdigkeit des opsi-server über TLS-Standard-Methoden sichergestellt werden. Jeder opsi-configserver verwaltet eine Certificate Authority (CA), die opsi CA. Diese CA wird vom opsi-configserver automatisch verwaltet. Jeder opsi-server, auch die opsi-depotserver erhalten vom opsi-configserver ein TLS-Zertifikat, das von dieser CA signiert ist. Auch diese Zertifikate werden automatisch erstellt, verteilt und bei Bedarf aktualisiert. Jeder Client, der der opsi CA vertraut, vertraut auch diesen Server-Zertifikaten.

Dies betrifft vor allem die Option 'verify_server_cert' und 'verify_server_cert_by_ca'. Für nähere Informationen bitte enstprechendes Kapitel im opsi-manual nachlesen.

2.2.5. Abkündigung vom opsi4ucs Paket

Im Rahmen von opsi 4.2 wurde der UCS-Support den anderen Distributionen angepasst. Die Funktion von opsi4ucs übernimmt ab opsi 4.2 das opsi-server Paket und dessen Varianten. Das opsi4ucs Paket existiert in opsi 4.2 als Transitionpaket, um die Migration von opsi 4.1 Installationen zu vereinfachen. Während des Upgradeprozesses wird das opsi4ucs Paket automatisch durch die opsi-server Pakete ersetzt.

2.3. Installationshinweise

Wir empfehlen dringend for dem Update eine Sicherung der Backends mit opsibackup zu erstellen:

opsi-backup create

Alle opsi-Komponenten, die im Rahmen dieses Releases veröffentlicht werden, sind an vielen Stellen voneinander abhängig. Es sollten daher immer alle Komponenten aktualisiert werden.

Wir empfehlen zuerst den Server und danach die opsi-Pakete (Produkte) zu aktualisieren.

In einer Multi-Depot-Umgebung wird empfohlen die Aktualisierung auf dem Configserver zu beginnen und erst danach die Depots zu aktualisieren.

Wir empfehlen nach dem Update die Ausführung von opsi-setup --set-rights, um sicher zu stellen, dass die Zugriffsberechtigungen korrekt gesetzt sind. Die Ausführung des Befehls kann mehrere Minuten in Anspruch nehmen.

2.3.1. Hinweise zum Aktualisieren der Betriebssystem-Pakete

Bitte stellen Sie sicher, dass Sie zum Zeitpunkt der Aktualisierung die jeweils aktuellsten Pakete von opsi 4.1 aus dem Stable-Bereich verwenden!

2.3.2. Hinweise zum Aktualisieren von opsi-Paketen

opsi-Pakete sind in der Regel kompatibel zu sowohl opsi 4.1 als auch opsi 4.2.

Die offiziellen opsi 4.2-Repositories auf download.uib.de enthalten Pakete, welche mit opsi 4.1 kompatibel sind. Bitte beachten Sie, dass diese Pakete nicht zwingend 4.2 als Version angegeben haben müssen, um kompatibel zu sein.

2.3.3. Migration eines opsi 4.1-Servers

Auf unterstützten Betriebsystemen ist es möglich eine bestehende opsi 4.1-Installation auf opsi 4.2 zu migrieren.

Falls die opsi-Server durch opsi verwaltet werden, kann die Migration über das Paket l-opsi-server-migrate durchgeführt werden.

Eine Aktualisierung von opsi 4.0 direkt auf opsi 4.2 wird nicht unterstützt. In diesen Fällen muss erst eine Aktualisierung auf opsi 4.1 durchgeführt werden, bevor eine Aktualisierung auf opsi 4.2 möglich ist.
Vorbedingung für eine Migration

Der opsi-Server benötigt ab Version 4.2 Zugriff auf eine Redis- und eine Grafana-Instanz. Sollen diese Dienste ebenfalls auf dem opsi-Server bereitgestellt werden, empfehlen wir einen Umstieg auf das Paket 'opsi-server-full' während der Migration. Dieses Paket installiert und konfiguriert alles notwendige auf dem opsi-Server (im folgenden wird dies als Single-Server-Setup beschrieben).

Für die Installation von Grafana werden die Grafana-Repositories benötigt:

Debian/Ubuntu:
sudo apt-get install -y apt-transport-https software-properties-common wget gnupg
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/deb stable main" > /etc/apt/sources.list.d/grafana.list
RHEL/CentOS:
yum install wget
cd /etc/yum.repos.d
cat <<EOF > grafana.repo
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF
openSUSE:
zypper install wget
cd /etc/zypp/repos.d
cat <<EOF > grafana.repo
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF
Wechseln zu den neuen Repositories

Als erstes müssen die opsi 4.2-Repositories in die Paketquellen Ihres Betriebsystems eingetragen werden.

Die nachfolgenden Befehle fügen die neuen Repositories und, sofern benötigt, den Repository-Schlüssel hinzu. Diese folgenden Befehle benötigen 'root'-Rechte.

Ubuntu 20.04 LTS Focal Fossa:

echo "deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/xUbuntu_20.04/ /" > /etc/apt/sources.list.d/opsi.list
wget -q -O - https://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/xUbuntu_20.04/Release.key | sudo apt-key add -

Ubuntu 18.04 LTS Bionic Beaver:

echo "deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/xUbuntu_18.04/ /" > /etc/apt/sources.list.d/opsi.list
wget -q -O - https://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/xUbuntu_18.04/Release.key | sudo apt-key add -

Debian 11 Bullseye:

echo "deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/Debian_11/ /" > /etc/apt/sources.list.d/opsi.list
wget -q -O - https://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/Debian_11/Release.key | sudo apt-key add -

Debian 10 Buster:

echo "deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/Debian_10/ /" > /etc/apt/sources.list.d/opsi.list
wget -q -O - https://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/Debian_10/Release.key | sudo apt-key add -

CentOS 8:

cd /etc/yum.repos.d
wget https://download.opensuse.org/repositories/home:uibmz:opsi:4.2:stable/CentOS_8/home:uibmz:opsi:4.2:stable.repo
yum makecache

RHEL 8:

cd /etc/yum.repos.d
wget https://download.opensuse.org/repositories/home:uibmz:opsi:4.2:stable/RHEL_8/home:uibmz:opsi:4.2:stable.repo
yum makecache

openSUSE Leap 15.1:

cd /etc/zypp/repos.d
wget https://download.opensuse.org/repositories/home:uibmz:opsi:4.2:stable/openSUSE_Leap_15.1/home:uibmz:opsi:4.2:stable.repo
zypper refresh

openSUSE Leap 15.2:

cd /etc/zypp/repos.d
wget https://download.opensuse.org/repositories/home:uibmz:opsi:4.2:stable/openSUSE_Leap_15.2/home:uibmz:opsi:4.2:stable.repo
zypper refresh

SLES 15 SP 1:

cd /etc/zypp/repos.d
wget https://download.opensuse.org/repositories/home:uibmz:opsi:4.2:stable/SLE_15_SP1/home:uibmz:opsi:4.2:stable.repo
zypper refresh

SLES 15 SP 2:

cd /etc/zypp/repos.d
wget https://download.opensuse.org/repositories/home:uibmz:opsi:4.2:stable/SLE_15_SP1/home:uibmz:opsi:4.2:stable.repo
zypper refresh

Univention UCS 4.4:

echo "deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/Univention_4.4/ /" > /etc/apt/sources.list.d/opsi.list
wget -q -O - https://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/stable/Univention_4.4/Release.key | sudo apt-key add -
Aktualisierung der Betriebssystem-Pakete

Nach dem Eintragen der neuen Paketquellen kann das System migriert werden.

Die Standard-ACLs (/etc/opsi/backendManager/acl.conf) wurden mit opsi 4.2 aus Sicherheitsgründen verändert. Wir empfehlen daher dringend die neue Version der Konfigurationsdatei zu verwenden.
Bei RPM-basierten Distributionen werden im Rahmen der Migration bereits vorhandene Konfigurationsdateien durch neue ersetzt. Beachten Sie hierzu die Hinweise unter den entsprechenden Distributionen.

Debian und Ubuntu werden mit folgenden Befehlen auf opsi 4.2 aktualisiert:

Single-Server-Setup:

apt update
apt install opsi-server-full

Manuelles Setup:

apt update
apt install redis-server redis-timeseries grafana
systemctl daemon-reload
systemctl enable grafana-server
systemctl start grafana-server
apt dist-upgrade

RedHat und CentOS werden mit folgenden Befehlen auf opsi 4.2 aktualisiert:

Single-Server-Setup:

yum makecache
yum install opsi-server-full
yum upgrade

Manuelles Setup:

yum makecache
yum install redis-server redis-timeseries grafana
systemctl daemon-reload
systemctl enable grafana-server
systemctl start grafana-server
yum upgrade

OpenSUSE bzw SUSE Linux Enterprise Server (SLES) wird mit folgenden Befehlen auf opsi 4.2 aktualisiert:

Single-Server-Setup:

zypper refresh
zypper install opsi-server-full

Manuelles Setup:

zypper refresh
zypper install redis-server redis-timeseries grafana
systemctl daemon-reload
systemctl enable grafana-server
systemctl start grafana-server
zypper dup --from home_uibmz_opsi_4.2_{release}

Univention UCS wird mit folgenden Befehlen auf opsi 4.2 aktualisiert:

Single-Server-Setup:

univention-install opsi-server-full

Manuelles Setup:

univention-install redis-server redis-timeseries grafana
systemctl daemon-reload
systemctl enable grafana-server
systemctl start grafana-server
univention-install opsi-server
Aktualisierung der opsi-Pakete

Der letzte Schritt ist die Aktualisierung auf die neuesten opsi-Pakete.

Verwendung der Standardkonfiguration

Wenn Sie keine Veränderungen gegenüber der Standard-Auslieferung unter /etc/opsi/package-updater.repos.d/ vorgenommen haben, können Sie die opsi-Pakete direkt über den aufgeführten Aufruf aktualisieren:

opsi-package-updater -v update
Opsi-Pakete die Server-seitige Python Skripte enthalten

Bitte installieren Sie opsi-Pakete neu, die Python-Skripte für die Ausführung auf dem Server enthalten. Dies sind in der Regel opsi-client-agent, opsi-linux-client-agent und alle Pakete die Windows-Betriebssysteme installieren (win*). Details hierzu sind an dieser Stelle zu finden: Abschnitt 2.2.1.1.

Nach diesen Schritten ist Ihr opsi 4.1 Server auf das Release 4.2 migriert und einsatzbereit.

Upgrade von opsi 4.0.7

Wenn Sie von einem opsi 4.0.7 kommen, sollten Sie opsi 4.1 überspringen und direkt auf opsi 4.2 aktualisieren. * Aktualisieren Sie zunächst Ihr Serverbetriebssystem auf eine Version, die von opsi 4.0.7 und 4.2 unterstützt wird (z.B. Ubuntu 18.04). * Dann aktualisieren Sie Ihren opsi-Server auf opsi 4.2 wie oben beschrieben. * Zuletzt aktualisieren Sie den opsi-client-agent auf die letzte stabile Version 4.2.

2.4. Known Bugs / Known Problems

KNOWN BUGS:

  • opsi-admin: Der interaktive Modus funktioniert nicht mit non-ASCII Zeichen wie Umlaute ö, ä, ü.

2.5. Abkündigung

In diesem Kapitel werden die Abkündigungen aufgelistet.

2.5.1. EOL: opsi 4.1 Q4/2021

Bisher haben wir den jeweiligen opsi-Vorgänger (oldstable) mindestens ein Jahr lang parallel zur aktuellen Version unterstützt. In diesem Fall haben wir uns aber entschieden, die Zeit auf die Hälfte zu verkürzen und opsi 4.1 für das 4. Quartal 2021 (30.11.2021) abzukündigen. Der Hauptgrund für die verkürzte EOL-Zeit: Nicht alle aktuellen Betriebssysteme unterstützen opsi 4.1, darunter z. B. Ubuntu 20.04. opsi 4.1 basiert komplett auf Python 2, und diese Version hat bereit im April 2020 das EOL erreicht und erhält keine Updates mehr.

Über die opsi-Supportverträge unterstützen wir Sie gerne beim Update auf die neue opsi-Version. Auch nach dem EOL von opsi 4.1 sind wir für Sie da und helfen bei Migrationen – wir empfehlen aber dringend, die Zeit bis zum Ende von Q4/2021 zu nutzen und auf opsi 4.2 zu aktualisieren.

2.5.2. Abkündigung: Distributionen für opsi-server

Diese Distributionsversionen werden aus verschiedenen Gründen nicht weiter von opsi unterstützt.

  • CentOS 7.x

  • Debian 8.x

  • RedHat Enterprise Linux 7.x

  • Suse Linux Enterprise Server 12

Siehe auch gesondertes Kapitel: Abschnitt 2.6.

2.6. opsi Support Matrix

Im folgenden finden Sie eine Übersicht auf welchen Plattformen opsi als Server läuft.

2.6.1. Supported distributions for server

Date: 11.12.2020

Distribution

Opsi 4.2

Debian 8 Jessie

discontinued

Debian 9 Stretch

supported

Debian 10 Buster

supported

Debian 11 Bullseye

supported

Ubuntu 16.04 LTS Xenial Xerus

discontinued

Ubuntu 18.04 LTS Bionic Beaver

supported

Ubuntu 20.04 LTS Focal Fossa

supported

RHEL 7

unsupported

RHEL 8

supported

CentOS 7

unsupported

CentOS 8

supported

openSUSE Leap 15.1

supported

openSUSE Leap 15.2

supported

SLES 12SP1

unsupported

SLES 12SP2

unsupported

SLES 12SP3

unsupported

SLES 15SP1

supported

SLES 15SP2

supported

UCS 4.4

supported

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued

Sollten Sie den opsi-server auf einer Betriebssystemversion einsetzen, welche im vorigen Abschnitt nicht als Unterstützt aufgeführt ist, so empfehlen wir Ihnen ein Betriebssystem-Update bevor Sie opsi 4.2 einspielen.

2.7. Geänderte Standardeinstellungen

Mit opsi 4.2 wurden einige Standard-Einstellungen geändert, um Erfahrungen aus dem opsi-Betrieb wiederzuspiegeln.

Wichtig ist dies vorallem, wenn in einer bestehenden Umgebung neue opsi-Server installiert werden, da sich diese unter Umständen anders verhalten.

  • Die geänderte acl.conf beachten.

2.8. Wechsel zu Python 3 und PyInstaller

Diese Version basiert auf Python 3. Alle opsi Python Applikationen (opsiconfd, opsipxeconfd, opsiclientd, opsi-utils, …​) werden nun als ausführbare Dateien mit PyInstaller ausgeliefert. Bitte nutzen Sie den opsi-python Interpreter für Ihre eigenen Skripte, welche Zugriff auf die python-opsi library benötigen.

2.9. MySQL backend: Limitierung der "connection lifetime"

Um die Fehlermeldungen: "mysql server has gone away" zu vermeiden, wurde die Standardkonfiguration des MySQL Backends geändert. Die Option connectionPoolRecycling hat nun als Standardwert: 28800. Diese Einstellung limitiert die Lebenszeit der Verbindungen im Connection Pool, welches für die Verbindungen zu MySQL (bzw. MariaDB) Server genutzt wird.

2.10. opsi Support Matrix Linux Clients

Im folgenden finden Sie eine Übersicht auf welchen Linux Plattformen opsi als Client läuft.

2.10.1. Supported as opsi-client: Linux

Stand 09.11.2020

Tabelle 1. Unterstützte Linux-OS als Client in opsi 4.2 und 4.1

Distribution

OS-Installation

netboot products

client-agent

opsiclientd

Debian 11 Bullseye

supported

debian, debian11

supported

supported

Debian 10 Buster

supported

debian, debian10

supported

supported

Debian 9 Stretch

discontinued

debian, debian9

discontinued

discontinued

Debian 8 Jessie

discontinued

debian, debian8

discontinued

discontinued

Ubuntu Jammy 22.04 LTS

supported

ubuntu, ubuntu22-04

supported

supported

Ubuntu Focal 20.04 LTS

supported

ubuntu, ubuntu20-04

supported

supported

Ubuntu Bionic 18.04 LTS

supported

ubuntu, ubuntu18-04

supported

supported

Ubuntu Xenial 16.04 LTS

discontinued

ubuntu, ubuntu16-04

discontinued

discontinued

Ubuntu Trusty 14.04 LTS

discontinued

ubuntu, ubunt14-04

discontinued

discontinued

Linux Mint 21

supported

mint21

supported

supported

Linux Mint 20-3

supported

mint20-3

supported

supported

Linux Mint 20-2

supported

mint20-2

supported

supported

Linux Mint 20-1

supported

mint20-1

supported

supported

RHEL 9

supported

rhel9

supported

supported

RHEL 8

supported

rhel8

supported

supported

Alma Linux 9

supported

alma9

supported

supported

Alma Linux 9

supported

alma8

supported

supported

Rocky Linux 9

supported

rocky9

supported

supported

Rocky Linux 8

supported

rocky8

supported

supported

RHEL 7

discontinued

CentOS 8

discontinued

centos8

discontinued

discontinued

CentOS 7

discontinued

centos70

discontinued

discontinued

SLES 15-4

supported

sles15-4

supported

supported

SLES 15-3

supported

sles15-3

supported

supported

SLES 15-2

supported

sles15-2

supported

supported

SLES 15-1

supported

sles15-1

supported

supported

SLES 12 SP5

supported

sles12sp5

supported

discontinued

SLES 12 SP4

supported

sles12sp4

supported

discontinued

SLES 12 SP3

supported

sles12sp3

supported

discontinued

SLES 12 SP2

discontinued

sles12sp2

discontinued

discontinued

SLES 12 SP1

discontinued

sles12sp1

discontinued

discontinued

SLES 12

discontinued

sles12

discontinued

discontinued

openSuse Leap 15.4

supported

opensusel15-4

supported

supported

openSuse Leap 15.3

supported

opensusel15-3

supported

supported

openSuse Leap 15.2

discontinued

opensusel15-2

discontinued