Technik

Portable Perl-Skripte unter Windows

15. Dezember 2024 · Programmierung · andreas · Kein Kommentar

Um ein Perl-Skript portabel zu machen, muß zusammen mit dem Skript auch die Perl Laufzeitumgebung sowie die benötigten Bibliotheken ausgeliefert werden.

Befragt man die Suchmaschine der Wahl, landet man meist bei der Empfehlung, einen Perl-Packer zu nehmen, von denen es im CPAN zwei Stück gibt: PAR-Packer und perlcc, wobei von der Verwendung von perlcc im produktiven Umfeld ganz klar abgeraten wird: “Use for production purposes is strongly discouraged.”.

Mit pp gibt es ein eigenes Skript, auf Basis von PAR ausführbare Dateien erzeugt und ein Skript mitsamt aller benötigter Bibliotheken in einer einzelnen .EXE-Datei verpackt.

Das Packen ist recht flexibel und schnell erledigt, die einzelnen Optionen können in der Dokumentation nachgeschlagen werden.

pp -o test.exe --gui --addfile=test.ini --addfile=test.ico test.pl -T test

Wer noch gerne ein schöne(re)s Icon für die erzeugte .EXE-Datei verwenden möchte, kann dies mit einem Einzeler hinzufügen:

perl -e "use Win32::Exe; $exe = Win32::Exe->new('test.exe'); $exe->set_single_group_icon('test.ico'); $exe->write;"

Als Ergebnis wird eine Datei “test.exe” erzeugt, die dann auf ein System ohne Perl-Laufzeitumgebung kopiert und dort ausgeführt werden kann. Die Beschreibung “perlcc that works without hassle” klingt erstmal gut und die Ergebnisse funktionieren, bringen aber leider in der Anwendung einige Probleme mit sich:

Technisch gesehen wandelt pp nicht wirklich das Skript in eine .EXE-Datei, sondern erzeugt ein selbstenpackendes Archiv, dessen Inhalt nach dem Entpacken letztendlich ausgeführt wird. Das Archiv wird standardmäßig ins TEMP-Verzeichnis des ausführenden Benutzers entpackt, was spätestens dann zu Problemen führt, wenn - aus guten Grund - unprivilegierten Benutzern das Ausführen von Code innerhalb des TEMP-Verzeichnis verboten ist.

Zum Entpacken wird ein Verzeichnis nach dem Muster “%TEMP%\par-USER\cache-GUID” angelegt, wobei USER durch eine Hex-Repräsentation des ausführenden Benutzers und GUID durch einen Hash der ausführbaren Datei ersetzt wird. Letzteres lässt sich mit Hilfe des Parameters “-T” durch einen festen Wert ersetzten, so daß der Pfad dann “%TEMP%\par-USER\cache-test” lautet.

Durch das Cachen der entpackten Dateien wird bei späteren Starts die Wartezeit deutlich verkürzt, je nach System und Anzahl der Benutzer können aber zahlreiche Dateileichen im Temp-Verzeichnis verbleiben.

Manuelle Paketierung

Abgesehen von der suboptimalen Ausführung erledigt pp das Sammeln aller benötigter Dateien sowie Erstellen des Pakets zuverlässig, so daß sich die Verwendung von pp als Zwischenschritt zum manuellen Packen anbietet.

Nach dem erstmaligen Ausführen der von pp erzeugten Datei werden folgende Inhalte des Verzeichnisses “%TEMP%\par-USER\cache-test” in ein Arbeitsverzeichnis kopiert:

  • der komplette Ordner “inc” inklusive aller darin enthaltenen Unterverzeichnisse
  • die Dateien “libgcc_s_seh-1.dll”, “libstdc++-6.dll”, “libwinpthread-1.dll” sowie “perl530.dll”

Anschließend kann noch etwas augeräumt werden:

  • im Ordner “inc” können die Dateien “MANIFEST” sowie “META.yml” gelöscht werden
  • im Ordner “inc/script” kann die Datei “main.pl” gelöscht werden

Zum Ausführen müssen aus der Perl-Installation noch zwei Dateien kopiert werden:

  • die Datei “perl.exe” oder “wperl.exe” aus dem Ordner “perl/bin” ins Arbeitsverzeichnis - je nachdem, ob es sich um eine Kommandozeilen- oder GUI-Anwendung handelt
  • die Datei “lib.pm” aus dem Ordner “perl/lib” in den Ordner “inc/lib”

Anschließend kann aus dem Ordner “inc” das Skript mit folgendem Aufruf gestartet werden:

..\perl.exe -I lib script\test.pl

Iron Maiden Legacy Of The Beast - Sunset Celebration

10. Dezember 2024 · Spiele · andreas · Kein Kommentar

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.

Legacy Of The Beast - Sunset Celebration

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.


unattended-upgrades

16. November 2024 · Betriebssysteme · andreas · 1 Kommentar

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.

/etc/apt/apt.conf.d/50unattended-upgrades
... 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

Anpassung Zeitsteuerung

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
/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
/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

Drittanbieterquellen

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:

/etc/apt/apt.conf.d/50unattended-upgrades
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 ...

Pebble 2 Seitenteile ersetzt

05. November 2024 · Hardware · andreas · Kein Kommentar

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.

Pebble 2

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.


aa-genprof meldet "ERROR: Include file /etc/apparmor.d/libvirt/libvirt-UUID.files not found"

29. Oktober 2024 · Anwendungen · andreas · Kein Kommentar

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:

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:

$ sudo touch "/etc/apparmor.d/libvirt/libvirt-UUID.files"

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:

$ 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.

UUID ist Platzhalter für die UUID der jeweiligen virutellen Maschine, also z.B. “libvirt-a47d1fb1-22f7-467d-ad14-36242f971df4”