Ich brauchte kürzlich an meinem gut abgehangenen Desktop-Rechner dann doch mal die Möglichkeit meine Sony-Kopfhörer per Bluetooth zu verbinden. Da Bluetooth vor 10 Jahren allerdings für Hauptplatinen von normalen Rechnern noch nicht üblich war, hat mein Rechner kein Bluetooth. Ich habe deshalb jetzt, ohne große Recherche und nur von der spontanen Verfügbarkeit getrieben, einen BT-8500 von Edimax gekauft. In den USB-Port eingesteckt poppte im KDE sofort das Bluetooth-Applet auf und ich könnte die Kopfhörer verbinden. Die Verbindung zu den Kopfhörer ist auch richtig stabil, mindestens genau so gut wie vom Fairphone.

Wie gut der Adapter für andere Szenarien geeignet ist kann ich nicht sagen. Aber wer sich fragt ob ein Edimax BT-8500 unter openSUSE Leap 15.5 für Bluetooth-Audio funktioniert: das geht komplett ohne Bastelei.

Während Minecraft auf openSUSE früher auf älteren Version immer einfach so funktioniert hat, endet der Versuch Version 1.20.4 auf openSUSE Leap 15.5 zu starten reproduzierbar mit einem Absturz.

Der in der Fehlermeldung angegebene Exit-Code 6 hiflt leider nicht viel weiter. Suchen danach führen zu vielen verschiedenen möglichen Problemen. Einen guten Hinweis liefert aber der über die Fehlermeldung erreichbare Absturzbericht:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000000, pid=22905, tid=22907
#
# JRE version:  (17.0.8+7) (build )
# Java VM: OpenJDK 64-Bit Server VM (17.0.8+7-LTS, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libjimage.so+0x3ac8]  ZipDecompressor::decompress_resource(unsigned char*, unsigned char*, ResourceHeader*, ImageStrings const*)+0x28
#

Grund für den Absturz ist ein ungültiger Speicherzugriff. Und dieser scheint nicht im eigentlichen Minecraft-Code sondern in der Java-Laufzeitumgebung (JRE) selbst zu passieren. Es scheint also eine Inkompatilibität zwischen der von Minecraft verwendeten Java-Laufzeitumgebung und openSUSE Leap 15.5 zu geben.

Glücklicherweise lässt sich die von Minecraft verwendete Java-Laufzeitumgebung konfigurieren. Diese findet sich im Abschnitt "Mehr Optionen" der Installationseinstellungen. Tragen wir hier /usr/bin/java ein, so wird das aktuellste auf dem System installierte Java verwendet.

Sollten wir später zur mitgelieferten Version zurückkehren wollen, so können wir den Wert über das X neben dem Feld auch wieder löschen. In diesem Fall benutzt Minecraft dann wieder seine eigene Version.

Die Konfiguration einer Installation von Minecraft finden wir übrigens unter „Bearbeiten“ im erweiterten Menü der Installation im Reiter „Installationen“.

Sollte auf unserem System keine aktuelle Laufzeitumgebung für Java installiert sein, so endet der nächste Versuch Minecraft zu starten übrigens wieder mit einer Fehlermeldung. Die Laufzeitumgebung können wir in diesem Fall schnell per Zypper nachinstallieren. Da der Absturzbericht uns verraten hat, dass Minecraft normallerwise Version 17 verwendet, installieren wir am besten auch genau diese nach:

sudo zypper in java-17-openjdk

Danach können wir dann endlich Minecraft auf openSUSE Leap 15.5 genießen.

Beim Upgrade von openSUSE Leap 15.3 auf openSUSE Leap 15.4 ergibt sich bei pre-commit ein interessantes Problem. Auf älteren Versionen von Leap konnte das Paket aus dem Entwicklungsprojekt devel:languages:python installiert werden. Dort findet sich aber keine Version für Leap 15.4. Eine solche findet sich jetzt in meinem Projekt home:theMarix:py36 und lässt sich von dort einfach installieren:

zypper addrepo https://download.opensuse.org/repositories/home:theMarix:py36/15.4/home:theMarix:py36.repo
zypper refresh
zypper install python3-pre-commit

Das Problem entsteht, weil pre-commit es bisher nicht in die Distribution geschafft hat. Das ist normalerweise kein Problem, weil die Pakete in den Entwicklungsprojekten auch für alle aktuellen Versionen von Leap gebaut werden. Speziell bei Leap 15.4 ist hier aber etwas interessantes passiert. pre-commit hat in Version 2.17.0 verständlicherweise die Unterstützung für Python 3.6 fallengelassen. Allerdings setzt Leap 15.4 aus Kompatibilitätsgründen noch auf diese Version von Python. Da jetzt aber das Upgrade auf 2.17.0 in devel:languages:python passierte bevor Leap 15.4 angelegt wurde, wurde die letzte mit Python 3.6 lauffähige Version 2.16.0 nie für Leap 15.4 gebaut. Anders für Leap 15.3, für das genau diese Version bis zuletzt noch installierbar war.

Im Projekt home:theMarix:py36 befindet sich jetzt einfach ein Link auf die letzte Revision des Pakets in devel:languages:python die noch mit Python 3.6 kompatibel war. So gibt es jetzt zwar leider keine aktuelle Version von pre-commit für Leap 15.4, aber immerhin eine ohne Verrenkungen nutzbare, die mit dem Update auf 15.5 wird sich dass dann ganz von alleine wieder auf das aktuelle Paket wechseln wird. Und auch wenn das jetzt wahnsinnig aufwendig klingt, der Zeitaufwand das Paket anzulegen war geringer als der diesen Artikel zu schreiben.

Die Tage musste ich leider Feststellen, dass mein KTorrent beim Download der aktuellen Pwned-Passwords-List von Have I been Pwned komplett einfror. Eine Suche nach dem Problem liefert nicht viele Treffer, aber fördert einen 5 Jahre alten Forenbeitrag zutage, der eine Lösung für das Problem liefert. Den Firefox einmal kurz zu schließen taut KTorrent wieder auf.

Das Problem scheint nur aufzutreten, wenn KTorrent aus dem Firefox startet. Das passiert wenn man Firefox einen Link auf eine Torrent-Datei mit KTorrent öffnen lässt, dieser aber noch nicht lief. Dadurch gibt zwei einfache Wege das Problem zu umgehen und die obige Lösung dann gar nicht erst zu brauchen:

1. Ist KTorrent bereits gestartet bevor Firefox die Datei übergibt, so scheint das Problem nicht aufzutreten.
2. Kopiert man die URL der Torrent-Datei in die Zwischenablage, kann man diese auch aus KTorrent direkt mit Datei - Adresse öffnen bzw. Strg+P öffnen und umgeht die Interaktion zwischen Firefox und KTorrent komplett.

Mit dem am Mittwoch durch den Patch openSUSE-SLE-15.3-2022-198 gelieferten Kernel mit Version 5.3.18-150300.59.43.1 startet Leap 15.3 auf vielen Systemen mit Radeon-Grafik nicht mehr. Gleich nach dem Laden des Kernels friert das System ein und schaltet die Bildschirmausgabe ab. Glücklicherweise gibt es aber gleich zwei einfache Wege betroffene Systeme wieder zum laufen zu bekommen. Die Systeme können entweder mit der vorherigen Kernelversion oder dem Kernelparameter nomodeset gestartet werden.

Die schnellste Variante ist sicher einfach den vorherigen Kernel zu starten. Dieser lässt sich im Bootmenü von Grub über die erweiterten Optionen einfach auswählen. Standardmäßig hebt openSUSE übrigens immer den genutzten und die zwei neuesten Kernel auf. Es sollte also immer ein funktionsfähiger Kernel zur Verfügung stehen. Mehr zu diesem Feature findet sich in einem älteren Artikel von mir.

Stört es, wie beispielsweise bei einem sowieso ohne Monitor betriebenen System, nicht, wenn das Modesetting nicht funktioniert, so lässt sich auch der neue Kernel booten. Der Bug lässt sich durch Nutzung des Kernelparameters nomodeset umgehen. Am einfachsten lässt sich dieser über das Modul Bootloader im Abschnitt System von YaST konfigurieren. Dafür muss das System aber erst mal laufen. Dafür kann entweder, wie oben beschrieben der alte Kernel genutzt werden, oder der Parameter einmal beim Start manuell gesetzt werden.

Um den Bootparameter beim Start manuell zu setzen muss im Bootmenü die Taste E gedrückt werden. Dies öffnet den gerade ausgewählten Startmenüeintrag in einem einfachen Editor. Hier ist die mit linux beginnende Zeile zu suchen und an deren Ende der Parameter nomodeset hinzuzufügen. Durch einen Druck auf F10 startet das System dann mit dem modifizierten Eintrag. Der Eintrag wird allerdings nicht permanent übernommen. Man muss ihn anschließend noch per YaST persistieren, kann sich dafür aber auch erst mal nichts kaputt machen.

Mehr Informationen zu diesem Problem finden sich im Bugzilla. Dort gibt es auch schon eine verifizierte richtige Lösung des Problems, welche im nächsten Kernel-Patch dann enthalten sein dürfte.

Aktualisierung vom 7.2.2022: Mit dem Update openSUSE-SLE-15.3-2022-340, welches den Kernel auf Version 5.3.18-150300.59.46 hebt, ist das Problem behoben. Die betroffenen Systeme starten auch ohne den Workaround nomodeset zu nutzen wieder. Solltet Ihr vorsichtshalber den letzten Kernel, mit dem euer System noch gestartet hat, zur dauerhaften Aufbewahrung markiert haben, so solltet ihr nicht vergessen auch dies wieder rückgängig zu machen. Sonst liegt der alte Kernel unnötig dauerhaft rum.

Ich nutzte schon seit 2011 einen USB-Stick um bei meinem mit openSUSE laufenden Heimserver beim Start das Passwort für die Festplattenverschlüsselung „eingeben“ zu können ohne eine Tastatur oder einen Monitor am System angeschlossen zu haben. Den dafür genutzten Mechanismus habe ich auch schon damals hier im Blog dokumentiert. Leider funktionierte der dort beschriebene Mechanismus aber seit openSUSE Leap 42.2 nicht mehr. Auf den nachfolgenden Versionen gibt es aber einen neuen Mechanismus, der sogar noch besser funktioniert. Dieser wird hier beschreiben und wurd auf allen Versionen von openSUSE Leap 42.2 bis 15.5 erfolgreich getestet.

Festplattenverschlüsselung

Für die Festplattenverschlüsselung wird ganz klassisch LUKS genutzt, so wie auch openSUSE ein System mit Festplattenverschlüsselung aufsetzen würde. Da der Schlüssel vom USB-Stick während des initialen Boots aus der Initrd gelesen wird muss /boot allerdings unverschlüsselt sein. Moderne Versionen von openSUSE erlauben auch einen Boot mit verschlüsselter Boot-Partition. In diesem Fall wird der Schlüssel aber bereits von Grub abgefragt. Diese Variante wird vom hier beschriebenen Mechanismus nicht unterstützt.

Da LUKS die Nutzung mehrerer alternativer Schüssel unterstützt empfiehlt es sich das System zunächst mit einer klassischen Passphrase einzurichten. Dies erleichtert Offline-Upgrades des Systems und das Einbinden der Festplatten zu Wiederherstellungs- und Wartungszwecken.

USB-Stick als Schlüssel

Da der USB-Stick später aus der Initramfs gelesen werden soll, empfiehlt es sich ein dort sowieso eingebundenes Dateisystem zu nutzen. Ich nutze hierfür immer noch Ext2. Ist der Stick als /dev/sdb im System zu sehen, kann er wie folgt passend formatiert werden.

mkfs.ext2 -L keystick /dev/sdb

Das Label keystick ist wichtig um den Schüssel später leicht referenzieren zu können. Außerdem ist es beim Mount mit Label möglich eine zweite Kopie des Sticks zu erstellen falls das Original mal zerstört wird.

Anschließend sollte ein Schlüssel generiert und auf dem USB-Stick hinterlegen werden. Dies kann mit pwgen gemacht werden:

pwgen -s 1024 1 > /media/keystick/keyfile

Und schließlich muss der Schlüssel der verschlüsselten Partition hinzugefügt werden.

cryptsetup luksAddKey /dev/sda2 /media/keystick/keyfile

In diesem Beispiel befindet sich die verschlüsselte Partition auf /dev/sda2.

USB-Stick beim Booten nutzen

Um den Schlüssel beim Booten vom USB-Stick zu lesen muss der Kernelparameter rd.luks.key auf die Schlüsseldatei zeigen.

rd.luks.key=/keyfile:LABEL=keystick

Hier wird wieder das, bei der Formatierung des Sticks vergebene, Label für das Dateisystem genutzt. Der Pfad ist relativ zum per Label referenzierten Dateisystem. Konfigurieren lässt sich der Kernelparameter am einfachsten über die Bootloaderkonfiguration in Yast.

Damit der Parameter rd.luks.key funktioniert benötigt es allerdings noch eine Änderung. In der Standardkonfiguration nutzt die Initrd bei openSUSE Systemd. Dann hat der Parameter allerdings keinen Effekt. Deshalb muss Dracut, welches in openSUSE die Initrd baut, so konfiguriert werden, dass es eine Initrd ohne Systemd baut. Dazu ist eine neue Datei /etc/dracut.conf.d/50-keystick.conf mit folgendem Inhalt anzulegen:

omit_dracutmodules+=" systemd "

Die Leerzeichen im Wert sind hier Absicht. Ohne diese wirft Dracut eine Warnung:

dracut: WARNING: <key>+=" <values> ": <values> should have surrounding white spaces!
dracut: WARNING: This will lead to unwanted side effects! Please fix the configuration file.

Ein anschließendes mkinitrd erzeugt eine Initrd ohne Systemd und das System kann zukünftig bei eingestecktem USB-Stick ohne Passworteingabe gestartet werden.

Vorteile gegenüber der alten Methode

Bei der alten Methode blieb das System in einer Schleife hängen wenn der USB-Stick beim Boot nicht gesteckt war. Ohne Stick konnte das System gar nicht mehr gebootet werden. Bei der hier beschriebenen Methode versucht das System zunächst die Schüsseldatei vom USB-Stick zu lesen. Kann es diese aber nicht finden, so fällt es auf die klassische Passworteingabe zurück. Wurde der USB-Stick also nicht als einziges Passwort eingerichtet lässt sich das System im Notfall auch noch so starten.

Diese Woche erschien die Beta von openSUSE Leap 15.3, der nächsten Version von openSUSE Leap. Ich habe meinen primären privaten Rechner bereits darauf aktualisiert und es war völlig unspektakulär. Was auf den ersten Blick enttäuschend klingt ist aber etwas wirklich gutes, denn es heißt, dass ich keinerlei Probleme hatte und weiterhin alles funktioniert.

Das die Aktualisierung auf die nächste Version so unspektakulär ist war gar nicht so selbstverständlich, denn technisch gab es unter der Haube größere Umwälzungen. OpenSUSE verwendet für alles, dass es auch in SUSE Linux Enterprise gibt, direkt das Paket von dort. Eine gute Nachricht, für alle, die auf ein grundsolides System bauen wollen. Durch die direkte Nutzung der Pakete von SLE gibt es auch nicht nur maximale Kompatibilität, sondern Patches werden auch direkt verfügbar sein, ohne die Zeitverzögerung durch die Portierung von SLE auf openSUSE.

Auch meine Methode zum Booten mit Keystick funktioniert mit der Beta von Leap 15.3 wunderbar.

Einen kleinen Stolperer gibt es momentan noch beim Onlineupgrade auf die Beta, zumindest wenn man bereits den Weg mit der Variablen releasever in den Quellen für die Paketpfade nimmt. Nach dem Update zeigt /etc/products.d/baseproduct ins Leere. Das hat zur Folge, dass Zypper die Paketquellen nicht mehr findet:

Warnung: Der Symlink /etc/products.d/baseproduct ist defekt oder fehlt!
Der Link muss auf die .prod-Datei Ihrer Kernprodukte in /etc/products.d verweisen.

Zum Glück lässt sich dies sehr leicht reparieren und bis zum finalen Release von 15.3 wird diese Problem auch gelöst sein.

sudo rm /etc/products.d/baseproduct && sudo ln /etc/products.d/Leap.prod /etc/products.d/baseproduct

Auch wenn es momentan in 15.3 aus Nutzersicht keine Features gibt für die es dringend ein Update bräuchte, sollte, wer ein in irgendeiner Form ein ungewöhnliches Set-Up hat, der Beta also auf jeden Mal einen Versuch gönnen. Denn so können Probleme idealerweise noch vor dem Release gefunden und behoben werden. Dazu bietet sich natürlich eine Zweitinstallation an, auch wenn die Beta sogar schon stabil genug für die tägliche Nutzung erscheint.

Der Klett Verlag bietet zu vielen seiner Lehrwerke auch Begleitmaterialien auf CD ROM an. Die Anwendung auf diesen CDs öffnet tatsächlich nur HTML-Datei, so dass sich die CDs durch direktes Öffnen der Datei index.html Datei auch wunderbar auf nicht-Windows-Systemen nutzen ließen. Häufig wird dann aber eine kaputte Seite dargestellt, und die Fehlerkonsole des Browsers beschwert sich über fehlende Dateien, z.B. für die Schriftarten. Des Rätsels Lösung ist, dass diese Dateien auf der Ebene des Joliet-Dateisystems als versteckt markiert sind und für Anwendungen so normalerweise nicht sichtbar sind. Unter Windows kümmert sich die Klett-Anwendung darum diese vor dem Öffnen der index.hml sichtbar zu schalten.

Mit dem Wissen darum, dass die Dateien auf Dateisystemebene versteckt sind, kann man die CDs auch unter Linux wunderbar nutzen. Die Lösung findet sich dann beispielsweise auf askubuntu.com: Die CD muss mit der Option unhide eingebunden werden.

Während normalerweise auch Nutzer CDs mounten können, muss dies in diesem Fall allerdings durch Root gemacht werden, da Nutzer keine Optionen beim Mounten angeben dürfen. Auf meinem openSUSE-System führe ich also folgende Schritte aus:

mkdir /tmp/klett
sudo mount -o unhide -t iso9660 /dev/sr0 /tmp/klett

Danach ist die CD mit allen Dateien in /tmp/klett verfügbar und ich kann z.B. mit einem xdg-open /tmp/klett/index.html den Inhalt öffnen.

Zur Erklärung der obigen Kommandozeile:

• Mit mkdir /tmp/klett lege ich ein temporäres Verzeichnis an. Es in /tmp anzulegen erspart es mir hinterher aufräumen zu müssen.
• sudo ist Notwendig, da ein normaler Nutzer keine Optionen angeben kann.
• -o unhide macht die normalerweise versteckten Dateien sichtbar.
• -t iso9660 gibt explizit an welches Dateisystem verwendet wird. mount kann dies normalerweise auch automatisch erkennen.
• /dev/sr0 ist mein optisches Laufwerk.

Für den Fall, dass Ihr der Mailingliste oder den openSUSE Gruppen in Social Media folgt, könntet ihr mitbekommen haben, dass die openSUSE Community ad-hoc board elections abhält, um einen offenen Platz im openSUSE Board zu füllen.

Solltet ihr das noch nicht gewusste haben, oder sogar wenn ihr das wusstet, könnte es dennoch sein, dass ihr verpasst habt, dass ich die Ehre habe von Gerald als Kandidat für die Wahl vorgeschlagen worden zu sein - und dass ich diese Nominierung angenommen habe.

Ic...

Letzte Woche habe ich Version 0.2.1 des Zypper-Patch-Status-Collectors veröffentlicht. Mit diesem kleinen, in Python geschriebenen, Helfer lässt sich der Aktualisierungsstand eines openSUSE-Systems durch Prometheus überwachen. Prometheus kann so nicht nur Alarme generieren wenn Sicherheitsaktualisierungen noch nicht angewandt sind, sondern auch wenn einzelne Dienste nach Aktualisierungen noch nicht neu gestartet wurden oder das System neu gestartet werden müsste.

Der Collector nutzt Zypper um nach ausstehen Patches und Service- oder Systemneustartbedarf zu schauen und gibt diese Information im Format von Prometheus-Metriken aus. Dies sieht dann so aus wie in der README beschrieben:

# HELP zypper_applicable_patches The current count of applicable patches
# TYPE zypper_applicable_patches gauge
zypper_applicable_patches{category="security",severity="critical"} 0
zypper_applicable_patches{category="security",severity="important"} 2
zypper_applicable_patches{category="security",severity="moderate"} 0
zypper_applicable_patches{category="security",severity="low"} 0
zypper_applicable_patches{category="security",severity="unspecified"} 0
zypper_applicable_patches{category="recommended",severity="critical"} 0
zypper_applicable_patches{category="recommended",severity="important"} 0
zypper_applicable_patches{category="recommended",severity="moderate"} 0
zypper_applicable_patches{category="recommended",severity="low"} 0
zypper_applicable_patches{category="recommended",severity="unspecified"} 0
zypper_applicable_patches{category="optional",severity="critical"} 0
zypper_applicable_patches{category="optional",severity="important"} 0
zypper_applicable_patches{category="optional",severity="moderate"} 0
zypper_applicable_patches{category="optional",severity="low"} 0
zypper_applicable_patches{category="optional",severity="unspecified"} 0
zypper_applicable_patches{category="feature",severity="critical"} 0
zypper_applicable_patches{category="feature",severity="important"} 0
zypper_applicable_patches{category="feature",severity="moderate"} 0
zypper_applicable_patches{category="feature",severity="low"} 0
zypper_applicable_patches{category="feature",severity="unspecified"} 0
zypper_applicable_patches{category="document",severity="critical"} 0
zypper_applicable_patches{category="document",severity="important"} 0
zypper_applicable_patches{category="document",severity="moderate"} 0
zypper_applicable_patches{category="document",severity="low"} 0
zypper_applicable_patches{category="document",severity="unspecified"} 0
zypper_applicable_patches{category="yast",severity="critical"} 0
zypper_applicable_patches{category="yast",severity="important"} 0
zypper_applicable_patches{category="yast",severity="moderate"} 0
zypper_applicable_patches{category="yast",severity="low"} 0
zypper_applicable_patches{category="yast",severity="unspecified"} 0
# HELP zypper_service_needs_restart Set to 1 if service requires a restart due to using no-longer-existing libraries.
# TYPE zypper_service_needs_restart gauge
zypper_service_needs_restart{service="nscd"} 1
zypper_service_needs_restart{service="dbus"} 1
zypper_service_needs_restart{service="cups"} 1
zypper_service_needs_restart{service="sshd"} 1
zypper_service_needs_restart{service="cron"} 1
# HELP zypper_product_end_of_life Unix timestamp on when support for the product will end.
# TYPE zypper_product_end_of_life gauge
zypper_product_end_of_life{product="openSUSE"} 1606694400
zypper_product_end_of_life{product="openSUSE_Addon_NonOss"} 1000000000000001
# HELP zypper_needs_rebooting Whether the system requires a reboot as core libraries or services have been updated.
# TYPE zypper_needs_rebooting gauge
zypper_needs_rebooting 0
# HELP zypper_scrape_success Whether the last scrape for zypper data was successful.
# TYPE zypper_scrape_success gauge
zypper_scrape_success 1

In diesem Beispiel stehen zwei Sicherheitspatches aus und mehrere Services, unter anderem der SSH Daemon, bräuchten einen Neustart weil sie noch mit bereits gelöschten, also durch ein Update ersetzten, Bibliotheken arbeiten.

Durch Umleiten der Ausgabe in eine prom Datei ins Textfile-Collector-Verzeichnis des Node-Exporters von Prometheus kommen die Metriken dann ins Monitoring. Wurde der Node-Exporter wie folgt aufgerufen:

node_exporter --collector.textfile.directory /var/lib/node_exporter/collector

Dann lassen sie die Metriken wie folgt in Prometheus abladen:

zypper-patch-status-collector > /var/lib/node_exporter/collector/zypper.prom

Stündlich per Systemd Timer aufgerufen hat Prometheus dann eine gute Übersicht über den Aktualisierungszustand der beobachteten openSUSE-Systeme.

Sind alle Metriken in Prometheus lassen sich dann auch verschiedene nützliche Alarme definieren. Das folgende ist die Liste der auf dem Collector basierenden Alarme die ich momentan in meinem Alertmanager definiert habe:

- alert: 'ZypperPatchesPending'
  expr: 'sum(zypper_applicable_patches) by (instance) > 0'
  for: '5m'
  labels:
    alert_severity: 'warning'
  annotations:
    summary: 'There are new patches available for {{ $labels.instance }}.'
    description: 'Run `zypper patch --with-update` on {{ $labels.instance }}.'
- alert: 'ZypperCriticalPatchesPending'
  expr: 'sum(zypper_applicable_patches{category="security"}) by (instance) + sum(zypper_applicable_patches{severity="critical"}) by (instance) > 0'
  for: '5m'
  labels:
    alert_severity: 'page'
  annotations:
    summary: 'There are security patches pending on {{ $labels.instance }}.'
    description: 'Run `zypper patch --with-update` on {{ $labels.instance }}.'
- alert: 'ZypperSuggestsServiceRestart'
  expr: 'zypper_service_needs_restart'
  for: '5m'
  labels:
    alert_severity: 'warning'
  annotations:
    summary: 'Zypper suggest to restart {{ $labels.service }} on {{ $labels.instance }}.'
    description: 'Run `systemctl restart {{ $labels.service }}` on {{ $labels.instance }}.'
- alert: 'ZypperSuggestsReboot'
  expr: 'zypper_needs_rebooting != 0'
  for: '5m'
  labels:
    alert_severity: 'warning'
  annotations:
    summary: 'Zypper suggest to reboot {{ $labels.instance }}.'
    description: 'Run `systemctl reboot` on {{ $labels.instance }}.'
- alert: 'ProductEndOfLifeNear'
  expr: 'zypper_product_end_of_life < time() + 4 * 7 * 24 * 3600'
  for: '5m'
  labels:
    alert_severity: 'warning'
  annotations:
    summary: '{{ $labels.product }} on {{ $labels.instance }} reaches end of life within four weeks.'
    description: 'Upgrade {{ $labels.product }} on {{ $labels.instance }} to the next version.'
- alert: 'ProductEndOfLifeReached'
  expr: 'zypper_product_end_of_life < time()'
  for: '5m'
  labels:
    alert_severity: 'page'
  annotations:
    summary: '{{ $labels.product }} on {{ $labels.instance }} reached end of life.'
    description: 'Upgrade {{ $labels.product }} on {{ $labels.instance }} to the next version.'
- alert: 'ZypperPatchDataOutdated'
  expr: 'time() - node_textfile_mtime{file="zypper.prom"} > 24 * 3600'
  for: '5m'
  labels:
    alert_severity: 'page'
  annotations:
    summary: 'Patch status has not been updated for 24 hours.'
    description: |
      The patch status of {{ $labels.instance }} has not been updated for 24 hours. Check the status of the timer and the service:
        systemctl status zypper-patch-status-collector.timer
        systemctl status zypper-patch-status-collector.service
- alert: 'ZypperScrapeFailed'
  expr: 'zypper_scrape_success == 0'
  for: '24h'
  labels:
    alert_severity: 'page'
  annotations:
    summary: 'Failed to successfully query patch status for 24 hours now.'
    description: |
      Querying zypper for the current patch status has not been successful for 24 hours. Check the status of the service:
        systemctl status zypper-patch-status-collector.service

Die Installation des Collectors erfolgt am einfachsten über mein Community-Paket auf software.opensuse.org. Ich veröffentliche das Paket zwar auch auf pypi.org, aber ein Werkzeug mit Bezug zu Zypper am System vorbei zu installieren wäre dann doch etwas sehr verquer.