openSUSE Planet - DeutschPlanet openSUSE site providing newest news from the openSUSE Projecthttps://planet.opensuse.org/images/icon.svghttps://planet.opensuse.org/images/logo.svg2024-03-29T09:04:24+00:00https://planet.opensuse.org/de/Plutotag:marix.org,2024-03-24:/am-linuxrechner-bluetooth-per-usb-nachrusten.htmlMatthias Bachhttps://marix.org2024-03-23T23:00:00+00:002024-03-23T23:00:00+00:00Am Linuxrechner Bluetooth per USB nachrüsten<p>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.</p>
<p>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.</p>tag:marix.org,2024-01-06:/minecraft-auf-opensuse-leap-155.htmlMatthias Bachhttps://marix.org2024-01-06T14:00:00+00:002024-01-06T14:00:00+00:00Minecraft auf openSUSE Leap 15.5<p>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.</p>
<p><img alt='Bildschirmfoto der Fehlermeldung "Spielabsturz" beim Versuch Minecraft 1.20.4 auf openSUSE Leap 15.5 zu starten' src="//marix.org/Bilder/Minecraft%20auf%20OpenSUSE%20Leap%2015.5/Fehlermeldung.png"></p>
<p>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:</p>
<pre><code>#
# 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
#
</code></pre>
<p>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.</p>
<p>Glücklicherweise lässt sich die von Minecraft verwendete Java-Laufzeitumgebung konfigurieren.
Diese findet sich im Abschnitt "Mehr Optionen" der Installationseinstellungen.
Tragen wir hier <code>/usr/bin/java</code> ein, so wird das aktuellste auf dem System installierte Java verwendet.</p>
<p><img alt="Bildschirmfoto der Auswahl der Java-Programmdatei in der Konfiguration einer Minecraft-Installation" src="//marix.org/Bilder/Minecraft%20auf%20OpenSUSE%20Leap%2015.5/Konfiguration%20der%20Java-Version.png"></p>
<p>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.</p>
<p>Die Konfiguration einer Installation von Minecraft finden wir übrigens unter „Bearbeiten“ im erweiterten Menü der Installation im Reiter „Installationen“.</p>
<p><img alt="Bildschirmfoto vom Zugang zur Installationskonfiguration" src="//marix.org/Bilder/Minecraft%20auf%20OpenSUSE%20Leap%2015.5/Zugang%20zu%20den%20Einstellungen%20einer%20Installation.png"></p>
<p>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:</p>
<pre><code>sudo zypper in java-17-openjdk
</code></pre>
<p>Danach können wir dann endlich Minecraft auf openSUSE Leap 15.5 genießen.</p>
<p><img alt="Bildschirmfoto eines laufenden Minecraft 1.20.4 auf openSUSE Leap 15.5" src="//marix.org/Bilder/Minecraft%20auf%20OpenSUSE%20Leap%2015.5/Erfolg.png"></p>tag:marix.org,2022-02-07:/pre-commit-auf-opensuse-leap-154.htmlMatthias Bachhttps://marix.org2022-02-06T23:00:00+00:002022-02-06T23:00:00+00:00Pre-commit auf openSUSE Leap 15.4<p>Beim Upgrade von openSUSE Leap 15.3 auf openSUSE Leap 15.4 ergibt sich bei <a href="https://pre-commit.com/"><code>pre-commit</code></a> ein interessantes Problem.
Auf älteren Versionen von Leap konnte das Paket aus dem <a href="https://build.opensuse.org/project/show/devel:languages:python">Entwicklungsprojekt <code>devel:languages:python</code></a> installiert werden.
Dort findet sich aber keine Version für Leap 15.4.
Eine solche findet sich jetzt in meinem Projekt <a href="https://build.opensuse.org/package/show/home%3AtheMarix%3Apy36/python-pre-commit"><code>home:theMarix:py36</code></a> und lässt sich von dort einfach installieren:</p>
<pre><code>zypper addrepo https://download.opensuse.org/repositories/home:theMarix:py36/15.4/home:theMarix:py36.repo
zypper refresh
zypper install python3-pre-commit
</code></pre>
<p>Das Problem entsteht, weil <a href="https://pre-commit.com/"><code>pre-commit</code></a> 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.
<a href="https://pre-commit.com/"><code>pre-commit</code></a> 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 <code>devel:languages:python</code> 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.</p>
<p>Im Projekt <a href="https://build.opensuse.org/package/show/home%3AtheMarix%3Apy36/python-pre-commit"><code>home:theMarix:py36</code></a> befindet sich jetzt einfach ein Link auf die letzte Revision des Pakets in <code>devel:languages:python</code> die noch mit Python 3.6 kompatibel war.
So gibt es jetzt zwar leider keine aktuelle Version von <a href="https://pre-commit.com/"><code>pre-commit</code></a> 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.</p>tag:marix.org,2022-01-29:/ktorrent-friert-ein.htmlMatthias Bachhttps://marix.org2022-01-28T23:00:00+00:002022-01-28T23:00:00+00:00KTorrent friert ein<p>Die Tage musste ich leider Feststellen, dass mein KTorrent beim Download der aktuellen <a href="https://haveibeenpwned.com/Passwords">Pwned-Passwords-List von Have I been Pwned</a> komplett einfror.
<a href="https://www.qwant.com/?q=ktorrent+freezes">Eine Suche nach dem Problem</a> liefert nicht viele Treffer, aber fördert <a href="https://forums.opensuse.org/showthread.php/523076-Ktorrent-freeze-and-Firefox">einen 5 Jahre alten Forenbeitrag zutage, der eine Lösung für das Problem liefert</a>.
Den Firefox einmal kurz zu schließen taut KTorrent wieder auf.</p>
<p>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:</p>
<ol>
<li>Ist KTorrent bereits gestartet bevor Firefox die Datei übergibt, so scheint das Problem nicht aufzutreten.</li>
<li>Kopiert man die URL der Torrent-Datei in die Zwischenablage, kann man diese auch aus KTorrent direkt mit <em>Datei - Adresse öffnen</em> bzw. <code>Strg+P</code> öffnen und umgeht die Interaktion zwischen Firefox und KTorrent komplett.</li>
</ol>tag:marix.org,2022-01-28:/bootprobleme-mit-leap-153-und-radeon-grafik.htmlMatthias Bachhttps://marix.org2022-01-27T23:00:00+00:002022-02-06T23:00:00+00:00Bootprobleme mit Leap 15.3 und Radeon-Grafik<p>Mit dem am Mittwoch durch den Patch <code>openSUSE-SLE-15.3-2022-198</code> gelieferten Kernel mit Version <code>5.3.18-150300.59.43.1</code> 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 <code>nomodeset</code> gestartet werden.</p>
<p>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 <a href="https://marix.org/alte-kernelversionen-installiert-behalten.html">einem älteren Artikel von mir</a>.</p>
<p>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 <code>nomodeset</code> umgehen.
Am einfachsten lässt sich dieser über das Modul <em>Bootloader</em> im Abschnitt <em>System</em> 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.</p>
<p>Um den Bootparameter beim Start manuell zu setzen muss im Bootmenü die Taste <code>E</code> gedrückt werden.
Dies öffnet den gerade ausgewählten Startmenüeintrag in einem einfachen Editor.
Hier ist die mit <code>linux</code> beginnende Zeile zu suchen und an deren Ende der Parameter <code>nomodeset</code> hinzuzufügen.
Durch einen Druck auf <code>F10</code> 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.</p>
<p>Mehr Informationen zu diesem Problem finden sich <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1195168">im Bugzilla</a>.
Dort gibt es auch schon eine verifizierte richtige Lösung des Problems, welche im nächsten Kernel-Patch dann enthalten sein dürfte.</p>
<p><strong>Aktualisierung vom 7.2.2022</strong>: Mit dem Update <code>openSUSE-SLE-15.3-2022-340</code>, welches den Kernel auf Version <code>5.3.18-150300.59.46</code> hebt, ist das Problem behoben.
Die betroffenen Systeme starten auch ohne den Workaround <code>nomodeset</code> 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.</p>tag:marix.org,2021-03-06:/opensuse-leap-151-mit-usb-stick-als-schlussel-fur-die-festplattenverschlusselung.htmlMatthias Bachhttps://marix.org2021-03-05T23:00:00+00:002023-06-09T22:00:00+00:00openSUSE Leap 15.1 mit USB-Stick als Schlüssel für die Festplattenverschlüsselung<p>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 <a href="https://marix.org/usb-stick-als-schl%C3%BCssel-f%C3%BCr-die-festplattenverschl%C3%BCsselung.html">schon damals hier im Blog dokumentiert</a>.
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.</p>
<h2 id="festplattenverschlusselung">Festplattenverschlüsselung</h2>
<p>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 <code>/boot</code> 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.</p>
<p>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.</p>
<h2 id="usb-stick-als-schlussel">USB-Stick als Schlüssel</h2>
<p>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 <code>/dev/sdb</code> im System zu sehen, kann er wie folgt passend formatiert werden.</p>
<pre><code>mkfs.ext2 -L keystick /dev/sdb
</code></pre>
<p>Das Label <code>keystick</code> 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.</p>
<p>Anschließend sollte ein Schlüssel generiert und auf dem USB-Stick hinterlegen werden. Dies kann mit <code>pwgen</code> gemacht werden:</p>
<pre><code>pwgen -s 1024 1 > /media/keystick/keyfile
</code></pre>
<p>Und schließlich muss der Schlüssel der verschlüsselten Partition hinzugefügt werden.</p>
<pre><code>cryptsetup luksAddKey /dev/sda2 /media/keystick/keyfile
</code></pre>
<p>In diesem Beispiel befindet sich die verschlüsselte Partition auf <code>/dev/sda2</code>.</p>
<h2 id="usb-stick-beim-booten-nutzen">USB-Stick beim Booten nutzen</h2>
<p>Um den Schlüssel beim Booten vom USB-Stick zu lesen muss der Kernelparameter <code>rd.luks.key</code> auf die Schlüsseldatei zeigen.</p>
<pre><code>rd.luks.key=/keyfile:LABEL=keystick
</code></pre>
<p>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.</p>
<p>Damit der Parameter <code>rd.luks.key</code> 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 <code>/etc/dracut.conf.d/50-keystick.conf</code> mit folgendem Inhalt anzulegen:</p>
<pre><code>omit_dracutmodules+=" systemd "
</code></pre>
<p>Die Leerzeichen im Wert sind hier Absicht.
Ohne diese wirft Dracut eine Warnung:</p>
<pre><code>dracut: WARNING: <key>+=" <values> ": <values> should have surrounding white spaces!
dracut: WARNING: This will lead to unwanted side effects! Please fix the configuration file.
</code></pre>
<p>Ein anschließendes <code>mkinitrd</code> erzeugt eine Initrd ohne Systemd und das System kann zukünftig bei eingestecktem USB-Stick ohne Passworteingabe gestartet werden.</p>
<h2 id="vorteile-gegenuber-der-alten-methode">Vorteile gegenüber der alten Methode</h2>
<p><a href="https://marix.org/usb-stick-als-schl%C3%BCssel-f%C3%BCr-die-festplattenverschl%C3%BCsselung.html">Bei der alten Methode</a> 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.</p>tag:marix.org,2021-03-06:/die-beta-von-opensuse-leap-153-ist-da.htmlMatthias Bachhttps://marix.org2021-03-05T23:00:00+00:002021-03-05T23:00:00+00:00Die Beta von openSUSE Leap 15.3 ist da<p>Diese Woche <a href="https://news.opensuse.org/2021/03/03/opensuse-leap-153-reaches-beta-build-phase/">erschien die Beta von openSUSE Leap 15.3</a>, 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.</p>
<p>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.</p>
<p>Auch <a href="https://marix.org/opensuse-leap-151-mit-usb-stick-als-schlussel-fur-die-festplattenverschlusselung.html">meine Methode zum Booten mit Keystick</a> funktioniert mit der Beta von Leap 15.3 wunderbar.</p>
<p>Einen kleinen Stolperer gibt es momentan noch beim <a href="https://en.opensuse.org/SDB:System_upgrade#Running_the_Upgrade">Onlineupgrade</a> auf die Beta, zumindest wenn man bereits den Weg mit der Variablen <code>releasever</code> in den Quellen für die Paketpfade nimmt.
Nach dem Update <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1182951">zeigt <code>/etc/products.d/baseproduct</code> ins Leere</a>.
Das hat zur Folge, dass Zypper die Paketquellen nicht mehr findet:</p>
<pre><code>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.
</code></pre>
<p>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.</p>
<pre><code>sudo rm /etc/products.d/baseproduct && sudo ln /etc/products.d/Leap.prod /etc/products.d/baseproduct
</code></pre>
<p>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.</p>tag:marix.org,2021-01-04:/cd-roms-von-klett-unter-linux-nutzen.htmlMatthias Bachhttps://marix.org2021-01-03T23:00:00+00:002021-01-03T23:00:00+00:00CD-ROMs von Klett unter Linux nutzen<p>Der <a href="https://www.klett.de">Klett Verlag</a> 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 <code>index.html</code> 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 <code>index.hml</code> sichtbar zu schalten.</p>
<p>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 <a href="https://askubuntu.com/questions/370906/unable-to-see-files-in-dvd-hidden-using-windows-7">auf askubuntu.com</a>: Die CD muss mit der Option <code>unhide</code> eingebunden werden.</p>
<p>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:</p>
<pre><code>mkdir /tmp/klett
sudo mount -o unhide -t iso9660 /dev/sr0 /tmp/klett
</code></pre>
<p>Danach ist die CD mit allen Dateien in <code>/tmp/klett</code> verfügbar und ich kann z.B. mit einem <code>xdg-open /tmp/klett/index.html</code> den Inhalt öffnen.</p>
<p>Zur Erklärung der obigen Kommandozeile:</p>
<ul>
<li>Mit <code>mkdir /tmp/klett</code> lege ich ein temporäres Verzeichnis an. Es in <code>/tmp</code> anzulegen erspart es mir hinterher aufräumen zu müssen.</li>
<li>
<code>sudo</code> ist Notwendig, da ein normaler Nutzer keine Optionen angeben kann.</li>
<li>
<code>-o unhide</code> macht die normalerweise versteckten Dateien sichtbar.</li>
<li>
<code>-t iso9660</code> gibt explizit an welches Dateisystem verwendet wird. <code>mount</code> kann dies normalerweise auch automatisch erkennen.</li>
<li>
<code>/dev/sr0</code> ist mein optisches Laufwerk.</li>
</ul>https://crowbyte.org/de/running-for-the-opensuse-board-ad-hoc-board-elections-2020Pierre Böckmannhttps://crowbyte.org/de/2020-08-21T13:20:00+00:002020-08-21T13:20:00+00:00Ich kandidiere für das openSUSE board - ad-hoc board elections 2020<p>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.</p><p>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.</p><p>Ic...</p>tag:marix.org,2020-06-21:/den-aktualisierungsstand-von-opensuse-mit-prometheus-uberwachen.htmlMatthias Bachhttps://marix.org2020-06-20T22:00:00+00:002020-06-20T22:00:00+00:00Den Aktualisierungsstand von openSUSE mit Prometheus überwachen<p>Letzte Woche habe ich Version 0.2.1 des <a href="https://gitlab.com/Marix/zypper-patch-status-collector">Zypper-Patch-Status-Collectors</a> 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.</p>
<p>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:</p>
<pre><code># 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
</code></pre>
<p>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.</p>
<p>Durch Umleiten der Ausgabe in eine <code>prom</code> Datei ins Textfile-Collector-Verzeichnis des Node-Exporters von Prometheus kommen die Metriken dann ins Monitoring.
Wurde der Node-Exporter wie folgt aufgerufen:</p>
<pre><code>node_exporter --collector.textfile.directory /var/lib/node_exporter/collector
</code></pre>
<p>Dann lassen sie die Metriken wie folgt in Prometheus abladen:</p>
<pre><code>zypper-patch-status-collector > /var/lib/node_exporter/collector/zypper.prom
</code></pre>
<p>Stündlich per Systemd Timer aufgerufen hat Prometheus dann eine gute Übersicht über den Aktualisierungszustand der beobachteten openSUSE-Systeme.</p>
<p>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:</p>
<pre><code>- 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
</code></pre>
<p>Die Installation des Collectors erfolgt am einfachsten über <a href="https://software.opensuse.org/package/python3-zypper-patch-status-collector">mein Community-Paket auf software.opensuse.org</a>.
Ich veröffentliche das Paket zwar auch <a href="https://pypi.org/project/zypper-patch-status-collector/">auf pypi.org</a>, aber ein Werkzeug mit Bezug zu Zypper am System vorbei zu installieren wäre dann doch etwas sehr verquer.</p>