WordPress bietet standardmäßig keine Möglichkeit, einen Kommentar zwischen verschiedenenen Beiträgen zu verschieben. Das Vorgehen hierbei ist aber recht ähnlich dem Verschieben aller Kommentare.

Zunächt müssen die IDs der beiden Beiträge ermittelt werden, zwischen denen verschoben werden soll sowie die ID des zu verschiebenden Kommentars. Wer das nicht direkt in der Datenbank erledigen will, kann die WordPress-Oberfläche zu Rate ziehen: einfach beim jeweiligen Artikel bzw. Kommentar auf “Bearbeiten” klicken und die ID aus der URL entnehmen, z.B. “/wp-admin/post.php?post=4392&action=edit” und “/wp-admin/comment.php?action=editcomment&c=6493”.

Dann kann der Kommentar verschoben werden:

Anschließend muß noch die Anzahl der zu den Beiträgen vorhandenen Kommentare korrigiert werden, was mit zwei weiteren SQL-Befehlen erledig ist:

Gerade wenn es darum geht, daß nur ein Delta kopiert werden soll, ist rsync (gegenüber z.B. cp) mein Werkzeug der Wahl. Umso erstaunter war ich daß rsync bei einem

immer wieder alle Dateien neu auf den USB-Stick kopierte, auch wenn zwischenzeitlich an der Quelle keine Änderungen vorgenommen wurden.

Einen ersten Hinweis auf die Ursache liefert der Beitrag “rsync to USB flash drive always transferring all data” bei Stack Exchange, denn der Stick war tatsächlich mit exFAT formatiert.

Eine Suche nach Hintergrundinformationen führte zum Microsoft Dev Blog-Beitrag “Why does the timestamp of a file increase by up to 2 seconds when I copy it to a USB thumb drive?”

This means that copying a file to a FAT-formatted device (typically a floppy drive or a USB thumb drive) can increase the timestamp by up two seconds.

in dem die Erklärung, warum immer aufgerundet wird, gleich mitgeliefert wird:

To avoid this infinite loop, the convention is always to round up, so that the copy of a file is never older than the original.

Zumindest der referenzierte Knowledge Base-Artikel “KB127830 - Time Stamps Change When Copying From NTFS to FAT” ist über die WaybackMachine des Internet Archive noch zu finden und erklärt den Mechanismus:

File time stamps on FAT drives are rounded to the nearest twoseconds (even number) when the file is written to the drive. The file timestamps on NTFS drives are rounded to the nearest 100 nanoseconds when thefile is written to the drive. Consequently, file time stamps on FAT drivesalways end with an even number of seconds, while file time stamps on NTFSdrives can end with either even or odd number of seconds.

When files are copied from NTFS drives to FAT drives, somefile time stamp rounding has to occur; the file time stamp is rounded up to the next even second.

Auch wenn sich das Beispiel auf NTFS vs. FAT bezieht, gilt das gleiche auch im Hinblick auf ext4 und FAT. Abhilfe schafft der Parameter “–modify-window” auf den auch die rsync-FAQ hinweist:

Another common cause involves sending files to an Microsoft filesystem: if the file’s modified time is an odd value but the receiving filesystem can only store even values, then rsync will re-transfer too many files. You can avoid this by specifying the –modify-window=1 option.

Mit dem Aufruf

lässt sich rsync von der Rundung nicht mehr aus der Ruhe bringen und verhält sich wie erwartet.

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.

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:

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:

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.

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

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:

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.

Anschließend müssen die geänderten Konfigurationsdateien noch eingelesen und die Timer neu gestartet werden:

Der Status der Einplanung lässt sich mittels “systemctl” einsehen

Was unattended-upgrades tatsächlich so angestellt hat, lässt sich auch mit Hilfe von “journalctl” auswerten:

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”:

Die benötigten Angaben kann man direkt aus der Debugausgabe entnehmen

und die Zeile dann der Sektion “Unattended-Upgrade::Origins-Pattern” hinzufügen:

Anschließend wird Zammad wie geplant aktualisiert: