Am 02. Dezember wurde mehr oder minder überraschend mitgeteilt, daß das offizielle Iron Maiden-Spiel “Legacy Of The Beast” zum Jahresende 2024 eingestellt und die Server heruntergefahren werden.
Bis dahin kann im Rahmen der Sunset Celebration vieles ausprobiert werden, was bisher mühevoll erarbeitet werden wollte: Drop-Rates wurden erhöht, Kosten verringert und alle Echtgeld-Angebote aus dem Shop entfernt.
In der Vergangenheit habe ich Server so konfiguriert, daß Updates automatisiert über cron-apt heruntergeladen und installiert wurden. Seit der Einführung von systemd steht mit den uattended-upgrades eine weitere Möglichkeit zur Verfügung, welche eine detailliertere Konfiguration erlaubt.
$ sudo apt-get install unattended-upgrades
Die Grundkonfiguration erfolgt über die Datei “/etc/apt/apt.conf.d/50unattended-upgrades”, in der nach erfolgter Installation zumindest die Parameter “Unattended-Upgrade::Mail” sowie “Unattended-Upgrade::MailReport” angepasst werden sollten.
...
Unattended-Upgrade::Mail "an.wen.auch.immer@wo.auch.immer";
...
Unattended-Upgrade::MailReport "always";
...
“Unattended-Upgrade::MailReport” kann nach erfolgreicher Testphase auch wieder zurück auf den Default-Wert “on-change” gestellt werden, falls das tägliche “es gab nix zu tun” nervt.
Um die Funktionalität zu aktivieren, kann entweder die Datei “/etc/apt/apt.conf.d/20auto-upgrades” manuell angepasst oder “dpkg-reconfigure” verwendet werden. Nach dem Aufruf von
$ sudo dpkg-reconfigure unattended-upgrades
die Frage “Aktualisierungen für Stable automatisch herunterladen und installieren?” mit “ja” beantworten.
Für einen Testlauf kann “unattended-upgrade” mit dem Parameter “-d” für Debug manuell gestartet werden:
$ sudo unattended-upgrade -d
Der Zeitpunkt, zu dem das Herunterladen bzw. Installieren tatsächlich durchgeführt wird, lässt sich über zwei Overrides definieren. Wichtig ist hierbei, im ersten Schritt mit “OnCalendar=” erst einmal bestehende Einträge zu löschen, bevor dann die eigenen Werte gesetzt werden - sonst werden die angegebenen Werte zusätlich übernommen.
$ sudo mkdir /etc/systemd/system/apt-daily.timer.d
$ sudo vi /etc/systemd/system/apt-daily.timer.d/override.conf
[Timer]
OnCalendar=
OnCalendar=04:00
RandomizedDelaySec=0
$ sudo mkdir /etc/systemd/system/apt-daily-upgrade.timer.d
$ sudo vi /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
[Timer]
OnCalendar=
OnCalendar=05:00
RandomizedDelaySec=0
Anschließend müssen die geänderten Konfigurationsdateien noch eingelesen und die Timer neu gestartet werden:
$ sudo systemctl daemon-reload
$ sudo systemctl restart apt-daily.timer
$ sudo systemctl restart apt-daily-upgrade.timer
Der Status der Einplanung lässt sich mittels “systemctl” einsehen
$ sudo systemctl status apt-daily.timer
● apt-daily.timer - Daily apt download activities
Loaded: loaded (/lib/systemd/system/apt-daily.timer; enabled; preset: enabled)
Drop-In: /etc/systemd/system/apt-daily.timer.d
└─override.conf
Active: active (waiting) since Tue 2024-09-17 11:29:25 CEST; 46s ago
Trigger: Wed 2024-09-18 04:00:00 CEST; 16h left
Triggers: ● apt-daily.service
$ sudo systemctl status apt-daily-upgrade.timer
● apt-daily-upgrade.timer - Daily apt upgrade and clean activities
Loaded: loaded (/lib/systemd/system/apt-daily-upgrade.timer; enabled; preset: enabled)
Drop-In: /etc/systemd/system/apt-daily-upgrade.timer.d
└─override.conf
Active: active (waiting) since Tue 2024-09-17 11:29:33 CEST; 53s ago
Trigger: Wed 2024-09-18 05:00:00 CEST; 17h left
Triggers: ● apt-daily-upgrade.service
Was unattended-upgrades tatsächlich so angestellt hat, lässt sich auch mit Hilfe von “journalctl” auswerten:
$ sudo journalctl --since yesterday -u apt-daily.service
$ sudo journalctl --since yesterday -u apt-daily-upgrade.service
In der Standardkonfiguration aktualisiert unattended-upgrades nur die vom System bereitgestellten Quellen, alle weiteren Quellen müssen in der Datei “/etc/apt/apt.conf.d/50unattended-upgrades” noch hinzugefügt werden. Dies sieht man im Debug-Modus hier auch am Beispiel von “zammad”:
$ sudo unattended-upgrade -d | grep zammad
Marking not allowed <apt_pkg.PackageFile object: filename:'/var/lib/apt/lists/dl.packager.io_srv_deb_zammad_zammad_stable_debian_dists_12_main_binary-amd64_Packages' a=,c=main,v=,o=https://packager.io/gh/zammad/zammad,l=Debian 12 packages for zammad/zammad arch='amd64' site='dl.packager.io' IndexType='Debian Package Index' Size=56880 ID:33> with -32768 pin
Applying pin -32768 to package_file: <apt_pkg.PackageFile object: filename:'/var/lib/apt/lists/dl.packager.io_srv_deb_zammad_zammad_stable_debian_dists_12_main_binary-amd64_Packages' a=,c=main,v=,o=https://packager.io/gh/zammad/zammad,l=Debian 12 packages for zammad/zammad arch='amd64' site='dl.packager.io' IndexType='Debian Package Index' Size=56880 ID:33>
Checking: zammad ([<Origin component:'main' archive:'' origin:'https://packager.io/gh/zammad/zammad' label:'Debian 12 packages for zammad/zammad' site:'dl.packager.io' isTrusted:True>])
adjusting candidate version: zammad=6.3.1-1726553725.106af4c8.bookworm
Package zammad has a higher version available, checking if it is from an allowed origin and is not pinned down.
Die benötigten Angaben kann man direkt aus der Debugausgabe entnehmen
"origin=https://packager.io/gh/zammad/zammad,component=main,label=Debian 12 packages for zammad/zammad"
und die Zeile dann der Sektion “Unattended-Upgrade::Origins-Pattern” hinzufügen:
Unattended-Upgrade::Origins-Pattern {
...
"origin=https://packager.io/gh/zammad/zammad,component=main,label=Debian 12 packages for zammad/zammad";
...
};
Anschließend wird Zammad wie geplant aktualisiert:
$ sudo unattended-upgrade -d | grep zammad
Erlaubte Ursprünge sind: origin=Debian,codename=bookworm,label=Debian, origin=Debian,codename=bookworm,label=Debian-Security, origin=Debian,codename=bookworm-security,label=Debian-Security, origin=https://packager.io/gh/zammad/zammad,component=main,label=Debian 12 packages for zammad/zammad
Checking: zammad ([<Origin component:'main' archive:'' origin:'https://packager.io/gh/zammad/zammad' label:'Debian 12 packages for zammad/zammad' site:'dl.packager.io' isTrusted:True>])
pkgs that look like they should be upgraded: zammad
...
Pakete, welche aktualisiert werden: zammad
...
zammad (6.3.1-1726721589.817498f6.bookworm) wird eingerichtet ...
Ich habe ein Paar Ersatz-Seitenteile für meine Pebble 2 bestellt und montiert. Die Uhr war im defekten Zustand sowieso nicht mehr verwendbar und das finanzielle Risiko hielt sich mit der Anschaffung der beiden Seitenteile in Grenzen.
Der Umbau hat mit Hilfe der detaillierten Anleitung gut funktioniert. Meine Pebble ist ein Gehäusetyp “B”, so daß das Zurechtfeilen der Kanten glücklicherweise entfallen konnte.
Als Kleber habe ich wie vorgeschlagen den nächstbesten “B7000 Universal Kleber” verwendet, wobei ich ein bißchen zu viel aufgetragen habe. Beim anschließenden Reinigen des Überschusses habe ich die schwarze Lackierung der Tasten erst versehentlich teilweise und anschließend absichtlich komplett entfernt. Passt eigentlich ganz gut zur Uhr und auch das Versprechen eines “satisfying clicks” wurde gehalten: die mechanischen Ersatztasten haben tatsächlich ein besseres Druckgefühl als die originalen Silikontasten.
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:
#include <libvirt/libvirt-UUID.files>
Zur Lösung gibt es zwei Ansätze, die beide in der Vergangenheit zu keinen Komplikationen geführt haben:
Um den Fehler zu beheben, kann z.B. über das “touch”-Kommando eine leere Datei mit dem gesuchten Namen erzeugt werden:
$ sudo touch "/etc/apparmor.d/libvirt/libvirt-UUID.files"
Somit ist die Include-Bedingung erfüllt und aa-genprof startet ohne Fehlermeldung.
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:
$ sudo rm "/etc/apparmor.d/libvirt/libvirt-*"
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.
Eigentlich sollte an dieser Stelle ein detaillierter Blick auf “Encased: A Sci-Fi Post-Apocalyptic RPG” stehen, aber letztendlich waren es (mal wieder) technische Unzulänglichkeiten, welche den Spielspaß nicht nur getrübt, sondern das Erreichen des Spielendes beinahe erfolgreich verhindert hätten.
Encased ist - kurz zusammengefasst
“A very good RPG in the spirit of Fallout (1, 2)” [Quelle]
oder wie Peter Bathge bei “Gamestar” schrieb
A Sci-Fi Post-Apocalyptic RPG lautet der Untertitel und stellt damit die Weichen für die Erwartungshaltung des unbedarften Spielers. Nach dem Test hätte ich jetzt aber einen passenderen Untertitel für Encased: »Das Fallout-Wasteland, das ich immer wollte … [Quelle]
Den ersten Fehler findet man leider schon nach einer ersten Proberunde - man kann das Spiel nämlich nicht regulär verlassen. Klickt man im Menü auf “Exit” passiert exakt nichts, außer daß sich das Spiel in eine Endlosschleife begibt. Der Fehler wurde u.a. im Oktober 2022 unter “Trying to Exit Freezes the Game” im GOG Forum dokumentiert und offensichtlich nie behoben. Glücklicherweise fragt irgendwann GNOME von selbst, ob man den Prozess manuell beenden möchte, alternativ kann auch ein thematisch passender “kill”-Befehl an der Kommandozeile abgesetzt werden.
Innerhalb der einzelnen Orte läuft Encased stabil - bis man versucht, einen anderen Ort oder die Weltkarte zu betreten. Hier kommt es gefühlt in rund einem Zehntel aller Wechsel zu einem Absturz und der Spieler landet unerwartet auf dem Desktop. Dieses Problem ist nervig, aber leicht abzumildern und man gewöhnt sich im Laufe des Spielens daran, vor jedem Ortswechsel sicherheitshalber mit “F5” eine Schnellspeicherung vorzunehmen. Abstürze scheinen bei Encased aber generell bei vielen Spielern aufzutreten, wie eine Suche über die Foren bei Steam zeigt.
Absolut frustrierend ist aber, daß das Spiel kurz vor dem Epilog reproduzierbar an der gleichen Stelle abstürzt, was auf Reddit im Beitrag “Game crashes every time I try to descend to the landing pad at Concord” und auch bei Steam unter “Possible Linux crash solution” dokumentiert wurde. Dort ist auch ein potentieller Workaround zu finden - zusammen mit der Frage
I now wonder if all the crahes I encountered playing through the game would have not happened if I had used that option from the beginning. [Quelle]
Tatsächlich kann man - wie bei Reddit beschrieben - mit der Windows-Version problemlos den Ortswechsel zum Landing Pad vollziehen, den Workaround mit dem Kommandozeilenparameter habe ich erst im Nachgang gefunden.
Schade, eigentlich hätte ich gerne eine weitere Runde in der Welt gedreht und ein paar alternative Handlungsoptionen ausprobiert - so wurde das Spiel nach dem Epilog und anschließendem erneutem Crash stattdessen direkt deinstalliert und die Gamestar-Überschrift “Das Rollenspiel, das ihr euren Freunden empfehlen werdet” trifft zumindest für mich nicht zu.
Daß Software Fehler hat ist leider unumgänglich und daß noch so viele Tests nicht alle Fehler aufdecken können leider auch. Wenn aber schwerwiegende und reproduzierbare Fehler nicht behoben werden, dann ist das aus Spielersicht nicht nur ärgerlich, sondern dem Käufer gegenüber schlicht eine Unverschämtheit.