Die Firefox Multi-Account Containers sind eine offizielle Erweiterung von Mozilla, die hoffentlich bald nativ im Browser eingebaut wird. Aufgabe ist die Trennung des Website-Speichers in Tab-spezifische Container, d.h. Cookies, die in einem Container vorhanden sind, sind in anderen Containern nicht verfügbar.

Im Gegensatz zur Funktionalität ist die Verwaltbarkeit leider alles andere als gelungen - in der aktuell verfügbaren Version können nur im Browser geöffnete Domains einer Umgebung hinzugefügt werden, das manuelle Hinzufügen einer Domain zu einer Umgebung ist nicht vorgesehen. Dies hat den Nachteil, daß bei allen Websites, welche mit Redirections arbeiten, die Multi-Account Containers nur eingeschränkt verwendet werden können.

Glücklicherweise kann hier mittels “about:debugging”, der Entwicklerwerkzeuge und der Javascript-Konsole Anbhilfe geschaffen werden. Das Vorgehen wurde von Philip Snowberger in “Another way to manually add another site to Firefox Multi-Account Containers” auf Github beschrieben:

Nach dem Starten des Debug-Modus wird zuerst das Objekt einer Domain ausgelesen, zu deren Umgebung eine weitere Domain hinzugefügt werden soll.

Im konkreten Beispiel soll die Domain “accounts.ebay.de” der Umgebung hinzugefügt werden, in der “www.ebay.de” bereits vorhanden ist:

obj = Object(await browser.storage.local.get("siteContainerMap@@_www.ebay.de"))

Dann wird eine Kopie der vorhandenen Einstellungen unter dem Zielnamen angelegt

obj["siteContainerMap@@_accounts.ebay.de"] = obj["siteContainerMap@@_www.ebay.de"]

und die ursprüngliche Domain aus dem ausgelesenen Objekt gelöscht:

delete obj['siteContainerMap@@_www.ebay.de']

Als letzter Schritt wird das Objekt zurückgeschrieben

await browser.storage.local.set(obj)

womit die Tab-Umgebung um die neue Domain erweitert wurde.

Beim Upgrade von Debian 11 (Bullseye) auf Debian 12 (Bookworm) wurde das komplette System wie vorgesehen aktualisiert, lediglich das Zammad-Paket zeigte in der Weboberfläche die falsche Version:

Dies ist Zammad Version 6.1.0-1700492762.96ac5a60.bullseye

Was auf auch ein Anzeigefehler in Zammad hätte sein können, wurde von dpkg bestätigt

$ dpkg -s zammad
...
Version: 6.1.0-1700492762.96ac5a60.bullseye
...

und apt zeigte keinerlei Motivation, das Paket zu aktualisieren.

$ sudo apt update
...
Alle Pakete sind aktuell.

Daß die eigentlich richtige Datei zur Installation zur Verfügung stand, bestätigte ein Aufruf von “apt-cache policy”

$ sudo apt-cache policy zammad
zammad:
  Installiert:           6.1.0-1700492762.96ac5a60.bullseye
  Installationskandidat: 6.1.0-1700492762.96ac5a60.bullseye
  Versionstabelle:
 *** 6.1.0-1700492762.96ac5a60.bullseye 100
        100 /var/lib/dpkg/status
     6.1.0-1700492762.96ac5a60.bookworm 500
        500 https://dl.packager.io/srv/deb/zammad/zammad/stable/debian 12/main amd64 Packages
...

Trotz offensichtlich verfügbarer Bookworm-Installationsdatei hielt apt die Bullseye-Version für geeigneter. Die Suche nach der Ursache bzw. deren Lösung führte zum Beitrag “Distupgrade debian buster to bullseye - zammad still shows buster version” im Zammad-Forum, der für das Upgrade von Bullseye auf Bookworm noch genauso gilt. Dort erklärt MrGeneration vom Zammad-Core-Team:

Due to the way our version numbers are generated, you end up in

6.0.0-1692176490.0e2399eb.buster
6.0.0-1692176490.0e2399eb.bullseye

those versions. Versioning is done alphabetical. So buster vs bullseye apart from the rest of the version string being the same is your issue.

Das gleiche Verhalten tritt auch hier auf: beim Vergleich der beiden Versionen “6.1.0-1700492762.96ac5a60.bullseye” und “6.1.0-1700492762.96ac5a60.bookworm” ist apt nach Vergleich der Versionsnummern der Meinung, daß “bullseye” neuer als “bookworm” ist und behält deshalb die Bullseye-Version, statt auf die Bookworm-Version zu aktualisieren. Dies kann man auch mit dpkg evaluieren:

$ dpkg --compare-versions 6.1.0-1700492762.96ac5a60.bookworm lt 6.1.0-1700492762.96ac5a60.bullseye && echo "älter"
älter

Die im oben verlinkten Beitrag vorgeschlagene Lösung eines “apt remove zammad” gefolgt vom einem “apt install zammad” ist zumindest im Fall des Upgrades von Bullseye auf Bookworm nicht notwendig, da Zammad auch in der Bullseye-Version problemlos arbeitet.

Mit der nächsten Änderung der tatsächlichen Versionsnummer wurde dann auch auch auf das Bookworm-Paket aktualisiert:

...
Preparing to unpack .../zammad_6.1.0-1701163867.5a81e629.bookworm_amd64.deb ...
Unpacking zammad (6.1.0-1701163867.5a81e629.bookworm) over (6.1.0-1700492762.96ac5a60.bullseye) ...
Setting up zammad (6.1.0-1701163867.5a81e629.bookworm) ...
...

Nach einem Fehler wärend der Cron-Ausführung liefen die Hintergrundjobs der Nextcloud-Instanz unauffällig, die Feeds der App “News” wurden allerdings nicht mehr aktualisiert. Der Strack-Trace des abgebrochenen Cron-Jobs meldete als letzten Eintrag

#6 /***/cron.php(158): OC\BackgroundJob\JobList->setLastJob(Object(OCA\News\Cron\UpdaterJob))
#7 {main}

In der Protokollierung der Nextcloud-Instanz waren keine auf die News-App bezogenen Fehlermeldungen enthalten. Ein manueller Cron-Aufruf lief ebenfalls ohne sichtbare Fehlermeldungen durch und Nextcloud meldete in den Grundeinstellungen

Die letzte Aufgabe lief vor einer Minute.

während sich die News-App über eine letzte Aufgaben-Ausführung vor 11 Stunden beschwerte.

Die Lösung war ein Reset des News-Jobs auf der Kommandozeile

$ php occ news:updater:job --reset

Nach dem Reset wurden die Feeds bei der nächsten Cron-Ausführung wieder ordnungsgemäß aktualisiert.

Nachdem der aktuelle Arbeits-PC inzwischen mehr als sechs Jahre alt ist wurde es Zeit, sich über einen Nachfolger Gedanken zu machen. Grundlegend stellt sich die Frage, ob ein klassischer PC im Tower-Gehäuse überhaupt noch zeitgemäß ist, denn im Gegensatz zu früheren Jahren übernimmt der Chipsatz die meisten Zusatzfunktionen und lediglich eine steckbare Graphikkarte bleibt als Argument für ein größeres Gehäuse.

Im bisherigen PC ist eine NVIDIA GeForce GTX 1050 Ti verbaut, eine Tatsache die ich seit dem Wechsel auf Linux gerne geändert hätte. Daß sinnvolle NVIDIA-Treiber nur als proprietäre Lösung verfügbar sind ist eine Sache, weit ärgerlicher ist aber, daß diese nur den veralteten X-Server unterstützen und nicht das deutlich modernere Wayland Display-Server-Protokoll.

Passend zu den Überlegungen erschien im Laufe des Jahres der c’t Bauvorschlag: Ryzen-Mini-PC, der die Blaupause für den neuen PC lieferte. Auf Bildern sind Größen meist schlecht einzuschätzen, vor allem ohne Vergleich. Freundlicherweise hat sich Harumi für einen Fototermin eingefunden und vor dem Gerät posiert.

Weiterlesen

Die Oberfläche von Thunderbird 115 “Supernova” ist nicht unumstritten, die Modernisierung war m.E. aber längst überfällig. Leider funktionieren mit der neuen Version einige liebgewonnene Plugins nicht mehr, so auch das von mir bisher eingesetzte Manually Sort Folders.

Während die Arbeit an einer Anpassung des Plugins im Gange ist, kann man sich mit einem im Github-Thread “Please update for Thunderbird 115” geposteten Workarounds behelfen:

Über die Datei “userChrome.css” kann das Design angepasst und somit auch durch das Hinzufügen einiger Anweisungen die Ordnerliste sortiert werden:

#folderTree ul {
	display: grid;
}

#folderTree li[title~='GanzVorne,'], #folderTree li[title='GanzVorne'] {
	order: 1;
}

...

#folderTree li[title~='GanzHinten,'], #folderTree li[title='GanzHinten'] {
	order: 99;
}

Nachdem mit der ersten Anweisung die Ordnerliste auf den Typ “grid” geändert wurde, kann mit Hilfe weiterer Anweisungen anhand des Ordnernamens (im Beispiel “GanzVorne” und “GanzHinten”) eine Reihenfolge für die Darstellung der Ordner festgelegt werden.