Beim Start einer virtuellen Maschine wird normalerweise mit Hilfe von virt-aa-helper - je nach Bedarf - entweder ein neues Apparmor-Profil erzeugt oder ein bestehendes Profil für die zu startende Maschine modifiziert:

When a VM/container is started, libvirtd decides whether to ask virt-aa-helper to create a new profile or modify an existing one. [Quelle]

Beim Stoppen der virtuellen Maschine sollte das Profil dann auch wieder entfernt werden:

When the VM/container is shutdown, libvirtd asks virt-aa-helper to remove the profile, and virt-aa-helper unloads the profile from the kernel [Quelle]

Leider scheint virt-aa-helper beim Aufräumen aber schlampig zu arbeiten, denn während die Datei “libvirt-UUID.files” tatsächlich mit dem Stoppen der virtuellen Maschine aus dem Verzeichnis “/etc/apparmor.d/libvirt/” verschwindet, verbleibt die Datei “libvirt-UUID” dort weiterhin.

Über genau diesen Schiefstand stoplert aa-genprof beim Start, denn in “libvirt-UUID” ist ein Verweis auf die Datei “libvirt-UUID.files” enthalten, die aber nicht mehr existiert:

Zur Lösung gibt es zwei Ansätze, die beide in der Vergangenheit zu keinen Komplikationen geführt haben:

Erzeugen der fehlenden Datei

Um den Fehler zu beheben, kann z.B. über das “touch”-Kommando eine leere Datei mit dem gesuchten Namen erzeugt werden:

Somit ist die Include-Bedingung erfüllt und aa-genprof startet ohne Fehlermeldung.

Entfernen der vorhandenen Profilreste

Da beim nächsten Start der virtuellen Maschine bei Bedarf sowieso ein neues Profil angelegt wird, ist es auch gefahrlos möglich, die noch vorhandenen Profildateien zu entfernen:

Es sollte allerdings darauf geachtet werden, den Ordner nicht komplett zu leeren oder gar zu löschen, da die darin enthaltenen Template-Dateien (“TEMPLATE.lxc” bzw “TEMPLATE.qemu”) werden von virt-aa-helper als Vorlage zum Erstellen neuer Profile verwendet.

Mit needrestart gibt es für Lunix-basierte Hosts eine Anwendung, die sich in den dpkg,- rpm- oder pacman-Mechanismus einklinkt und nach einer Aktualisierung des Systems mitteilt, ob und welche Systemkomponenten einen Neustart benötigen.

Neben zahlreichen Konfigurationsmöglichkeiten bietet needrestart auch einen Nagios-kompatiblen Ausgabemodus zur Einbindung in das Monitoring-System:

Checkmk ist in der Lage, über MRPE auch Nagios-kompatible Skripte zu verwenden, allerdings geht es auch einfacher mit Hilfe eines Local Checks:

A local check can be written in any programming language supported by the target host. The script must be constructed so that each check produces a status line consisting of four parts. Here is an example:

0 “My service” myvalue=73 My output text which may contain spaces

Die Skripte werden im Verzeichnis “/usr/lib/check_mk_agent/local/” abgelegt und automatisch vom Agenten mitverarbeitet.

Für needrestart reicht ein kleiner Wrapper, der das Ergebnis des Checks in einen numerischen Status wandelt und die Meldung selbst als Statusdetail ausgibt. Der Dienstname wird auf “needrestart” gesetzt und auf die Übermittlung von Metriken verzichtet.

Nachdem das Skript angelegt und ausführbar gemacht wurde, muß auf dem Host nur noch ein Service-Discovery durchgeführt werden damit der neue Service übernommen werden kann.

Auf einem Raspberry Pi hatte ich das Problem, daß ALSA bei jedem Neustart des Systems die Reihenfolge der Ausgabegeräte neu sortierte:

Mal war der PMA-50 als Karte 1 verfügbar, mal wurde ihm die 2 zugewiesen und als Folge daraus war das in der “alsa.conf” festgelegte Ausgabegerät nicht immer das von mir eigentlich gewünschte und der externe DAC blieb stumm.

ALSA kann statt der Nummer der Karte (wie in gefühlt 99% aller Beispiele zu finden) auch deren Namen verwenden werden. Eine Liste aller gültigen Geräte findet sich unter “/proc/asound/”:

Nach einer Anpassung der “alsa.conf” funktioniert der USB-DAC unabhängig von der zugewiesenen Gerätenummer:

In den letzten Tagen sorgte eine Änderung am “KeepassXC"-Paket in Debian für hitzige Diskussionen.

Der grundlegende Gedanke, ein Paket mit minimalem und ein Paket mit vollständigem Funktionsumfang anzubieten ist hierbei nicht ungewöhnlich: eine solche Aufspaltung gibt es bis hin zu den Desktop-Umgebungen, wo z.B. bei der Installation zwischen einem “gnome” und einem “gnome-core"-Paket gewählt werden kann, welches nur den minimal notwendigen Umfang zu Betrieb der Desktopumgebung enthält.

Was allerdings nicht nur mir unangenehm aufstößt ist die Vorgehensweise des Paketbetreuers, der statt der Erstellung eines zusätzlichen “keepassxc-core”-Pakets das ursprüngliche “keepassxc”-Paket um bestehende Funktionalität erleichtert und somit bestehende Installationen mit der nächsten Aktualisierung beschneidet.

Dies ist offensichtlich ohne vorherigen Dialog mit den KeepassXC-Entwicklern geschehen und führt dazu, daß nun vermehrt Anwender bei KeepassXC (nicht vorhandene) Fehler melden, denn

This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there’s little that can be done about that. [Quelle]

Dieser Satz und vor allem eine Aussage wie

Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks. [Quelle]

lässt aber nicht unbedingt (nur) auf sachliche Hintergründe schließen, sondern zeigt deutlich, wo das eigentliche Problem liegt - und erinnert mich von der Grundeinstellung an den Münchner OB Dieter Reiter.

In einem Verzeichnis auf der lokalen Festplatte schlummerten noch ein paar Uralt-Mails, welche alle als einzelne Textdateien gespeichert waren. Leider bietet Thunderbird keine Möglichkeit, über die Oberfläche einen Importvorgang anzustoßen, aber es geht auch recht einfach durch die Hintertür.

In der Oberfläche wird in den “Lokalen Ordnern” mittels Rechsklick ein neuer Ordner “GanzalteMails” angelegt. Dies bewirkt, daß im Profilverzeichnis ("~/.thunderbird/PROFILNAME/Mail/Local Folders/") zwei Dateien “GanzalteMails” und “GanzalteMails.msf” erzeugt werden. In diesem Ordner wird auf Dateisystemebene nun händisch ein neuer Unterordner “GanzalteMails.sbd” erzeugt, in welchen die Textdateien kopiert werden.

Damit Thunderbird die Texte auch tatsächlich als Mailbox-Files erkennt, ist es wichtig, daß jede Datei - wie in RFC 4155 “The application/mbox Media Type” beschrieben - mit einem korrekten Vorspann beginnt:

mbox database files can be recognized by having a leading character sequence of “From”, followed by a single Space character (0x20), followed by additional printable character data

Was genau nach dem Leerzeichen kommen muß, kann sich zwischen verschiedenen Anwendungen unterscheiden, weshalb die meisten Mailclients fast alles akzeptieren, was auch nur halbwegs standardkonform aussieht. Thunderbird genügt z.B. ein

als Kennzeichnung. Wer dies einfach und komfortabel an den Anfang aller “*.txt”-Dateien einfügen möchte, kann sed als Werkzeug verwenden: