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.

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.

Probleme mit dem cryptsetup-Workarround

Vor einigen Monaten veröffentlichte ich eine Anleitung zur Verschlüsselung eines Ubuntu-Servers. Da es einen Bug im cryptsetup gab, wurde in dem Artikel ein Workarround beschrieben. Mittlerweile wurde das cryptsetup-Paket aktualisiert und der entsprechende Bug gefixt. Allerdings führt dies zu Problemen mit dem Workarround. Möchte man den Server nun entsperren, erhält man folgende Meldung:

$ cryptroot-unlock
/bin/cryptroot-unlock: line 192: 2: parameter not set
/bin/cryptroot-unlock: line 192: 2: parameter not set
/bin/cryptroot-unlock: line 192: 2: parameter not set

Gelöst werden kann dieses Problem in dem folgendes Kommando genutzt wird:

sed 's/print $1, $5/print $1, $3/' /bin/cryptroot-unlock > /tmp/cryptroot-unlock; ash /tmp/cryptroot-unlock

Damit lässt sich der Server entsperren. Im zweiten Schritt kann nun der Workarround entfernt werden und das initramfs aktualisiert werden:

rm /etc/initramfs-tools/hooks/cryptsetup-fix.sh 
update-initramfs -u

Nach einem Neustart des Systems, kann dieses nun wie folgt entsperrt werden:

BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cryptroot-unlock 
Please unlock disk cryptroot (/dev/md1): 
cryptsetup: cryptroot set up successfully
# exit

Anschließend wird das System hochgefahren und der Server steht zur Verfügung.

10 Jahre alter Bug in JetBrains IDEs

Zur Entwicklung nutze ich in vielen Fällen die IDEs von JetBrains. Aus meiner Sicht sind die IDEs von JetBrains im Grunde großartig. Doch wo Licht ist, da fällt auch Schatten. Wenn man diese IDEs mit einer deutschen Tastaturbelegung nutzt, so wird man desöfteren mit Problemen konfrontiert sein. So ist es z.B. nicht möglich die Tastenkombination für die zeilenweise Auskommentierung zu nutzen. Es funktioniert mit einer deutschen Tastaturbelegung nicht. Manchmal kann man diese Probleme umgehen. Unter macOS würde die Nutzung des Numpads als Workarround in den meisten Fällen mangels Numpad scheitern.

Ein Beispiel für problematische Tastaturkürzel

Bei meiner Suche nach einer Lösung bin ich über einen entsprechenden Bug im Ticketsystem von JetBrains gestolpert: JRE-216. Dieser Bug vom 31. Oktober 2007 ist mittlerweile über 10 Jahre alt und noch immer ungelöst. Er verweist unter anderem auf das Ticket IDEA-165950. Auch in diesem Ticket geht es um die Unterstützung nationaler Tastaturbelegungen. Gelöst ist dieses Ticket nicht; auch wenn es mittlerweile Bestrebung gab, das Problem anzugehen. So heißt es weiter warten, auf eine endgültige Lösung; für ein Problem welches viele Entwickler Zeit, Ärger und Produktivität kostet.

Fehlersuche mit „git bisect“

In größeren Projekten arbeiten meist mehrere Entwickler an einem Git-Repository. Und wie es bei der Software-Entwicklung nun einmal ist kommt es ab und an zu Fehlern. Bei einer komplexen Versionshistorie ist es allerdings schwierig den Ursprungscommit eines Fehlers zu finden. An dieser Stelle hilft das Git-Kommando bisect weiter. Zum Start muss Git mitgeteilt werden welcher der letzte (aus Sicht des Entwicklers) korrekt funktionierende und der erste fehlerhafte Commit ist. Dies geschieht im Terminal auf dem Repository mittels:

git bisect start
git bisect good <hash>
git bisect bad <hash>

Danach checkt bisect einen Commit aus. Dieser Commit muss nun auf den gesuchten Fehler überprüft werden. Ist der Fehler weiterhin vorhanden, so teilen wir dies Git mittels:

git bisect bad

mit. Ist der Fehler nicht mehr vorhanden, so teilen wir Git dies ebenfalls mit:

git bisect good

Dieser Prozess wird dabei so lange durchlaufen bis Git uns am Ende des Prozesses mitteilt, in welchem Commit der Fehler seinen Ursprung hat. Danach können wir uns den Commit notieren und bisect mittels:

git bisect reset

mitteilen das der Prozess zu einem Ergebnis geführt hat. Dadurch wird das Repository in seinen Ursprungszustand versetzt.