Probleme mit rsync bei der Kompression über SSH

Ich nutze rsync in Verbindung mit dem rsync-time-backup für einfache Backups eines Servers. In letzter Zeit erhielt ich dort ein Problem mit bestimmten Dateien, welche ich synchronisieren wollte. rsync brach hier mit der Meldung:

deflate on token returned 0 (32765 bytes left)

ab. Abhilfe schaffte es hier rsync, ohne die Option –compress zu nutzen. Hier liegt wohl ein Problem bzw. ein Bug vor, der unter Umständen zu diesem Verhalten führt. Da rsync-time-backup diese Option bei einem Backup über SSH automatisch hinzufügt, habe ich die entsprechende Zeile:

RSYNC_FLAGS="$RSYNC_FLAGS --compress"

auskommentiert. Damit funktionierte der entsprechende Synchronisierungsvorgang wieder ohne Probleme. Einziger Nachteil war die erhöhte Laufzeit der Synchronisierung, da nun mehr Daten über die Leitung gesendet werden.

WordPress CLI installieren und nutzen

Für das Content-Management-System WordPress existiert neben dem eigentlichen System auch eine separate Kommandozeile. Die hört auf den Namen WP-CLI und muss im ersten Schritt installiert werden:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp

Damit ist die WP-CLI installiert und kann über das Kommando:

wp --info

getestet werden. Um WP-CLI aktuell zu halten, kann das Kommando:

wp cli update

genutzt werden.

Grundsätzlich sollten die Befehle der WP-CLI im Kontext des Webserver-Nutzers ausgeführt werden. In den meisten Fällen ist dies www-data. Eine Ausnahme bilden die Befehle zur Installation und zur Aktualisierung. Wird versucht ein WP-CLI-Befehl unter dem root-Nutzer auszuführen, so erhält der Nutzer folgende Meldung:

Error: YIKES! It looks like you’re running this as root. You probably meant to run this as the user that your WordPress installation exists under.

If you REALLY mean to run this as root, we won’t stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.

If you’d like to continue as root, please run this again, adding this flag: –allow-root

If you’d like to run it as the user that this site is under, you can run the following to become the respective user:

sudo -u USER -i — wp

Per sudo mit dem korrekten Nutzer ausgeführt funktioniert das Ganze:

sudo -u www-data wp transient delete --all
Success: 163 transients deleted from the database.

Mittels der WP-CLI lassen sich eine Reihe von Aufgaben bewerkstelligen. So verfügt die CLI über Methoden, um Kommentare zu erzeugen und zu verwalten. Mit dem Befehl:

wp comment delete $(wp comment list --status=spam --format=ids)

können z.B. alle Spam-Kommentare gelöscht werden. Über den core-Namespace können unter anderem WordPress-Updates vorgenommen werden:

wp core update

Vor allem im Zusammenhang mit einer Automation spielt WP-CLI seine Stärken aus. So können neue WordPress-Installationen angelegt werden und entsprechende Plugins automatisch installiert werden. In der Entwickler-Dokumentation von WordPress findet sich eine Referenz der Befehle der WP-CLI.

Entwickelt wird WP-CLI auf Github. Lizenziert ist das CLI unter der MIT-Lizenz und damit freie Software. Die offizielle Seite des Projektes ist unter wp-cli.org zu finden.

RAID-Synchronisation unter Ubuntu beschleunigen

Wenn ein Ubuntu-Server mit einem Software-RAID betrieben wird, so kann der Status des RAIDs über den Befehl:

cat /proc/mdstat

eingesehen werden. Eine entsprechende Ausgabe könnte dann wie folgt aussehen:

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sda2[0] sdb2[1]
      11714556864 blocks super 1.2 [2/2] [UU]
      bitmap: 6/88 pages [24KB], 65536KB chunk

md0 : active raid1 sda1[0] sdb1[1]
      4189184 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Wird ein RAID neu aufgebaut bzw. synchronisiert sieht die Ausgabe etwas ausführlicher aus:

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sda2[0] sdb2[1]
      11714556864 blocks super 1.2 [2/2] [UU]
      [==================>..]  resync = 94.6% (11088768000/11714556864) finish=153.3min speed=67991K/sec
      bitmap: 12/88 pages [48KB], 65536KB chunk

md0 : active raid1 sda1[0] sdb1[1]
      4189184 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Die Synchronisation kann unter anderem über die Variable speed_limit_max gesteuert werden. Der Standardwert für dieses Limit liegt bei 200000. Wird dieser Wert höher gesetzt:

echo 1250000 > /proc/sys/dev/raid/speed_limit_max

kann die Synchronisation mehr Ressourcen nutzen und läuft somit schneller. Das bedeutet natürlich auch, dass das System im Allgemeinen stärker ausgelastet wird. Nach einem Neustart wird der geänderte Wert wieder auf seinen ursprünglichen Wert gesetzt.

Node.js unter Ubuntu 22.04 installieren

Wenn Node.js unter der aktuellen Ubuntu-LTS Version 22.04 installiert werden soll, so kann hierfür apt benutzt werden:

apt install nodejs

Das Problem an dieser Version aus den offiziellen Paketquellen ist, das sie ziemlich veraltet ist und mittlerweile meist neuere Node.js Versionen benötigt werden. Der gängige Weg wäre es nun die aktuelle LTS-Version von Node.js über den Befehl:

curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash -
apt install -y nodejs

zu installieren. Allerdings schlägt dies mangels eines für Ubuntu 22.04 hinterlegtem Paket mit folgender Meldung fehl:

Your distribution, identified as „jammy“, is not currently supported, please contact NodeSource at https://github.com/nodesource/distributions/issues if you think this is incorrect or would like your distribution to be considered for support

Hier kann sich beholfen werden, indem das Paket manuell heruntergeladen und installiert wird, um die Prüfung zu umgehen:

wget https://deb.nodesource.com/node_16.x/pool/main/n/nodejs/nodejs_16.9.1-deb-1nodesource1_amd64.deb
apt install ./nodejs_16.9.1-deb-1nodesource1_amd64.deb

Sobald die Pakete für Ubuntu 22.04 (Jammy) unter Nodesource bereitstehen kann das Setup-Skript wieder genutzt werden, um die Pakete aktuell zu halten. Alternativ kann Node.js auch über Snap installiert werden:

snap install node --classic

Dabei wird die aktuelle 18er-Version von Node.js installiert.

LibreOffice druckt nur weiße Seiten

Unter macOS hatte ich mit LibreOffice seit einiger Zeit das Problem, dass es nur weiße Seiten ausdruckte. Auch die entsprechende Druckvorschau unter macOS war leer. Das Erzeugen von PDFs und der anschließende Druck hingegen funktionierten ohne Probleme.

Die Druckvorschau zeigt nur leere Seiten

Verursacht wird der Fehler wohl durch die Bibliothek Skia, bei welcher es sich um eine freie 2D-Grafik Bibliothek handelt, welcher seit der 7er-Version der Office-Suite genutzt wird. Glücklicherweise kann die Nutzung dieser Bibliothek in den Einstellungen von LibreOffice deaktiviert werden.

In den Einstellungen kann die Nutzung der Bibliothek deaktiviert werden

Dort findet sich unter dem Punkt LibreOffice > View, die Option Use Skia for all rendering welche deaktiviert werden sollten. Nach einem Neustart von LibreOffice kann auch unter macOS wieder gedruckt werden. In der kommenden Version 7.3.1 soll diese Option unter macOS standardmäßig deaktiviert sein.