WordPress-Kommentar zu einem anderen Beitrag verschieben

16. März 2025 · Anwendungen · andreas · Kein Kommentar

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:

	UPDATE wp_comments SET comment_post_ID = <ID_neuer_Beitrag> WHERE comment_ID = <ID_Kommentar>;

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

	UPDATE wp_posts SET comment_count = (SELECT COUNT(*) FROM wp_comments WHERE comment_post_ID = <ID_alter_Beitrag> AND comment_approved = 1) WHERE ID = <ID_alter_Beitrag>;
UPDATE wp_posts SET comment_count = (SELECT COUNT(*) FROM wp_comments WHERE comment_post_ID = <ID_neuer_Beitrag> AND comment_approved = 1) WHERE ID = <ID_neuer_Beitrag>;

rsync kopiert immer wieder alle Dateien neu auf USB-Stick

01. März 2025 · Anwendungen · andreas · Kein Kommentar

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

# rsync -av /meine-quelle /mnt/stick/

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

# rsync -av --modify-window=1 /meine-quelle /mnt/stick/

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

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”

Needrestart in Checkmk einbinden

02. Juli 2024 · Anwendungen · andreas · Kein Kommentar

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:

	# needrestart -p
OK - Kernel: 6.1.0-22-amd64, Services: none, Containers: none, Sessions: none|Kernel=0;0;;0;2 Services=0;;0;0 Containers=0;;0;0 Sessions=0;0;;0

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.

	#!/usr/bin/bash
NEEDRESTART="$(/usr/sbin/needrestart -p)"
if [[ "$NEEDRESTART" =~ ^OK ]]; then
        STATE=0
elif [[ "$NEEDRESTART" =~ ^WARN ]]; then
        STATE=1
elif [[ "$NEEDRESTART" =~ ^CRIT ]]; then
        STATE=2
else
        STATE=3
fi
echo "$STATE \"needrestart\" - $NEEDRESTART"

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.

ALSA kann auch Gerätenamen

25. Juni 2024 · Anwendungen · andreas · Kein Kommentar

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

	$ cat /proc/asound/cards

 0 [Headphones     ]: bcm2835_headpho - bcm2835 Headphones
                      bcm2835 Headphones
 1 [PMA50          ]: USB-Audio - PMA-50
                      D & M Holdings Inc. PMA-50 at usb-3f980000.usb-1.1.3, high speed
 2 [vc4hdmi        ]: vc4-hdmi - vc4-hdmi
                      vc4-hdmi

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.

/etc/asound.conf
pcm.!default {
    type hw
    card 1
}

ctl.!default {
    type hw
    card 1
}

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

	$ ls -l /proc/asound/

dr-xr-xr-x 4 root root 0 25. Jun 08:42 card0
dr-xr-xr-x 4 root root 0 25. Jun 08:42 card1
dr-xr-xr-x 8 root root 0 25. Jun 08:42 card2
...
lrwxrwxrwx 1 root root 5 25. Jun 08:42 Headphones -> card0
...
lrwxrwxrwx 1 root root 5 25. Jun 08:42 PMA50 -> card2
...
lrwxrwxrwx 1 root root 5 25. Jun 08:42 vc4hdmi -> card1
...

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

/etc/asound.conf
pcm.!default {
    type hw
    card PMA50
}

ctl.!default {
    type hw
    card PMA50
}