Marix.org

Wenn Workflows in Codeberg CI nicht starten wollen

2025-06-22T00:00:00+02:00

Codeberg ist eine großartige Plattform für Codehosting, die durch einen Verein unabhängig von finanziellen Interessen und in Europa betrieben wird. Sie bietet viele der Funktionen, die GitHub so beliebt gemacht haben, darunter auch Codeberg CI, das es ermöglicht, Workflows auf Commits und Pull Requests auszuführen. Gestern rannte ich jedoch wieder einmal in das Problem, dass Workflows nicht starten wollten. Da das Problem und seine Lösung zwar in einem Issue auf Codeberg erwähnt werden, dieser aber nicht schnell zu finden ist und die Lösung auch nur skizziert, möchte ich diese hier auch nochmal dokumentieren.

Das Problem

Nachdem ein neuer Commit zu Codeberg geschickt wurde, startet der Workflow nicht. Beim Öffnen des Workflows wird angezeigt, dass ein Fehler aufgetreten ist.

Geht man auf „Fehler anzeigen“, wird angezeigt:

could not load config from forge: %!w()

Startet man den Werkflow über die Schaltfläche „Neustarten“ in der oberen rechten Ecke neu, so ändert sich die Fehlermeldung zu:

pipeline definition not found

Dieses Problem tritt auch bei Workflows auf, die zuvor einwandfrei funktioniert haben. Die Ursache für dieses Verhalten liegt oft in der hohen Last auf Codeberg, die durch DOS-Angriffe oder KI-Scraper verursacht wird. Diese hohe Last kann dazu führen, dass Events verloren gehen, was wiederum zu diesem Zustand führt.

Die Lösung

Die Lösung für dieses Problem besteht darin, einen neuen Commit zu pushen. Mit der folgenden Technik kann dies ohne zusätzliche Änderungen am Code erfolgen.

Lokalen Commit anpassen: Folgender Befehl, auf dem lokalen Branch ausgeführt, erstellt einen Commit, der dem alten entspricht, aber eine neue Prüfsumme hat:
```
git commit --amend --allow-empty
```
Den neuen Commit zu Codeberg schieben: Folgender Befehl überschreibt den letzten stand auf Codeberg mit dem neu erstellten Commit.
```
git push --force-with-lease
```

Wichtig: Diese Technik darf nur verwendet werden, wenn man sich sicher ist, dass niemand anderes mit dem Branch arbeitet. Ansonsten bekommt die anderen Nutzer:innen Probleme, wenn die den Branch aktualisieren wollen. Wenn es doch notwendig sein sollte, dann solten die anderen Nutzer:innen informiert werden, sodass sie beim nächsten Pull die Rebase-Strategie verwenden.

Fazit

Trotz dieses kleinen Problems is Codeberg eine großartige Plattform, die ich gerne nutze. Kennt man das Problem und die Lösung, ist es auch, falls es auftritt, schnell behoben.

Damit Codeberg weiter eine großartige Plattform bleibt, ist es wichtig, dass wir sie unterstützen. Ich tue dies aktuell, mangels Zeit für ein ehrenamtliches Engagement, durch eine Födermitgliedschaft.

Spielen auf openSUSE

2025-06-16T00:00:00+02:00

Im Blog von openSUSE erschient Anfang des Jahres ein Artikel über das Spielen auf openSUSE. Der Artikel ist ein toller Startpunkt um sich openSUE fürs Gaming perfekt einzurichten und beschreibt tatsächlich ziemlich genau auch mein System:

Steam um einfach Spiele zu installieren die ich auch auf dem Steam Deck nutzen will.
Lutris um meine Spielesammlung zu verwalten und auch um von Gog.com und anderen zu installieren.
Die proprietären Nvidia-Treiber, da ich eine Nvidia-Grafikkarte nutze.
MangoHud um die FPS und andere Statistiken im Spiel anzuzeigen.
GameMode um die Energieverwaltung des Systems automatisch umzustellen.

Die größte Abweichung zwischen meinem System und dem Artikel liegt darin, dass ich Leap verwende, während der Artikel auf Tumbleweed eingeht. Meine Entscheidung liegt hier vor allem darin begründet, dass vor langer Zeit die Nutzung der Nvidia-Treiber auf Leap einfacher war. Außerdem habe ich so auf allen openSUSE-Systemen in der Familie die gleiche Basis.

Außer dem Nvidia-Treiber erwähnt der Artikel auch die, keine weitere Konfiguration benötigende, Unterstützung von AMD-Grafikkarten. Von dieser werde ich, bei der aktuellen Entwicklung des Grafikkartenmarktes, wohl auch beim nächsten Hardware-Upgrade profitieren.

Ein Werkzeug, das ich regelmäßig nutze, fehlt im Artikel: Piper. Damit verwalte ich die Profile meiner Maus.

Besonders hat mich gefreut, dass der Artikel mit GameMode auch ein Werkzeug erwähnt, dass ich vor langer Zeit mal in die Distribution gebracht habe. Es ist immer schön zu sehen, wenn Pakete tatsächlich auch von anderen genutzt und geschätzt werden, und man nicht nur für sich selbst gearbeitet hat.

Tailscale auf Android automatisch starten

2025-06-05T00:00:00+02:00

Die meisten Android-Apps, die dauerhaft im Hintergrund laufen sollen, bieten eine Option zum automatischen Start an. Bei Tailscale fehlt diese Option allerdings. Das wirkt auf den ersten Blick etwas seltsam, denn als VPN sollte Tailscale seine Arbeit ja eigentlich dezent im Hintergrund erledigen.

Tatsächlich benötigt Tailscale aber keine spezielle Einstellung, um im Hintergrund zu laufen, denn Android hat dafür eine eigene Einstellung. Diese findet sich in den Einstellungen unter „Netzwerk & Internet“ > „VPN“ > „Tailscale“ > „Durchgehend aktives VPN“. Zumindest ist dies unter Android 14 der Fall. Die Struktur der Einstellungen ändert sich bei Android ja häufiger mal mit neuen Versionen.

Ob der Netzwerkverkehr dann über einen VPN-Tunnel läuft, hängt dann von der Konfiguration in der Tailscale-App ab. Nur wenn dort ein Exit-Node konfiguriert ist, wird der gesamte Netzwerkverkehr über Tailscale geleitet. Ansonsten wird nur der Verkehr zu anderen Tailscale-Geräten über den VPN-Tunnel geleitet. Der restliche Verkehr läuft dann zwar auf dem Gerät einmal durch Tailscale, verlässt das Gerät dann aber wie ohne VPN.

Wenn die PineTime nur noch das Infinitime-Logo anzeigt

2025-06-01T00:00:00+02:00

Kürzlich begrüßte mich meine PineTime mit dem InfiniTime-Logo und tat nichts weiter. Ich schloss sofort, dass die Uhr abgestürzt und im Recovery-Modus gelandet war. Ein Neustart sollte das Problem beheben, dieser brachte mich aber nur wieder in den Recovery-Modus.

Eine kurze Recherche führte mich zu einem alten Fehlerbericht im InfiniTime-Repository. Die Uhr befand sich tatsächlich im Recovery-Modus. Ich hatte es aber wohl geschafft die Uhr im Schlaf gleich mehrfach neu zu starten. Daraufhin ging die Uhr von einer fehlerhaften Firmware aus und löschte diese, sodass sie nur noch im Recovery-Modus starten konnte.

Glücklicherweise verbindet sich die Uhr auch im Recovery-Modus noch automatisch mit Gadgetbridge. Damit lässt sich dann auf dem normalen Weg, wie auch bei einem normalen Update, die Firmware neu aufspielen.

Nachdem die Firmware neu aufgespielt ist und die Uhr neu gestartet hat, darf man dann lediglich nicht vergessen diese, auch hier genau wie bei einem Update, wieder neu zu bestätigen. Ansonsten landet man beim nächsten, gewollten oder ungewollten, Neustart wieder im gleichen Zustand.

Der yt-dlp Spickzettel

2025-03-30T00:00:00+01:00

yt-dlp ist ein leistungsstarkes Kommandozeilen-Tool zum Herunterladen von Videos und Audiodateien von einer Vielzahl von Websites, darunter YouTube, Vimeo, die Mediatheken der öffentlich-rechtlichen Sender, und viele andere. Es ist eine Weiterentwicklung des ursprünglichen youtube-dl und bietet zahlreiche zusätzliche Funktionen und Verbesserungen. Allerdings kann einen die Vielzahl an Optionen und Parametern, die ein Aufruf von yt-dlp --help ausspuckt, und die auch https://github.com/yt-dlp/yt-dlp dokumentiert, schnell überfordern. Deshalb hier ein Spickzettel mit den wichtigsten Optionen und Parametern, die ich häufig benutze.

Die Kommandozeile

yt-dlp ist eine Kommandozeilenanwendung. Als solche muss sie über eine Konsole oder ein Terminal aufgerufen werden. Sie nimmt ihren exakten Arbeitsauftrag beim Auftrag durch Optionen und Argumente entgegen. Die grundlegende Syntax für yt-dlp lautet:

yt-dlp [OPTIONEN...] URL [URL...]

Hierbei ist:

URL: Die URL einer Webseite auf der sich der herunterzuladende Inhalt befindet.
OPTIONEN...: Verschiedene Optionen, die das Verhalten von yt-dlp steuern. Diese haben üblicherweise die Form --option oder --option wert. Mehrere Optionen können durch Leerzeichen getrennt angegeben werden.

Ein Video herunterladen

Um ein Video herunterzuladen, reicht folgender Befehl:

yt-dlp https://example.com/seite/mit/video

In diesem Fall lädt yt-dlp das Video von der angegebenen URL herunter und speichert es im aktuellen Verzeichnis. Hierbei wählt es automatisch das Format mit der besten verfügbaren Qualität aus.

Handelt sich bei dem Medieninhalt auf der Webseite um eine Audiodatei, wird diese ebenfalls heruntergeladen. Allerdings wird diese in diesem Fall oft nicht in einem der gebräuchlichen Audioformate gespeichert, sodass nicht jedes Abspielgerät mit diesen Dateien zurechtkommt.

Nur Audio herunterladen

yt-dlp kann auch explizit nur die Audiodatei herunterladen. In diesem Fall wird die Audiodatei in einem der gebräuchlichen Audioformate gespeichert.

yt-dlp --extract-audio https://example.com/seite/mit/audio

Dies funktioniert insbesondere auch bei Webseiten, die Videos mit einer Audiospur anbieten. So lässt sich zum Beispiel die Audiospur eines Videos herunterladen, ohne das Video selbst zu speichern.

yt-dlp --extract-audio https://example.com/seite/mit/video

Ausgabeformat festlegen

Soll yt-dlp die heruntergeladenen Dateien in einem bestimmten Format speichern, kann dies mit der Option --merge-output-format angegeben werden. Um beispielsweise die heruntergeladenen Videos im MP4-Format zu speichern, lautet der Befehl:

yt-dlp --merge-output-format mp4 https://example.com/seite/mit/video

In diesem Fall wählt yt-dlp automatisch das beste verfügbare, in einem MP4 speicherbare, Videoformat aus und speichert es zusammen mit der Audiospur in einer MP4-Datei.

Dies funktioniert auch bei Audiodateien. Für diese gibt es aber nochmal einen eigenen Parameter, der die Audiodatei in einem bestimmten Format speichert. Dieser Parameter heißt --audio-format und sollte in Kombination mit der Option --extract-audio verwendet werden. Um beispielsweise die heruntergeladene Audiodatei im MP3-Format zu speichern, lautet der Befehl:

yt-dlp --extract-audio --audio-format mp3 https://example.com/seite/mit/audio

Dateiname anpassen

Der Parameter --output ermöglicht es, den Dateinamen der heruntergeladenen Datei anzupassen. Hierbei ist es wichtig, dass der Dateiname immer auf %(ext)s endet. yt-dlp ersetzt diesen Platzhalter durch die Dateierweiterung des heruntergeladenen Inhalts. Da yt-dlp während des Downloads aber verschiedene temporäre Dateien anlegt, braucht es diesen Platzhalter um Kollisionen zu vermeiden, auch wenn explizit eine MP4-Datei heruntergeladen wird.

yt-dlp --output "mein_video.%(ext)s" --merge-output-format mp4 https://example.com/seite/mit/video

In diesem Fall wird die heruntergeladene Datei in mein_video.mp4 gespeichert.

Mehrere Dateien herunterladen

Übergibt amn yt-dlp mehrere URLs, lädt yt-dlp alle angegebenen Dateien herunter.

yt-dlp https://example.com/seite/mit/video1 https://example.com/seite/mit/video2

Außerdem erkennt yt-dlp auf vielen Seiten auch Playlisten und lädt alle Videos in der Playlist herunter.

yt-dlp https://example.com/seite/mit/playlist

Weiterführende Links

Diese Liste kratzt natürlich nur an der Oberfläche. Alle möglichkeiten yt-dlp aufzurufen, um Beispielsweise mehrere Tonspuren in bestimmten Sprachen herunterzuladen, finden sich in der Hilfe, die mit yt-dlp --help aufgerufen werden kann. Außerdem gibt es auf https://yt-dlp-docs.netlify.app/ eine umfangreiche inoffizielle Dokumentation in englischer Sprache mit vielen Beispielen.

Avidemux Warteschlange: Effiziente Videobearbeitung im Handumdrehen

2025-03-29T00:00:00+01:00

Avidemux ist ein beliebtes Open-Source-Tool zur Videobearbeitung, das sich durch seine Benutzerfreundlichkeit und Vielseitigkeit auszeichnet. Ein oft übersehenes, aber äußerst nützliches Feature ist die Warteschlange, die es ermöglicht, mehrere Videos zu schneiden und anschließend in einem Rutsch zu verarbeiten. Doch wie nutzt man diese Funktion? Außer einem Menüeintrag um „Zur Warteschlange hinzufügen“ gibt es im Benutzerinterface von Avidemux nämlich keine weiteren Hinweise darauf, dass Avidemux eine Warteschlange hat.

Aufträge zur Warteschlange hinzufügen

Dieser Teil ist noch einfach. Anstatt das Video zu speichern, wählt man im Datei-Menü den Eintrag "Zur Warteschlange hinzufügen" um Aufträge zur Warteschlange hinzufügen.

Verwaltung und Ausführung der Warteschlange

Für die Verwaltung und Ausführung der Warteschlange gibt es ein eigenes Benutzerinterface: Avidemux Jobs. Leider hat dieses Interface keinen Eintrag im Startmenü, was die Nutzung erschwert. Um Avidemux Jobs zu starten, muss man die Anwendung direkt über die Konsole aufrufen. Der Name der ausführbaren Datei beginnt immer mit avidemux3_jobs_, gefolgt vom Namen des UI-Toolkits. Auf openSUSE lautet der Name beispielsweise avidemux3_jobs_qt5.

Abhängigkeit von Avidemux Kommandozeilenversion

Avidemux Jobs verwendet standardmäßig die Kommandozeilenversion von Avidemux zur Abarbeitung der Warteschlange. Daher muss diese installiert sein. Sollte die Kommandozeilenversion nicht verfügbar sein, kann man Avidemux Jobs anweisen, die QT-Version zu verwenden.

Manueller Startmenü-Eintrag

Umgebungen wie KDE ermöglichen es, manuell einen Startmenü-Eintrag für Avidemux Jobs anzulegen. Dies spart den Umweg über die Konsole und erleichtert den Zugriff auf das Tool.

Zukünftige Verbesserungen

Um das Problem für zukünftige Versionen zu lösen, habe ich einen Pull Request bei Avidemux eingereicht, der einen Startmenü-Eintrag für Avidemux Jobs anlegt. Bleibt zu hoffen, dass dieser in einer der nächsten Versionen von Avidemux integriert wird.

GIMP im Einzelfenster-Modus nutzen

2025-03-28T00:00:00+01:00

GIMP startet standardmäßig im Mehrfenster-Modus, was heutzutage eher ungewöhnlich ist. Wer lieber den in den meisten Anwendungen üblichen Einfenster-Modus nutzen möchte, kann ganz einfach über das Menü darauf wechseln.

Die Option „Einzelfenster-Modus“ findet sich in der Menüleiste unter „Fenster“.

Eventuell fehlende Dialoge, wie die Werkzeugeinstellungen, können anschließend über den Abschnitt „Andockbare Dialoge“ im Fenster-Menü hinzugefügt werden.

Mit einem aktuellen Android mit dem VPN einer alten FRITZ!Box verbinden

2024-05-24T00:00:00+02:00

Wer in die Verlegenheit kommt sich von einem aktuellen Android mit dem VPN einer älteren FRITZ!Box, wie der 7560, verbinden zu müssen, stellt schnell fest, dass sich der von der FRITZ!Box gewünschte VPN-Typ "IPSec" oder "IPSec Xauth PSK" im VPN-Dialog von Android nicht auswählen lässt. Android hat diese auf dem veralteten Anmeldeverfahren IKEv1 basierenden Typen nämlich in Version 12 rausgeworfen. AVM unterstützt die moderneren Anmeldeverfahren auf Basis von IKEv2 aber erst ab FRITZ!OS 7.50. Und dieses ist nicht mehr für alle noch unterstützten FRITZ!Boxen erschienen.

Eine Lösung für diese Problem ist auf dem Androiden die App VpnCilla zu installieren. Diese dient ausschließlich dazu sich mit alten IKEv1-VPNs zu verbinden. Bevor ihr diese kauft empfiehlt es sich zunächst einmal die Probeversion VpnCilla (Trial) auszuprobieren. Klappt alles und ihr möchtet die App über den Probezeitraum hinaus verwenden, so lassen sich die Einstellungen anschließend auch in die Vollversion übernehmen.

Für meinen Ursprünglichen Einsatzzweck, ich brauchte für ein Wochenende die Option Verbindungen ins Internet über einen bestimmten Anschluss umzuleiten, hätte mir die Probeversion übrigens völlig ausgereicht. Da das zu meiner völligen Zufriedenheit funktioniert hat, habe ich mir dann anschließend trotzdem, als Dankeschön an den Autor, die Vollversion gekauft. Diese habe ich seitdem auch gelegentlich mal wieder genutzt habe. Dabei ist es mir dann auch durchaus mal passiert, dass ich einen ganzen Tag mit aktivem VPN herumgelaufen bin, weil ich vergessen hatte es Abzuschalten und es auch nicht zu irgendwelchen Problem geführt hätte, die mich das hätten merken lassen.

Was die Nutzung des veralteten VPN-Typs angeht, so sollte natürlich, wenn möglich, schon besser ein aktueller genutzt werden. Bei aktuellen FRITZ!Boxen bietet sich hierbei die Nutzung von Wireguard an. Geht es aber nur darum die eigene Internetnutzung über einen bestimmten Anschluss umzuleiten und sind im Netz der FRITZ!Box keine sonstigen offenen Dienste, so sollte die Nutzung der älteren VPN-Typen unproblematisch. Der Austausch der FRITZ!Box würde in diesem Fall nur Elektroschrott produzieren, denn schlimmstenfalls reduziert ein angreifbares VPN die Sicherheit ja darauf, dass die Geräte im VPN und an der FRITZ!Box effektiv direkt im Internet stehen.

Widerspenstige DVDs auslesen

2024-04-06T00:00:00+02:00

Normalerweise ist Handbrake ja eine zuverlässige und einfache Lösung wenn es darum geht DVDs für die Wiedergabe auf Geräten ohne optisches Laufwerk in eine Videodatei zu wandeln. Bei einer DVD rannte ich dabei jetzt aber in ein kurioses Problem. Nach ungefähr der Hälfte des Umwandlungsprozesses sagte Handbrake es sei fertig. Die Videodatei enthielt dann aber auch nur die Hälfte des Films.

Online finden sich verschiedene Erklärungen für dieses Phänomen. Nur passten Erklärungen wie eine überlastete CPU oder Leseprobleme von der DVD nicht zu meiner Situation. Handbrake hatte die CPU quasi für sich alleine. Und das Problem trat auch auf wenn ich die Daten aus einem mit dvdbackup erstellten Abbild auf SSD einlas.

Auch der VLC tat sich mit dieser DVD erstaunlich schwer. Er erzeugte zwar eine Videodatei welche den kompletten Film enthielt, doch Ton und Bild waren asynchron. Außerdem scheint VLC es nicht zu unterstützen eine Datei mir mehreren Tonspuren zu erstellen.

Die Lösung war es letztlich, wie im Artikel zum manuellen rippen von DVDs auf Ubuntuusers erläutert, mit MPlayer den Film von der DVD in eine einzelne VOB Datei zu extrahieren.

mplayer dvd://2 -v -dumpstream -dumpfile title02.vob

In meinem Fall war der relevante Titel der zweite auf der DVD. Ansonsten ist entsprechend die Nummer des Titels an das Argument dvd:// anzuhängen.

Während dvdbackup die Struktur der DVD mit mehreren VOBs komplett replizierte, gibt es jetzt nur eine Datei. Und diese Datei lies sich dann ganz normal und erfolgreich mit Handbrake konvertieren. Der einzige Wermutstropfen ist, dass dabei die Kapitelstruktur verloren gegangen ist.

Mehrsprachige Videos aus der ZDF Mediathek herunterladen

2024-03-26T00:00:00+01:00

Die Mediatheken der Öffentlich-Rechtlichen haben ja immer wieder Perlen zu bieten. Leider aber häufig nur für sehr kurze Zeit, und nicht umbedingt dann, wenn ich als Nutzer auch Zeit habe diese zu konsumieren. Und auch so manches Endgerät, wie die PlayStation, harmonieren nicht so wunderbar mit den Mediatheken. Mit MediathekView und yt-dlp gibt es aber ja zum Glück hervorragende Möglichkeiten Medien zur zeit- und gerätesouveränen Nutzung auf einen lokalen DLNA-Server oder ein Plex zu sichern.

Das Problem

Ärgerlich ist hierbei, wenn Original- und synchronisierte Version in den Mediatheken als separate Videos angeboten werden. Denn das Video ist ja in allen Versionen dasselbe. Wird es für alle Sprachversionen separat gesichert, sorgt es für doppelte Downloadgröße und doppelten Speicherbedarf. Dabei würde eine zusätzliche Tonspur nur minimalen Platz verbrauchen.

Mehrsprachige Videos herunterladen

In der Mediathek des ZDF finden sich inzwischen auch Videos bei denen allen Sprachversionen parallel ausgeliefert werden. Leider lassen sich diese nicht direkt über MediathekView herunterladen. Aber mit yt-dlp ist dies möglich. Der Magie besteht hierdrin in der Nutzung des Parameters --audio-multistream und der korrekten Auswahl der Tonspuren. Letzere lässt sich durch die Auswahl bestaudio auch automatisieren, allerdings müssen alle Sprachen explizit angegeben werden, also beispielsweise bestaudio[language=de]+bestaudio[langauge=en].

Die Arbeit an ein Skript delegieren

Um die Sprachen nicht jedes mal von Hand auswählen zu müssen hilft ein kleine Shellscript welches zuerst per yt-dlp --dump-json die Metadaten des Videos abfragt, aus diesen die Sprachen per jq extrahiert und daraus den passenden Parameter für yt-dlp baut.

#!/bin/bash

set -eu -o pipefail

echo "Lade ${1} als ${2}"

AUDIO=$(yt-dlp --dump-json "${1}" | jq -r '[[.formats[] | select(.vcodec == "none") | .language] | sort | unique[] | "+bestaudio[language=\(.)]"] | join("")')

yt-dlp --write-subs --sub-langs 'deu,eng,fra' --audio-multistreams --format "bestvideo${AUDIO}" --embed-metadata --merge-output-format 'mp4' --write-thumbnail --output "${2}.%(ext)s" "${1}"

Das Skript übernimmt die URL eines Videos als erster Parameter, und schreibt mehrsprachiges Video, Untertitel, und ein Titelbild in Dateien welche den zweiten Parameter als Namen nutzen. Das erlaubt die Dateien direkt mit den passenden Namen für die Metadatenerkennung von Plex anzulegen. Um also beispielsweise Sugar aus der ZDF-Mediathek für eine Wiedergabe an der PS5 per Plex herzunterzuladen würde das, als zdf_mt_dl.sh abgelegte, Skript wie folgt aufgerufen:

zdf_mt_dl.sh 'https://www.zdf.de/filme/spielfilm-highlights/sugar-108.html' 'Sugar (2022)'

Das Skript erklärt

Das anfängliche set -eu -o pipefail stellt sicher, dass das Skript abbricht wenn:

ein Aufruf im Skript einen Fehler zurückgibt (-e),
und zwar auch, wenn wir das Ergebnis per Pipe weitergeben (-o pipefail).
Auch beim Zugriff auf eine undefinierte Variable bricht das Skript ab (-u).

yt-dlp --dump-json holt die Metadaten von der übergebenen URL und gibt diese als JSON aus. Diese verarbeiter der Aufruf von jq weiter. Aus allen Formaten werden nur diese ausgewählt, bei welchen das Attribut vcoded den Wert none hat, also die reinen Audio-Stream. Von diesen lesen wir das Attribut language aus, sortieren diese, sortieren Duplicate aus, und setzen diese per \(.) jeweils in die Zeichenkette "+bestaudio[language=\(.)]" ein. Wichtig ist hier, dass wir das ganze nochmal ein eckigen Klammern haben, damit bekommen wir nicht eine Zeichenkette pro Zeile im Output von jq, sondern bekommen das ganze immer noch als JSON-Array. Damit können wir diese am Schluss noch per join("") zusammenfassen und bekommen dann so etwas wie +bestaudio[language=de]+bestaudio[langauge=en] welches wir dann anschließend über die Variable ${AUDIO} in unseren Aufruf von yt-dlp setzen können.

Beim Aufruf von yt-dlp nutzt das Skript noch ein paar weitere Parameter:

--write-subs holt, falls verfügbar, auch die Untertitel mit aus der Mediathek.
--sublangs 'deu,eng,fra' wählt die Sprachen aus die --write-subs versuchen soll.
--audio-multistreams sorgt dafür, dass mehrere Tonspuren in der geschriebenen Datei landen dürfen. Sonst gäbe die Auswahl mehrerer Spuren einen Fehler.
--format "bestvideo${AUDIO}" wählt die Spuren aus. Wir wollen die beste Videospur, und zu jeder Sprache das beste Audio. ${AUDIO} wird hier mit der Spezifikation der Tonspuren ersetzt die wir zuvor zusammegebastelt haben.
--embed-metadata sorgt dafür, dass die Tonspuren auch schöne Namen haben.
--merge-output-format sorgt dafür, dass eine mp4 statt einer mkv geschrieben wird. Das hat bei der Weitergabe an eine PlayStation den Vorteil, dass die PlayStation MP4-Dateien, anders als Matroska-Dateien direkt abspielen kann. So wird im Zweifel der Medienserver ein klein wenig entlastet.
--write-thumbnail sorgt dafür, dass das Titelbild zur Datei mitgesichert wird.
--output "${2}.%(ext)s" schließlich lässt yt-dlp unseren vorgegebenen Dateinamen übernehmen, aber für die einzelnen Dateien selbst die passende Endung auswählen. Ein deutscher Untertitel lautet beim oben genannten Beispiel also unter Sugar (2022).deu.vtt, das Video selbst unter Sugar (2022).mp4.

Aktuelle Versionen des Skripts

Die aktuelle Version des Skripts ist auf Codeberg zu finden: https://codeberg.org/Marix/mt-dl. Diese kann auch mit den Mediatheken anderer Sender, wie der ARD und Arte, genutzt werden.

Am Linuxrechner Bluetooth per USB nachrüsten

2024-03-24T00:00:00+01:00

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.

Dynamisches Laden von Kernelmodulen beim Zugriff durch Nutzer

2024-03-14T00:00:00+01:00

Ich stolperte letztens über ein paar alte Image-Dateien welche damals wohl mit CloneCD angefertigt worden waren. Damit liesen sie sich nicht so einfach über die üblichen Linux-Boardmittel einbinden. Und extra ein Windows zu booten um Virtual CloneDrive zu nutzen wäre ja auch irgendwie unsportlich. Zum Glück gibt es die hervorragende Software CDEmu, welche diese Abbilder im CUE/BIN-Format als virtuelles Laufwerk einbinden kann.

Damit der, für CDEmu nötige, Kerneltreiber nur bei Bedarf geladen wird, das aber transparent und ohne Root-Rechte funktioniert, müssen einige Mechanismen ineinandergreifen welche zwar alle Dokumentiert, aber erstaunlich schwer durch Suchen zu finden sind wenn man die entscheidenden Begriffe noch nicht kennt.

Um die Gerätedateien für die nachzuladenden Module beim Start des Systems anzulegen gibt es modules.devname. Kernelmodule können also angeben, dass sie eine Gerätedatei brauchen und diese wird beim Start angelegt.
Auf Systemen mit Systemd kennt udev das spezielle Tag uaccess. Wird dieses auf einer Gerätedatei gesetzt, so wird dynamisch die ACL an dieser Datei so gesetzt, dass aktuell angemeldete Nutzer auf diese Zugreifen können.
Die Regeln von udev werden eigentlich durch das Laden der Kernelmodule, bzw. das Auftauchen von Gerätedateien ausgelöst. Die per modules.devname angelegten Dateien lösen diese Regeln aber nicht aus. udev kennt aber die Option static_node welche udev anweist die Regel auch auf die Platzhalterdatei anzuwenden.

Erst in der Kombination der drei Mechanismen ist es ohne Root, nur mit Login, möglich ein Modul wie den Treiber für das virtuelle Laufwerk dynamisch nachzuladen. Ein weiteres Beispiel für eine udev-Regel welche diese Mechanismen nutzt findet sich übrigens bei der vom Steam-Controller genutzten Datei /dev/uinput:

KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

CDEmu wirft, wenn die Berechtigungen nicht korrekt gesetzt sind übrigens folgende Fehlermeldung:

FEHLER: Fehler beim Verbunden zum CDEmu Daemon: g-io-error-quark: Error calling StartServiceByName for net.sf.cdemu.CDEmuDaemon: Timeout was reached (24)

Ein Blick in das Log des Daemons mit dem sich cdemu zu verbinden sucht zeigte dann, dass der Service nicht die Berechtigung hat auf den virtuellen Gerätetreiber zuzugreifen:

cdemu0: Kernel I/O: failed to open control device /dev/vhba_ctl: Keine Berechtigung!

Minecraft auf openSUSE Leap 15.5

2024-01-06T15:00:00+01:00

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.

Minecraft auf der PlayStation mit geteiltem Bildschirm spielen

2024-01-02T22:00:00+01:00

Ein großer Vorteil der Konsolenversion von Minecraft ist, dass man diese offline auch völlig ohne Onlinekonten spielen kann. Sucht man allerdings nach online nach einer Anleitung für den lokalen Mehrspielermodus mit geteiltem Bildschirm, so sind die Ergebnisse erstmal voll mit Anleitungen welche die Erstellung eines Kontos für das PSN und bei Microsoft als essentielle Schritte angeben. Dies ist aber gar nicht notwendig. Weitere Spieler können jederzeit dem lokalen Spiel beitreten. Dafür benötigt weder der startende Spiel noch der noch der beitretende Spieler ein Konto im PSN oder bei Microsoft.

Um einem laufenden Spiel bezutreten ist lediglich folgendes notwendig:

Aktivieren eines weiteren DualSense- oder DualShock,
Auswahl einen lokalen Benutzers auf der PlayStation auswählen, und schließlich
Drücken der Optionstaste, das ist die Taste rechts oberhalb vom Touchpad, auf dem beitretenden Controller.

Daraufhin wird der Bildschirm geteilt und es erscheint im neuen Bildschirmsegment Frage ob der Beitritt zum Spiel gewünscht ist. Ein weiter Druck auf die Optionstaste bringt einen dann auch schon in die gerade geladene Welt.

Soweit ich das testen kann funktioniert das ganze auch in allen Kombinationen von Spielern mit und ohne PSN- und Microsoft-Konten.

Eine kleine Falle gibt es allerdings noch. Besitzt der startende Spieler ein vollwertiges PSN-Konto, so werden Welten per Voreinstellung im Online-Modus angelegt. In diesem Fall scheitert der Beitritt ohne Onlinekonto dann mit einer entsprechenden Fehlermeldung. Dies lässt sich aber schnell Lösen indem man das Onlinespiel für diese Welt deaktiviert.

Hat der startende Spieler zwar ein PSN-Konto, dies ist aber durch die Kindersicherung bezüglich des Onlinespiels eingeschränkt, so tritt dieses Problem nicht auf. In diesem Fall werden Welten per Voreinstellung im Offline-Modus gestartet da sie der Spieler sonst ja selbst nicht betreten könnte.

Ubisofts kleine Falle für Steam-Spieler und Gamemode-Nutzer

2023-07-04T00:00:00+02:00

Seit einiger Zeit ermöglicht es Ubisoft ja wieder seine Spiele über Steam zu kaufen und zu spielen. Dank Steams exzellenter Integration von Proton, haben wir eine sehr komfortable Möglichkeit diese unter Linux, und natürlich auch auf dem Steam Deck zu spielen. Allerdings hat uns Ubisoft hierbei eine kleine Falle gestellt. Ubisoft Connect läuft nachdem man ein Spiel beendet hat einfach im Hintergrund weiter.

Startet man Spiele vom Desktop, macht dies eigentlich keinen großen Unterschied. Nutzt man allerdings Programme welche auf das Ende des Spielprozesses warten, so kann es zu unerwünschtem Verhalten kommen. So denkt Steam das Spiel laufe weiter, und lässt einen keine anderen Spiele starten. Ebenso bleibt das System, wenn man gamemoderun nutzt, unerwartet im Gamemode, was zu unnötig hoher Energieaufnahme und, vor allem, unnötigem Lärm führt. Das war tatsächlich auch der Grund weshalb es mir auffiel, denn ich setze über den Gamemode während dem Spielen mein Emailprogramm offline.

Leider gibt es bisher wohl keine gute Lösung für das Problem. In den Einstellungen gibt es zwar eine Option welche so klingt als würde sie das Problem lösen. Leider sorgt sie aber nur dafür, dass der Client nicht minimiert wird, nicht dafür, dass er sich beendet.

Meine bisherigen Suchen führten weiterhin zu ein paar abenteuerlichen Skripten für einzelne Ubisoft-Spiele auf Windows und einem Eintrag im Steam-Forum, in dem jemand die baldige Veröffentlichung eines kommerziellen Tools ankündigte. Aber keine dieser Lösungen funktioniert wirklich. So bleibt es dabei, dass wir bei Ubisoft-Spielen leider nach dem Beenden daran denken müssen auch Ubisoft Connect zu beenden.

Verbindungsprobleme mit Ubisoft Connect unter Linux lösen

2023-05-18T00:00:00+02:00

Der Versuch das aktuelle TrackMania zu starten führte auf meinem Rechner unter Linux reproduzierbar zu folgendem Fehler:

Verbindung Verloren

Ein Ubisoft-Dienst ist im Moment nicht verfügbar. Du kannst es später erneut versuchen oder in den Offline-Modus wechseln.

Zum Glück hatte jemand auf Reddit schon sehr viel Zeit darauf verwendet, dass Problem zu debuggen. Das Problem entsteht, wenn IPv4-Pakete auf dem Weg zu den Ubisoft-Servern fragmentiert werden. Es lässt sich lösen, indem man dem Linux Kernel auf für IPv4 die maximale Paketgröße auf dem Weg zum Empfänger ermitteln lässt, so dass es nicht zu Fragementierung kommt. Dies geschieht über die Option net.ipv4.tcp_mtu_probing, welche dafür auf den Wert 1 zu setzen ist.

Zum Testen lässt sich die Option per sudo sysctl net.ipv4.tcp_mtu_probing=1 temporär aktivieren. Mit dem nächsten Reboot, oder einem sudo sysctl net.ipv4.tcp_mtu_probing=0 ist das normale Verhalten wiederhergestellt.

Um das Verhalten permanent zu aktivieren muss die Option in die Sysctl-Konfiguration eingetragen werden. Am besten in eine eigene Datei in /etc/sysctl/conf.d/. Also, /etc/sysctl.d/50-enable-ipv4-mtu-probing.conf anlegen und folgendes reinschreiben:

sysctl net.ipv4.tcp_mtu_probing=1

Bei IPv6 gibt es übrigens keine Fragementierung. Hier ist das zur Problemlösung aktivierte Verhalten der Standard. Würde Ubisoft also nicht auf einem veralteten Protokoll hängen, so gäbe es das Problem gar nicht.

Meine Gedanken zum neuen Sprint-Format der Formel 1

2023-05-09T00:00:00+02:00

Nachdem die Formel 1 vor zwei Jahre das Sprint-Qualifying eingeführt, und es letztes Jahr in den Sprint umbenannt hat, wurde dieses Jahr das Format noch einmal grundsätzlich überarbeitet. Und als Fan bin ich zwiegespalten, zwischen der Freude darüber endlich einen richtigen Sprint zu bekommen und dem Gefühl, dass es inzwischein einfach zu viel Formel 1 gibt.

Grundsätzlich finde ich das neue Format gut. Das alte Format fühlte sich nie wie ein Sprint an. Eigentlich waren die Sprint-Wochenenden eher Marathon-Grand-Prixs mit einer Unterbrechung nach dem ersten Rennviertel. Die einzigen Punkte welche das Sprint-Wochenende von einem 400km-Rennen mit Rotphase unterschieden waren, dass ausgeschiedene Fahrzeuge wieder ins Rennen zurück gebracht werden konnten, und dass es eine kleine Menge Punkte für die Position zum Zeitpunkt der Unterbrechung gab. Letzteres gibt es ja aber in anderen Rennserien, beispielsweise mit den Stages in der NASCAR, durchaus auch.

Mein Problem mit dem neuen Format ist, dass es den Kalender effektiv auf 29 Rennen aufbläst. Früher war ein Rennen der Formel 1 etwas dass man geradezu gewartet hat. Heute kann man gefühlt jederzeit ein Rennen sehen. Möchte man der Meisterschaft folgen, und nicht einzelne Rennen als Event betrachten, so lässt sich das nur noch schwer mit anderen Interessen unter einen Hut bekommen. Ein Jahr hat nun mal nur 52 Wochenenden. Davon nimmt die Formel 1 nun schon fast die Hälfte in Anspruch, und sechs davon nun auch noch einen Arbeitstag.

In den 90ern und 2000ern, bei 16 bis 18 Rennen, hätte ich mich über ein paar Rennen mit dem aktuellen Sprint-Format gefreut. Es wäre etwas besonderes gewesen, auf das man vorher gewartet hätte, und für das auch die Zeit gewesen wäre. Heute erweitern sie nur einen Kalender der einen sowieso schon erschlägt.

Pre-commit auf openSUSE Leap 15.4

2022-02-07T00:00:00+01:00

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.

Besser Brille putzen

2022-02-05T00:00:00+01:00

Viele Jahre habe ic mich damit, wie man eine Brille eigentlich am besten reinigt, gar nicht groß beschäftigt. Da echte Gläser ja fast alles abkönnen, hab ich die Brille halt unter Wasser gehalten, und sonst halt an allem abgewischt, was gerade da war. Als ich dann vor ein paar Jahren relativ kurzfristig eine neue brauchte, gab es beim lokalen Optiker meines Vertrauens unter den Modellen, die an mir erträglich aussahen, keines in das echtes Glas konnte. So musste ich dann doch auf Plastik wechseln.

Nun ist Plastik weniger kratzfest als Glas. Ob das einen relevanten Unterschied macht habe ich nie ausprobiert. So stand ich auf jeden Fall vor der Frage: Wie bekomme ich diese Gläser jetzt gereinigt ohne sie zu beschädigen. Hier hatte mein Optiker dann einen tollen Tipp für mich: Eine Sprühflasche mit Spüli und Wasser. Damit ergibt sich dann ein unglaublich einfacher Weg die Brille zu putzen der zu klasse Ergebnissen führt:

Gläser einsprühen.
Mit fliesendem Wasser abspülen.
Mit einem normalen Spültuch trocken reiben.

Wieso ist diese Methode so toll? Sie vermeidet das Problem, dass das verwischen von Schmutz auf der Brille Gläser verkratzen kann, denn diese werden in Schritt eins und zwei bereits abgespült. Durch das Sprühen schafft man es auch gleich das Spülmittel gleichmäßig auf den Gläsern zu verteilen, so dass das Spülen auch bereits zuverlässig allen Dreck mitnimmt.

Was die Sprühflasche angeht, habe ich übrigens festgestellt, dass die Sprühflaschen aus dem Friseurbedarf richtig toll sind. Sie kosten fast nichts und sind so klein, dass sie keinen Platz wegnehmen. So kann man diese auch an allen Orten an denen man sich häufiger aufhält Bunkern.

KTorrent friert ein

2022-01-29T00:00:00+01:00

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:

Ist KTorrent bereits gestartet bevor Firefox die Datei übergibt, so scheint das Problem nicht aufzutreten.
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.

Bootprobleme mit Leap 15.3 und Radeon-Grafik

2022-01-28T00:00:00+01:00

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.

American und Euro Truck Simulator 2 1.40

2021-03-26T00:00:00+01:00

Diese Woche erschien Version 1.40 der beiden Geschwisterspiele American und Euro Truck Simulator 2. Und ich bin begeistert, sowohl vom neuen Lichtsystem als auch von der Überarbeitung des deutschen Teils der Karte.

Tatsächlich immer noch etwas erstaunt es mich immer noch ein wenig, dass ich von diesem Spiel so begeistert sein kann. Früher hab ich mich immer gefragt wer so etwas eigentlich spielt, aber dank eine Humble Bundles hab ich dann irgendwann doch mal den Euro Truck Simulator ausprobiert. Dabei habe ich festgestellt, es ist einfach das perfekte Spiel, wenn man nach einem stressigen Tag einfach gar nicht mehr die Energie für ein stressiges Actionspiel, wie Descent oder Gran Turismo, oder ein anstrengendes Strategiespiel, wie Civilisation, hat. Man kann einfach einen Podcast hören, die Landschaft genießen, und hat trotzdem noch genug Beschäftigung um nicht noch etwas anders anzufangen das einem vom Podcast und der Landschaft ablenken würde.

Das neue Lichtsystem und die Überarbeitung des deutschen Teils der Karte werten in Version 1.40 den Genuss der Landschaft noch einmal deutlich auf. Straßenlaternen tauchen jetzt Landschaft und Führerhaus in stimmiges Licht, und Sonnenuntergänge sind so wunderbar wie auf dem obigen Bild. Und dank mehr Details ist Deutschland zu durchfahren jetzt genau so schön wie es zuvor schon die Länder aus der Erweiterung Going East waren, ein großer Vorteil wenn man zu Begin des Spiels Mannheim als seinen Unternehmensstandort ausgewählt hat. Der einzige Wermutstropfen ist, dass mir jetzt ein Flackern bei horizontalen Linien auffällt.

Die Beta von openSUSE Leap 15.3 ist da

2021-03-06T00:00:00+01:00

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.

openSUSE Leap 15.1 mit USB-Stick als Schlüssel für die Festplattenverschlüsselung

2021-03-06T00:00:00+01:00

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.

CD-ROMs von Klett unter Linux nutzen

2021-01-04T00:00:00+01:00

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.

Mein bisher kleinster Pull-Request

2020-10-25T00:00:00+02:00

Kürzlich berichtete @maralorn@chaos.social über seinen bisher kleinsten Pull Request. Dies lies mich kurz darüber nachdenken, was wohl mein kleinster Pull Request bisher war. Tatsächlich habe ich kürzlich einen Pull Request bei Ceph gemacht um einen Tippfehler in der Beschreibung des RPM Paketes für den Prometheus-Exporter zu fixen. Jetzt mag man sich drüber streiten was der Wert eines solchen Pull Requests ist, aber für mich waren es keine fünf Minuten Arbeit und in Zukunft muss sich keiner mehr über den Tippfehler wundern.

Wer sich nun fragt was ich mit Ceph mache: schon lange gar nichts mehr. Der Tippfehler war mir tatsächlich nur aufgefallen weil ich ein zypper search prometheus gemacht habe als ich, nach dem Update auf openSUSE Leap 15.2, welches jetzt alle Prometheus-Pakete jetzt auch ARM zur Verfügung stellt, mein Monitoring komplett auf diese umgestellt habe.

Catherine

2020-10-23T00:00:00+02:00

Ach Catherine, ich würde dich ja eigentlich gerne mögen. Aber genau wie dein Hauptcharakter kann ich dass nicht so uneingeschränkt. Dabei klingt die Idee philosophische Fragen rund um Verantwortung, Beziehung, dem Wunsch nach Ordnung und dem nach individueller Freiheit an sich so reizvoll. In der Umsetzung ist Catherine dann aber vor allem lang, lang, und nochmal lang.

Als Spiel ist Catherine eine Kombination aus Visual Novel und einem Jump and Run. Die Visual Novel besteht aus langen Cutscenes, kombiniert mit zwei Dialoghubs in denen man zwischen den Leveln landet. Alleine in den Dialogszenen ist das Pacing schon wahnsinning langsam, und die langen Ladezeiten auf der PS3 helfen dann auch nicht gerade. Auch den Kletterpassagen merkt man die länge des Spiels deutlich an. Dass die Ladeanimation, welche einem einem den Fortschritt im Spiel anzuzeigen scheint, bei entsprechendem Fortschritt einen zweiten Teil bekommt, könnte man noch als zur Geschichte passendes Stilmittel einordnen. Aber, dass die Passagen ab diesem Punkt dann, zumindest auf der niedrigsten Schwierigkeitsstufe, auch wieder deutlich einfacher werden spricht dann doch eine deutliche Sprache.

Dabei hätte ich es ja eigentlich vorher wissen können. Ein Spiel das seiner Bewerbung derart auf Erotik setzt ahnt wohl schon, dass seine sonstigen Qualitäten nicht als Kaufimpuls reichen werden. Zumal im Spiel dann weniger Erotik vorhanden ist als in jedem Need for Speed. Wer das Spiel also deshalb gekauft haben sollte schaut gleich doppelt doof aus der Wäsche.

★★☆☆☆

In einer Sternewertung kann ich Catherine nur zwei von fünf geben. Was schade ist, denn in deutlich kürzerer Form hätte das Spiel durchaus spannend sein können. Wer ein großer Fan von Spielen mit philosophischen Gedanken ist, der kann Catherine durchaus mal eine Chance geben. Zumindest wenn, wie in meinem Fall, Catherine über Playstation Plus oder auf anderem Weg ohne zusätzliche Kosten ins Haus kommt. Jeder Andere verbringt seine Zeit lieber mit einem anderen Spiel.

Den Aktualisierungsstand von openSUSE mit Prometheus überwachen

2020-06-21T00:00:00+02:00

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.

Der schusselige WLAN-Client

2020-05-11T00:00:00+02:00

Das Lenovo Thinkpad E470 ist ein wunderbarer Laptop und openSUSE Leap funktioniert darauf hervorragend, wäre da nicht ein kleines Problem mit dem WLAN: Der Laptop ist etwas schusselig was das Passwort für das WLAN angeht. Immer wieder scheint er es zu vergessen und fragt per Dialog nach. Scheinbar scheint er einen dann aber nicht zu verstehen, und fragt immer wieder. Gibt man aber erst einmal auf, bricht den Verbindungsversuch ab und bittet ihn kurz darauf nochmal die Verbindung aufzubauen, so erinnert er sich plötzlich und verbindet sich ohne weitere Nachfragen.

Beim Versuch dem Problem auf den Grund zu gehen stellte ich schnell fest, dass es offensichtlich nicht am seit vielen Jahren immer wieder migrierten Nutzer liegt, denn das Problem tritt auch für einen neuen Nutzer auf. Es ist aber auch nie zu hundert Prozent zuverlässig reproduzierbar, was die Fehlersuche zusätzlich erschwert. So dachte ich zunächst, dass es eventuell mit der Initialisierung der Hardware zu hat, da es sehr häufig nach einem Neustart des Rechners auftauchte. Auch trat das Problem eigentlich immer nur bei einem automatischen Verbindungsaufbau auf, also z.B. wenn das Netzwerk komplett deaktiviert wurde. War die WLAN-Hardware hingegen ohne aufgebaute Verbindung aktiv und ich wählte das Netzwerk über das Netzwerkapplet von KDE aus, so verband sich der Rechner zuverlässig. Allerdings habe ich das Problem aber nie nach einem Suspend beobachtet, was diese Theorie zumindest unwahrscheinlicher machte.

Eine Nachfrage auf der Mailingliste von openSUSE brachte mich dann mit einem Verweis auf eine Diskussion auf der deutschsprachigen Liste auf die Lösung des Problems: Anscheinend verursacht die MAC address randomization das Problem. Seit jene abgeschaltet ist trat das Problem nicht mehr auf.

Ein einfacher weg die MAC address randomization abzuschalten findet sich auf https://blog.muench-johannes.de/networkmanager-disable-mac-randomization-314. Es ist lediglich die Datei /etc/NetworkManager/conf.d/100-disable-wifi-mac-randomization.conf mit folgendem Inhalt anzulegen:

[connection]
wifi.mac-address-randomization=1

[device]
wifi.scan-rand-mac-address=no

Wieso dieses Vorgehen in einem Netzwerk ohne MAC-Adressen-Filter notwendig sein sollte ist mir zwar schleierhaft, aber solange es hilft…

Die randomisierten MAC-Adressen zu deaktivieren hat natürlich eine Auswirkung auf die Privatsphäre. Da dieser Rechner aber ausschließlich zuhause oder bei öffentlichen Auftritten genutzt wird ist dies in diesem Fall verschmerzbar.

Alte Kernelversionen installiert behalten

2019-08-16T00:00:00+02:00

OpenSUSE behält in seiner Standardkonfiguration bei einer Aktualisierung des Kernels stets die letzte zuvor installierte Version. Diese kann beim Systemstart über die erweiterten Startmodi ausgewählt werden. Das hat den großen Vorteil, dass sollte der neue Kernel einen Fehler haben, man noch zu einem funktionierenden System zurückkehren kann. Man kann also einfach mit dem alten Kernel weiterarbeiten und auf eine Behebung des Fehlers warten.

Doch was passiert bei der nächsten Aktualisierung? Hier gibt es mehrere Optionen. Löst die nächste Aktualisierung das Problem, kann man wieder auf den aktuellen Kernel wechseln und die alten Versionen können einem egal sein. Ist das Problem mit der nächsten Aktualisierung nicht behoben gibt es zwei mögliche Fälle. Im einfachen Fall startet das System mit dem neuen Kernel gar nicht. In diesem Fall kann man weiterhin mit dem alten Kernel weiterarbeiten, denn das System behält stets den aktuell laufenden Kernel installiert Solange neuere Kernel gar nicht starten können die alten Versionen somit auch nicht entfernt werden. Spannender wird es, wenn der neue Kernel zwar startet, aber trotzdem nicht korrekt funktioniert. So läuft womöglich der proprietäre Treiber von NVIDIA nicht oder ein Fehler im Kernel tritt nur in bestimmten Situationen auf. In diesem Fall würde das System in der Standardkonfiguration nach dem, aus seiner Sicht erfolgreichen, Start den alten Kernel entfernen und nur die zwei defekten Kernel behalten.

Zum Glück lässt sich die Menge der aufbewahrten Kernel sehr flexibel Konfigurieren. Die Konfiguration findet sich in der Datei /etc/zypp/zypp.conf Entscheiden ist der Wert der Option multiversion.kernels. Diese wird standardmäßig wie folgt gesetzt:

multiversion.kernels = latest,latest-1,running

Damit werden die neuesten beiden und der aktuell laufende Kernel behalten. Hier lassen sich aber auch explizite Versionen eintragen. Damit sieht die Zeile dann wie folgt aus:

multiversion.kernels = latest,latest-1,running,4.12.14-lp151.28.10.1

Wichtig ist, dass hier die Paketversion benötigt wird, nicht die vom Kernel bei einem uname -a ausgegebene Version. Letzteres würde lautet für den im Beispiel benutzen Kernel folgendes ausgeben.

Linux test 4.12.14-lp151.28.10-default #1 SMP Sat Jul 13 17:59:31 UTC 2019 (0ab03b7) x86_64 x86_64 x86_64 GNU/Linux

Die dazugehörige Paketversion lässt sich per rpm oder zypper abfragen:

> rpm -qa kernel-default
kernel-default-4.12.14-lp151.28.10.1.x86_64
kernel-default-4.12.14-lp151.28.13.1.x86_64

> zypper search -s kernel-default
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                 | Typ        | Version               | Arch   | Repository
---+----------------------+------------+-----------------------+--------+--------------------------------
i+ | kernel-default       | Paket      | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
i+ | kernel-default       | Paket      | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default       | Paket      | 4.12.14-lp151.28.7.1  | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default       | Paket      | 4.12.14-lp151.28.4.1  | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default       | Paket      | 4.12.14-lp151.27.3    | x86_64 | Haupt-Repository (OSS)
   | kernel-default       | Quellpaket | 4.12.14-lp151.28.13.1 | noarch | Hauptaktualisierungs-Repository
   | kernel-default       | Quellpaket | 4.12.14-lp151.28.10.1 | noarch | Hauptaktualisierungs-Repository
   | kernel-default       | Quellpaket | 4.12.14-lp151.28.7.1  | noarch | Hauptaktualisierungs-Repository
   | kernel-default       | Quellpaket | 4.12.14-lp151.28.4.1  | noarch | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.28.7.1  | x86_64 | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.28.4.1  | x86_64 | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.27.3    | x86_64 | Haupt-Repository (OSS)
i+ | kernel-default-devel | Paket      | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
i+ | kernel-default-devel | Paket      | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default-devel | Paket      | 4.12.14-lp151.28.7.1  | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default-devel | Paket      | 4.12.14-lp151.28.4.1  | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default-devel | Paket      | 4.12.14-lp151.27.3    | x86_64 | Haupt-Repository (OSS)

Wie im Beispiel zu sehen ist, liefert zypper die einfacher zu lesende Ausgabe, rpm aber eine deutlich kompaktere.

Hat man so den funktionierenden Kernel vor dem automatischen Aufräumen geschützt, lässt es sich ganz entspannt auf eine reparierte Version warten. Wurde der Fehler behoben, und spätestens nach dem nächsten Distributionsupgrade, sollte man allerdings die Konfiguration wieder zurücksetzen um nicht unnötig alte Kernel mit sich herumzuschleppen. Denn diese benötigen nicht nur Platz, sie verlängern auch die Installationszeit mancher Updates.

Weitere Informationen zur Installation mehrerer Kernelversionen finden sich in der englischen Referenzdokumentation von openSUSE Leap.

Automatisiertes Tippen von Passwörtern auf openSUSE

2019-08-11T00:00:00+02:00

Die Passwortverwaltung KeePass hat das äußerst praktische Feature Auto-Type um Anmeldeformulare in jeglicher Software, also nicht nur im Browser, per Knopfdruck ausfüllen zu können. Damit spart man sich das manuelle Kopieren und Einfügen, was nicht nur komfortabler ist, sondern auch verhindert, dass das Passwort auf diesem Weg doch an einer falschen Stelle landet. Leider funktionierte dies in openSUSE bisher nur, wenn man manuell das Paket xdotool nachinstalliert. Ansonsten begrüßt folgende Fehlermeldung:

Die Fehlermeldung sagt dem Nutzer zwar bereits wie das Problem zu beheben ist, aber ich als Nutzer bevorzuge es eigentlich, wenn Dinge einfach funktionieren. Von daher sollte die Installation des Paketes keepass eigentlich dafür sorgen, dass auch xdotool installiert wird.

Zum Glück hat openSUSE einen gut Dokumentierten Prozess um Korrekturen zu Paketen beizutragen. Das Paket zu reparieren ist also fast genau so schnell erledigt wie die fehlende Abhängigkeit zu installieren. Und als Bonus muss ich es auf dem nächsten System dann nicht wiederholen.

Wie man an meinem Request sehen kann habe ich xdotool übrigens nicht einfach als Abhängigkeit zu keepass hinzugefügt, denn KeePass funktioniert ja auch ohne xdotool fehlerfrei. Stattdessen nutze ich den Vorschlagsmechanismus, also Recommends statt Depends. So bekommt ein normaler Nutzer das empfohlene Paket automatisch mitinstalliert. Wer aber --no-recommends nutzt, um beispielsweise aus Sicherheitsgründen oder wegen beschränktem Platz auf der Systemfestplatte, nur die absolut notwendigen Pakete installieren möchte, bekommt weiterhin die gleiche minimale Installation wie bisher.

Leider habe ich meine Korrektur minimal zu spät beigetragen, als dass sie es noch in openSUSE Leap 15.1 geschafft hätte. Von daher profitiert man bisher in in Tumbleweed davon. Mit der nächsten Leap-Version können dann aber auch Leap-Nutzer ohne manuelle Nacharbeit Auto-Type nutzen.

openSUSE-Pakete für den Client und das Dateisystem von Keybase

2018-11-12T00:00:00+01:00

Keybase gehört zu den Diensten, die zwar irgendwie wahnsinnig nützlich sind, denen der breite Erfolg bisher aber leider verwehrt wurde. Das Kernfeature besteht darin, dass es einen Weg bietet eine verschlüsselte Kommunikation mit Personen aufzubauen von denen man nur einen Social-Media-Account kennt. Durch das Verfahren, einen Beweis über die Eigentümerschaft des Schlüssels im Social-Media-Account zu hinterlegen, kann man diesen, anders als Schlüsseln welche man von einem PGP-Keyserver erhalten hat, recht gut Vertrauen. Leider bietet allerdings Keybase kein Installationspaket seiner Software für openSUSE an, so dass ich nun selber Pakete erstellt habe.

Die grundlegenden Funktionen von Keybase sind über das Kommandozeilenwerkzeug keybase verfügbar. Dieses wird vom Paket keybase-client bereitgestellt und lässt sich in Tumbleweed durch ein einfaches sudo zypper install keybase-client installieren. Für Leap 15.0 ist das Paket leider nur als Versuchspaket verfügbar, welches sich am besten per 1-Klick-Installation von software.opensuse.org installieren lässt.

Außerdem bietet Keybase noch zwei weitere nützliche Funktionen. Mit dem dazugehörigen Dateisystem lassen sich Daten verschlüsselt und signiert mit anderen Nutzer tauschen. Auch öffentlich lassen sich darüber Dateien anbieten. Diese erscheinen dann unter https://<nutzername>.keybase.pub, und sind natürlich nicht verschlüsselt sondern nur signiert. Hierfür wird das Paket kbfs benötigt. Ist diese installiert, kann man per systemctl --user start kbfs das Dateisystem starten, welches dann unter ${XDG_RUNTIME_DIR}/keybase/kbfs erscheint.

Die zweite nützliche Funktion ist es Git-Repositories verschlüsselt in Keybase abzulegen. Hierzu wird das Paket kbfs-git benötigt. Sobald diese installiert ist, und das Dateisystem aktiv, kann Git auf Repositories welche das Protokoll keybase nutzen zugreifen. Die Verwaltung erfolgt hierbei über das Kommando keybase git.

Dieser Rattenfänger befreit Mäuse

2018-10-31T00:00:00+01:00

Seit letzter Woche ist Piper in openSUSE Tumbleweed als Paket enthalten. Piper erlaubt es für eine ganze Reihe Spielermäuse diese auch unter Linux ganz genau so zu konfigurieren, wie es sonst die nur unter Windows verfügbaren Programme der Hersteller tun.

Bei meiner Logitech G502 kann ich mit Piper nicht nur grafisch zwischen den einzelnen Profilen wechseln, sonder ich kann auch für jedes Profil die Auflösungsstufen, die Tastenbelegung und die LEDs konfigurieren.

Zur Installation muss das Paket piper ausgewählt werden, entweder in der grafischen Paketverwaltung, per 1-Klick-Installation auf software.opensuse.org oder auf der Kommandozeile:

sudo zypper install piper

In openSUSE Leap ist Piper aktuell leider nicht nutzbar. Der darunterliegende Service Ratbagd hatte seine Sicherheitsbegutachtung beim Release von Leap 15.0 leider noch nicht abgeschlossen. Mit der kommenden Version 15.1 sollte der Nutzung von Piper auf Leap dann aber auch nichts mehr im Wege stehen.

HTTP/2 im Apache auf openSUSE

2018-10-23T00:00:00+02:00

Nachdem es inzwischen keine Version von openSUSE mehr gibt in welcher der Apache zu alt ist um HTTP/2 zu unterstützen, gibt es eigentlich keine Ausrede mehr um dieses nicht einzusetzen. Tatsächlich ist die Installation auf openSUSE auch schon hervorragend vorbereitet, man muss lediglich berücksichtigen, dass HTTP/2 nicht mit dem Multi-Processing-Module (MPM) Worker kompatibel ist, welches immer noch der Standard ist.

Um HTTP/2 zu aktivieren ist zunächst ein kompatibles MPM zu installieren. Eine gute Wahl ist hierbei das MPM Event, welches unter openSUSE durch das Paket apache2-event bereitgestellt wird.

sudo zypper install apache2-event

Alle notwendige Konfiguration kann anschließend in der Datei /etc/sysconfig/apache2 vorgenommen werden:

Das korrekte MPM auswählen: APACHE_MPM=event.
Das HTTP2-Module durch hinzufügen von http2 zum Wert von APACHE_MODULES aktivieren.
Den Wert HTTP2 zu APACHE_SERVER_FLAGS um die von openSUSE mitgelieferte Konfiguration für HTTP/2 zu aktivieren.

Ab dem nächsten, per systemctl restart apache2 durchführbaren, Neustart ist der Server dann per HTTP/2 zu erreichen.

Um für Browser per HTTP/2 nutzbar zu sein muss der Server übrigens TLS reden, da Firefox und Chrome HTTP/2 nur für sichere Verbindungen unterstützen. Das sollte heutzutage aber sowieso der Standard sein.

GameMode

2018-06-22T00:00:00+02:00

Beim Spielen möchte man am liebsten ungestört sein. Deshalb bietet es sich häufig an so manches Program beim Starten eines Spieles zu schließen. Auch weisen viele Spiele von Feral Interactive, z.B. F1 2017, weisen einen beim Start recht deutlich darauf hin, dass sie für die CPU eigentlich gerne den Performance-Modus aktiviert hätten. Programme zu beenden und den Energiesparmodus zu wechseln, vor allem aber dies nach Ende der Spielesitzung alles wieder rückgängig zu machen, ist mühselig und steht dem spontanen Spielegenuß im Weg. Hier hilft der von Feral Interactive entwickelte GameMode.

GameMode läuft als Prozess im Hintergrund und bietet eine einfache Funktion: Über die dazugehörige Bibliothek können Spiele den Rechner in einen Spielemodus schalten. Im Spielemodus wird die CPU in den Performance-Modus geschaltet. Außerdem lassen sich beliebige weitere beim Start des Spielemodus auszuführende Aktionen definieren um beispielsweiße den Mail-Client für die dauer der Spielesitzung zu beenden. Am Ende der Spielesitzung schaltet GameMode die CPU dann von alleine wieder in den balancierten Modus, so dass nicht weiter unnötig viel Energie verbraucht wird.

Da selbst Spiele von Feral Interactive noch nicht durchgängig GameMode unterstützen gibt es außerdem libgamemodeauto. Libgamemodeauto kann per LD_PRELOAD mit einer Anwendung mitgeladen werden und sorgt dann automatisch für den Wechsel in den Spielemodus. Installiert man libgamemodeauto über das openSUSE-Paket libgamemodeauto0, so findet es sich in /usr/lib64/libgamemodeauto.so.0. Um es im Spiel game zu nutzen ist diese dann wie folgt zu starten:

LD_PRELOAD=/usr/lib64/libgamemodeauto.so.0 game

Um Spiele per Steam mit libgamemodeauto zu starten ist in den Startoptionen des Spieles folgendes einzutragen:

LD_PRELOAD=$LD_PRELOAD:/usr/lib64/libgamemodeauto.so.0 %command%

Diese Kommandozeilen finden sich auch in der Paketbeschreibung von libgamemodeauto0, welche sich per zypper info libgamemodeauto0 anzeigen lässt.

Der einfachste Weg GameMode zu installieren ist den Download oder die Anleitung von software.opensuse.org zu nutzen. In Tumbleweed reicht ein einfaches zypper install ligbamemodeauto0. In Leap ist libgameodeauto leider noch nicht eingezogen, so dass zuvor das Repository games:tools hinzugefügt werden muss.

Zusätzliche Aktionen für den Start und das Ende des Spielemodus lassen sich in der Datei ~/.config/gamemode.ini definieren. Bei mir sieht diese so aus:

[custom]
start=
  cd && boinccmd --set_run_mode never
  akonadictl stop
  balooctl suspend
  notify-send "GameMode started"
end=
  notify-send "GameMode ended"
  akonadictl start
  balooctl resume
  cd && boinccmd --set_run_mode auto

Mit boinccmd wird Boinc für die dauer der Spielesitzung angehalten. Mit akonadictl halte ich effektiv mein Emailprogram an und mit balooctl schalte ich für die Dauer der Spielesitzung die Indizierung der Desktopsuche aus. Nach Änderungen an der Konfigurationsdatei muss GameMode einmal beendet werden, am einfachsten über killall gamemoded. Durch die nächste Anwendung, welche den GameMode nutzen möchte, wird der Prozess automatisch wieder gestartet, dann mit der neuen Konfiguration.

Für einfache Tests gibt es außerdem noch die Möglichkeit den Spielemodus mittels gamemode -r explizit zu aktivieren. Beenden des Programmes per Strg+C deaktiviert den Spielemodus dann wieder.

Ein paar Tipps zum Aktualisieren von openSUSE

2018-06-10T00:00:00+02:00

Seit dem 25. Mai 2018 ist openSUSE Leap 15.0 verfügbar. Ein guter Grund mal ein paar Tipps zur Aktualiserung von openSUSE auf eine neue Version zu geben. Da ich für gewöhnlich mithilfe des Installationsmediums aktualisiere beziehen sich meine Tipps primär auf diese Methode. Aber gerade der Hinweis wie man verwaiste Pakete findet ist natürlich auch nach einem sogenannten Live-Upgrade hilfreich.

Der NVIDIA-Treiber

Meiner Erfahrung nach empfiehlt es sich den NVIDIA-Treiber vor dem Update zu deinstallieren. Bei früheren Versionen von openSUSE habe ich es ansonsten schon erlebt, dass auch nach hinzufügen des NVIDIA-Repositories für die neue Version noch der alte Treiber installiert bleibt. Dieser funktioniert dann allerdings nicht. Linux, bzw. X.org, ist an dieser Stelle zwar hart im Nehmen und nutzt dann automatisch Nouveau, aber dieser kann dem proprietären Treiber von NVIDIA leider nicht annähernd das Wasser reichen.

Sollte das System bereits aktualisiert und Nouveau aktiv sein, so empfiehlt es sich den alten NVIDIA-Treiber mittels zypper remove nvidia* komplett zu deinstallieren und anschließen neu zu installieren. Eine Neuinstallation mittels zypper install --force hat bei mir in der Vergangenheit meißtens nicht den gewünschten Erfolg gebracht.

UEFI

Bei einem System welches sowohl im EFI-Modus als auch im Bios-Kompatibilitätsmodus starten kann ist es wichtig das Upgrade im selben Modus zu starten welchen das alte System nutzt. Bei openSUSE 42.2 endete ich dadurch, dass ich dies nicht getan habe, mit einem nicht bootfähigen System. Allerdings gibt es im Zweifelsfall einen einfachen Ausweg. Einfach auf dem bereits aktualisieren System das Update nochmal im richtigen Modus ausführen. Da alle Pakete schon aktualisiert sind und nur noch der Bootcode korrekt installiert werden muss, geht dies dann auch recht schnell.

Repositories

Bei einem Update mithilfe des Installationsmediums werden alle zusätzlichen Repositories aus dem System entfernt. Dies führt zu einem sauberen Update, kann aber zur Folge haben, dass man anschließend mühsam zusammensuchen muss woher man eine bestimmte Anwendung hatte. Hierzu empfiehlt es sich vor der Aktualisierung einen Überblick zu verschaffen welche Pakete man aus dritten Quellen installiert hat.

Die konfigurierten Repositories

Zypper kann einem mit repos -u die Liste der aktuell konfigurierten Repositories mit ihren URLs ausgeben. So ist es, falls das Repository auch nach dem Update noch benötigt wird, möglich, durch einfaches Ersetzen der Versionsnummer in der URL, an das passende Repository der neuen Version zu kommen. Auf meinem großen Rechner sieht dies dann zum Beispiel so aus:

> zypper repos -u
Die Repository-Prioritäten sind ohne Effekt. Alle aktivierten Repositorys teilen sich die gleiche Priorität.

#  | Alias                           | Name                                                    | Aktiviert | GPG-Überprüfung | Aktualisierung | URI
---+---------------------------------+---------------------------------------------------------+-----------+-----------------+----------------+-------------------------------------------------------------------------------------
1 | code                            | Visual Studio Code                                      | Ja        | (r ) Ja         | Ja             | https://packages.microsoft.com/yumrepos/vscode
2 | download.nvidia.com-leap        | nVidia Graphics Drivers                                 | Ja        | (r ) Ja         | Ja             | http://download.nvidia.com/opensuse/leap/42.3
3 | download.opensuse.org-non-oss   | Haupt-Repository (NON-OSS)                              | Ja        | (r ) Ja         | Ja             | http://download.opensuse.org/distribution/leap/42.3/repo/non-oss/
4 | download.opensuse.org-non-oss_1 | Aktualisierungs-Repository (Nicht-Open-Source-Software) | Ja        | (r ) Ja         | Ja             | http://download.opensuse.org/update/leap/42.3/non-oss/
5 | download.opensuse.org-oss       | Haupt-Repository (OSS)                                  | Ja        | (r ) Ja         | Ja             | http://download.opensuse.org/distribution/leap/42.3/repo/oss/
6 | download.opensuse.org-oss_1     | Hauptaktualisierungs-Repository                         | Ja        | (r ) Ja         | Ja             | http://download.opensuse.org/update/leap/42.3/oss
7 | isv_ownCloud_desktop            | The ownCloud Desktop Client (openSUSE_Leap_42.3)        | Ja        | (r ) Ja         | Ja             | http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/openSUSE_Leap_42.3/
8 | opensuse-guide.org-repo         | Libdvdcss Repository                                    | Ja        | (r ) Ja         | Ja             | http://opensuse-guide.org/repo/openSUSE_Leap_42.3/
9 | packman.inode.at-suse           | Packman Repository                                      | Ja        | (r ) Ja         | Ja             | http://packman.inode.at/suse/openSUSE_Leap_42.3/
10 | repo-debug                      | openSUSE-Leap-42.3-Debug                                | Nein      | ----            | ----           | http://download.opensuse.org/debug/distribution/leap/42.3/repo/oss/
11 | repo-debug-non-oss              | openSUSE-Leap-42.3-Debug-Non-Oss                        | Nein      | ----            | ----           | http://download.opensuse.org/debug/distribution/leap/42.3/repo/non-oss/
12 | repo-debug-update               | openSUSE-Leap-42.3-Update-Debug                         | Nein      | ----            | ----           | http://download.opensuse.org/debug/update/leap/42.3/oss/
13 | repo-debug-update-non-oss       | openSUSE-Leap-42.3-Update-Debug-Non-Oss                 | Nein      | ----            | ----           | http://download.opensuse.org/debug/update/leap/42.3/non-oss/
14 | repo-source                     | openSUSE-Leap-42.3-Source                               | Nein      | ----            | ----           | http://download.opensuse.org/source/distribution/leap/42.3/repo/oss/
15 | repo-source-non-oss             | openSUSE-Leap-42.3-Source-Non-Oss                       | Nein      | ----            | ----           | http://download.opensuse.org/source/distribution/leap/42.3/repo/non-oss/

Installierte Pakete eines Repositories anzeigen

Fragt man sich wozu ein bestimmtes Repository im System ist kann man sich mit zypper search --repo <repository-id> --installed-only die aus einem bestimmten Repository installierten Pakete anzeigen lassen. Am Beispiel des NVIDIA-Repositories sieht das bei mir dann so aus:

> zypper search -r download.nvidia.com-leap -i
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                      | Zusammenfassung                                                       | Typ
---+---------------------------+-----------------------------------------------------------------------+------
i+ | nvidia-computeG04         | NVIDIA driver for computing with GPGPU                                | Paket
i+ | nvidia-gfxG04-kmp-default | NVIDIA graphics driver kernel module for GeForce 400 series and newer | Paket
i+ | nvidia-glG04              | NVIDIA OpenGL libraries for OpenGL acceleration                       | Paket
i+ | x11-video-nvidiaG04       | NVIDIA graphics driver for GeForce 400 series and newer               | Paket

Verwaiste Pakete aufräumen

Nach dem Update lohnt es sich häufig verwaiste Pakete zu entfernen. Solche kann man mit einer Kombination von zypper search und grep leicht auffinden:

> zypper search --details --installed-only --type package | grep Systempakete
i+ | Desurium                                    | Paket | 0.8.0_rc10-3.1                                       | x86_64 | (Systempakete)

Möchte man ein Paket gerne behalten lohnt es sich mit zypper search --details <Paketname> zu schauen ob es eine andere Version des Paketes in einem der konfigurierten Repsitories gibt. Findet sich dort keine Version, so lohnt meißtens ein Besuch auf https://software.opensuse.org.

Grid Autosport auf openSUSE 42.3

2018-05-10T00:00:00+02:00

Grid Autosport ist ein zwar älteres, aber immer noch exzellentes Rennspiel das zwar kein definitiv Arcaderacer ist, einen aber auch nicht mit einem Hardcoresimulationsanspruch erschlägt. Ähnlich wie Gran Tourismo findet es einen exzellenten Mittelweg und ist, im Gegensatz zu diesem, auch auf Linux spielbar. Es eignet sich somit also auch für ein kurzes Rennen in der Mittagspause, was nicht heißt, dass man keine Stunden darin versenken kann. Leider lässt es sich unter openSUSE 42.3 aber nachdem man es per Steam heruntergeladen hat nicht direkt starten.

Das Problem

Nach dem Start rödelt der rechner kurz, es kommt aber kein Spielfenster hoch. Startet man Steam aus einer Konsole, so erscheint dort beim Versuch das Spiel zu starten folgendes:

>>> Adding process 17089 for game ID 255220
>>> Adding process 17089 for game ID 255220Installing breakpad exception handler for appid(steam)/version(1506500000)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
>>> Adding process 17090 for game ID 255220
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: relocation error: /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4: symbol ENGINE_load_builtin_engines, version OPENSSL_1.0.0 not defined in file libcrypto.so.1.0.0 with link time reference
Game removed: AppID 255220 "GRID Autosport", ProcID 17086

Hier liegt also eine Inkompatibilität zwischen der vom Spiel mitgebrachten Curl-Bibliothek und den von Steam mitgebrachten Bibliotheken SSL und Crypto vor.

Die Lösung aus dem Netz

Beim Googeln findet sich schnell eine Lösung welche vorschlägt libcrypto.so.1.0.0 aus der Steam-Runtime entfernen. Dies löst auch das Problem mit Grid Autosport. Allerdings hat diese Lösung auch Nachteile. Da die Steam-Runtime modifiziert wird ist damit zu rechnen, dass das nächste Steam-Update die Dateien wiederherstellt und man die Datei erneut entfernen muss. Außerdem kann es damit zu Problemen in anderen Spielen kommen welche sich auf die von Steam mitgelieferte Version verlasen.

Die bessere Lösung

Die obige Lösung weißt aber bereits den Weg zu einer besseren Lösung, denn sie funktioniert deshalb, weil openSUSE bereits kompatible Versionen der beiden Bibliotheken enthält. Tatsächlich betrifft dieses Problem einige Spiele welche von Feral Interactive portiert wurden. So ist auch Dirt Rally von diesem Problem betroffen. Für dieses Spiel findet sich eine Lösung welche sich Analog auch auf Grid Autosport anwenden lässt:

Ins Spielverzeichnis wechseln: cd <steam library>/steamapps/common/Grid\ Autosport/lib/x86_64.

Dort auf die libcrypto des Systems linken:

> ln -s /lib64/libcrypto.so.1.0.0
> ln -s /lib64/libssl.so.1.0.0

Diese Lösung ist besser, weil sie nur das einzelne Spiel betrifft und nicht global die Steam-Runtime beschädigt. Sie hat allerdings den Nachteil, dass sie kaputt gehen kann falls Steam mal die Dateien anfasst, z.B. bei einem Update. Updates von Grid Autosport sind aber deutlich seltener als solche von Steam selbst, und auf meinem System hat der Fix auch schon einige Patches überlebt.

Zwei neue Pakete für openSUSE

2018-04-25T00:00:00+02:00

openSUSE Tumbleweed enthält jetzt zwei neue Pakete welche ich erstellt habe: python-emoji und python-ntfy. Ersteres hat es sogar noch in openSUSE Leap 15.0 geschafft.

Die Funktionalität von python-emoji ist schnell erklärt und trotzdem unglaublich nützlich, wie diese leichte Abwandlung des Beispiels aus der Paketbeschreibung auf PyPI zeigt:

>> import emoji
>> print(emoji.emojize('Python ist :thumbs_up:'))
Python ist 👍

Natürlich funktioniert dies sowohl in modernem Python als auch in klassischem Python.

Eines der Pakete welche von python-emoji profitieren ist python-ntfy. python-ntfy ermöglichte es aus der Konsole Benachritigungen zu verschicken. Diese können entweder auf der Arbeitsfläche angezeigt werden, oder über verschiedene Backends an ein Smartphone weitergeleitet werden. Allerdings sind momentan noch nicht Backends auch für openSUSE paketiert. Besonders praktisch ist der Befehl ntfy done. Nutzt man diesen um einen lange laufenden Prozess zu starten, so bekommt man, sobald dieser fertig ist, eine Nachricht welche auch über Erfolg oder Misserfolg und die Laufzeit des Prozesses informiert. Man kann sich also ganz gemütlich in die Hängematte legen während der Rechner ackert. 😉

Mastodon

2018-04-22T00:00:00+02:00

So toll Twitter ist, so unnatürlich fühlen sich derartig zentralisierte Plattformen im Ineternet auch immer an. Bisher konnte sich allerdings auch noch keine verteiltere Alternative durchsetzen. Dabei gibt es eigentlich keinen Grund wieso kurze öffentliche Beitrage nicht wie Email mithilfe vieler vernetzter Anbieter verteilt werden sollten. An dieser Herausforderung versucht sich Mastodon. Nachdem ich davon jetzt schon ein paar mal gehört habe gebe ich diesem jetzt auch mal eine Chance. Ihr findet mich dort als @marix@chaos.social.

Bash-Completion for OSC in Verzeichnissen mit Leerzeichen

2018-03-21T00:00:00+01:00

Mit diesem Artikel führe ich meine Serie zu kleinen Beträgen zu freier Software fort. Diesmal nahm ich mich dem Problem an, dass die Bash-Completion des Kommandozeilenprogrammes für den Open Build Service – osc – in Verzeichnissen mit Leerzeichen im Pfad nicht richtig funktioniert.

Ich gehöre zu dieser, anscheinend raren, Spezies Mensch die ihren Ordnern gerne sprechenden Namen gibt. Deshalb Nutze ich in diesen auch häufiger mal Leerzeichen. Dabei stoße ich regelmäßig auf das Problem, dass Anwendungen mit solchen Ordnern nicht korrekt umgehen können. So auch die Bash-Completion von osc, welche statt der gewünschten Vorschläge Fehlermeldungen produzierte:

> osc add /usr/lib/osc/complete: Zeile 90: test: Zu viele Argumente.
/usr/lib/osc/complete: Zeile 91: test: Zu viele Argumente.
/usr/lib/osc/complete: Zeile 92: test: Zu viele Argumente.
/usr/lib/osc/complete: Zeile 96: test: Zu viele Argumente.
/usr/lib/osc/complete: Zeile 90: test: Zu viele Argumente.
/usr/lib/osc/complete: Zeile 91: test: Zu viele Argumente.
/usr/lib/osc/complete: Zeile 92: test: Zu viele Argumente.
/usr/lib/osc/complete: Zeile 96: test: Zu viele Argumente.

Der Fix ist trivial und war schnell implementiert und ändert nur sieben Zeilen Code. Einfach in den betroffenen Zeilen doppelte Anführungszeichen um die Variable ${PWD} eingefügt und schon wurde der Verzeichnisname korrekt im ganzen, statt als mehrere Argument, an test übergeben. Wenige Stunden später wurde der Pull-Request auf Github dann auch schon in den Hauptzweig gemerged. In Zukunft stolpert man also über ein WTF weniger. 😃

Insgesamt hat der Pull-Request in diesem Fall weniger Zeit gekostet als diesen Artikel zu schreiben. Vermutlich hat mich der Ärger den ich früher mit diesem Bug hatte mehr Zeit gekostet als der Fix. Es lohnt sich also immer gleich mal auf den Code zu schauen. Viele Probleme lassen sich viel leichter abstellen als man denkt.

Tests für openSUSE's Paket des Prometheus-Node-Exporters

2018-03-12T00:00:00+01:00

Dies ist mein erster Testballon für eine neue Serie von Artikeln auf meiner Webseite. Mit diesen Artikeln möchte ich eine Reiher kleiner Open-Source-Beiträge, welche ich von Zeit zu Zeit en passant vornehme, Dokumentiere. Das schöne an freier Software ist ja gerade, dass man nicht auf einen Hersteller angewiesen ist um Fehler zu beheben oder die Software für den eigenen Bedarf zu ertüchtigen. Auf den ersten Blick können andere Projekte aber durchaus erstmal einschüchtern wirken. Dabei lässt sich häufig schon mit sehr kleinen, einfachen Beiträgen „die Welt“ verbessern. Vielleicht lässt sich ja die eine oder andere Hemmschwelle abbauen, wenn welche Bandbreite an kleinen und größen Beiträgen man vornehmen kann.

Letzten Monat habe ich mir mal openSUSEs Paket des Node-Exporters für Prometheus angesehen, da ich diesen auch für mein eigenes, privates Monitoring einsetze. Hierbei fiel mir auf, dass beim Paketieren die Tests nicht ausgeführt wurden. Eigentlich sollten die Tests einer Software beim paketieren immer ausgeührt werden. Nur so ist sichergestellt, dass die Software mit den in der Distribution genutzten Versionen von Compilern und genutzten Bibliotheken sauber funktioniert.

Das Beispiel im Wiki von openSUSE beinhaltet das Ausführen der Tests. Somit ist der Fehler schnell behoben.

%check
%gotest github.com/prometheus/node_exporter...

Eine kleine Besonderheit gab es allerdings noch zu beachten: Der Node-Exporter nutzt Testdaten welche im Repository nur gepackt vorliegen. Diese sind vor Ausführung der eigentlichen Tests noch zu entpacken. Ein kurzer Blick auf das Makefile verrät, dass hierfür das Target collector/fixtures/sys/.unpacked zuständig ist. Also schnell noch ein make collector/fixtures/sys/.unpacked in den Abschnitt %build eingefügt und schon funktioniert alles.

Damit war der Submitrequest dann auch schon bereit und ist inzwischen auch angenommen worden.

Steam vergisst ständig die Anmeldung

2018-02-26T00:00:00+01:00

Seit einiger Zeit fragte mich mein Steam bei fast jedem Start nach der Anmeldung, obwohl die Option die Anmeldung zu speichern gesetzt war. Immer wenn die Anmeldung verloren ging war die Oberfläche außerdem wieder auf Englisch eingestellt. Das Problem lässt sich lösen indem man Steam das Recht nimmt die Datei ~/.steam/registry.vdf zu schreiben.

Lange Zeit war es für mich einfach nur nervig mich bei Steam immer wieder neu anmelden und die Sprache zurückstellen zu müssen. Als jetzt aber die VEX-LAN 18 vor der Tür stand wurde es ein echtes Problem, denn ohne gespeicherten Login funktioniert der Offlinemodus nicht. Dieser ist auf LANs aber wichtig, da dort üblicherweise kein Internet zur Verfügung steht.

Zum Glück bin ich nicht der erste der dem Problem begegnet ist. Neben der Fehlerbermeldung auf Github gibt es auch einen Eintrag in der Steam-FAQ von Arch-Linux in dem sich eine Möglichkeit findet das Problem zu vermeiden:

chmod -w ~/.steam/registry.vdf

Dieser Befehl unterbindet schreibenden Zugriff auf diese Datei des Steam-Clients. Letzter scheint diese zur Laufzeit immer wieder zu schreiben und dabei häufiger mal zu korrumpieren, so dass er sie beim nächsten Start neu initialiseren muss.

Das gute an diesem Workaround ist, dass weiterhin ein Wechsel zwischen Offline- und Onlinemodus möglich ist. Dieser scheint an andere Stelle gespeichert zu werden. Dennoch sollte man sich natürlich bewusst sein, dass es nun natürlich vorkommen kann, dass der Client eine gewünschte Einstellung nicht persistieren kann. Sollte es also zu merkwürdigem Verhalten kommen, sollte man Steam eventuell mal wieder erlauben die Datei zu schreiben. Bisher hat Steam mit diese Workaround aber wunderbar funktioniert.

openSUSE Leap 42.3 auf dem Raspberry Pi 2 ohne Monitor nutzen

2018-01-02T00:00:00+01:00

Der Raspberry Pi 2 ist ein praktischer kleiner Rechner, und das dafür vorgesehene Raspbian auch eine gut gemachte Linux-Distribution. Hat man allerdings schon auf mehreren Rechner openSUSE im Einsatz ist es viel attraktiver dieses auch dort zu verwenden, zumal dies völlig problemlos möglich ist. Der Einsatz von Tumbleweed auf dem Raspberry Pi 2 ist im Wiki von openSUSE detailliert dokumentiert. Mit wenigen kleinen Änderungen lässt sich so auch openSUSE Leap auf dem Raspberry Pi 2 nutzen, und zwar ohne an diesen Monitor oder Maus anschließen zu müssen.

Die Installation eines Betriebssystem auf dem Raspberry PI erfolgt stets dadurch den passenden Installer auf seine SD-Karte zu kopieren. Beim ersten Start wird diese dann passend eingerichtet. Die passende Datei für openSUSE Leap 42.3 findet sich auf http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/. Für den Betrieb ohne Tastatur und Monitor bietet sich die Variante Just enough OS (JeOS) an. Damit findet man die passende Datei indem man die Downloadseite nach JeOS-raspberrypi2 durchsucht. Aktuell ist dies http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l.raw.xz. Es empfiehlt sich auch die Prüfsumme zu checken.

> sha256sum -c openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz.sha256
openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz: OK
sha256sum: WARNUNG: 14 Zeilen sind nicht korrekt formatiert

Die Warnung zu den nicht formatierten Zeilen liegt daran, dass der Inhalt mit PGP signiert ist. Die Signatur lässt sich mit GPG prüfen.

> gpg --verify openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz.sha256
gpg: Signatur vom Mi 26 Jul 2017 19:39:17 CEST mittels RSA-Schlüssel ID 3DBDC284
gpg: Korrekte Signatur von "openSUSE Project Signing Key <opensuse@opensuse.org>" [vollständig]
note: random_seed file not updated

Jetzt wo klar ist, dass das Image nicht beschädigt ist, kann man der Anleitung für Tumbleweed im openSUSE-Wiki folgen.

Achtung! Das Schreiben auf die SD-Karte kann, wenn man den falschen Gerätebezeichner erwischt, Daten auf einer anderen Platte zerstören. Wenn man sich nicht 100% sicher ist welchen Gerätebezeichner die SD-Karte hat, dann kann man direkt nach dem Einstecken in dmesg nachsehen, welchen Bezeichner die Karte bekommen hat. In meinem Beispiel hat der Kartenleser mehrere Einschübe, so dass gleich mehrere Geräte auftauchen, aber nur für das Gerät mit der SD-Karte wird die Kapazität (sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)) und die Partitionsliste (sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3) ausgegeben.

> dmesg | tail -n 30
[13801.698740] EXT4-fs error (device sdi6): htree_dirblock_to_tree:986: inode #2: block 8582: comm dolphin: bad entry in directory: directory entry across range - offset=0(0), inode=4489218, rec_len=32780, name_len=129
[13814.445903] sdi: detected capacity change from 8026849280 to 0
[13897.279227] sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)
[13897.285959]  sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3
[14939.444590] usb 2-6: USB disconnect, device number 2
[37767.485975] usb 2-6: new SuperSpeed USB device number 3 using xhci_hcd
[37767.532474] usb 2-6: New USB device found, idVendor=8564, idProduct=4000
[37767.532478] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37767.532479] usb 2-6: Product: USB3.0 Card Reader
[37767.532479] usb 2-6: Manufacturer: Realtek
[37767.532480] usb 2-6: SerialNumber: 201412031053
[37767.539943] usb-storage 2-6:1.0: USB Mass Storage device detected
[37767.546235] scsi host8: usb-storage 2-6:1.0
[37768.558079] scsi 8:0:0:0: Direct-Access     Generic- USB3.0 CRW    -0 1.00 PQ: 0 ANSI: 6
[37768.558355] sd 8:0:0:0: Attached scsi generic sg6 type 0
[37768.569622] scsi 8:0:0:1: Direct-Access     Generic- USB3.0 CRW    -1 1.00 PQ: 0 ANSI: 6
[37768.569862] sd 8:0:0:1: Attached scsi generic sg7 type 0
[37768.582535] scsi 8:0:0:2: Direct-Access     Generic- USB3.0 CRW    -2 1.00 PQ: 0 ANSI: 6
[37768.582758] sd 8:0:0:2: Attached scsi generic sg8 type 0
[37768.601427] scsi 8:0:0:3: Direct-Access     Generic- USB3.0 CRW    -3 1.00 PQ: 0 ANSI: 6
[37768.601678] sd 8:0:0:3: Attached scsi generic sg9 type 0
[37769.473299] sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)
[37769.473958] sd 8:0:0:0: [sdf] Attached SCSI removable disk
[37769.475113] sd 8:0:0:3: [sdi] Write Protect is off
[37769.475116] sd 8:0:0:3: [sdi] Mode Sense: 2f 00 00 00
[37769.475608] sd 8:0:0:1: [sdg] Attached SCSI removable disk
[37769.477768] sd 8:0:0:3: [sdi] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[37769.478227] sd 8:0:0:2: [sdh] Attached SCSI removable disk
[37769.484922]  sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3
[37769.488248] sd 8:0:0:3: [sdi] Attached SCSI removable disk

Um das Image auf die Karte zu schreiben benötigt man Root-Rechte. Das Gerät muss von /dev/sdX auf den korrekten Bezeichner angepasst werden. Für obiges Beispiel /dev/sdi.

> sudo -s
# xzcat openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct
328+1 records in
328+1 records out
1377828864 bytes (1.4 GB, 1.3 GiB) copied, 147.571 s, 9.3 MB/s
# sync

Hierbei passiert folgendes:

xzcat entpackt das Image auf die Standardausgabe.
dd übernimmt über die Standardeingabe das entpackte Image und schreibt es 1:1 auf das angegebene Gerät, und zwar ohne zu Puffern.
sync stellt sicher, dass alle Daten auch wirklich geschrieben wurden und die Karte sicher entnommen werden kann.

Anschließend kann man den Raspberry Pi 2 mit den üblichen Schritten in Betrieb nehmen:

Karte herausnehmen und in den Pi stecken,
Netzwerk an den Raspberry Pi 2 anschließen,
und dann Strom auf Pi geben.

Der initiale Start kann einige Zeit dauern. Bei mir waren dies gut anderthalb Stunden, mit einer schnelleren SD-Karte kann man hier aber Zeit sparen.

Hat man keinen Monitor am Raspberry Pi 2, so steht man nun vor der Herausforderung dessen Netzwerkadresse herauszufinden um sich mit dem zu verbinden. Prinzipiell kann man diese herausfinden indem man nach dem letzten Gerät schaut, dass sich am Router angemeldet hat. Löst der Router auch die von den Rechnern selbst gewählten Namen auf, so ist es sogar noch einfacher, da sich ein frisches openSUSE immer mit dem Rechnernamen linux meldet. An einer Fritz!Box ist er deshalb als linux.fritz.box erreichbar.

Nun kann man sich also das erste mal anmelden. Der Nutzer ist root und das Passwort linux. Hat man eine Fritz!Box also: ssh root@linux.fritz.box. Beim ersten Anmelden sollte man gleich noch die Inbetriebnahme das Basissystems abschließen:

Das Passwort ändern,
dem eigenen SSH-Key per ssh-copy-id auf dem Raspberry Pi Berechtigung zum Anmelden geben,
Updates einspielen,
und den Hostnamen ändern.

Letzterer Schritt ist wichtig, da es sonst bei Inbetriebnahme eines weiteren Raspberry Pi zu kollisionen kommen kann und man sich unnötig die Auflösung der Netzwerkadresse des neuen Systems erschwert.

Das Just enough in JeOS ist übrigens durchaus ernst gemeint. Wer sein System anschließend mit Ansible weiter einrichten möchte sollte dort noch Python komplett installieren: zypper in python3. Ohne diesen Schritt kann es zu kuriosen Fehlermeldungen kommen, da Teile der Standardbibliothek in der minimalen Installation von Python fehlen.

Wieso ich pytest in PyCharm immer mit --no-cov ausführe

2017-12-12T00:00:00+01:00

Immer wieder habe ich mich, beim Versuch einen fehlgeschlagenen Test in PyCharm zu debuggen, gewundert wieso meine Haltepunkte misachtet werden. Um dies zu vermeiden führe ich pytest in PyCharm inzwischen immer mit der Option --no-cov aus.

Das Plugin pytest-cov hilft einem wunderbar dabei einen Überblick über die Testabdeckung zu behalten. Um es nicht immer explizit aktivieren zu müssen bietet es sich an dieses über einen passenden Eintrag in der pytest.ini zu tun.

[pytest]
addopts = --cov=example

In PyCharm hat das Plugin allerdings nur einen geringen Mehrwert, denn dort achte ich eigentlich weniger auf Ausgabe von PyTest, denn ich bekomme ich ja grafisch angezeigt wenn Tests fehlschlagen. Möchte ich mir die Testabdeckung ansehen, so bietet mir PyCharm eine eigene Möglichkeit diese einzusammeln, samt passender Visualisierung.

Dafür kollidiert pytest-cov aber mit dem Debugger von PyCharm. Denn beide registrieren sich per sys.settrace um allen ausgeführten Code inspizieren zu können. Nutzt man pytest-cov innerhalb des Debuggers, überschreibt es dessen dort hinterlegte Funktion. Damit hat der Debugger dann nicht mehr die Möglichkeit in die Ausührung einzugreifen. Um dies zu vermeiden muss man pytest-cov durch die Option --no-cov deaktiveren. Damit fehlt dann zwar auch die Information zur Testabdeckung, aber dafür hat PyCharm ja, wie gesagt, seine eigene Funktionalität.

Wie man Python-Module in PyCharm ausführt

2017-12-02T00:00:00+01:00

Beim Lesen der Veröffentlichungsankündigung von PyCharm 2017.3 stellte ich amüsiert fest, dass PyCharm 2017.3 es jetzt unterstützt Python-Module auszuführen. Tatsächlich ging dies in PyCharm schon immer, wenn man verstanden hatte wie PyCharm die Parameter mit denen es Python aufruft zusammensetzt.

Enthält ein Modul in der aktuellen Pythonumgebung ein Paket __main__.py, so kann man dieses durch den Aufruf python -m <modulename> direkt ausführen. Ein beliebtes Bespiel dafür ist der in der Standardbibliothek enthaltene einfache HTTP-Server, der mit python -m http.server <port> ausgeführt werden kann.

PyCharm 2017.3 erlaubt einem jetzt über ein Dropdown auszuwählen ob man eine Datei oder ein Modul ausführen will. Tatsächlich funktioniert dies aber auch in älteren Versionen. Hierzu muss lediglich als letzte Option für den Pythoninterpreter – nicht das Skript – -m angegeben werden. PyCharm ruft nämlich am Ende immer <ausgewählter Pythoninterpreter> <Interpreteroptionen> <Skriptname> <Skriptparameter> auf. Enden die Interpreteroptionen mit -m interpretiert Python den „Skriptnamen“ als Modulnamen. In älteren Versionen von PyCharm muss man für obiges Beispiel also lediglich als Skript http.server und bei den Interpreteroptionen -m eintragen.

Öffentliche PSN-Profile

2017-10-05T22:15:00+02:00

Durch das PS4-Systemsoftware-Update 5.00 wurde ich auf eine Änderung im Playstation Network aufmerksam auf welche ich lange gewartet hatte: Es gibt jetzt öffentliche Profile.

Meins habe ich natürlich gleich mal zur Liste meiner Profile hinzugefügt. Damit könnt ihr jetzt sehen, was ich auf der Playstation so treibe. Auch könnte ihr mir so deutlich einfacher eine Freundschaftsanfrage schicken. Wie bei Steam nehme ich die aber auch im PSN nur an wenn aus der Anfrage hervorgeht wer ihr seid, beziehungsweise woher wir uns kennen. Denn so schön Nicknames oft sind, sie helfen nicht immer dabei euch wiederzuerkennen.

Wenn das System zu gut aufräumt

2017-09-04T22:30:00+02:00

Eigentlich ist es ja gewünscht wenn das System einem regelmäßig die temporären Dateien wegräumt. Löscht es einem dabei aber auch Dateien welche man gerade erst dort abgelegt hatte, dann steht wohl irgendwas in der Konfiguration schief.

Ich nutze tatsächlich häufig das Verzeichnis /tmp. Gerade beim Schreiben kleiner Skripte ist es ganz angenehm sich im Fehlerfall einfach darauf zu verlassen, dass übrig gebliebene temporäre Dateien schon wieder verschwinden werden. Auch meine virtuellen Python-Umgebungen lege ich, seit mich Holger Peters mal auf diese Idee gebracht hat, stets dort ab. Seit einiger Zeit löschte mir meine openSUSE meine gerade angelegten Dateien aber immer kurz nach dem Systemstart unter der Nase weg.

Da das Problem immer kurz nach dem Systemstart auftrat war schnell klar, dass da wohl der Aufräumcronjob schuld sein muss. Auch wenn dies natürlich inzwischen gar kein Cronjob mehr ist sondern ein Systemd-Timer.

marix@eddie:~> systemctl list-timers
NEXT                         LEFT        LAST                         PASSED       UNIT                         ACTIVATES
Di 2017-09-05 21:10:12 CEST  22h left    Mo 2017-09-04 21:10:12 CEST  1h 9min ago  systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.serv
Mo 2017-09-11 00:00:00 CEST  6 days left Mo 2017-09-04 20:55:51 CEST  1h 23min ago fstrim.timer                 fstrim.service

Der alte Cronjob hatte eine Konfigurationsdatei in /etc/sysconfig in der man die Schonzeit für Dateien in /tmp und /var/tmp konfigurieren konnte. Beim Systemd-Job übernehmen die Konfigurationsdateien von systemd-tmpfiles diesen Job. Die dazugehörige Manpage ist tmpfiles.d (5).

Die Standardatei /usr/lib/tmpfiles.d/tmp.conf erklärt auch ganz brav diese Verzeichnisse in Ruhe zu lassen. Das ist zwar nicht ganz was ich möchte, aber auch nicht Grund meines Problemes.

# Clear tmp directories separately, to make them easier to override
# SUSE policy: we don't clean those directories
q /tmp 1777 root root -
q /var/tmp 1777 root root -

Die schuldige Konfiguration fand sich in /etc/tmpfiles.d/tmp.conf. Hier muss, bei einem der vielen Versionsupgrades welche mein System hinter sich hat, ein kleiner Übertragungsfehler passiert sein.

d /tmp 1777 root root 0d
d /var/tmp 1777 root root -
x /tmp/* - - - - root

Mit dem Alter Null Tage wird systemd-tmpfiles angewiesen alle Dateien zu löschen, egal wann sie zuletzt modifiziert wurden. Auch wenn dies die meißten Anwendungen in meinem System klaglos hinnahmen sorgte es natürlich für einiges WTF was meine eigenen Skripte und die die virtuellen Python-Umgebungen anging. Die korrektur des Wertes auf einen Tag hat mein Problem erfolgreich gelöst.

d /tmp 1777 root root 1d
d /var/tmp 1777 root root -
x /tmp/* - - - - root

Und das schöne an Systemd ist, dass man so eine Änderung dann auch gleich sehr leicht testen kann.

sudo systemctl start systemd-tmpfiles-clean.service

Eine Anwendung welche mit dem agressiven Aufräumen der temporären Dateien gar nicht klar kommt ist übrigens meine früher so geliebter Browser Opera. Nachdem die temporären Dateien weggräumt wurden findet dieser seine bereits laufende Instanz nicht mehr und fliegt dann beim Versuch ein zweites mal das gleiche Profil zu öffnen ordendlich auf die Fresse. Dies hat mich hinreichend genervt, so dass ich kürzlich zum Firefox gewechselt bin. Seit ich kurz darauf die hier beschriebene Fehlkonfiguration behoben habe funktioniert aber auch der, inzwischen von mir nicht mehr wirklich genutzte, Opera wieder tadellos.

Umgebaut

2017-08-27T21:30:00+02:00

Ich habe meine Webseite ein wenig umgebaut. Damit sollte Marix.org jetzt auch auf mobilen Geräten besser lesbar sein. Allerdings sind sicherlich einige Links kaputt gegangen. Alle alten Blogposts sowie der RSS-Feed werden zwar verübergehend umgeleitet, solltet ihr letzteren nutzen empfehle ich auch allerdings zeitnah auf die neue URL https://marix.org/feeds/all.atom.xml umzustellen.

Gründe für den Umbau gab es gleich mehrere. So war Marix.org auf mobilen Geräten ziemlich unbrauchbar und ein Wechsel von Drupal 7 auf Drupal 8 war auch überfällig. Meine Performanceprobleme mit Drupal hatten sich zwar bereits durch einen Wechsel von Strato zu Netcup gelöst, aber die häufig notwendigen Sicherheitsupdates, welche bei Drupal leider auch nicht mit einem zypper up schnell eingespielt sind, blieben ein Ärgernis. So habe ich jetzt auf eine komplett statische Seite umgestellt welche mithilfe das Python-basierte Pelican generiert wird.

Optisch lässt sich auf dieser Seite sicherlich noch einige herausholen. Die Vergängerin war allerdings auch keine Schönheit und letztendlich sollte es ja auf die Inhalte ankommen. Jetzt, wo ich nicht mehr jeden Mittwoch Zeit auf Sicherheitsupdates verschwende komme ich dann ja vielleicht endlich mal dazu die eine oder andere Idee, welche ich noch für diese Seite habe, umzusetzen. Der Entwürfeordner ist auf jeden Fall zum bersten voll.

openSUSE Leap 42.2 auf antiker Hardware

2016-12-19T21:24:15+01:00

Bei uns ist immer noch ein, inzwischen vermutlich als antik geltender, ASUS-Laptop mit einem Core2 Duo und 3 GiB RAM im Einsatz, bisher mit openSUSE 13.1. Angesichts dessen Supportendes, war aber ein update nötig. Und da auch das damals vorinstallierte Windows Vista sein Lebensende erreicht hatte, und seit mehreren Jahren nicht mehr genutzt war, führte ich eine Neuinstallation mit openSUSE Leap 42.2 durch. Wie bei jeder Rechnerneuinstallation stolperte ich dabei über ein paar Eigenarten, aber insgesamt läuft das System wunderbar.

Insgesamt fühlt sich das System flotter an als vorher. Der Hauptgrund dafür ist wohl, dass das System recht sparsam mit dem Hauptspeicher umgeht. So nutzt es wenn man die üblichen Anwendungen, wie KMail und ownCloud, im Hintegrund hat und dann noch DM Fotowelt, ein mittelgroßes Open-Office-Dokument mit Fotos und Firefox mit einer zweistelligen Anzahl Tabs offen hat nur run 2 GiB seines Hauptspeichers. So kommt das System dann trotz vollverschüsselter Festplatte und ohne SSD auf nutzbare Geschwindigkeit.

Ein Wermutstropfen ist, dass ich die in KDE eingebaute Volltextsuche abschalten musste. Obwohl das System bei Installation und während des Zurückkopierens aller Dateien auch über Nacht stabil lief, war damit Schluss sobald die Volltextsuche anfing die Dateien zu indizieren. Nach fünf bis zehn Minuten war der Rechner komplett eingefroren. Auch ein SSH auf den Rechner war nicht mehr möglich.

Ein weiterer interessanter Bug ist, dass die Plugins von Parley nicht funktionieren. Diese haben in der Shebang kf5kross als Interpreter angegeben, allerdings wird dieses nicht installiert.

PyCharm 2016.3

2016-12-05T20:44:46+01:00

Letzte Woche erschien PyCharm 2016.3 und brachte ein paar Feature auf die ich schon lange gewartet habe. Vor allem ist es endlich möglich, dem Django-Testrunner beliebige Argumente zu übergeben. Damit lässt sich endlich --keepdb und --parallel nutzen. Ersteres beschleunigt die Testausführung ungemein, wenn man immer wieder wenige kurze Tests ausführen möchte, letzteres macht große Testsuiten erträglich.

Außerdem wird jetzt, wenn man eine Virtualenv konfiguriert hat, diese in der eingebauten Konsole automatisch aktiviert. Auch Git remotes lassen sich endlich über PyCharm hinzufügen, ohne, dass man extra eine Konsole öffnen muss. Tatsächlich sind beides keine Feature, für die es keine einfachen Workarounds gab. Wieso es in einer ansonsten so auf flüssige Workflows getrimmten IDE aber so lange gedauert hat diese Kleinigkeiten einzubauen ist mir etwas unverständlich.

Das neue Python 3.6 wird jetzt auch unterstützt. Allerdings werde ich, auch wenn diese aus verschiedenen Gründen sehr spannend ist, wohl noch eine Weile warten müssen, bis ich diese richtig einsetzen kann. Das gleiche gilt für den neuen Numpy-Array- und Dataframe-Viewer im Debugger. Als ich noch regelmäßig mit OpenCL gearbeitet habe musste ich mir die entsprechende Funktionalität immer selber bauen. Schön, dass jetzt einfach an Bord zu haben, wenn man es mal benötigt. Gerade bei Gelegenheitsnutzung, wie es bei mir gerade mit Numpy ist, ist es besonders ärgerlich sich notwendige Werkzeuge selbst bauen zu müssen.

Insgesamt lohnt das Update auf PyCharm 2016.3 also. Für mich vor allem wegen der deutlich verbesserten Django-Unterstützung.

Devpi-Builder 2.2.0

2016-07-05T23:58:40+02:00

Eine der coolen Sachen an Open-Source ist, dass einem immer wieder mal andere Nutzer Verbesserungen implementieren zu denen man selber lange nicht gekommen ist. Dies ist auch bei Version 2.2.0 von Brandon, dem Devpi-Builder, so. Dank eines Pull-Requests von Travis Mehlinger bekommt man nun, wenn eine Build fehlschlägt, die Fehlermeldung sauber mit der restlichen Ausgabe präsentiert, und muss sich diese nicht mühsam aus der Konsole herausklauben. Diese Problem hatte mich schon länger gestört.

Devpi-Builder 2.1.0

2016-04-24T12:56:19+02:00

Es ist ja cool, wenn es einem der Arbeitgeber ermöglicht nützliche Software als Open Source zu veröffentlichen. Noch cooler ist aber, wenn diese Software auch wirklich außerhalb der eigenen Firma verwendet wird. Und besonders schön ist es, wenn man dies daran merkt, dass von externen Nutzern Verbesserungen beigetragen werden. So durfte ich diese Woche Version 2.1.0 von Brandon, dem Devpi-Builder, veröffentlichen nachdem Hans Lawrenz Unterstützung für zertifikatsbasierte Authentifizierung beigetragen hat.

Devpi-Cleaner 0.2.0

2016-04-17T21:46:37+02:00

Wer einen größeren Devpi-Server betreibt kommt immer wieder mal in die Situation Pakete von diesem löschen zu müssen. Für einzelne Pakete lässt sich dies mit dem normalen Devpi-Client noch leidlich komfortabel lösen, aber schon nichtvolatile Indices machen daraus ein aufwendiges Unterfangen mit mehreren manuellen Schritten, bei dem leicht Fehler unterlaufen. Um diese Problem zu lösen gibt es Léon, den Devpi-Cleaner, der es beispielsweise ermöglichte alle alten Enwicklungsversionen zu entfernen oder den Index nur für die Dauer der Löschoperation volatil zu schalten.

Die Notwendigkeit auf dem Devpi aufzuräumen ergibt sich nicht nur, wenn mal ein Paket falsch hochgeladen wurde. Auch Änderungen der Indexstruktur können eine Aufräumaktion sinnvoll machen. Und wer Continuous Integration ernst nimmt und zu jedem erfolgreichen Build ein Paket hochlädt, dem blähen alte, nicht mehr benötigte Entwicklungsversionen die Backupgröße, und damit auch die Erstellungsdauer auf.

Bei meinem Arbeitgeber Blue Yonder ist es glücklicherweise gerne gesehen allgemein nutzbare Software als Open Source zu veröffentlichen. So konnte ich letzte Woche Version 0.2.0 von Léon, dem Devpi-Cleaner veröffentlichen. Nicht nur sind jetzt komplexere Auswahlkriterien möglich, sondern das Löschen geht jetzt auch deutlich schneller und dank Fortschrittsbalken mit Restzeitabschätzung hat man eine Chance seine Kaffeepausen zeitoptimiert einzulegen. Eine komplette Liste der Änderungen findet sich im Changelog.

Kein CUDA nach dem Update auf openSUSE Leap 42.1

2016-04-15T22:41:40+02:00

Nachdem ich meine Workstation von openSUSE 13.1 auf openSUSE Leap 42.1 migriert hatte funktionierten lies sich die Grafikkarte nicht mehr zum Rechnen nutzen. Irgendwie hatte es einen Fehler bei der Installation des neuen Grafiktreibers gegeben. Seine Neuinstallation löste das Problem.

Das Problem

Nach dem Update fanden CUDA nutzende Anwendungen keine Grafikkarte. So meldete Boinc No usable GPUs found. Prinzipiell funktionierte die Grafikkarte aber. So hatte ich volle 3D-Beschleunigung, und auch nvidia-smi meldete die erwarteten Daten:

+------------------------------------------------------+
| NVIDIA-SMI 340.93     Driver Version: 340.93         |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 580     Off  | 0000:01:00.0     N/A |                  N/A |
| 43%   49C   P12    N/A /  N/A |    494MiB /  1535MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Compute processes:                                               GPU Memory |
|  GPU       PID  Process name                                     Usage      |
|=============================================================================|
|    0            Not Supported                                               |
+-----------------------------------------------------------------------------+

Die Analyse

NVIDIA bietet CUDA zwar für einige SUSE-Varianten zum Download, aber leider nicht für Leap 42.1. Es gibt zwar Pakete für das unterliegende SLE 12, aber diese verlangen einen Grafikttreiber welcher nicht zum Kernel von Leap 42.1 passt. Deshalb habe ich mich für die Analyse auf OpenCL-Beispiel-Code zurückgezogen. Denn für OpenCL benötigt man nur die Header, welche man einfach direkt zum Code legen kann, und einen C-Compiler.

Schon der erste Versuch mit einem Beispielprogramm welches nur die OpenCL-Runtime initialisiert zeigt das Problem:

> sudo ./platform
modprobe: FATAL: Module nvidia-uvm not found.
Failed to get platforms: -1001

Das sudo ist hier übrigens nur vorangestellt um es zu ermöglichen Kernel-Module nachzuladen. Ohne sudo erhält man den gleichen Fehler, aber ohne die essentielle Information zum Kernelmodul.

Schnell konnte ich herausfinden, dass eigentlich alle Kernelmodule installiert sind:

> rpm -ql nvidia-gfxG03-kmp-default-340.93_k4.1.12_1-36.7.x86_64 | grep \.ko
/lib/modules/4.1.12-1-default/updates/nvidia.ko

> rpm -ql nvidia-uvm-gfxG03-kmp-default-340.93_k4.1.12_1-36.7.x86_64 | grep \.ko
/lib/modules/4.1.12-1-default/updates/nvidia-uvm.ko

> ls /lib/modules/4.1.12-1-default/updates/
nvidia.ko  nvidia-uvm.ko

Allerdings war das nicht das Modulverzeichnis des aktuell laufenden Kernels:

> uname -a
Linux eddie 4.1.13-5-default #1 SMP PREEMPT Thu Nov 26 16:35:17 UTC 2015 (49475c3) x86_64 x86_64 x86_64 GNU/Linux

Wo liegen also dessen Module? /lib/modules/4.1.13-5-default/updates existiert nicht. Das NVIDIA-Modul ist aber schnell gefunden:

> ls /lib/modules/4.1.13-5-default/weak-updates/updates/
nvidia.ko

Nur fehlt in diesem Verzeichnis das nvidia-uvm.ko.

Die Lösung

Eine Neuinstallation des dazugehörigen Paketes lässt dann endlich auch OpenCL wieder richtig initialisieren:

> zypper in in -f nvidia-uvm-gfxG03-kmp-default

> ls /lib/modules/4.1.13-5-default/weak-updates/updates/
nvidia.ko  nvidia-uvm.ko

> modprobe nvidia-uvm

> ./platform
Failed to get platforms: -1001

> sudo ./platform
NVIDIA CUDA - OpenCL 1.1 CUDA 6.5.51 - NVIDIA Corporation - FULL_PROFILE

> ./platform
NVIDIA CUDA - OpenCL 1.1 CUDA 6.5.51 - NVIDIA Corporation - FULL_PROFILE

Um die Grafikkarte tatsächlich zu verwenden war dann allerdings noch ein Neustart notwendig.

openSUSE 13.1 mit UEFI und Vollverschlüsselung auf openSUSE Leap 42.1 migrieren

2016-01-03T22:38:05+01:00

Da der offizielle Support für openSUSE 13.1 am 5.1.2015 endet war es höchste Zeit meine Workstation mal auf openSUSE Leap 42.1 zu migrieren. Solche Migrationen mache ich mit SUSE schon seit es noch einstellige Versionsnummern hatte. Diesmal war die Migration allerdings ungewohnt holprig.

Meine Workstation nutzt ein vermutlich nicht ganz gewöhnliches Set-Up. OpenSUSE ist parallel zu Windows 10 installiert, und beides wird per UEFI Secure Boot gestartet. Den UEFI-Boot habe ich dann auch gleich mal genutzt um mir mit Anlauf selbst in den Fuß zu schießen: OpenSUSE unterstützt es zwar schon seit Ewigkeiten eine Upgrade aus dem laufenden System durchzuführen, da es mir aber immer als der sauberere Ansatz vorkam – und sicher auch aus Nostalgie – mache ich solche Updates immer noch ganz altmodisch per DVD. Allerdings bietet mein ASUS-EFI in der Bootmedienauswahl das Blu-Ray-Laufwerk immer zwei mal an. Einmal ganz oben in der Liste als BIOS-Boot, und einmal ganz unten als echten UEFI-Boot. Natürlich habe ich – wollte ja nur schnell mal das Update starten – den oberen Eintrag genommen und mein EFI-System dann mal schön im BIOS-Modus aktualisiert. Leider fängt openSUSE diesen PEBKAC aktuell nicht ab und hat mir dann mal schön die Bootloaderkonfiguration kaputtgeschrieben. Zum Glück ist der Fehler – wenn man erst mal verstanden hat, was man falsch gemacht hat – trivial zu korrigieren. Einfach nochmal das Upgrade im UEFI-Modus starten, von Leap 42.1 auf Leap 42.1 aktualisieren (ja, das geht). Danach ist der Bootloader korrekt geschrieben.

Leider tritt einem beim Versuch die DVD mit openSUSE Leap 42.1 per UEFI zu booten Bug 950569 in den Weg. Der Bootcode auf der DVD ist nicht korrekt signiert, was auf meinem System zufolge hat, dass der Bildschirm einfach schwarz bleibt. Das Problem lässt sich lösen, indem man Secure Boot im BIOS temporär deaktiviert. Zum Glück installiert openSUSE Leap 42.1 bei der Installation bzw. dem Upgrade bereits die aktuellsten Version aller Pakete. So bleibt Nachzüglern wie mir nicht nur die Updateorgie nach der Installation erspart, sondern es landet auch korrekt signierter Code auf der Platte, so dass Secure Boot nach dem Update gleich wieder aktiviert werden kann.

Ein weiteres Problem bei openSUSE Leap 42.1 ist, dass es zumindest bei Upgrades nicht korrekt mit verschlüsselten Root-Partitionen umgehen kann. Beim Boot „vergisst“ das System nach der Passphrase zu fragen. Wechselt man durch die Konsolen findet zeigt sich folgende Fehlermeldung: Failed to start systemd-cryptsetup@luks<codierte ID>.service:. Ich habe die ID in der Fehlermeldung mal gekürzt ;). Wie in Bug 904987 lässt sich das Problem lösen, indem man dem Kernel explizit sagt, dass er die entsprechende Partition entschlüsseln soll, indem man ihm die ID des LUKS-Containers per Kernelparameter rd.luks.uuid mitgibt.

Die ID des LUKS-Containers lässt sich mit Cryptsetup herausfinden. Liegt die Root-Partition z.B. auf /dev/sda2, so lässt sich die ID wie folgt herausfinden.

> cryptsetup luksUUID /dev/sda2
07246af2-915a-bd54-6a5s-6a5c35d15f45

Der Bootparameter muss dann in /etc/sysconfig/bootloader zum Wert DEFAULT_APPEND hinzugefügt werden. Dieser sollte dann z.B. wie folgt aussehen:

DEFAULT_APPEND="splash=silent quiet showopts rd.luks.uuid=07246af2-915a-bd54-6a5s-6a5c35d15f45"

Anschließend einmal den Bootloader neu schreiben lassen und das System fragt wieder nach dem Passwort. Idealerweise wird dieser Workaround schon vor dem Update implementiert. Nicht, weil dann der Bootloader sowieso neu geschrieben wird, sondern weil man sich dann das Herumgewurschtel mit einem Recovery-System spart.

Projekte von Gitorious zu Gitlab.com umgezogen

2015-04-24T22:06:08+02:00

Da Gitorious nach der Akquise durch Gitlab Ende Mai die Pforten schließen wird, beziehungsweise nur noch Archivcharakter haben wird, habe ich alle meine dortigen Projekte zu Gitlab umgezogen. Einhard, FindOpenCL, CLU, Quick Cluster Overview und Klepsydra sind dort nun unter meinem Account zu finden.

Quick Cluster Overview jetzt auf Gitlab.com gehostet

2015-04-24T21:57:27+02:00

Aufgrund der baldigen Abschaltung von gitorious.org ist das Repository von Quick Cluster Overview umgezogen. Es befindet sich nur auf Gitlab.com. Die neue URL lautet https://gitlab.com/Marix/QuickClusterOverview.

Kalibrieren von Joysticks in Windows 8

2014-11-25T23:25:48+01:00

Öffnet man in Windows 8 die Gamecontrollereinstellungen, z.B. durch Rechtsklick auf den zu Kalibrierenden Joystick im Dialog „Geräte und Drucker“, so fehlt der seit vielen Windowsversionen gewohnte Dialog zum Kalibrieren des Joysticks. In Microsofts Foren findet sich zum Glück eine Lösung für das Problem. Hält man im Dialog „Gamecontroller“ die Umschalt- und die Steuerungstaste gedrückt während man den Knopf „Eigenschaften“ drückt, so kommt der alte Eigenschaftsdialog hoch, inklusive der Option den Joystick zu kalibrieren.

Ich habe die Lösung nur mit einem Logitech Extreme 3D getestet. Ich kann mir aber nicht vorstellen, dass Windows sich bei anderen Joysticks hier anders verhält.

„Indie Game: The Movie“ auf openSUSE

2014-11-23T21:56:37+01:00

Startet man unter openSUSE, bzw. mit einem KDE-Desktop, von Steam aus „Indie Game: The Movie“, so kommt zwar ein archaisch wirkendes Xterm hoch, welches behauptet einem Adobe AIR zu installieren, allerdings passiert danach nichts mehr. Hat man Adobe AIR bereits installiert startet „Indie Game: The Movie“ ohne Probleme.

Hier kommen gleich mehrere Probleme zusammen:

Adobe AIR unterstützt schon seit mehreren Jahren Linux offiziell nicht mehr. Es muss also eine alte Version installiert werden, welche dann natürlich nicht die modernsten Annahmen macht was die Linuxumgebung angeht
Die Standardinstallation von Adobe AIR benötigt root-Rechte. Steam führt man allerdings normalerweise nicht als root aus, und das Skript welches die Installation durchführt fordert auch offensichtlich keine an.
Adobe AIR will bei der Installation auf KWallet, oder alternativ den Gnome Keyring zugreifen. Auf openSUSE 13.1 mit KDE findet es aber, obwohl natürlich KWallet installiert ist, keinen von beiden.

Woran genau die Installation scheitert habe ich nicht herausgefunden.

Zur manuellen Installation ist zunächst Adobe AIR von der Archivseite http://helpx.adobe.com/air/kb/archived-air-sdk-version.html herunterzuladen. Es empfiehlt sich die letzte Version mit Linuxunterstützung, also die 2.6 Runtime, zun nutzen. Diese muss mit root-Rechten und Zugriff auf X ausgeführt werden. Hierbei ergibt sich dann das Problem, dass KWallet nicht gefunden wird. Adobe AIR ist eine 32-bit Anwendung, auf den inzwischen üblichen 64-bit-Systemen prüft es offensichtlich im falschen Verzeichnis auf die Existenz der Bibliothek. Legt man, an sich redundant, das korrekte Verzeichnis in die Umgebungsvariable LD_LIBRARY_PATH, so läuft der Installer erfolgreich durch. Nach dem Download ist also folgendes in einer Konsole auszuführen.

chmod +x AdobeAIRInstaller.bin
su # sudo gibt per default keinen Zugriff auf den laufenden X-Server
LD_LIBRARY_PATH=/usr/lib64 ./AdobeAIRInstaller.bin

Android-Apps ohne Benachrichtigungen

2014-10-28T11:25:44+01:00

Auf einem Samsung Galaxy S3 Mini musste ich feststellen, dass TextSecure keine Benachrichtigungen anzeigte. Nachrichten wurden zwar zugestellt, aber nur durch Öffnen der App lies sich feststellen, ob neue Nachrichten vorlagen. In der App selbst war allerdings alles korrekt eingestellt. Schuld an den fehlenden Benachrichtigungen war vielmehr Android, welches es auf Systemebene noch einmal erlaubt Benachrichtigungen für einzelne Apps ein- und auszuschalten.

Um die entsprechende Einstellung vorzunehmen muss man in den Systemeinstellungen von Android den Abschnitt „Apps“, der bei Samsung „Anwendungsveraltung“ heißt wählen. Wählt man dort eine App aus, so gibt es dort ein Feld „Benachrichtigungen anzeigen“. Ist dort kein Haken gesetzt, so filtert Android alle Benachrichtigungen der App aus.

Einhard 0.4

2014-10-27T18:19:35+01:00

Ab sofort ist Version 0.4 von Einhard verfügbar.

Diese Version bietet folgende neuen Fähigkeiten:

Mehrzeilige Lognachrichten werden jetzt besser dargestellt.
Das Zeichen zum Separieren der Bestandteile des Zeitstempels kann frei gewählt werden. Normalerweise wird weiter der Doppelpunkt verwendet.
Ein Großteil des Codes wurde von den Headern in eine Bibliothek verschoben um Code der Einhard verwendet schneller kompilieren zu lassen.
Einhard kann jetzt aus mehreren Threads heraus verwendet werden.
Einhard kann auch mit Clang genutzt und übersetzt werden.

Der Code findet sich auf Gitlab unter dem Tag v0.4: https://gitlab.com/Marix/Einhard/tree/v0.4:. Von dort lässt er sich auch als Tarball herunterladen.

Civilization 5, V-Sync und KDE

2014-09-11T00:31:21+02:00

In Civilization 5 gibt es zwar eine V-Sync-Option, allerdings ist im Spiel dann bei mir doch das hässliche Tearing zu sehen gewesen. Die Lösung: Die Arbeitsflächeneffekte für Vollbildfenster deaktivieren. Diese, bzw. deren V-Sync-Einstellung scheint mit der von Civilization 5 zu kollidieren. Die Einstellung findet sich in den Systemeinstellungen unter „Arbeitsflächen-Effekte“->„Erweitert“.

Threema

2014-01-04T18:06:01+01:00

Nach dem NSA-Skandal scheint sich jetzt mit Threema endlich mal ein Messanger fürs Handy zu implementieren, welcher aus Datenschutzsicht nicht eine komplette Katastrophe ist. Anders als WhatsApp, Google Hangouts, Facebook und SMS läuft hier die Kommunikation nicht unverschlüsselt durchs Netz, sondern wird für den Empfänger verschlüsselt. Da Threema auch nur dann ein beruhigendes Grün für den Kontakt anzeigt, wenn der Schlüssel des Kommunikationspartners einmal per QR-Code-Scan verifiziert wurde, trägt die App auch anders als solche welche die Schlüssel zentral verteilen nicht in trügerischer Sicherheit.

Dennoch hat natürlich auch Threema Probleme. Da der Quellcode nicht offen liegt ist es unmöglich sicherzustellen, dass der geheime Schlüssel nicht doch irgendwie nach außen geleaked wird. Wichtiger ist aber, dass die Verkehrsdaten, oft auch Metadaten genannt, weiterhin an einer zentralen Stelle anfallen. Es reicht also immer noch eine Stelle anzugreifen um an diese Daten zu kommen.

Als Alternative zu Whatsapp, Google Hangouts und Konsorten ist Threema definitiv ein Schritt in die richtige Richtung. Langfristig benötigt es aber eine ähnlich komfortable Lösung welche auf offenen Standards beruht, so dass eine komplett vertrauenswürdige Kette aufgebaut werden kann. Eine freie Implementierung würde es erlauben nach Hintertüren zu suchen. Insbesondere muss aber die Serverstruktur dezentralisiert werden, so dass nicht alle Verkehrsdaten an einem Punkt anfallen. Betreibt man einen eigenen Server, so müssen Nachrichten zu anderen Nutzen desselben die eigene Infrastruktur nie verlassen, und ein aufgemachter Server würde nur Verkehrsdaten von Nachrichten welche über diesen liefen betreffen, aber nicht die dritter. Im Prinzip gibt es Jabber und PGP ja auch schon die zugrundeliegende Infrastruktur für eine solche Lösung. Allerdings muss hier noch am Bedienkomfort gearbeitet werden. So bin ich beispielsweise mit den bisherigen Möglichkeiten Jabber-Nachrichten aufs Handy zu schieben unzufrieden, und auch die einfache Validierung des Kommunkationsschlüssels via QR-Code habe ich in einem solchen Setup bisher noch nicht gesehen.

Ich bin natürlich auch per Threema zu erreichen. Fragt mich einfach nach meiner ID. Meine alte ID YYYZBANM solltet ihr bitte nicht mehr verwenden. Nach einem kuriosen Androidfehler habe ich diese verloren und hatte leider auch kein Backup. Selbst mit letzterem würde ich ihr allerdings auch nicht mehr trauen.

Chiliproject-Tickets aus Commits heraus schließen

2013-09-25T15:31:22+02:00

In ChiliProject – und natürlich auch in Redmine – können Tickets aus Commits heraus referenziert und Geschlossen werden. Da ich immer wieder neu heraussuchen muss, wie das geht, hier die Kurzanleitung:

refs #123

Referenziert das Ticket 123. Alternativ ist auch references oder IssueID möglich. Um ein Ticket zu schließen ist folgendes in den Commit einzufügen:

fixes #123

Alternativ kann closes verwendet werden.

Referenziert oder schließt man Ticket aus einem Commit, so wird der Commit automatisch auch vom Ticket aus verlinkt. Dies erlaubt es leicht nachzuvollziehen, wie ein Problem gelöst wurde.

Das ganze lässt sich auch anpassen. Die Einstellungen finden sich unter Administration->Konfiguration->Projektarchive.

Die Trailer der letzten Wochen: Meine Highlights

2013-07-05T16:46:13+02:00

In den letzten Wochen gab es einige coole Trailer zu neuen Spielen. Hier sind meine persönlichen Highlights.

Der Trailer der neuesten Erweiterung zu Civilization V klotzt statt zu klettern. „Brave new World“ werde ich definitiv spielen müssen. Zumindest sobald ich mal zur letzten Erweiterung „Gods and Kings“ gekommen bin.

Nadeo hat gleich zum Doppelschlag ausgeholt. Mit „TrackMania 2: Stadium“ holen sie Nations auf den aktuellen technischen Stand. Aber auch wenn ich sicherlich wieder genug Zeit im Stadion verlieren werde, so fasziniert mich „TrackMania 2: Valley“ doch deutlich mehr. Lob gebührt Nadeo auch für die Musik, die sie für beide Trailer sehr gut ausgesucht haben.

Außerdem gibt es neues vom Hexer. „The Witcher 3“ verspricht ein wahrhaft episches Abenteuer zu werden.

Der Trailer zu „Borderlands 2: Tiny Tina“ verspricht die klassischen Action-RPGs jetzt mal dem für Borderlands typischen Humor auszusetzen.

Der Trailer zum neuen Need for Speed hat mich auch wieder gepackt. Allerdings scheint „Rivals“ mal wieder ein Aufguß zu werden. Aber solange es mit Supersportwagen ist...

Zu guter Letzt gibt es mal wieder eine Erweiterung zu Eve Online. Der Trailer ist mal wieder episch. Ich werde um das Spiel trotzdem vorsichtshalber mal weiter einen großen Bogen machen.

Aktive Reservierungen in SLURM verlängern

2013-06-25T11:09:17+02:00

SLURM quittiert den Versuch eine bereits in Nutzung befindliche Reservierung zu verlängern normalerweise mit der Fehlermeldung, die Knoten seien bereits in Benutzung. Dies ist in diesem Fall natürlich richtig, allerdings ist dies kein echter Konflikt, so die Jobs bereits die Reservierung nutzen. In diesem Fall macht es Sinn SLURM anzuweisen den Fehler zu ignorieren.

Als kleines Beispiel soll folgende Reservierung verlängert werden:

bach@login:~> scontrol show reservation bach_2
ReservationName=bach_2 StartTime=2013-06-10T00:00:00 EndTime=2013-07-01T23:59:59 Duration=21-23:59:59

Der naive Versuch die Reservierung zu verlängern scheitert:

bach@login:~> sudo scontrol update reservationname=bach_2 endtime=2013-07-29
Error updating the reservation: Requested nodes are busy
slurm_update error: Requested nodes are busy

Weist man die Reservierung an etwaige Nutzungkonflikte zu ignorieren, so kann sie problemlos verlängert werden:

sudo scontrol update reservationname=bach_2 endtime=2013-07-29 flags=IGNORE_JOBS
Reservation updated.

Das Flag IGNORE_JOBS bleibt für die Reservierung aktiv, es muss für weitere Änderungen nicht erneut angegeben werden. Beim Hinzufügen von Knoten kann es dadurch allerdings passieren, dass Knoten welche bereits durch lange Jobs blockiert sind in die Reservierung aufgenommen werden.

Glossareinträge in TikZ-UML-Diagrammen verwenden

2013-05-09T10:54:29+02:00

TikZ-UML und Glossaries sind äußerst nützliche Pakete für LaTeX. Leider scheiterte mein erster Versuch einen Eintrag meines Glossars als Klassenname zu verwenden mit folgender Fehlermeldung:

! Missing \endcsname inserted.

                   \let
l.95                            \umlemptyclass[y=0, x=0]{\glstext{prng}}

Die Lösung ist auf den Link zum Glossar zu verzichten. Da TikZ-UML den Klassennamen als zur Identifikation nutzt darf er keine Links erhalten. Nutzt man beispielsweise \glsentrytext anstelle von \glstext wird der Glossareintrag zum Klassennamen. Nur draufklicken um in das Glossar zu kommen kann man leider nicht.

Makros als OpenCL-Kommandozeilenparameter

2013-02-04T17:16:00+01:00

Die OpenCL-Specifikation enthält bei der Übergabe von Makros als Kommandozeilenparameter eine Falle für alle welche die Syntax des gcc gewohnt sind. Während bei GCC -DMACRO[=WERT] angesagt ist, ist der Parameter in OpenCL mit einem Leerzeichen spezifiziert, also -D MACRO[=WERT].

Die AMD und NVIDIA-Platformen kommen wunderbar mit der vom GCC gewohnten, allerdings nicht standardkonformen, Syntax zurecht. Apple ist hier wählerischer, und so bekommt man bei Verwendung der von GCC gewohnten Variante mitunter den Fehlercode CL_INVALID_BUILD_OPTIONS. In PyOpenCL wird daraus dann folgende Fehlermeldung: pyopencl.RuntimeError: clBuildProgram failed: invalid build options - Leider geht aus der Fehlermeldung nicht so exakt hervor, was den Compiler genau stört. Tatsächlich ist dies auch gar nicht so einfach zu beantworten, denn der Compiler scheint tatsächlich nur ein Problem zu haben, wenn die Kommandozeile nach einen -DFOO endet. Ein -DFOO -DBLA verarbeitet er völlig erwartungsgemäß.

Natürlich liegt der Fehler hier aber beim Anwender, eine standardkonforme Spezifikation der Macros funktioniert immer. Ungeschickt ist natürlich das etwas inkonsistente Handling der Parameter, welches es mitunter schwierig macht den Fehler zu finden.

Steam einfach auf openSUSE installieren

2013-02-02T15:56:08+01:00

Es ist jetzt wieder möglich Steam per 1-Klick-Installation auf openSUSE zu installieren. Die passenden Links findet man über die SUSE Software Suche.

Steam war bereits kurz nach Start der offenen Beta im OpenSUSE Build Service verfügbar, dort aber im Januar aufgrund rechtlicher Problem wieder herausgeflogen. Im Endeffekt lief es darauf hinaus, dass es von Valve keine offizielle Genehmigung für das openSUSE-Projekt gab Steam zu verbreiten. Jetzt hat Steam seine Lizens so geändert, dass jeder Steam-Pakete weiterverbreiten darf, und prompt ist Steam auch wieder für openSUSE verfügbar. Es ist sind zwar mit SUSE wohl noch nicht alle Formalitäten für die Verbreitung von kommerzieller Software über die SUSE-Infrastruktur geklärt, aber da jetzt klar ist, dass Valve die Verbreitung in dieser Form erlaubt gehe ich davon aus, dass Steam weiterhin offiziell für SUSE verfügbar sein wird. Wer weiß, vielleicht ist es dann ja bei openSUSE 12.3 von Anfang an ganz offiziell dabei.

Cyberpunk 2077

2013-02-01T11:20:16+01:00

Diesen Januar gab es ja einige imposante Rendertrailer zu sehen. Am meisten beeindruckt hat mich allerdings der Trailer für Cyberpunk 2077. Nicht nur finde ich ihn optisch beeindruckend, auch freue ich mich auf ein erwachsenes Rollenspiel abseits des Fantasy-Settings. Ich konnte mich schon immer mehr für Science-Fiction begeistern. Die Bioshock-Spiele waren zwar sehr cool, aber nach den Witcher-Spielen erwarte ich von CD Project, dass Cyberpunk 2077 noch eine ganze Ecke erwachsener und düsterer rüberkommt.

Spannend ist natürlich auch, was CD Project am 5. Februar verkünden wird. Witcher 3? Falls ja wäre es für mich höchste Zeit mal den ersten Teil durchzuspielen.

MIDI-Eingabe in openSUSE 12.1

2012-03-10T14:13:15+01:00

Da kommt man nach langer Zeit endlich mal wieder dazu seine Hercules DJ Console MK2 anzuschließen, und dann findet Mixxx kein MIDI-Gerät. Die Lösung ist einfach. In aktuellen Versionen von openSUSE sind die Geräte unter /dev/snd nur noch für den Nutzer root und die Gruppe audio verfügbar. Die Lösung: Den eigenen Nutzer der Gruppe audio hinzufügen, neu anmelden und schon geht es wieder. :)

OpenCL-Tracing mit Tau

2012-01-24T18:24:32+01:00

Um OpenCL-Anwendungen auf der NVIDIA Platform zu tracen gibt es den NVIDIA Visual Profiler. Um sie auf der AMD Platform zu tracen gibt es den AMD APP Profiler. Problem gelöst – oder? Leider gibt es ein paar spezielle Situationen in denen das nicht reicht. Der AMD APP Debugger kann zwar auf der Kommandozeile tracen und funktioniert unter Linux, seine Visualisierung ist allerdings als Plugin für Visual Studio implementiert. Die Express-Versionen von Visual Studio unterstützen leider keine Plugins, und Visual Studio kaufen nur um ein Plugin auszuführen? Der inzwischen kostenlose gDEBugger kann zwar unter Linux visualisieren, kann aber nicht auf der Kommandozeile messen. Tau, eigentlich zum Profilen und Tracen von großen Clusteranwendungen gedacht, löst das Problem. Aufgrund seines eigentlichen Anwendungszieles ist es zwar etwas komplexer zu verwenden, aber weniger Aufwand als die Visualisierung der Tracingdaten komplett selbst zu schreiben, wie es mein erster Versuch war.

Tau installieren

Tau ist für eine Anwendung ihrer Größe recht leicht zu installieren. Zunächst sind die Quellen von http://www.cs.uoregon.edu/Research/tau/downloads.php herunterzuladen. Trotz des Formulars ist hierzu keine Anmeldung notwendig. Anschließend lässt sich Tau mit dem üblichen Zweisatz installieren. Wenn es nur um OpenCL geht ist hierbei keine große Konfiguration notwendig.

./configure -opencl=
make install

Tau installiert sich übrigens in ein nach der Architektur benanntes Unterverzeichnis des Build-Verzeichnisses…. Soll es woanders lassen müsste man configure den passenden Pfad via -prefix mitgeben. Man beachte, das es hier nur einen Minus gibt….

Anschließend müssen noch PATH und LD_LIBRARY_PATH angepasst werden, also z.B.:

export PATH=$HOME/tau-2.21.1/x86_64/bin/:$PATH
export LD_LIBRARY_PATH=$HOME/tau-2.21.1/x86_64/lib/:$LD_LIBRARY_PATH

Trace erstellen

Um ein Trace zu erstellen verwendet man tau_exec wie folgt:

TAU_TRACE=1 tau_exec -T PROFILE,SERIAL -opencl

TAU_TRACE=1 ist notwendig damit Tau auch Tracing und nicht nur Profiling betreibt. SERIAL ist notwendig damit tau_exec die Anwendung direkt und nicht via mpirun startet.

Anschließend existieren mehrere tautrace.0.0.?.trc-Dateien. Da Jumpshot mit slog2-Dateien arbeitet müssen diese noch konvertiert werden:

tau_treemerge.pl
tau2slog2 tau.trc tau.edf -o .slog2

Trace analysieren

Die slog2-Datei kann anschließend mit Jumpshot analysiert werden. Jumpshot ist in Tau enthalten, muss also nicht extra installiert werden. Die slog2-Datei enthält alle Trace-Informationen, kann also problemlos zur analyse auf andere Rechner verschoben werden.

Für eine sinnvolle Analyse in Jumpshot empfiehlt es sich die Node aufzuklappen um die einzelnen OpenCL devices und den Host-Thread als einzelne Lanes zu sehen. Leider ist Jumpshot kein besonders nutzerfreundliches Programm, sondern versucht sämtliche Java-Vorurteile zu erfüllen. Deshalb sollte man nach jeder Einstellungsändern – ob ausklappen der Lanes oder An- bzw. Abwahl von einzelnen Ereignissen – den Refresh-Knopf nutzen.

Philosophisches von zypper

2012-01-15T11:39:26+01:00

Beim Versuch den Simfy Desktop Player zu installieren überraschte zypper gerade mit folgender Meldung:

2 neue Pakete zu installieren.
Gesamtgröße des Downloads: 22,4 MiB. Nach der Operation werden zusätzlich 47,5 MiB belegt.
Fortfahren? [j/n/?] (j): j
Ungültige Antwort 'j'. [j/n/?] (j): j

Bleibt die Frage, was er damit sagen wollte:

Diese Software willst du eigentlich gar nicht verwenden?
Heißt ja, wirklich immer ja?
…

ACLs – Dann klappt auch das Inotify bei Mediatomb

2012-01-07T19:54:02+01:00

Die traditionellen Unix-Dateiberechtigungen stoßen öfter mal an ihre Grenzen. Zum Beispiel bei meinem Versuch Mediatomb auf meinem Homeserver Inotify verwenden zu lassen. Die Lösung für diese Limitierung sind ACLs. Hier zeige ich, wie man diese für Mediatomb sinnvoll setzen kann.

Den Inotify-Modus möchte ich in Mediatomb aus zwei Gründen verwenden. Ersten muss man dann nicht warten bis der nächste Scan nach neuen Dateien abgeschlossen ist, denn meistens möchte man die Datei ja sofort anschauen. Zweitens muss Mediatomb dann nicht immer wieder den Verzeichnisbaum ablaufen wenn sich gar nichts geändert hat. Im Idealfall können die Festplatten also deutlich länger schlafen.

Das Problem mit dem Inotify-Modus besteht darin, dass Mediatomb hierfür Schreibberechtigung auf den Verzeichnissen benötigt, welche es auf Änderungen überwachen soll. Klassisch kann man aber ja nur die drei Berechtigungen – Eigentümer, Gruppe und den Rest – setzen. Prinzipiell kann man natürlich immer wenn man ein Verzeichnis anlegt anschließend Eigentümer oder Gruppe passend umsetzen, dann ist Mediatomb aber schon gescheitert. Eine bessere Lösung sind ACLs, mit denen man beliebig viele Berechtigungen vergeben kann. Außerdem ist es mit ACLs auch einfach Default-Werte zu setzen welche anschließend für alle im Verzeichnis angelegten Dateien und Unterverzeichnisse übernommen werden.

Meine ACL für das oberste Verzeichnis sieht aus wie folgt:

user::rwx
user:mediatomb:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:mediatomb:rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Der Nutzer und die Gruppe können im Verzeichnis lesen und schreiben, dadurch kann zum Beispiel meine Frau auch die Fotos umsortieren. Alle anderen können das Verzeichnis lesen. Dies könnte man auch restriktiver handhaben, aber da Mediatomb den Inhalt dieser Verzeichnisse aller Welt verfügbar macht hat eine weitere Einschränkung wenig Sinn. Der Benutzer mediatomb bekommt explizit Lese- und Schreibberechtigung für dieses Verzeichnis. Dadurch kann Mediatomb dann Inotify verwenden um das Verzeichnis auf Veränderungen zu überwachen.

Besonders wichtig sind die mit default: beginnenden Einträge. Diese legen wiederum die ACL fest welche in diesem Verzeichnis neu angelegte Dateien und Unterverzeichnisse bekommen. Bei Unterverzeichnissen werden diese außerdem wieder als Default übernommen. Das hier ein x in den Berechtigungen steht macht übrigens nicht jeden Datei ausführbar. Diese Berechtigungen werden immer mit dem vom anlegenden Programm angegebenen Berechtigungen kombiniert. So sind Verzeichnissen dann automatisch ausführbar (sonst könnte man ihre Inhalte nicht sehen), und normale Dateien nicht – es sei denn sie werden explizit als ausführbar angelegt.

Um diese ACL auf einen bestehenden Dateibaum anzuwenden packt man sie am besten in eine Datei, in meinem Fall habe ich sie einfach acl genannt, und wendet sie mit setfacl rekursiv an.

setfacl -R --set-file acl /OberstesVerzeichnis/

Hierbei gibt es noch einen kleinen Trick. Die Berechtigung X, anstelle von x macht eine Datei nur ausführbar wenn sie Verzeichnis oder bereits ausführbar ist. So verhindert man mit folgender ACL, dass alle Dateien ausführbar werden, stellt aber sicher, dass Verzeichnisse angezeigt werden können.

user::rwX
group::rwX
other::r-X
mask::rwX
user:mediatomb:rwX
default:user::rwx
default:group::rwx
default:other::r-x
default:mask::rwx
default:user:mediatomb:rwx

Bessere D3-Startlinks für http://d3.descent.cx/

2011-09-24T20:13:16+02:00

Das hier vorgestellte Skript baut die Seite http://d3.descent.cx/ so um, dass die Links zu den Spielen durch Links mit dem Protokoll d3 ersetzt werden. Hat man z.B. Vortex installiert, so kann man durch den Klick auf den Link direkt Descent 3 starten, welches dann mit dem korrekten Server verbindet. Getestet habe ich das Skript mit Opera sowie mit Firefox, wobei letzterer die Greasemonkey-Erweiterung benötigt.

In Opera müss man zunächst sicherstellen, dass User-JavaScript aktiviert ist. Hierzu geht man im Menü auf Extras->Einstellungen->Erweitert->Inhalte->JavaScript-Optionen. Hier muss ein User-JavaScript-Verzeichnis eingetragen sein. In dieses Verzeichnis wird die Datei d3.descent.cx.user.js abgespeichert, und beim nächsten Aufruf von http://d3.descent.cx/ werden die Links schon ersetzt.

In Firefox muss zunächst die Erweiterung Greasemonkey installiert werden. Nach dem nötigen Neustart ist die Datei d3.descent.cx.user.js zu öffnen. Man kann die Datei direkt mit dem Firefox auswählen, ein herunterladen ist im Prinzip nicht notwendig, wenn auch möglich. Nachdem der Installationsdialog bestätigt wurde, werden anschließend bei jedem Aufruf von http://d3.descent.cx/ die Links ersetzt.

Hier nochmal der Link zum herunterladen bzw. zur Installation: d3.descent.cx.user.js

OpenCL: Buffer vs. mehrere Devices

2011-09-19T18:24:56+02:00

Da OpenCL sowohl auf CPUs als auch auf GPUs funktioniert kommt man recht schnell in die Situation in der mehr als ein OpenCL-Device verwendet werden will. Doch was passiert in diesem Fall mit dem kostbaren, weil wenigem, Grafikkartenspeicher? Die Funktion clCreateBuffer bietet ja leider keine Möglichkeit anzugeben auf welchem Device der Speicher allokiert werden soll.

Die einfachste Variante mit mehreren OpenCL-Devices zu arbeiten ist alle in einem Context zu verwalten. In diesem Fall wird ein Buffer aber immer für alle Devices angelegt. Wird ein Speicher also nur auf einem Device benötigt muss man befürchten, dass dieser auch auf anderen Devices kostbaren Speicher verbraucht.

Glücklicherweise sollte dies sowohl auf AMD, als auch auf NVIDIA-Hardware kein Problem darstellen. Beide teilen einem Buffer immer erst dann Speicher auf der Grafikkarte zu wenn dieser dort das erste mal verwendet wird. AMD dokumentiert dies explizit in seinem AMD APP Programming Guide. NVIDIA geht in seiner GPU Computing Documentation zwar nicht explizit auf diese Problematik ein, Beiträge in den Foren von NVIDIA und Khronos dokumentieren aber dieses Verhalten. Bedenken sollte man allerdings, dass man, um von diesem Verhalten zu profitieren, CL_MEM_COPY_HOST_PTR nicht verwenden darf.

AMDs Programming Guide empfiehlt explizit einen gemeinsamen Context für alle Devices zu verwenden, da dies programmiertechnisch die einfacherere Lösung ist. Es wird aber auch eingestanden, dass ein Context pro Device deutlich flexibler ist. Dies ist beispielsweise die einzige Möglichkeit CPUs mit NVIDIA-Grafikkarten zu kombinieren.

Die Flexibilität mehrere Contexte hat allerdings ihren Preis. So ist es nicht möglich die Ausführung zwischen mehreren Contexten über Events zu synchronisieren. Die OpenCL-Spezifikation weist explizit darauf hin, dass ein Befehl in einer Workqueue immer nur auf Events welche zum gleichen Context gehören warten kann. Prinzipiel kann diese Beschränkung mithilfe von Event Callbacks und User Events umgangen werden, dies ist aber auch mit einem höheren Aufwand verbunden.

Außerdem sollte man auch immer bedenken, dass Buffer welche ausschließlich auf der CPU verwendet werden mit CL_MEM_ALLOC_HOST_PTR oder CL_MEM_USE_HOST_PTR initialisiert werden sollten um unnötiges kopieren der Daten zu vermeiden.

Liebe Berliner, geht Wählen!

2011-09-18T11:33:12+02:00

Heute sind Wahlen in Berlin. Und da nichts besser wird wenn man seine Stimmer nicht erhebt, möchte ich hier noch einmal alle zum Gang zur Wahlurne aufrufen. Ihr müsst ja gar nicht gut finden was SDP/CDU/FDP und Grüne machen. Im Zweifelsfall gibt es immer noch genug „Einthemenparteien“ welche einen Standpunkt vertreten den ihr für wichtig haltet. Die mögen zwar mit eurer Stimme nicht ins Parlament einziehen, aber ihr gebt damit dem vertretenen Thema Gewicht, denn jede Partei, für die es nicht zur Mehrheit gereicht hat, hätte diese Stimme natürlich gerne gehabt. Außerdem gibt es dieses Jahr in Berlin, wie unter anderem bei Fefe berichtet, auch noch eine recht kuriose Möglichkeit das Parlament zu verkleinern und damit Steuergelder zu sparen. Also, auch wenn Blumentop eigentlich zur Bundestagswahl 2009 sang, gültig ist immer noch: „Beweg dein Arsch!“;

Spaß mit gcc und geschützten Leerzeichen

2011-09-14T21:16:03+02:00

Wenn ich von meinem Mac aus in einem Vim auf einem anderen Rechner programmiere beschwert sich gcc öfter mal über folgendes und weigert sich die Datei zu kompilieren:

some_source.cpp:519:2: error: stray ‘\302’ in program
some_source.cpp:519:2: error: stray ‘\240’ in program

Nachdem ich mir lange Zeit immer damit behalf die Zeile zu löschen und neu zu schrieben, war das auf die Dauer doch etwas unbefriedigend. Bei Stackoverflow fand ich dann den Hinweis in die richtige Richtung. Das Problem ergibt sich durch versehentlich eingegebene geschützte Leerzeichen.

Mit diesem Wissen ist es möglich Vim zu sagen, dass er diese im Code markieren soll, so dass man sie gezielt löschen kann.

set listchars=nbsp:_
set list

Der listchars-Befehl legt fest wodurch welches Zeichen ersetzt werden soll, der list-Befehl aktiviert die Ersetzung. Ich lasse mir die geschützten Leerzeichen durch einen Unterstrich anzeigen, prinzipiell ist hier fast jedes Zeichen möglich. Da die ersetzten Zeichen in einer anderen Farbe dargestellt werden kann man sie auch nicht mit regulären Unterstrichen verwechseln. Außerdem lasse ich mir prinzipiell auch Tabulatoren und überschüssige Leerzeichen am Zeilenende anzeigen, so dass diese Zeile in meiner .vimrc jetzt so aussieht:

set listchars=tab:»·,trail:·,nbsp:_

Wie man in node.js URLs auf Funktionen abbildet

2011-09-04T12:56:40+02:00

Das „Hallo, Welt!“ in node.js ist es einen kleinen Webserver zu bauen der eben diesen Text zurück gibt. Doch was, wenn man nicht nur eine Seite zurückgeben möchte? Eine kleine Funktion hilft abhängig von der eingegebenen URL verschiedenen JavaScript-Funktionen aufzurufen.

In der Doku zu node.js geht hervor, dass das Request-Objekt die URL im Attribut url enthält. Der einfachste Weg URLs auf Funktionen abzubilden ist ein Objekt zu erstellen welches einfach die Pfade als Attributsname und die dazugehörigen Funktionen als Attributswerte verwendet. Dann können wir einfach direkt am Objekt die URL aufrufen. Das abbildende Objekt könnte so aussehen:

var url_mapping = {
  '/': printIndex,
  '/index.html': printIndex
}

Die Funktion printIndex kann so aussehen:

// Ok, not really an index, but works.
var printIndex = function(req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello, World!\n');
}

Die Abbildung wird dann wie folgt implementiert:

mapped = url_mappings[req.url];
if (mapped) {
  mapped(req, res);
} else {
  console.log(req.url + ' has not been mapped');
  invalidURL(req, res);
}

Der Code nutzt aus, dass wir in JavaScript dynamisch auf Werte eines Objektes zugreifen können und undefined zurückbekommen wenn der Wert im Objekt nicht gesetzt ist. Theoretisch könnte es hier ein Problem geben da JavaScript Objekte immer ein paar eigene Attribute besitzen, wie z.B. die Funktion hasOwnProperty, aber da die URL immer mit einem Schrägstrich beginnt, kann man mit keinem dieser Werte kollidieren, es sei denn irgendeine JavaScript-Bibliothek beginnt irgendwann wahnsinnigerweise Objekte mit solchen Werten anzureichern.

Mit der einfachen Funktion können wir zwar schon URLs auf Funktionen abbilden, oft möchte man aber eine ganze Klasse von URLs auf eine Funktion abbilden. Mithilfe des URL-Moduls könnte man zwar die URL noch um den Query-Teil bereinigen, aber wenn man alle URLs die mit einem bestimmten String anfangen, oder gar die einem bestimmten regulären Ausdruck entsprechen, abgebildet werden sollen kommen wir mit dem bisherigen Ansatz nicht weiter.

Um auch diesen Fall abzuhandeln können wir einen Array nutzen der Objekte enthält die jeweils ein Muster auf eine Funktion abbildet:

var pattern_mapping = [
  { pattern: '/echo/', mapped: echo },
  { pattern: /^\/regexp/, mapped: printMatch }
];

Möchten wir die richtige Funktion für eine URL finden so müssen alle Muster im Array durchprobieren. Da JavaScripts typeof-Operator leider reguläre Ausdrücke nicht eindeutig identifiziert akzeptieren wir alles welches die für unseren Test benötigte Methode aufweist:

for (i = 0; !mapped && i < pattern_mappings.length; i = i + 1) {
  pattern = pattern_mappings[i].pattern;
  console.log('Testing pattern ' + i + ': ' + pattern + ' [' + typeof(pattern) + ']');
  if( typeof(pattern) === 'string' && req.url.slice(0, pattern.length) === pattern ) {
    mapped = pattern_mappings[i].mapped;
  } else if ( pattern.test && typeof(pattern.test) === 'function' && pattern.test(req.url) ) {
    // we can only assume it's a regexp, as typeof is not clear on it,
    // but if it has a test function...
    mapped = pattern_mappings[i].mapped;
  }
}

Das ganze kann man natürlich noch beliebig aufbohren. Eine naheliegende Verbesserung wäre der aufgerufenen Funktion noch als dritten Parameter das abgebildete Muster zu übergeben. Ohne weitere Verbesserungen sieht die komplette Funktion so aus:

function(req, res, url_mappings, pattern_mappings) {
  // Forward decleration of variables as recommended by Crockford
  var i;
  var mapped;

  console.log('Request url: ' + req.url);

  // check whether the url has a direct mapping
  mapped = url_mappings[req.url];
  if (mapped) {
    mapped(req, res);
  } else {
    // url did not match any of the direct mappingss
    // check whether it matches anny of the patterns
    for (i = 0; !mapped && i < pattern_mappings.length; i = i + 1) {
      pattern = pattern_mappings[i].pattern;
      console.log('Testing pattern ' + i + ': ' + pattern + ' [' + typeof(pattern) + ']');
      if( typeof(pattern) === 'string' && req.url.slice(0, pattern.length) === pattern ) {
        mapped = pattern_mappings[i].mapped;
      } else if ( pattern.test && typeof(pattern.test) === 'function' && pattern.test(req.url) ) {
        // we can only assume it's a regexp, as typeof is not clear on it,
        // but if it has a test function...
        mapped = pattern_mappings[i].mapped;
      }
    }
    if (mapped) {
      mapped(req, res);
    } else {
      console.log(req.url + ' has not been mapped');
      invalidURL(req, res);
    }
  }
}

Zum einfacheren rumspielen mit dem Code gibt es das Beispiel als Datei: path.js

Mediatomb vs. PS3 vs. Opera

2011-04-16T12:16:31+02:00

Seit ich meine PS3 von meinem Heimserver aus mit Videos, Musik und Bildern versorge hatte ich immer wieder das Problem, dass die PS3 scheinbar zufällig das dafür genutzte Mediatomb mal sah, und mal nicht sah. Inzwischen konnte ich das Problem auf eine Wechselwirkung mit Opera Unite zurückführen. Schaltet man diese Funktionalität auf allen Rechnern im LAN aus verschwindet das Problem.

Schnell hatte ich festgestellt, dass das Problem unabhängig vom von mir verwendeten Betriebssystem ist. Verwirrend war, dass andere Nutzer im gleichen Netz das Problem aber nicht hervorriefen. Das Problem musste also durch eine Anwendung hervorgerufen werden welche nur ich nutze, und zwar auf jedem Betriebssystem. Da diese Menge nur aus Quassel-IRC und Opera besteht, ersteres aber keinerlei UPnP-Funktionalität besitzt, war das Problem schnell eingegrenzt.

Sucht man nach UPnP und Opera findet man auch schnell heraus, dass dieses nur vom Opera Unite genutzt wird. Schaltet man dies ab, indem man auf der Seite opera:config in den User Prefs den Haken vor Enable Unite entfernt, verschwindet auch die Störung.

Da ich für Opera Unite sowieso keinerlei Nutzen sehe ist dies eine für mich funktionierende Lösung des Problems. Unbefriedigend ist allerdings, dass das Problem überhaupt existiert. Schließlich ist die Idee von UPnP ja gerade, dass die Dinge funktionieren ohne, dass man von Hand eingreift, und die PS3 sollte im Zweifelsfall halt mehrere Medienserver anzeigen.

Zwei Hinweise zum IPv6-Routing mit openSUSE

2011-04-02T11:09:57+02:00

Den Artikel Doppelmoppel – IPv6-Zugang fürs LAN nachrüsten in der aktuellen c't möchte ich nutzen um auf zwei Punkte hinzuweisen welche in den meisten Dokumentationen zum Thema leider fehlen, ohne die es unter openSUSE aber nicht funktioniert.

Das mit dem LAN verbundene Netzwerkinterface benötigt eine gültige IPv6-Adresse aus dem LAN-Subnetz. Diese muss von Hand vergeben werden, da die Zuweisung per radvd am lokalen Interface nicht funktioniert.

Diese Adresse kann man via ifconfig add <in radvd eingetragenes prefix>:<mac addresse>/64 vergeben. Ist die Link-lokale Addresse z.B. fe80::442b:39ff:f231:95cd/64 und das Prefix 2a01:498:4c8::/64 so wäre die Addresse 2a01:498:4c8:0:4a5b:39ff:feed:95cd/64.

Hat das lokale Interface keine gültige IPv6 im LAN-Subnetz werden die aus dem LAN kommenden Pakete vom Router verworfen.

Nutzt man die SuSEfirewall2 muss man diese so konfigurieren, dass sie Verbindungen vom LAN ins IPv6 zulässt. Per Default blockt die SuSEfirewall2 nämlich alle durchzuleitenden IPv6-Pakete.

Hierzu editiert man die Datei /etc/sysconfig/SuSEfirewall2 und ändert den Wert FW_FORWARD auf "<lokales IPv6-Netz>,2000::/3". 2000::/3 bezeichnet alle gültigen IPv6-Adressen. Im obigen Beispiel wäre der Eintrag dann FW_FORWARD="2a01:498:4c8::/64,2000::/3". Wichtig bei diesem Eintrag ist die Reihenfolge, denn Verbindungen sind immer vom ersten zum zweiten möglich. Wer die Einträge vertauscht erlaubt also dem ganzen Internet Zugriff aufs LAN, kommt aber nicht raus.

Zum Abschluss möchte ich noch auf ein allgemeines Problem bei IPv6 hinweisen. Ein Teil der eigenen IPv6-Adresse wird aus der MAC-Adresse des eigenen Rechners abgeleitet. Dadurch ist man natürlich dauerhaft im Netz identifizierbar. Um das dadurch entstehende Datenschutzproblem zu entschärfen gibt es die IPv6 Privacy Extension, deren Aktivierung ich jedem ans Herz legen möchte. Wie das geht beschreibt ein ausführlicher Artikel bei Heise-Netze für alle Betriebssysteme. Ob die Aktivierung der Privacy Extensions erfolgreich war kann man z.B. durch den Aufruf von sixxs.net prüfen, welches oben rechts die aufrufende IPv6-Adresse anzeigt.

USB-Stick als Schlüssel für die Festplattenverschlüsselung

2011-03-05T01:57:05+01:00

OpenSUSE bietet seit einigen Versionen die Möglichkeit bei der Installation die Festplatte komplett zu Verschlüsseln. In Anbetracht der großen Menge an Daten macht dies heutzutage nicht nur bei Laptops, sondern auch bei stationären Rechnern Sinn. Wird der Rechner aber als Server — ohne Tastatur und Monitor — betrieben stört hierbei allerdings die notwendige Passworteingabe beim Starten des Rechners. Glücklicherweise bietet LUKS aber die Möglichkeit diese auf einem USB-Stick zu speichern, womit auch bei solchen Maschinen ein komfortabler Start möglich ist.

Achtung: Diese für openSUSE 11.3 erstellte Anleitung funktioniert bis einschließlich openSUSE 13.1. Auf openSUSE 13.2 und openSUSE Leap 42.1 habe ich sie nicht getestet. Auf openSUSE Leap 42.2 funktioniert sie nicht mehr. Es gibt einen neuen Mechanismus, welchen ich, sobald ich ihn ausführlich getestet habe, verbloggen und hier verlinken werde.

Ist ein USB-Stick als Schlüssel sicher?

Sicherheit ist immer relativ zur Bedrohung zu sehen. Auch beim USB-Stick stellt sich also die Frage wovor er schützen soll. Beim stationär zuhause stehenden Rechner hat die Verschlüsselung vor allem eine Funktion, sie schützt die Daten wenn die betroffen Festplatten mal das eigene Haus verlassen. Hierbei gibt es im Prinzip nur zwei Fälle. Stellt sich eine Platte während der Garantiezeit als defekt heraus so erspart einem die Verschlüsselung das heutzutage sehr zeitaufwendige Löschen der Platte. Wird die Festplatte entwendet, so ist sie ohne den USB-Stick, der natürlich in diesem Fall nicht im Rechner gesteckt haben darf, auch nicht auszulesen.

Ein großer Vorteil des USB-Sticks besteht hier darin, dass er sehr lange Passwörter ermöglicht. Möchte man lange Passwörten auf klassischem Weg verwenden kommt man um ein Aufschreiben des Passworts oft auch nicht herum. Außerdem gewinnt man eine Möglichkeit die Herausgabe des Passworts zu verweigern, sollte man je dazu aufgefordert werden. Bei einem langen Passwort welches man nie getippt hat ist die Chance sich zu erinnern nicht existieren. Auch hier gilt natürlich, der USB-Stick darf dann nicht trivial dem Rechner zuzuordnen sein.

Die Anleitung

Backup

Wie bei allen Operationen an der Basis eines Systems ist auch hier das Backup zu beginn wichtig. In diesem Fall ist es wichtig den Kernel und die Initramdisk zu sichern, da es sonst, sollte man sich bei der Konfiguration der Entsperrung via USB-Stick vertun, schwer ist wieder in das verschlüsselte System zu booten.

Unter openSUSE ist es hierbei wichtig den Anfang des initrd und kernel-Namens zu ändern, da diese vom Befehl mkinitrd sonst dennoch aktualisiert werden.

cp /boot/initrd-2.6.34-12 /boot/safe-initrd-2.6.34-12
cp /boot/vmlinuz-2.6.34-12 /boot/safe-enable-vmlinuz-2.6.34-12

Außerdem sollte man sich der Einfachheit halber gleich einen passenden Eintrag im Grub anlegen, wozu man in der Datei /boot/grub/menu.lst die passenden Zeilen einfügt:

title SafetyNet -- openSUSE 11.3 - 2.6.34-12
    root (hd0,0)
    kernel /safe-vmlinuz-2.6.34-12 root=/dev/system/root resume=/dev/system/swap splash=silent quiet showopts vga=0x317
    initrd /safe-enable-initrd-2.6.34-12

Dadurch kann man anschließend jederzeit auch noch mit dem bei der Installation vergebenen Passwort das System starten.

Anlegen des Schlüssels

Als nächstes muss ein Schlüssel erzeugt werden. Um nicht zu viele zusätzliche Module in die Initramdisk packen zu müssen empfiehlt es sich einen Ext2-formatierten Stick zu verwenden. Dieser kann mit

mkfs.ext2 -L keystick /dev/sdb

erzeugt werden. keystick gibt hierbei das Label des erzeugten Dateisystems an, /dev/sdb muss an den tatsächlichen Gerätenamen des USB-Sticks angepasst werden. Sollte der Stick bereits mit ext2 formatiert sein sollte dennoch ein Label gesetzt werden.

tune2fs -L keystick /dev/sdb

Das Label kann natürlich frei gewählt werden. Es dient später zur Identifizierung des Sticks. Dies hat zwei Vorteile:

Der USB-Stick unabhängig von hinzugekommenen oder entfernten Datenträgern gefunden
Anders als bei der Identifizierung über die ID des Sticks kann man einen zweiten Stick mit gleichem Label als Backup verwenden. Ich recycle gerne nutzlose Werbegeschenke für diese Aufgabe. Sollte mal eines kaputt gehen spare ich mir das Zeitaufwendige zurückspielen des Backups der ganzen platte, da ich den Schlüssel ja noch von einem zweiten USB-Stick laden kann.

Anschließend sollte ein Passwort generieren und auf dem USB-Stick hinterlegen. Meine bevorzugte Methode ist diese:

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

Nun kann man den erzeugten Schlüssel der verschlüsselten Partition hinzufügen. Leider verhält sich LUKS leicht unterschiedlich was interaktiv eingegebene Schlüssel und Schlüsseldateien angeht. Deshalb müssen wir unseren Schlüssel "interaktiv" eingeben. Hierzu erzeugt man zunächst eine Datei welche eine Zeile mit dem bei der Installation gewählten Schlüssel und eine mit dem neuen enthält.

cat oldkey /media/keystick/keyfile > tmp

Damit kann man nun die passenden Tastatureingaben simulieren:

cryptsetup luksAddKey /dev/sda2 < tmp

Anschließend wird die temporäre Datei nicht mehr benötigt:

rm tmp

Um zu testen ob der Schlüssel korrekt hinzugefügt wurde kann man probehalber einen leeren Schlüssel hinzufügen. LUKS ist schlau genug diesen Schlüssel nicht wirklich aufzunehmen:

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

Erstellen der neuen Initramdisk

Damit der Kernel bevor das Root-Verzeichnis eingebunden ist auf den USB-Stick zugreifen kann muss man sicherstellen, dass die USB-Module in der Initrandisk ist. Hierzu sollte man in openSUSE sicherstellen, dass die Variable INITRD_MODULES in /etc/sysconfig/kernel folgende Werte enthält:

usb_storage scsi_mod

Um LUKS den Schlüssel zu übergeben benötigt man ein Skript welches ihn vom USB-Stick liest. Dies kann an einer beliebigen Stelle im Dateisystem liegen, es wird beim erstellen der Initramdisk in diese gepackt:

#!/bin/sh

STICK=/dev/disk/by-label/keystick
FSTYPE=ext2
slumber=150
modprobe usb-storage 1>&2
modprobe scsi_mod 1>&2
mkdir /keystick 1>2&
sleep 5 1>2&

while [ $slumber -gt 0 ] && [ ! -e "$STICK" ]; do
      sleep 1
      slumber=$(( $slumber - 1 ))
done
if ! mount -t $FSTYPE -r $STICK /keystick ; then
   $( echo 'FAILED!!!' ) 1>2&
   echo ''
   exit 1
fi

cat /keystick/keyfile

umount /keystick 1>2&

Damit LUKS weiß, dass es den Wert von einem Skript erhält muss die Datei /etc/crypttab angepasst werden:

cr_sda2         /dev/sda2       none    initrd,luks,keyscript=/root/keyscript.sh

Hierbei sind zwei Dinge zu beachten:

Ist keyscript gesetzt ist keine interaktive Eingabe mehr möglich. Deshalb sollte man die alte Initramdisk (welche die alte Konfiguration enthält) vorher sichern.
Der Wert initrd ist notwendig, da openSUSE bei der Generierung der Initramdisk sonst nicht merkt, dass es das Keyscript mit einpacken muss.

Zu guter letzt kann durch den Aufruf von mkinitrd die neue Initramdisk erstellt werden. Ein Neustart sollte den Schlüssel dann vom USB-Stick lesen anstatt diesen interaktiv zu erwarten.

Hat man die neue Konfiguration hinreichen getestet kann man den bei der Installation vergebenen Schlüssel aus LUKS entfernen und die gesicherte Initramdisk löschen.

Eine Anmerkung zur Distributionsaktualisierung

Diese Anleitung habe ich ursprünglich anhand von openSUSE 11.3 erstellt. Sie gilt aber auch für aktuellere Versionen bis 13.1. Auf openSUSE Leap 42.2 funktionierte diese methode aber nicht! Auf neuere Versionen kann man über das normale DVD-Update aktualisieren. Hierbei muss man allerdings die verschlüsselte Partition über einen eingetippten Schlüssel öffnen. Hierzu hilft es den bei der initialien Installation verwendeten Schlüssel nicht deaktiviert zu haben, oder aber temporär per cryptsetup luksAddKey einen kürzeren Schlüssel hinzuzufügen. Getestet habe ich auf diese Weise das Update von 11.3 auf 11.4 und von 11.4 auf 12.1. Der Installer warnt einen zwar, dass es Probleme geben kann, wenn man Partitionen per Kernel Device Name mountet, dies hat sich aber bisher nicht als Problem herausgestellt.

Quellen

Da die Literatur — was openSUSE angeht — zu diesem Thema leider noch sehr dürftig ist habe ich mich vieler Quellen bedient, von denen ich hier nur die wichtigsten nennen möchte:

http://forum.ubuntuusers.de/topic/luks-root-partition-mit-schluessel-auf-usb-st/#post-1928847 lieferte die Vorlage für mein Keyscript.
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions hilft enorm beim Verständnis.
http://forums.fedoraforum.org/showthread.php?t=241942 zeigt im Prinzip den ganzen Vorgang, funktioniert leider nicht 1:1 für openSUSE.
http://wejn.org/how-to-make-passwordless-cryptsetup.html zeigt mehrere Variationen des Themas, aber passt auch nicht direkt auf openSUSE.
http://raftaman.net/?p=300 ist inspirierend, löst aber nicht ganz das gleiche Problem (der verwendete USB-Stick ist cool).
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt#Remote_unlocking_of_the_root_.28or_other.29_partition liefert Grundlagen, wenn man dies möchte.

Civilization V im LAN

2010-12-19T17:25:20+01:00

Nachdem Civilization V ja an Steam gebunden, und damit mit einem gewissen Online-Zwang aber auch SteamPlay, herauskam stellte sich die Frage wie es sich mit dem LAN-Modus verhält. Glücklicherweise bietet Steam ja auch einen Offline-Modus, so dass die LAN nicht unbedingt mit einem Internetanschluss versehen sein muss.

Ich habe den LAN-Modus bis jetzt übrigens nur in technischer Hinsicht einige Runden, alleine an zwei Rechnern, getestet. Die Startpositionen wirkten überaus fair, aber zum langfristigen Mehrspieler-Spielspaß kann ich so natürlich keine Aussage machen.

Fair-Use im LAN

Erfreulicherweise ist es möglich Civ V im LAN mit nur einer Lizens auf mehreren Rechnern zu spielen, so wie wir das früher ja eigentlich alle mit Spielen gemacht haben die noch nicht jeder hatte. Die Macher von Steam, die ja als Kopierschutzanbieter vermutlich hinter der entsprechenden Designentscheidung stehen, haben hier wohl den viralen Marketing-Faktor dieser Form von Fair-Use erkannt. Um das Spiel mit einem Steam-Account zu spielen ist wie folgt vorzugehen:

Steam auf jedem Rechner mit einem Account der Civ V besitzt starten und in den Offline-Modus versetzen. Es ist wichtig diesen Schritt auf jedem Rechner nacheinander durchzuführen, da ein Steam-Account nur auf einem Rechner gleichzeitig Online sein kann. Hierdurch ist auch sichergestellt, dass die Gäste keine Achievements erreichen können.
Den Profilnamen auf den Gästerechnern ändern. Dies ist nicht nur wichtig damit die Spieler im Spiel nicht alle gleich heißen, sondern weil sie sonst auch gar nicht auf den Server kommen.
Spiel starten und Spaß haben
Am Schluß darf man natürlich nicht vergessen auf den Gästerechnern im Steam wieder den Benutzer zu ändern.

Speichern

Ein manuelles Speichern ist im LAN nicht vorgesehen. Stattdessen wird das Spiel, anscheinend unabhängig von der Einstellung im Optionsmenü, jede Runde automatisch gespeichert.

Man kann zwar mit Strg+S den Speichern-Dialog aufrufen, welcher im Menü fehlt, diese Speicherstände werden aber im Laden-Dialog der beim Spielstart sichtbar ist nicht angezeigt.

Da die automatischen Speicherstände nur nach Runde benannt werden empfiehlt es sich bei jeder Spielunterbrechung die aktuelle Runde zu notieren und

SteamPlay

Auch wenn es dank SteamPlay möglich ist das Spiel, einmal gekauft, sowohl unter Windows als auch auf Mac OS X zu spielen, so klaffen die Versionen doch ein ganzes Stück auseinander. Deshalb ist es leider nicht möglich mit Windows und Mac OS X am gleichen Spiel teilzunehmen. Versucht ein Windows-Rechner auf einen Mac OS X-Server zu verbinden so erscheint eine Meldung, welche auf die abweichenden Versionsnummer hinweist.

Ich hoffe hier wird noch einmal darüber nachgedacht den Quelltext der beiden Versionen wieder zusammenzuführen, so dass in Zukunft beide Version synchron sind. Denn auch, dass die zusätzlich herunterladbaren Spielinhalte momentan nur für Windows verfügbar sind finde ich, bedenkt man, dass es sich nur um Völker und Szenarios handelt, unverständlich.

Wenn Apps im Android Market in "Authorizing purchase…" hängen…

2010-12-18T18:03:25+01:00

scheint dies, kann man Google glauben, ein weit verbreitetes und von Google ignoriertes Problem zu sein. Das Problem ist aber eigentlich leicht, wenn auch mit leichtem Komfortverlust zu lösen.

Den Download der betroffenen Anwendung im Market abbrechen.
In meinem Fall ging dies nicht im Dialog der Anwendung, sondern nur durch "Rechtsklick", also lange halten, in der Download-Übersicht.
Die Anwendung deinstallieren. Hierzu die Einstellungen starten, dort Anwendungen auswählen und die entsprechende Anwendung auswählen. Dort gibt es dann einen "Deinstallieren"-Knopf.
Den Cache des Markets löschen.
Ich bin mir nicht sicher ob dieser Schritt wirklich notwendig ist, er schadet aber auch nicht. Erneut in den Einstellungen die Anwendungen auswählen, dort den Market auswählen und den Knopf "Cache leeren" wählen.
Handy neustarten.
Erneut nicht umbedingt notwendig, aber sicher ist sicher.
Die Anwendung im Market erneut auswählen und installieren. Da der Kaufstatus am Account hängt kann man die Anwendungen ja so oft neu installieren wie man möchte.

Mit dieser Methode konnte ich das Problem bis jetzt immer beheben. Einziger Nachteil ist, dass man im Fall von Twidroy d anschließend die Accounts neu einrichten muss. Das Google zu dem Thema nicht viel sagt ist, meiner Meinung nach, auch weniger verwunderlich. Es scheint eigentlich nur bei Android-Updates aufzutreten, und die treten ja eigentlich nur bei Drittherstellern auf, z.B. beim mir durch den CyanogenMod auftreten.

c't offline update auf dem Mac

2010-11-03T18:12:38+01:00

Die c't Offline Update, mit dem sich Windows PCs ohne Netzwerkverbindung auf den neuesten Stand bringen lassen, kann seit Version 6.0 auf unter Linux die CD mit den Aktualisierungen erstellen. Dank gemeinsamen unixoiden Kultur funktioniert es damit auch auf dem Mac. Es müssen lediglich die notwendigen Kommandozeilenwerkzeuge, z.B. via MacPorts installiert werden. Auf jeden Fall notwendig sind: cdrtools, wget, dos2unix, cabextract und xmlstarlet. Anschließend reicht est Offline Update zu entpacken, in das Verzeichnis sh zu wechseln und das Skript DownloadUpdates.sh auszuführen. Das ISO findet sich anschließend im Verzeichnis iso.

Quick Cluster Overview jetzt auf Gitorious

2010-09-27T14:16:27+02:00

Da ich Quick Cluster Overview (QCO) die Tage für ein Projekt meiner universitären Arbeitsgruppe wieder rauskramen musste habe ich genutzt um den Quellcode gleich mal auf Gitourious zu schieben. Die URL der Projektseite lautet https://gitorious.org/qco.

Ich habe lokal noch einige Aktualisierungen und Ideen herumliegen. Ich hoffe ich finde die nächsten Tage mal die Zeit diese auch einzupflegen.

OpenCL und #include

2010-02-11T00:06:10+01:00

Jeder der das erste mal versucht in einem OpenCL-Kernel eine Headerdatei mit #include "header.h" einzubinden scheitert für gewöhnlich mit einer Fehlermeldung im Stiele von catastrophic error: cannot open source file "header.h". Grund ist, dass der Compiler normalerweise nicht im Quellverzeichnis nach der Headerdatei sucht. Man muss dem Befehl clBuildProgram explizit den Pfad per Compileroption -I /pfad/zu/den/headern/ übergeben.

Beim Implementieren der Parameterübergabe an clBuildProgram fällt schnell auf, wieso er den Pfad nicht von alleine kennt. Ein "-I ." funktioniert nämlich spätestens dann nicht mehr, wenn man das Programm nicht im Quellverzeichnis ausführt. Man benötigt also eine Konstante mit welcher man sich den korrekten Parameter zusammenbauen kann. Dies sieht dann zum Beispiel so aus:

char compiler_options[256];
sprintf( compiler_options, "-I \"%s\"", SOURCE_DIRECTORY );
err = clBuildProgram( program, 0, NULL, compiler_options, NULL, NULL);

Hier ist es wichtig, dass compiler_options groß genug ist um mit jedem möglicherweise übergebenen Pfad zu funktionieren!

Um den Code in unterschiedlichen Verzeichnissen übersetzen zu können definiert man diese Konstante am besten außerhalb und übergibt sie zur Compilezeit:

gcc -DSOURCE_DIRECTORY="$(pwd)" -o headerTest headerTest.c

Nutzt man CMake so reicht es in der CMakeList.txt die folgende Zeile hinzuzufügen:

add_definitions( -DSOURCE_DIRECTORY="${CMAKE_SOURCE_DIR}" )

So weit, so schön die Theorie. Leider scheitern die Implementierungen von Apple und NVIDIA an Leerzeichen im Pfad. Da sie die Gänsefüßchen als normale Zeichen interpretieren scheitern sie mit dem angegebenen Aufruf also auch an Pfaden ohne Leerzeichen. Ein korrekter Aufruf verzichtet also auf sie, kann dann aber nicht mehr mit Leerzeichen umgehen.

char compiler_options[256];
sprintf( compiler_options, "-I %s", SOURCE_DIRECTORY );
err = clBuildProgram( program, 0, NULL, compiler_options, NULL, NULL);

Zusätzliche Modulverzeichnisse für CMake

2010-02-09T01:43:49+01:00

Ein großer Nachteil von CMake ist, dass Standardordner im Benutzerverzeichnis kennt aus dem es zusätzliche Skripte ziehen kann. Gerade noch in der Entwicklung befindliche Skripte, wie mein FindOpenCL möchte man aber nicht gleich global im System verankern. Die Lösung liegt in der Variable CMAKE_MODULE_PATH. Die in dieser Variablen Verzeichnisse werden von find_package() vor den Verzeichnissen der CMake-Installation durchsucht.

Soll der Pfad zu den zusätzlichen Modulen nicht in jedem CMakeList.txt codiert werden, so muss er CMake aufgrund der mangelnden Konfigurierbarkeit bei jedem Aufruf übergeben werden. Da es sich um eine echte CMake-Variable handelt, welche nicht automatisch aus einer Umgebunsvariablen gleichen Namens gefüllt wird, ist es am einfachsten dies durch ein passendes Alias bei jedem Aufruf automatisch mitzugeben. Hierzu fügt man am Ende der ~/.bashrc folgende Zeile an:

# Have CMake also search for modules in ~/.cmake/modules
alias cmake="cmake -DCMAKE_MODULE_PATH=~/.cmake/modules"

Patch für die Hercules DJ Console-Treiber für Linux 2.6.30 und neuer

2010-02-06T16:48:20+01:00

Die Treiber für die DJ Controller von Hercules gibt es zwar in Paketen für so ziemlich alle Distributionsarten, aber leider nicht für die aktuellsten Version. Unter openSUSE 11.2 funktioniert der Treiber zunächst nicht, da dieses Kernel 2.6.31 verwendet, der Treiber aber eine ALSA-Funktion nutzen möchte welche in dieser Version aus dem Kernel flog. Ein kleiner Patch behebt das Problem indem er den entscheidenden Aufruf auf die neue Funktion ändert.

Hat man den Treiber nach der Anleitung auf der Webseite installiert, so kann man mit dkms status prüfen ob dieser im System erfolgreich installiert wurde. Auf System mit Kernel 2.6.30 aufwärt bekommt man hier nur die enttäuschende Meldung: hdjmod, 1.28: added. Wäre die installation erfolgreich gewesen müsste hier installed stehen.

Der nächste Schritt nach dem add ist der build. Ein Blick in das Logdatei /var/lib/dkms/hdjmod/1.28/build/make.log zeigt das Problem:

/var/lib/dkms/hdjmod/1.28/build/device.c:1663: error: implicit declaration of function ‘snd_card_new’

Der Patch behebt das Problem indem er für neuere Kernel den Funktionsaufruf durch auf die neue Funktion snd_card_create ändert. Um ihn anzuwenden wechselt man in das Verzeichnis /usr/src/hdjmod-1.28 und ruft dort sudo patch -p1 < /path/to/hdjmod_kernel_2.6.30.patch auf. Anschließen baut man mit sudo dkms build -m hdjmod -v 1.28 das Modul und installiert es mit sudo dkms install -m hdjmod -v 1.28.

Anschließend kann man im DJ Control Panel sehen, dass der Treiber beim Anschließen der Konsole erfolgreich geladen wird. Insgesamt ein gutes Beispiel dafür, wieso man Treiber Open Source halten sollte, aber leider auch ein gute Beispiel, wieso man Treiber nicht außerhalb des Kernels pflegen sollte.

>Hier kann man den Patch herunterladen<

MacPorts hinter Proxies verwenden

2010-01-20T16:51:35+01:00

Sitzt man mit seinem Mac in einem Netzwerk ohne direkten Zugang zum Internet funktioniert MacPorts leider nicht automatisch mit den im System eingepflegten Proxies. Durch manuelles Setzen der Umgebungsvariablen http_proxy und RSYNC_PROXY lässt sich MacPorts aber ohne Einschränkungen nutzen.

Das erste Problem entsteht dadurch, dass der Befehl sudo den ausgeführten Befehl von in der Shell gesetzten Umgebungsvariablen abschirmt. Dadurch sieht der port-Befehl in der Benutzershell gesetzte Proxy-Variablen nicht und kann sich nicht mit seinen Servern verbinden.

eccentrica:~ marix$ sudo port selfupdate
--->  Updating the ports tree
Error: Synchronization of the local ports tree failed doing rsync
Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports tree: Synchronization of 1 source(s) failed

Die Lösung dieses Problems ist mit sudo eine neue Shell zu starten in der die Umgebungsvariablen gesetzt werden können. Wichtig ist hierbei, dass MacPorts auch rsync verwendet, welches nicht die http_proxy-Variable interpretiert. Deshalb muss auch die Variable RSYNC_PROXY gesetzt werden.

eccentrica:~ marix$ sudo -s
Password:
bash-3.2# export http_proxy=http://proxy:8080
bash-3.2# export HTTPS_PROXY=http://proxy:8080
bash-3.2# export FTP_PROXY=http://proxy:8080
bash-3.2# export RSYNC_PROXY=proxy:8080
bash-3.2# port selfupgrade

An Stelle des port selfupgrade kann natürlich eine beliebige Anzahl anderer Befehle stehen.

Ein weiteres Problem entsteht, wenn MacPorts Subversion verwendet um an den Quelltext des zu installierenden Programmes zu kommen.

ash-3.2# port install iterm
--->  Computing dependencies for iTerm
--->  Fetching iTerm
Error: Target org.macports.fetch returned: Subversion check out failed
Error: Status 1 encountered during processing.
Before reporting a bug, first run the command again with the -d flag to get complete output.

Subversion lässt sich leider nicht über Umgebungsvariablen zur Verwendung des Proxies überreden. Stattdessen muss man die Datei ~/.subversion/servers entsprechend anpassen.

Mystic Mine unter openSUSE 11.2

2009-12-04T19:58:49+01:00

Mystic Mine ist ein lustiges Independent-Spiel das man ähnlich wie Frozen Bubble mal schnell zwischendurch spielen kann. Und das beste daran, es gibt eine native Linuxversion.

Leider scheiterte mein Versuch diese Linuxversion zu nutzen mit folgender Meldung:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/cx_Freeze/initscripts/Console.py", line 29, in 
  File "monorail.py", line 34, in 
  File "koon/app.py", line 10, in 
  File "koon/snd.py", line 4, in 
  File "ExtensionLoader_pygame_mixer.py", line 12, in 
ImportError: libSDL_mixer-1.2.so.0: cannot open shared object file: No such file or directory

Das ist mal ein schönes Beispiel für eine zielführende Fehlermeldung. SDL_mixer ist nicht installiert, die Installation der passenden Bibliothek hilft. sudo zypper in SDL_mixer

Serverupdate

2009-10-24T11:41:15+02:00

Ich werde im Laufe des Wochenendes den Server aktualisieren, dadurch wird die Seite, sowie Email, Subversion und einiges andere immer wieder mal nicht erreichbar sein.

Update: Der Server wurde inzwischen aktualisiert. Damit sollten die größten Störungen vom Tisch sein. Jetzt muss nur noch bei Gelegenheit Drupal einen Versionssprung machen, der Quasselcore wieder aufgesetzt werden, die Greylist getuned ...

2. Update: Die Greylist läuft auch wieder => Spam gegen 0. Genau so der Quasselcore und endlich kann mein Dovecot auch Sieve. :)

Nutzung von Graﬁkprozessoren in Anwendungen der Hochenergiephysik

2009-09-07T11:36:51+02:00

... ist der Titel meiner Diplomarbeit, mit welcher ich das Studium der Physik erfolgreich abschloss.

Die Menge an Daten die Experimente in der Hochenergiephysik erzeugen steigt immer weiter an. Klassische skalare Programme können aber nicht mehr davon profitieren, dass Prozessoren immer höher getaktet werden. Um größere Datenmengen verarbeiten zu können sind Anwendungen notwendig, die parallele Architekturen nutzen. Diese Diplomarbeit zeigt auf NVIDIA CUDA basierende Implementierungen und Optimierungen von drei Anwendungen verschiedenen Typs auf Grafikprozessoren. Zelluläre Automaten, welche für die Spurrekonstruktion verwendet werden können, werden durch eine Implementierung des Game of Life repräsentiert die 20 mal schneller als eine SSE nutzende Implementierung auf dem Hauptprozessor ist. Die Laufzeit eines Kalman-Filters, mit dem Spurparameter geschätzt werden, wird auf ein Siebtel gegenüber der auf SSE basierenden Implementierung beschleunigt. Auch der Linpack-Benchmark, als Anwendung zur Lösung von Gleichungssystemen, wird analysiert und so optimiert, dass er auf einer Grafikkarte 67.2 Gflops erreicht und auf mehrere Karten skaliert.

Die komplette englischsprachige Arbeit kann als PDF heruntergeladen werden.

Blumentopfs Wahlwerbespot

2009-08-27T12:03:09+02:00

Normallerweise versuche ich diese Seite, obwohl ich engagierter Pirat bin, unpolitisch zu halten und bin auch kein großer Fan von Hip-Hop. Den Wahlaufruf der Band Blumentopf zur Bundestagswahl 2009 finde ich aber so gut, dass er trotzdem hierher kommt.

Cuda ohne graphische Oberfläche profilen

2009-01-20T12:26:28+01:00

Mit CUDA ist es nicht mehr notwendig eine graphische Oberfläche auf dem GPGPU Knoten zu haben. Doch was, wenn man den GPU-Teil einer Anwendung profilen möchte? Der CUDA-Profiler basiert auf QT und läuft auf einem nackten Knoten ohne X nicht.

Zum Glück ist die Profilingfunktionalität von CUDA auf niedrigerer Ebene realisiert und lässt sich durch Umgebungsvariablen steuern. Der graphische Profiler nimmt einem diese Arbeit lediglich ab und lässt einen intuitiver die zu messenden Metriken bestimmen.

Die für die Konfiguration zuständigen Umgebungsvariablen sind:

CUDA_PROFILE – Dies ist die einzige zwingend erforderliche Variable. Hat sie den Wert 1 werden Profiler-Daten geschrieben.
CUDA_PROFILE_CSV – Ist diese Variable auf 1 gesetzt werden die Daten als CSV geschrieben. Dieses kann dan später vom Visual Profiler importiert werden.
CUDA_PROFILE_LOG – Hier kann der Name der Log-Datei vorgegeben werden. Ansonsten wird profile.log verwendet.
CUDA_PROFILE_CONFIG – Hier kann eine Konfigurationsdatei angegeben werden in welcher spezifiziert wird welche Zähler mitprotokoliert werden sollen.

In der durch CUDA_PROFILE_CONFIG angegebenen Datei können bis zu vier Zähler angegeben sein. Jeder Zähler muss hierbei in einer eigenen Zeile stehen. Die möglichen Werte sind:

gld_incoherent – Anzahl der nicht zusammengefügten lesenden Zugriffe auf den globalen Speicher, funktioniert nicht auf GT200-basierten Karten.
gst_incoherent – Anzahl der nicht zusammengefügten schreibenden Zugriffe auf den globalen Speicher, funktioniert nicht auf GT200-basierten Karten.
gld_coherent – Anzahl der zusammengefügten lesenden Speicherzugriffe.
gst_coherent – Anzahl der zusammengefügten schreibenden Speicherzugriffe.
local_load – Anzahl der lesenden Zugriffe auf den lokalen Speicher.
local_store – Anzahl der schreibenden Zugriffe auf den lokalen Speicher.
branch – Gesamte Anzahl der Verzweigungen
divergent_branch – Gesamte Anzahl der Verzweigungen welche zu serialisierter Ausführung führten
instructions – Befehlszähler
warp_serialize – Anzahl von Threads in Warps die aufgrund von Adresskonflikten beim Zugfriff auf den gemeinsamen oder den konstanten Speicher.
cta_launched – Anzahl der ausgeführten Blöcke.

So ist es dann durchaus auch möglich die Graphikkartennutzung in MPI-Programmen zu profilen. Hierbei muss man lediglich beachten, dass jeder Prozess seine eigene Ausgabedatei verwendet. Bei OpenMPI 1.3 kann man z.B. die Umgebungsvariable OMPI_COMM_WORLD_RANK nutzen und den Aufruf des eigenen, hier beispielsweise meinCudaProgramm genannten Programmes durch ein kleiens Skript ersetzen.

#!/bin/bash
export CUDA_PROFILE=1
export CUDA_PROFILE_CSV=1
export CUDA_PROFILE_LOG=meinCudaProgramm.profile.csv
./meinCudaProgramm

Projektpraktikumsbericht zu Quick Cluster Overview

2009-01-17T20:36:16+01:00

Dieser Bericht beschreibt die Funktionsweise, Installation und Konfiguration der von mir als Projektpraktikum geschriebenen Anwendung Quick Cluster Overview.

PDF des Berichtes: bericht.pdf

Projektpraktikumsvortrag über Quick Cluster Overview

2009-01-17T20:33:31+01:00

Dieser Projektpraktikumsvortrag stellt Quick Cluster Overview mit seinen wichtigsten Features vor und beschreibt seine Architektur.

PDF des Vortrags: vortrag.pdf

Ein paar Hinweise zur Migration eine openSUSE auf ein RAID5

2009-01-17T20:17:44+01:00

Möchte man ein System auf ein RAID5 migrieren reichen dafür die drei Festplatten. Für Ubuntu ist dies auf Netzpiraten.ch schön beschreiben.

Ist der Grund für die Migration ein Hardwarefehler, so dass man die Ausgangsfestplatte anschließend tauschen möchte, kann man, statt wie auf Netzpiraten.ch beschreiben, auch erst einmal ein RAID5 mit nur zwei Platten anlegen. Dies entspricht zwar eigentlich einem RAID1 mit unnötig umständlicher Paritätsberechnung, lässt sich aber später problemlos zu einem echten RAID5 erweitern und bietet bereits während der Wartezeit auf den Austausch die gewünschte Fehlertoleranz.

Ein solches, einem RAID1 entsprechendes RAID5, weigert sich YaST allerdings anzulegen. Nutzt man allerdings die auf Netzpiraten.ch oder im The Software-RAID HOWTO beschreibenen Befehle gelingt dies problemlos.

mdadm --create /dev/md0 -n2 -l5 /dev/sdb3 /dev/sdc3

Die hierfür zuvor notwendige Partitionierung lässt sich am besten aus dem laufenden openSUSE-System mit YaST machen. Um die Dateien zu kopieren lässt sich das RAID unter Knoppix einbinden. Dort kann man die Dateien mit cp --archive kopieren.

Möchte man das RAID5 später um eine Festplatte, zum Beispiel die zuvor eingesparte Dritte, erweitern, hilft die Beschreibung auf isomerica.net. Wer ext3 verwendet muss nur statt xfs_growfs resize2fs verwenden. Der komplette Vergrößerungsvorgang kann komplett aus dem laufenden System erfolgen. Hierbei hilft watch den Fortschritt zu beobachten.

Da man bei diesen Aktionen auch durchaus mal die falsche Partition zerstören kann empfiehlt sich generell ein vorheriges Backup. Auch etwas Training in VirtualBox kann nicht schaden bevor man sich auf sein Live-System stürzt, dort können viele Unklarheiten beseitigt werden solange man noch ein komplett laufendes System hat.

Quick Cluster Overview Version 0.1

2009-01-17T20:17:44+01:00

Version 0.1 von Quick Cluster Overview enthält die folgenden wichtigen Features:

Kann Daten aus Ganglia extrahieren.
Kann Daten aus Lemon extrahieren.
Generiert Übersichtsgraphen mit Gnuplot.
Enthält eine modifizierte Version von PHP-GNUPlot die eine höhere Geschwindigkeit aufweißt.
Zieht Daten maximal einmal pro konfiguriertem Zeitintervall aus dem Cluster und nutzt anschließend die bereits generierten Graphen.
Modularer Aufbau, dadurch leichte Erweiterbarkeit auf andere Monitoringsysteme und Plot-Anwendungen.
Leichte Modifizierbarkeit der Seitendarstellung durch den Einsatz der Smarty Template Engine.

Dokumentation welche die Installation und Konfiguration beschreibt findet sich im Download und im Projektpraktikumsbericht. Genauere Darstellungen der Funktionsweise im auf dieser Version basierenden Projektpraktikumsbericht und dem ebenfalls auf dieser Version basierenden Projektpraktikumsvortrag.

Benötigte Software:

Webserver
PHP 5 oder neuer
Gnuplot
Ganglia oder Lemon

Lizens: GPLv2, der Download enthält aber im Verzeichnis contrib einige Fremdanwendungen deren Lizens abweichen kann. Die entsprechenden Lizensen sind den einzelnen Anwendungen in diesem Verzeichnis zu entnehmen.

Datei: qco.0.1.tar.bz2

Import von Amarok 1.4-MySQL-Datenbank in Amarok 2

2008-12-23T20:04:17+01:00

Der Import meiner in MySQL abgelegten Amarok 1.4-Datenbank in Amarok 2 wollte zunächst nicht klappen. Ich scheiterte immer mit QMYSQL: Verbindungsaufbau nicht möglich. Zum Glück war vorher schon jemand über den Fehler gestolpert und hat eine Lösung gefunden, nämlich anstatt des Hostnamens die IP des Servers anzugeben. Nachlesen kann man dies alles unter KDE Bug 174269. Kaum war die Voreinstellung localhost in 127.0.0.1 geändert schon rödelte die Kiste los.

Abhilfe für den "The specified URL cannot be found"-Fehler auf Planet Descent

2008-11-24T00:02:16+01:00

Seit einiger Zeit bekommt man auf Planet Descent beim Versuch einen Beitrag einzustellen den Fehler "The specified URL cannot be found". Provoziert wird er durch bestimmte Zeichen wenn diese im Beitrag enthalten sind, unter anderem auch durch den doch recht nützlichen Zeilenumbruch. Abhilfe schafft User-JavaScript. Dieses Skript für Opera ersetzt die gefährlichen Zeichen durch ihre Escape-Sequenz und verhindert so den Fehler. Um das Skript zu verwenden muss es in den User-JavaScript-Ordner von Opera gelegt werden. Wo dieser sich befindet ist unter Extras->Einstellungen->Inhalte->JavaScript-Optionen im Feld User-JavaScript-Dateien zu sehen. Wird es nicht mehr benötigt kann es einfach aus diesem Ordner gelöscht werden. Prinzipiell sollte sich das Skript auch leicht an andere Browser wie zum Beispiel Firefox mit dem Greasemonkey-Plugin anpassen lassen. Da ich dieses aber nicht benutze habe ich es nicht getestet.

Aktuelle Version:

0.4 für Opera

Vorherige Version:

0.3 für Opera 0.2 für Opera 0.1 für Opera

Zu welchem Paket gehörte die Datei nochmal

2008-10-31T14:59:05+01:00

Will man unter openSUSE wissen zu welchem Paket eine Datei gehört lässt sich dies ganz leicht herausfinden. Leider gibt es in RPM oder Zypper keine expliziete Funktion um dies Abzufragen, aber sie lässt sich ganz leicht bauen aus vorhandenen Komponenten zusammenbauen.

RPM zeigt im Abfrage-Modus (-q) mit -l alle Dateien einem Pakets an. Mit -a arbeitet der Abfrage-Modus auf allen Paketen. Es liegt also nahe alle Dateien aller Pakete anzuzeigen und alle unbenötigten Informationen mit grep auszufiltern. In meinem Beispiel suche ich das Paket glibc-devel welches die Datei /usr/include/gnu/stubs.h enthält.

marix@eddie:~> rpm -qal | grep "/usr/include/gnu/stubs.h"
/usr/include/gnu/stubs.h

Leider funktioniert dies wie im Beispiel zu sehen ist nicht so richtig. Zwar wird die Datei gefunden, das Paket aber noch nicht mit angezeigt. RPM zeigt mit -l ja nur die Dateien an, aber nicht die Paketnamen. Zum Glück lässt sich RPM aber über die Option --queryformat genau sagen, welche Informationen es zu einem Paket wie anzeigen soll. Unter http://rpm.org/max-rpm-snapshot/s1-rpm-query-parts.html#S3-RPM-QUERY-QUERYFORMAT-OPTION ist auch der passende Formatierungstext zu finden.

marix@eddie:~> rpm -qa --queryformat '[%{=NAME}: %{FILENAMES}\n]' | grep /usr/include/gnu/stubs.h
glibc-devel: /usr/include/gnu/stubs.h

Screen Spickzettel

2008-10-10T18:41:03+02:00

Die wichtigsten Befehle für die Arbeit mit Screen.

Screen starten: screen

Wieder mit der letzten Screen-Sitzung verbinden: screen -R

Screen mit einer Sitzung mit einem vorgegebenen Namen erstellen: screen -S Name

Eine neue Screen-Sitzung im Hintergrund starten: screen -dmS Name

Liste aller Screen-Sitzungen anzeigen: screen --ls

Wieder mit der Screen-Sitzung mit dem vorgebenen Namen verbinden: screen -r Name

Eine Sitzung mit einem vorgegebenen Namen von ihrer Konsole trennen: screen -d Name

Von der aktuellen Sitzung trennen, die Sitzung läuft im Hintergrund weiter: Strg+A D Erst Strg und A drücken, dann D drücken.

In der Sitzung scrollen: Strg+A Escape Erst Strg und A drücken, dann Escape drücken. Anschließend kann mit den Pfeiltasten sowie Bild-Auf und Bild-Ab gescrollt werden. Erneutes drücken von Escape beenden den Scrollen-Modus wieder.

Den Namen des aktuellen Fensters ändern: Strg+A A Erst Strg und A drücken, dann Shift und A drücken. Der Name ist markiert, man kann ihn mit der Rücktaste löschen und einen neuen eingeben.

Strg+A eingeben: Strg+A a Erst Strg und A drücken, dann A drücken.

Ein neues Fenster erstellen: Strg+A c Erst Strg und A drücken, dann C drücken.

Zum nächsten Fenster wechseln: Strg+A n Erst Strg und A drücken, dann N drücken.

Zum vorherigen Fenster wechseln: Strg+A p Erst Strg und A drücken, dann P drücken.

Fensterliste anzeigen: Strg+A " Erst Strg und A drücken, dann " (Shift + 2 bei deutscher Tastatur) drücken.

Installation von KDE 4.1 unter openSUSE 11.0

2008-09-23T12:06:56+02:00

Momentan erfordert die Installation von KDE 4.1 unter openSUSE 11.0 etwas Handarbeit. Dennoch ist sie schnell und leicht erledigt. Für x86-Systeme gibt es unter http://de.opensuse.org/KDE/KDE4 auch Links zur Installation mit einem Klick. Wer ein x64-System hat oder es sowieso lieber per Hand macht findet hier eine kurze Anleitung.

Zunächst sind in Yast über den Punkt Software-Repositories folgende Repositories hinzuzufügen:

http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.0/
http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Extra-Apps/openSUSE_11.0/
http://download.opensuse.org/repositories/KDE:/KDE4:/Community/openSUSE_11.0_KDE4_Factory_Desktop/

Die letzten beiden sind optional, erhöhen aber die Anzahl der zur Verfügung stehenden Anwendungen.

Wie unter http://de.opensuse.org/KDE/KDE4 erwähnt, benötigt man außerdem auch noch das Qt-Repository, da KDE 4.1 eine neueres Qt benötigt als bei 11.0 mitgeliefert wird. Fehlt dieses erscheint bei der Auswahl von KDE 4.1-Paketen die Fehlermeldung nichts bietet libqt-x11 >= 4.4.2 benötigt von kdebase4-runtime-4.1.1-48.2.i586.

http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_11.0/

Sind alle Repositories hinzugefügt kann man in in Yast unter "Software installieren oder löschen" das Schema "KDE 4 Desktop-Umgebung" auswählen. Möchte man alle zum Schema gehörende Software installieren kann man, nachdem man das Schema ausgewählt hat, bei einem Rechtsklick in die Paketliste "Alle in dieser Liste"->"Installieren" auswählen. Hatte man schon KDE 4.0 installiert kann man auch einfach in der Menüleiste "Paket"->"Alle Pakete"->"Aktualisieren falls neuere Version verfügbar" auswählen. Dies aktualisiert dann KDE 4.0 auf 4.1.

JUnit Kurzreferenz

2008-08-24T22:37:57+02:00

Eigentlich als Einführung gedacht eignet sich der Artikel JUnit 4 in 60 Seconds hervorragend als Kurzreferenz da er alle Features übersichtlich mit je einem Satz erklärt.

Doppelt angezeigte Aktualisierungen im openSUSE-Updater

2008-08-24T17:15:50+02:00

Seit meinem Update auf openSUSE 11.0 zeigte das openSUSE-Updater-Applet (opensuseupdater-kde) mir alle Aktualisierungen doppelt an. Grund war, dass ich versehentlich zwei Update-Repositories eingebunden hatte. Das Entfernen eines der beiden Repositories löste das Problem. Im Bild ist zu sehen, dass die Updates für Java 5 und Java 6 doppelt vorhanden sind. Da das Applet nur eine graphische Schnittstelle für zypper ist lag es nahe zu schauen, ob dieses das gleiche Verhalten aufweist.

marix@eddie:~> zypper lu
Die Daten des Repositorys 'Lokale RPMs' sind veraltet. Sie können 'zypper refresh' als Root ausführen, um die Daten zu aktualisieren.
Lese installierte Pakete...
Patches
Repository                    | Name           | Version | Kategorie | Status
------------------------------+----------------+---------+-----------+---------
openSUSE-11.0-FTP-UPDATE 11.0 | java-1_5_0-sun | 96      | security  | Benötigt
openSUSE-11.0-Updates         | java-1_5_0-sun | 96      | security  | Benötigt
openSUSE-11.0-FTP-UPDATE 11.0 | java-1_6_0-sun | 97      | security  | Benötigt
openSUSE-11.0-Updates         | java-1_6_0-sun | 97      | security  | Benötigt

Auch zypper zeigt jedes Update doppelt. Doch auch die Ursache des Problems ist zu sehen. Jede Aktualisierung ist aus zwei verschiedenen Repositories zu beziehen. Das erklärt sowohl wieso es die Updates doppelt gibt, als auch, wieso trotzdem immer korrekt aktualisiert wurde. Denn zypper hat immer nur das Update aus der ersten Quelle wirklich installiert, ähnlich wie bei Paketen die aus mehreren Quellen zu holen sind.

marix@eddie:~> zypper lr
#  | Alias                         | Name                              | Aktiviert | Auffrischen
---+-------------------------------+-----------------------------------+-----------+------------
1  | Lokale_RPMs                   | Lokale RPMs                       | Ja        | Ja
2  | suse_1                        | openSUSE-11.0-FTP-SRC-NonOSS 11.0 | Ja        | Ja
3  | Marix'_Home_Repository_1      | Marix' Home Repository            | Ja        | Ja
4  | NVIDIA_Repository             | NVIDIA Repository                 | Ja        | Ja
5  | KDE:KDE4:Factory:Desktop      | KDE:KDE4:Factory:Desktop          | Ja        | Ja
6  | openSUSE-11.0-FTP_11.0        | openSUSE-11.0-FTP 11.0            | Ja        | Ja
7  | home:thindil_1                | home:thindil                      | Ja        | Ja
8  | VideoLan_Repository           | VideoLan Repository               | Ja        | Ja
9  | 11.0                          | openSUSE-11.0-FTP-UPDATE 11.0     | Ja        | Ja
10 | openSUSE-11.0-FTP-DEBUG_11.0  | openSUSE-11.0-FTP-DEBUG 11.0      | Ja        | Ja
11 | Marix'_Sane_Repository        | Marix' Sane Repository            | Nein      | Ja
12 | openSUSE-11.0-Updates         | openSUSE-11.0-Updates             | Ja        | Ja
13 | Security_and_Privacy_1        | Security and Privacy              | Ja        | Ja
14 | home:dstoecker                | home:dstoecker                    | Nein      | Ja
15 | Packman_Repository            | Packman Repository                | Ja        | Ja
16 | openSUSE-11.0-FTP-NonOSS_11.0 | openSUSE-11.0-FTP-NonOSS 11.0     | Ja        | Ja
17 | openSUSE-DVD 11.0             | openSUSE-DVD 11.0                 | Nein      | Nein
18 | suse                          | openSUSE-11.0-FTP-SRC 11.0        | Ja        | Ja

In der Auflistung aller Quellen sieht man an Position 9 und 12 die beiden Update-Repositories. Zum Glück kann man mit zypper die Repositories auch über ihre Nummer identifizieren, so ist das entfernen nur wenig Tipparbeit.

marix@eddie:~> sudo zypper rr 9
Entferne Repository 'openSUSE-11.0-FTP-UPDATE 11.0' [fertig]
Repository 'openSUSE-11.0-FTP-UPDATE 11.0' wurde entfernt.

Eine anschließende Überprüfung der verfügbaren Updates zeigt, dass das Problem erfolgreich behoben wurde.

marix@eddie:~> sudo zypper refresh Lade Metadaten von Repository 'Lokale RPMs' herunter [fertig] Repository 'openSUSE-11.0-FTP-SRC-NonOSS 11.0' ist aktuell. Repository 'Marix' Home Repository' ist aktuell. Repository 'NVIDIA Repository' ist aktuell. Repository 'KDE:KDE4:Factory:Desktop' ist aktuell. Repository 'openSUSE-11.0-FTP 11.0' ist aktuell. Repository 'home:thindil' ist aktuell. Repository 'VideoLan Repository' ist aktuell. Repository 'openSUSE-11.0-FTP-DEBUG 11.0' ist aktuell. Repository 'openSUSE-11.0-Updates' ist aktuell. Repository 'Security and Privacy' ist aktuell. Repository 'Packman Repository' ist aktuell. Repository 'openSUSE-11.0-FTP-NonOSS 11.0' ist aktuell. Repository 'openSUSE-11.0-FTP-SRC 11.0' ist aktuell. Alle Repositories wurden aufgefrischt. marix@eddie:~> zypper lu Lese installierte Pakete... Patches

Ist man sowieso schon auf der Konsole unterwegs kann man die Updates auch gleich von dort einspielen.

marix@eddie:~> sudo zypper up Lese installierte Pakete... Die folgenden Pakete werden aktualisiert: java-1_6_0-sun java-1_6_0-sun-devel java-1_6_0-sun-alsa java-1_6_0-sun-jdbc java-1_5_0-sun-plugin java-1_5_0-sun Die folgenden NEUEN Patches werden installiert: java-1_6_0-sun java-1_5_0-sun

Gesamtgröße des Herunterladens: 55,5 M. Nach der Operation werden zusätzlich 21,1 M genutzt. Fortfahren? [JA/nein]: Herunterladen von Paket java-1_6_0-sun-1.6.0.u7-1.1.x86_64 (1/8), 21,9 M (79,6 M installiert) Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 437,3 K Lade herunter: java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig (127,1 K/s)] Wende Delta an: ./java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig] Installiere: java-1_6_0-sun-1.6.0.u7-1.1 [fertig] Herunterladen von Paket java-1_5_0-sun-1.5.0_update16-1.1.i586 (2/8), 20,1 M (74,4 M installiert) Lade herunter: java-1_5_0-sun-1.5.0_update16-1.1.i586.rpm [fertig (195,7 K/s)] Installiere: java-1_5_0-sun-1.5.0_update16-1.1 [fertig] Herunterladen von Paket java-1_6_0-sun-devel-1.6.0.u7-1.1.x86_64 (3/8), 13,0 M (51,9 M installiert) Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 6,2 M Lade herunter: java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig (130,2 K/s)] Wende Delta an: ./java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig] Installiere: java-1_6_0-sun-devel-1.6.0.u7-1.1 [fertig] Herunterladen von Paket java-1_6_0-sun-alsa-1.6.0.u7-1.1.x86_64 (4/8), 40,0 K (88,0 K installiert) Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 16,5 K Lade herunter: java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig] Wende Delta an: ./java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig] Installiere: java-1_6_0-sun-alsa-1.6.0.u7-1.1 [fertig] Herunterladen von Paket java-1_6_0-sun-jdbc-1.6.0.u7-1.1.x86_64 (5/8), 32,0 K (88,0 K installiert) Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 16,2 K Lade herunter: java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig] Wende Delta an: ./java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig] Installiere: java-1_6_0-sun-jdbc-1.6.0.u7-1.1 [fertig] Herunterladen von Paket java-1_5_0-sun-plugin-1.5.0_update16-1.1.i586 (6/8), 469,0 K (1,7 M installiert) Lade Delta herunter: ./rpm/i586/java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm, 60,7 K Lade herunter: java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm [fertig] Wende Delta an: ./java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm [fertig] Installiere: java-1_5_0-sun-plugin-1.5.0_update16-1.1 [fertig]

Dateinamen in Gnuplot vervollständigen

2008-04-07T14:27:55+02:00

In Ubuntu fehlt Gnuplot leider die Unterstützung für die GNU Readline Bilbliothek. Deshalb kann man Dateinamen leider nicht mit der Tabulatortaste vervollständigen lassen.

Auf http://telin.ugent.be/~slippens/drupal/node/158 wird beschrieben, wie man mithilfe von rlwrap das Problem umgehen kann. Ist rlwrap noch nicht installiert lässt sich das leicht nachholen.

sudo aptitude install rlwrap

Anschließend ruft man gnuplot mithilfe von rlwrap auf. -c steht hierbei für die Vervollsändigung von Dateinamen, -a sorgt dafür, dass rlwrap uns die Vervollständigung unabhängig vom ausgeführten Programm anbietet.

rlwrap -a -c gnuplot

Der expliziete Aufruf von rlwrap entfällt durch das Hinzufügen eines Alias in ~/.bashrc.

alias gnuplot='rlwrap -a -c /usr/bin/gnuplot'

Anschließend lassen sich in Gnuplot von Anführungszeichen gesetzte Dateinamen mit der Tabulatortaste vervollständigen.

Unsichtbare Wände in Descent 3 mit Wine

2008-04-06T10:46:08+02:00

Wer unter Linux mithilfe von Wine die Windowsversion von Descent 3 spielt hatte seit ein paar Versionen mit unsichtaren Wänden zu kämpfen, genauer genommen mit einem abgeschalteten Z-Buffer-Test. Wine 0.9.59 behebt den Bug wieder. Fertige Pakete finden sich im openSUSE Build Service.

LVM unter Knoppix verwenden

2008-04-03T20:52:35+02:00

Muss man in einem System das LVM nutzt die Festplatte wechseln hilft Knoppix bei der Migration. Prinzipiell kann man einfach direkt die Partitionen von einer auf die andere Platte kopieren, möchte man aber diese Gelegenheit nutzen um das die Festplatte neu aufzuteilen, z.B. LVM nur noch für die Distribution zu verwenden während der Rest in einem RAID landet, muss man sich damit beschäftigen wie man LVM unter Knoppix nutzt.

Wie auch RAID nutzt LVM den Device Mapper. Dieser wird bei Knoppix, das ja eigentlich keine Festplatte verwendet, nicht automatisch geladen. Dies lässt sich aber leicht von Hand nachholen.

modprobe md

Nun sollte man die physikalischen Volume Groups suchen auf denen sich die logischen Volumes befinden.

vgscan --mknodes

Diese lassen sich nun mit mit vgchange aktivieren.

vgchange -a y

Jetzt lassen sich auch die logischen Volumes anzeigen.

lvscan

Dies erzeugt auch die notwendigen Device-Dateien, so dass man die darauf befindlichen Dateisysteme anschließend mounten kann. In meinem Fall das alte /- und das alte /local-Dateisystem, welche sich auf den logischen Volumes root und local befinden. Diese sind gehören zur Gruppe system.

mkdir /media/oldroot
mkdir /media/oldlocal
mount /dev/system/root /media/oldroot
mount /dev/system/local /media/oldlocal

Um die Dateien auf das neue Dateisystem zu schieben muss auf der Zielfestplatte erst das physische Volume erstellt werden. Die dafür zuvor notwendige Partitionierung geschieht am einfachsten mit YaST noch aus dem alten laufenden System bevor man den Umzug startet.

pvcreate /dev/sdc2

Auf dem physischen Volume lässt sich dann die neue Volume-Group erstellen. Ich verwende den Namen noraid mir selbst zu verdeutlichen auf dieser Gruppe keine wichtigen Daten abzulegen.

vgcreate noraid /dev/sdc2

Auf dieser neuen Gruppe können nun logische Volumes angelegt werden. In diesem Fall wieder root und local. Mit -L wird hierbei die Größe des Volumes angegeben.

lvcreate -n root -L 20G noraid
lvcreate -n local -L 40G noraid

Nun müssen auf den Volumes Dateisysteme angelegt werden. In meinem Fall ext3 mit den Standardeinstellungen.

mkfs.ext3 /dev/noraid/root
mkfs.ext3 /dev/noraid/local

Die neu erstellten Dateisysteme lassen sich nun mounten.

mkdir /media/newroot
mkdir /media/newlocal
mount /dev/noraid/root /media/newroot
mount /dev/noraid/local /media/newlocal

Jetzt können wir die Dateien von der alten Platte auf die neue Kopieren. Hierbei sorgt --archive dafür, dass die Metadaten der kopieren Dateien wie Zugriffs- und Erstellungszeiten, Berechtigungen usw. nicht ändern und symbolische Links als solche erhalten bleiben.

cp --archive /media/oldroot/* /media/newroot/
cp --archive /media/oldlocal/* /media/newlocal/

Ist der Vorgang beendet, was durchaus eine Weile dauern sollte, sollte man die Dateisysteme wieder unmounten und anschließend mit vgchange LVM wieder anhalten.

umount /media/oldroot umount /media/oldlocal umount /media/newroot umount /media/newlocal

vgchange -a n

Eine sehr gute Referenz zum zu LVM ist das Linux LVM HOWTO.

RAID5 unter Knoppix verwenden

2008-04-03T19:44:33+02:00

Möchte man Änderungen an den Festplatten durchführen ist eine Live-System wie Knoppix sehr praktisch, da es unabhängig von diesen seinen Dienst verrichtet. Dies funktioniert selbst dann, wenn auf dem System ein Software-RAID5 genutzt wird.

Knoppix lädt, vermutlich da es meist als Live-System ohne Festplatten verwendet wird, den dafür benötigten Treiber nicht von alleine. Dies lässt sich aber problemlos von Hand erledigen.

modprobe md

Da der Treiber nicht in den Kernel einkompiliert ist, sondern als Modul geladen wird ist es leider nicht möglich alle RAIDs mithilfe automatisch zu laden.

mdadm --auto-detect

Zunächst einmal lässt sich inspizieren, auf welchen Partitionen sich überhaupt ein RAID befindet. Die zwei Fragezeichen sorgen dafür, dass alle Partitionen auf allen Festplatten durchsucht werden. Zumindest solange keine Platte mehr als 10 Partitionen hat.

mdadm --examine --brief /dev/sd??

Hat man alle Partitionen des RAID gefunden lässt sich dieses mit mdadm --assemble in Betrieb nehmen. Hier liegt das RAID bei zwei Platten auf der dritten und bei einer auf der ersten Partition jeder Platte und wir verwenden den RAID-Device 0 für unser RAID.

mdadm --assemble /dev/md/0 /dev/sda3 /dev/sdb3 /dev/sdc1

Der Erfolg lässt sich mit im proc-Dateisystem überprüfen.

cat /proc/mdstat
Personalities : [linear] [raid6] [raid5] [raid4]
md0 : active raid5 sda3[0] sdc1[3] sdb3[2]
      808984832 blocks super 1.0 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
unused devices:

Damit haben wir das RAID als Festplatte eingebunden. Jetzt müssten wir noch noch das darauf befindliche Dateisystem einbinden. Hierzu legen wir einen Ordner an und binden mit Mounten den RAID-Device auf diesen.

mkdir /media/raid
mount /dev/md0 /media/raid

Jetzt lässt sich das RAID verwenden. Um die Datenkonsistenz zu wahren empfiehlt es sich das Dateisystem vor dem Herunterfahren explizit vom Dateisystem zu lösen und anschließend das RAID anzuhalten.

umount /media/raid
mdadmin --stop /dev/md/0

Mehr Informationen zu den einzelnen Befehlen und zur allgemeinen Verwendung von Software RAID finden sich im Software-RAID HOWTO.

Rootkits und Rootkit-Erkennung

2008-04-03T07:48:07+02:00

Im Mai 2006 hielt ich im Seminar Computersicherheit für Paranoiker diesen Vortrag, in dem ich zunächst über die Klassifikation und Funktionsweise von Rootkits sprach um dann Abwehrstrategien und Software zur Erkennung von Rootkits vorzustellen.

Zum Herunterladen:

Weitere Vorträge zur Computersicherheit von anderen Studenten sind auf der Materialienseite des Seminars, sowie auf der Materialienseite des vorherigen Semesters zu finden.

Paketverwaltung verloren

2008-02-29T07:49:19+01:00

Auf leider nicht nachvollziehbare Weise hatte ich letztens plötzlich mein YaST verloren. Dies machte sich dadurch bemerkbar, dass KDE den Versuch "Installieren von Software" zu Starten mit der Bemerkung es könne "/sbin/yast" nicht finden beendete. Zeitlich fiel das ganze mit einem KDE4-Update zusammen, allerdings war mir bei diesem kein Konflikt aufgefallen.

Zum Glück wird die Paket- und Quellenverwaltung inzwischen nicht mehr YaST-intern abgehandelt, sondern durch die libzypper, für die mit zypper auch ein Kommandozeilenwerkzeug existiert. So ließ sich YaST schnell wieder installieren.

sudo zypper install yast2

So bekam ich zwar mein YaST zurück, leider fehlte aber immer noch das Paket zum "Installieren von Software". Mit zypper war dies allerdings auch schnell gefunden.

zypper search yast

Das gesuchte Paket heißt yast2-packager, also schnell mit zypper installiert.

sudo zypper install yast2-packager

Rechner ausschalten mit openSUSE 10.3

2008-02-27T10:15:05+01:00

Nachdem ich endlich dazu gekommen war das Windows 2000 auf einem alten PIII 550 MHz durch openSUSE 10.3 zu ersetzen funktionierte der Rechner zwar wunderbar, allerdings weigerte er sich beharrlich sich nach dem Herunterfahren selbständig abzuschalten. Auch unter Windows hatte es damals etwas Nachdruck bei der Konfiguration der Energieverwaltung gebraucht, aber wie diesen Nachdruck unter Linux ausüben? Der Vergleich der Aufrufe des normalen und des Safemode-Systems in Grub legte schnell nahe alle Kombinationen der Parameter apm bzw. acpi = off oder on durchzuspielen. Doch alles half nichts. Der entscheidende Hinweis kam dann zufällig auf der opensuse Mailingliste. Mit der Parametrisierung apm=off und acpi=force schaltet das System sich wie gewünsch von alleine ab sobald es heruntergefahren ist. Das ganze noch mit Hilfe von Yast direkt in GRUB eingetragen und das System läuft, bzw. schaltet ab wie Butter.

Umzug einer Amarok-Sammlung von SQLite nach MySQL

2008-01-16T23:14:27+01:00

Eigentlich gibt es im Amarok-Wiki eine schöne Anleitung wie man seine Sammlung von SQLite nach MySQL konvertieren kann. Leider stieß ich dabei allerdings auf ein paar, zum Glück leicht lösbare, Schwierigkeiten.

Zunächst einmal habe ich analog zur Anleitung mit phpMyAdmin eine Datenbank mit dazugehörigem Benutzer für

Beim nächsten Importversuch scheiterte ich an einer "Duplicate Key"-Fehlermeldung. Ursache des ganzen war, dass die Datenbank mit der Kollation latin1_swedish_ci erstellt worden war, Amarok aber wie ganz KDE natürlich mit UTF-8 Zeichenketten arbeitet. Zum Glück kann man die Kollation in phpMyAdmin wenn man die Datenbank ausgewählt hat im Tab Operationen leicht auf utf8_general_ci ändern. Anschließend einmal alle Tabellen droppen und nochmal von vorne. Die Kollation latin1_swedish_ci scheint übrigens entweder in MySQL oder phpMyAdmin die Standardeinstellung zu sein. Zumindest habe ich dieses Verhalten schon auf mehreren Systemen beobachtet. Wer aufpasst kann sie übrigens in phpMyAdmin auch gleich beim Anlegen der Datenbank richtig auswählen.

Als nächstes stolperte ich über eine weitere kleine Inkonsistenz. So beachtet Amarok bei Verwendung der SQLite-Datenbank bei den Tags anscheinend die Groß-/Kleinschreibung. Dies macht natürlich eigentlich keinen Sinn, und da eine Groß-/Kleinschreibung ignorierende Kollation ausgewählt war hat MySQL sich natürlich korrekterweise über den Versuche mehrere gleiche Tags anzulegen beschwert. Also einfach mit einem Texteditor die Duplikate aus der Datai entfernt, Tabellen geleert und wieder von vorne.

Am Ender der Datei folgen noch ein paar "index create"-Statements. Da diese von Amarok bereits angelegt wurden schlagen diese ntürlich fehl. Da es die letzten Statements sind und die MySQL-Datenbank nicht transaktional ist kann man diesen Fehler aber getrost ignorieren.

Grund für die ganze Aktion war übrigens, dass Amarok bei großen Sammlungen mit der MySQL-Datenbank einiges schneller sein soll. Subjektiv scheint dies auch zu stimmen, allerdings habe ich keine Messungen durchgeführt welche diese Behauptung bestätigen.

Glimpfliche Schrecksekunden mit Amarok

2008-01-15T16:11:33+01:00

Nach einem durch Harwarefehler bedingten kurzfristigen Umzug meines Systems auf ein RAID5 bereitete Amarok mir zwei kurze Schrecksekunden. Zum Glück ließen aber beide sich ohne Probleme und viel Aufwand beseitigen.

Zunächst fingen alle Einträge in meiner Datenbank an sich zu verdoppeln. Sobald man ein Stück spielte oder es auch nur in die Wiedergabeliste hinzufügte fand man auf einmal zwei Einträge in der Datenbank. Diese waren absolut identisch und verwiesen auf die gleiche Datei. Dateien die neu zur Sammlung hinzugefügt wurden zeigten das verhalten interessanterweise nicht. Da ich die MySQL-Datenbank aufgrund des Umzugs die Datenbank sowieso gerade erst gesichert hatte wagte ich ein "Extras->Sammlung neu erfassen". Anschließend waren alle doppelten Einträge verschwunden, neue Duplikate gab es auch keine und Statistiken sind auch nicht verloren gegangen.

Die nächste Schrecksekunde kam kurz darauf. Leide kann ich nicht mehr nachvollziehen, ob eine Aktualisierung von Amarok oder die Erweiterung des RAID um eine weitere Festplatte die Ursache war. Plötzlich fehlten sämtliche Stücke in meiner Sammlung. Die Dateien waren natürlich noch dar und interessanterweise waren in den Tabellen der MySQL-Datenbank auch noch alle Einträge vorhanden, nur Amarok hielt es anscheinen nicht für nötig diese anzuzeigen. Nach der positiven Erfahrung beim letzten Problem wagte ich auch hier, natürlich mit einer aktuellen Datensicherung ausgerüstet, ein "Extras->Sammlung neu erfassen". Keine 10 Minuten später war die Sammlung wieder da, inklusive aller Statistiken.

Hinzuzufügen ist, dass ich nicht die offiziell mit openSUSE ausgelieferte Version von Amarok verwende, sondern die aus dem Packman Repository. Der mit mit openSUSE ausgelieferte Version fehlt nämlich die Unterstützung für MySQL.

Umzug abgeschlossen

2007-10-24T20:50:33+02:00

Der Umzug ist erfolgreich abgeschlossen. Jetzt wird wieder an Inhalten gearbeitet.

Auszeiten

2007-10-22T12:32:44+02:00

Auch wenn die wichtigsten Komponent von Marix World inzwischen umgezogen sind wird immer noch kräftig gearbeitet. Unter anderem an den Nameservern. Dadurch kann es auch in den nächsten Tagen immer wieder zu Ausfällen von bis zu 24 Stunden kommen.

Umgezogen

2007-10-20T11:46:26+02:00

Marix World ist auf einen Server umgezogen. Nachdem bei Server4You nur noch das nicht mehr unterstützte SuSE 9.3 angeboten wurde ist Marix World auf einen neuen Server bei Strato umgezogen. Dadurch kam es leider zu ein paar Ausfällen, da die Nameservereinträge erst korrekt weiterpropagiert werden mussten, aber sobald dieser Text lesbar ist war alles erfolgreich.

Zattoo unter openSUSE 10.2 64-Bit

2007-09-15T22:29:51+02:00

Wie auf heise online berichtet ist Zattoo jetzt auch in Deutschland frei verfügbar. Leider aber nur als 32-Bit-Programm und mit einer etwas merkwürdigen Installationsanleitung.

Zum Herunterladen ist zunächst eine Registrierung notwendig. Entgegen der Aussage auf der Webseite muss man aber eigentlich noch nicht mal eine gültige Emailaddresse verwenden, da keine Aktivierungsemail verschickt wird, sondern die Addresse wirklich lediglich zur Benutzeridentifikation verwendet wird.

Die Installationsanleitung verwundert etwas, da sie unter anderem möchte, dass man XULRunner in das Zattoo-Verzeichnis installiert, obwohl dieses eigentlich bei openSUSE mitgeliefert wird. An den in der Anleitung angegebenen von Hand angelegten symbolischen Links kommt man leider nicht vorbei. Außerdem sind im RPM leider keine Abhängigkeiten gepflegt. Deshalb müssen einige Bibliotheken leider von Hand auf 32-Bit umgestellt werden.

Bevor man das Zattoo-RPM installiert sollte man zunächst sicherstellen, dass man die folgenden Libraries in 32-Bit installiert hat. Es kann sein, dass weitere Bibliotheken benötigt werden, aber diese sind mir aufgefallen. Um ein Paket in 32-Bit zu installieren muss man im YAST Packetmanagment im Reiter Version die 32-Bit Version (i586) auswählen. Ist das Paket schon installiert kann es notwendig sein das Paket auch noch von Hand auf "Aktualisieren" zu setzen.

libgnomeui-32bit (Ok, die ist immer 32-Bit)
gtkglext
mozilla-xulrunner181
faad2

Nachdem das Zattoo-RPM installiert ist müssen die symbolischen Links hinzugefügt werden. Möchte man die XULRunner-Bibliothek von openSUSE verwenden sehen die Links allerdings etwas anders aus.

sudo ln -s /usr/lib/xulrunner-1.8.1/libgtkembedmoz.so libgtkembedmoz.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libxpcom.so libxpcom.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libmozjs.so libmozjs.so.0d
sudo ln -s /usr/lib/libplds4.so libplds4.so.0d
sudo ln -s /usr/lib/libplc4.so libplc4.so.0d
sudo ln -s /usr/lib/libnspr4.so libnspr4.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libxul.so libxul.so.0d

Anschließen muss man noch den Linker auf die im Zattoo-Verzichnis liegenden Bibliotheken und Links hinweisen.

sudo /sbin/ldconfig /usr/lib/zattoo/

Bei Auslassen dieses Schrittes stürzt Zattoo jedesmal ab sobald es anfängt einen Kanal abzuspielen. In der Logdatei

~/.Zattoo/Data/logs/zattoo.errorlog

findet sich dann eine Meldung, dass eine bestimmte Funktion nicht gefunden werden konnte.

Persönlich finde ich es auch noch praktisch das Programm als zattoo verfügbar zu machen, da zattoo_player doch etwas lang zum tippen ist und zattood ein Tab-Complete verhindert.

sudo ln -s /usr/bin/zattoo_player /usr/local/bin/zattoo

Anchließen hat man einen funktionierenden P2P-Fernseher der auf den ersten Eindruck sehr gut zu funktionieren scheint.

Lesezeichen aktualisiert

2007-09-12T10:32:35+02:00

Die Lesezeichen wurden mal wieder aktualisiert. Hinzugekommen sind Verweise auf Open Descent Foundation, Tools wie I2P und ein paar andere.

Ton für OSS-Programme

2007-07-05T21:04:43+02:00

Auf meine OpenSUSE 10.2 Systeme hatte ich zunächst in Anwendungen wie X2, welche beim Ton noch auf OSS setzen, keinen Ton. Zum Glück lies sich das Problem am Ende durch ein einfaches Löschen der Konfiguration von KDesktop lösen. Statt Ton bekam ich bei allen Anwendungen die OSS verwenden eine Fehlermeldung, obwohl der Ton bei anderen Anwendungen ging.

/dev/dsp: Das Gerät oder die Ressource ist belegt

Jegliche suche nach eventuell noch laufenden Programmen welche die Tonausgabe blockieren könnten brachte zunächst keinen Erfolg. Amarok, Arts etc. waren alle gegen Alsa konfiguriert. Es war auch ohne Probleme möglich mehrere Anwendungen gleichzeitig Ton ausgeben zu lassen. Auch waren die Treiber für die OSS-Emulation unter Alsa geladen.

marix@eddie:~> lsmod | grep oss
snd_pcm_oss            71680  0
snd_mixer_oss          35840  1 snd_pcm_oss
snd_pcm               115464  4 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd                    89384  14 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer

Einen entscheidenden Hinweis lieferte ein mutiges Durchstarten von Alsa.

sudo /usr/sbin/rcalsasound restart

Danach hatte ich zwar Ton in X2, allerdings war mein Desktop auf einmal schwarz. Ein Neustarten von KDesktop bestätigte meinen Verdacht. Anschließend war die Tonausgabe wieder blockiert. Beim Neustarten von Alsa beendete KDestkop kommentarlos. Offensichtlich war es für die blockade der Tonausgabe, was sich auch leicht prüfen lies.

marix@eddie:~> lsof /dev/dsp* /dev/snd/**
COMMAND    PID  USER   FD   TYPE DEVICE SIZE   NODE NAME
kdesktop 19572 marix  mem    CHR  116,4      255811 /dev/snd/pcmC0D0p
kdesktop 19572 marix   11r   CHR  116,2      255551 /dev/snd/timer
kdesktop 19572 marix   12u   CHR  116,4      255811 /dev/snd/pcmC0D0p
kdesktop 19572 marix   13u   CHR  116,6      255819 /dev/snd/controlC0

Blieb die Frage, wie man das Problem löst. Ein kurze Suche mit meiner Leiblingssuchmaschine (nicht die mit den zwei O, dafür bin ich schon zu lange im Netz) lieferte mir dann den entscheidenden Hinweis. Auf http://www.linux-club.de/ftopic60033.html ist zu lesen, dass diese Problem wohl durch die Konfiguration von KDesktop verursacht ist. Löschen der Konfiguration löst das Problem.

mv ~/.kde/share/config/kdesktoprc ~/.kde/share/config/kdesktoprc.bak

Leider habe ich nicht herausgefunden welcher Teil der Konfiguration das Problem verursacht, da diese eigentlich keine Informationen zur Tonausgabe enthält. Allerdings hat ein Löschen auch nur zur Folge, dass man den Bildschirmhintergrund und den Bildschirmschoner neu setzen muss, der Aufwand hält sich also in Grenzen. Das beste daran ist, dass jetzt auch Descent 3 wieder richtig funktioniert. Das hatte sich bis jetzt nämlich immer kommentarlos gleich wieder beendet.

Kleines Update: Nach diesen Änderungen ist es jetzt auch möglich OSS-Programme mit aoss zu verwenden. Dies hat den Vorteil, dass man den Amarok im Hintergrund weiterlaufen kann und somit Musik und Anwendungston hat.

Arts Startprobleme schnell gelöst

2007-07-05T11:08:52+02:00

Seitdem ich mein KDE mithilfe der Quelle http://software.opensuse.org/KDE:/KDE3/opensuse_10.2/ aus dem SuSE-Build-Service auf 3.5.7 aktualisiert habe stürzte Arts immer beim Start ab. Ein Start des artsd in der Konsole erzeugte anschließend diese Ausgabe.

marix@eddie:/opt/kde3/lib64> artsd
unix_connect: can't connect to server (unix:/tmp/ksocket-marix/eddie.site-5e24-468ca6d0)
loading extension from '/opt/kde3/lib64/libartsmidi.so' failed: /opt/kde3/lib64/libartsmidi.so: cannot open shared object file: No such file or directory
MCOP ObjectManager: Could not load extension libartsmidi.la.
MCOP ObjectManager: can't find implementation for Arts::MidiManager.
loading extension from '/opt/kde3/lib64/libartsbuilder.so' failed: /opt/kde3/lib64/libartsbuilder.so: cannot open shared object file: No such file or directory
MCOP ObjectManager: Could not load extension libartsbuilder.la.
MCOP ObjectManager: can't find implementation for Arts::ArtsBuilderLoader.
Speicherzugriffsfehler

Das ist dann auch schon der entscheidende Hinweis zur Lösung des Problems. Anscheinend wurden bei der Erstellung der Pakete ein paar Links vergessen. Ein hinzufügen der Links löst das Problem.


sudo ln -s libartsmidi.so.0 libartsmidi.so
sudo ln -s libartsbuilder.so.0 libartsbuilder.so
sudo ln -s libartsakode.so.0 libartsakode.so
sudo ln -s libarts_akode.so.0 libarts_akode.so

Punklandung in den D3-Stats

2007-05-23T11:04:42+02:00

Da habe ich in den D3-Stats nicht nur endlich die 1000-Punkte-Marke geknackt, nein, ich habe sie genau getroffen. Hätte ich das bewusst versucht hätte ich es nie geschafft. Da man es in meinem Profil vermutlich nur bis zur nächsten Aktualisierung sehen kann ist hier ein Screenshot vom freudigen Ereignis.

USB-Joysticks und openSUSE 10.2

2007-05-09T00:58:28+02:00

Schließt man einen USB-Joystick an hat openSUSE ein recht merkwürdiges Verhalten. Zumindest gilt dies für meinem Fall, bei dem ein Logitech Extreme 3D Pro an ein Asus Motherboard mit nForce 570 SLI-Chipsatz angeschlossen wird. Auf dem System läuft openSUSE 10.2 x86_64. Zum Glück lässt sich diese Problem mit wenigen Handgriffen lösen.

Zunächst scheint das System den Joystick korrekt zu erkennen, was unter anderem anhand von dmesg zu sehen ist.

marix@eddie:~> dmesg | grep Joystick
input: USB HID v1.10 Joystick [Logitech Logitech Extreme 3D Pro] on usb-0000:00:02.0-1
input: USB HID v1.10 Joystick [Logitech Logitech Extreme 3D] on usb-0000:00:02.0-4

Wie zu sehen ist habe ich gleich zwei Joysticks angeschlossen. Zunächst schein aber alles zu funktionieren.

Interessant wird die Sache sobald man versucht den Joystick zu verwenden. Started man zum Beispiel das hervorgagende D1X-Rebirth bekommt man eine wenig erfreulich Meldung.

sdl-joystick: found 0 joysticks

Bestätigt wird die schlechte nachricht auch beim Einsatz von joy2key.

Error opening /dev/input/js0!
Are you sure you have joystick support in your kernel?

Wie die Meldung vermuten lässt, liefert ein ls /dev/input/ | grep js nichts zurück. Der Joystick funktioniert zwar als USB-Gerät, aber seine Semantik ist unbekannt.

Die Fehlermeldung von joy2key führt zur Lösung. Um den Joystick auch unter /dev/input zu sehen muss das Kernelmodul joydev geladen werden.

eddie:~ # modprobe joydev

Damit dies auch bei jedem Systemstart automatisch geschieht muss eine zeile in /etc/init.d/boot.local eingefügt werden.

/sbin/modprobe joydev

Nun steht der Joystick auch bei jedem Systemstart sofort zur Verfügung.

Nun zur Kuriosität. Startet man YaST und installiert neue Software funktioniert der Joystick anschließend reproduzierbar auch so. In diesem Fall scheint aus irgendeinem Grund das Modul also immer geladen zu werden. Sieht fast so aus, als wären Joysticks leider nicht mehr verbreitet genug um von Anfang an berücksichtigt zu werden und wurden beim Startup einfach vergessen.

XIII und Date Execution Prevention

2007-04-10T09:55:32+02:00

Nach langer Zeit fand ich endlich mal Zeit den Comic-Shooter XIII zu testen. Nachdem ich nach dem Intro schon auf den weiteren Verlauf der Geschichte gespannt war, machte mir den Segen der Technik einen Strich durch die Rechnung. Das Spiel stürzte im ersten Level wiederholt mit einem Illegal Access Error ab. Zunächst würde man denken, kein Problem, es gibt ja Altavista, Google und Co. Nach dann doch etwas längerer Suche fand ich den entscheidenden Tipp. XIII scheint mit selbstmodifizierendem Code zu arbeiten. Ich hatte zwar gewusst, dass der Software-Renderer der verwendeten Unreal-Engine das nutzt, sonst sieht man dies aber doch eher selten. Die kollidiert natürlich mit der in Windows XP SP 2 eingeführten Data Execution Prevention (XIII), die auf unterstützten CPUs, bei mir einer AMD X2 3800+, defaultmäßig aktiv ist. Der eigentliche Sinn der Data Execution Prevention ist die Sicherheit des Systems zu erhöhen, denn normallerweise ändert eine Programm nicht seinen eigenen Befehlsabfolge sondern arbeitet auf Daten die nicht als Teil des Programms ausgeführt werden sollen. Geschieht dies doch ist dies meistens ein Hinweis darauf, dass ein Angreifer versucht hat einen Programmfehler auszunutzen um eigene Befehle auszuführen. DEP soll dies verhindern. Um auch Programme zu unterstützen die auf die Möglichkeit sich selbst zu umzuschreiben angewiesen sind gibt es aber die Möglichkeit diese für einzelne Programme abzuschalten. Nicht dem radikalen vorgeschlagenen Weg folgend DEP komplett abzuschalten fügt ich in den DEP-Einstellungen (zu finden über Arbeitsplatz>Einstellungen) eine Ausnahme für XIII hinzu. Leider half dies allerdings noch nicht. Eine alte Windows-Wahrheit bewahrheitete sich mal wieder. Egal was du umstellst und egal was Windows sagt, anschließend immer Neustarten. Nach einem Neustart allerdings konnte ich XIII endlich genießen. Ärgerlich, hätte ich XIII bei seinem erscheinen gespielt hätte ich auf meiner damaligen CPU (AMD 1400) diese Problem nicht gehabt, jetzt wo es schon alle möglichen Patches für XIII gab hat mich dann meine Hardware dran gehindert. Eigentlich sollte es ja andersrum sein ;).

Drupal rockt

2007-02-18T20:02:04+01:00

Jetzt, da ich endlich mal wenigstens ein paar Minuten Zeit habe um mich um meine Webseite zu kümmern gefällt mir Drupal immer mehr.

Dank Apaches mod_rewrite haben die einzelnen Seiten nun lesbare Addressen und mit Drupals Alias-Funktion werden sie auch noch merkbar. Caching und RSS-Aggregation machen die Seit auch Sonntags und mit dem Konqueror über DSL besuchbar.

Auch für meine Lesezeichen habe ich nun eindlich eine eigene Seite. Leider habe ich noch kein Drupal-Modul gefunden mit dem ich die Lesezeichen gut verwalten kann, aber dank des sehr guten Drupal-Stylesheets kann ich sie immerhin auch mit lesbarem Sourcecode auf einer Seite gruppiert und zweispaltig anzeigen.

Marix World aktualisiert

2007-02-11T22:21:47+01:00

Nachdem ich lange Zeit leider keine Zeit hatte mehr als das nötigste auf meinem Server zu machen wurde jetzt endlich mal die Seite aktualisiert. Drupal wurde auf die aktuellste Version gebracht, dies ist leicht dadurch ersichtlich, dass die Seite jetzt einigermasen ansehlich aussieht. Auch habe ich endlich wieder mein traditionelles Seitenlogo in die Seite eingebaut, auch wenn es dringend nochmal überarbeitet werden muss. Der Eisbär sieht momentan doch etwas gerupft aus. Als nächste Schritte werde ich jetzt bei gelegenheit Anfangen eine Linksammlung aufzubauen und alle Programme die früher mal auf meiner Seite zu finden waren wieder hochzuladen.

Webdemo gegen Vorratsdatenspeicherung

2006-12-12T00:56:50+01:00

Der Arbeitskreis Vorratsdatenspeicherung ruft zum 14.12.2006 zu einem Protesttag gegen die Vorratsdatenspeicherung auf. Gemäß der beschlossenen EU-Richtlinie zur Vorratsdatenspeicherung, sollen alle Telekommunikationsgesellschaften und Internetprovider in den EU-Staaten verpflichtet werden, die Verkehrsdaten aller Telekommunikationsvorgänge und Internetnutzungen aller Kundinnen und Kunden für mindestens sechs und bis zu 24 Monate zu speichern. Ein Briefgeheimnis ist damit gibt es damit für elektronischen Datenverkehr nicht mehr. Hinzu kommt das bei den heute üblichen Flatrates eine Speicherung von Verbindungsdaten noch nicht einmal zu Abrechnungszwecken notwendig ist, weshalb sie bisher aus Datenschutzgründen nicht zulässig war. Generell ist zu bedenken, dass alle Daten die erst einmal gesammelt sind natürlich auch Interessenten anziehen.