Größe der Packdateien unter Git beschränken

Im Versionsverwaltungssystem Git existieren im Repository sogenannte Packfiles. Diese werden genutzt um mehrere Objekte, wie z.B. Commits, Trees, Blobs oder Tags, als einzelne Dateien abzulegen. Damit fasst Git viele Objekte zu einer einzelnen komprimierten Datei zusammen. Ergänzt wird das ganze durch einen Index, um einen schnellen Zugriff zu ermöglichen. Dabei nutzt Git Delta-Kompression, indem es ähnliche Objekte, z. B. verschiedene Versionen derselben Datei, nicht vollständig speichert, sondern nur die Unterschiede.

Eine Git-Pack-Datei im Schema

Dies reduziert die Repository-Größe erheblich, kann aber bei ungünstigen Repositorys mit vielen Binärdaten zu Repositorys führen, welche mehrere dutzend Gigabyte große Pack-Dateien besitzen. Eine Steuerung ist über den Konfigurationsparameter pack.packsizelimit möglich:

git config pack.packsizelimit 5g

Damit würde diese Einstellung für das aktuelle Repository gesetzt werden. Wer das Ganze global benötigt, kann dies ebenfalls einstellen:

git config --global pack.packsizelimit 5g

Allerdings gilt diese Einstellung nicht sofort, stattdessen muss für ein Repack gesorgt werden:

git repack -Ad --max-pack-size=5g

Anschließend kann die Größe der Packs kontrolliert werden:

ls -lh .git/objects/pack

Allerdings sollte beachtet werden, das die Option grundsätzlich nur in Ausnahmefällen sinnvoll ist:

Note that this option is rarely useful, and may result in a larger total on-disk size (because Git will not store deltas between packs) and worse runtime performance (object lookup within multiple packs is slower than a single pack, and optimizations like reachability bitmaps cannot cope with multiple packs).

Spamhaus DQS unter Postfix konfigurieren

Spamhaus betreibt seit vielen Jahren einige der effektivsten Echtzeit-Blocklisten (DNSBLs) gegen Spam, Botnets und missbrauchte Mailserver. Viele Administratoren nutzen diese Listen über die klassischen öffentlichen DNS-Mirrors, etwa zen.spamhaus.org. Doch seit einiger Zeit schränkt Spamhaus die Nutzung genau dieser Public Mirrors deutlich ein.

Insbesondere gilt dies für Nutzer großer Hosting- und Cloud-Provider wie Hetzner oder OVH. Wer Spamhaus nun z.B. beim eigenen Mailserver mit diesen Providern einsetzt, wird im Log solche Meldungen entdecken:

Service unavailable; Client host [203.0.113.127] blocked using zen.spamhaus.org; Error: open resolver;

Die Legacy-Mirrors sind eigentlich nur für kleine Installationen gedacht, also für einzelne Mailserver, die klar identifizierbar über ihre eigene IP-Adresse sind. Doch genau diese eindeutige Identifikation funktioniert nicht mehr zuverlässig, wenn Anfragen über große Cloud-Infrastrukturen kommen. Damit kann die Fair-Use-Policy nicht mehr sinnvoll durchgesetzt werden.

Als Alternative bietet sich der Spamhaus-Dienst Data Query Service (DQS) an. Damit werden die Abfragen weiterhin per DNS ausgeführt, jedoch über einen individuellen Zugangsschlüssel, der als Subdomain eingebettet wird und so eine eindeutige Identifikation ermöglicht. Im ersten Schritt muss hierfür ein Account angelegt werden. Nachdem der Account erstellt wurde, kann sich über das Portal eingeloggt werden. Dort kann unter dem Punkt ProductsData Query Service ein DQS-Schlüssel erzeugt werden.

Das Portal von Spamhaus

Anschließend kann mit der Konfiguration von Postfix begonnen werden:

nano /etc/postfix/dnsbl-reply-map

In diese Datei wird Folgendes eingetragen:

dqskey.zen.dq.spamhaus.net=127.0.0.[2..11]	554 $rbl_class $rbl_what blocked using ZEN - see https://www.spamhaus.org/query/ip/$client_address for details
dqskey.dbl.dq.spamhaus.net=127.0.1.[2..99]	554 $rbl_class $rbl_what blocked using DBL - see $rbl_txt for details
dqskey.zrd.dq.spamhaus.net=127.0.2.[2..24]	554 $rbl_class $rbl_what blocked using ZRD - domain too young
dqskey.zen.dq.spamhaus.net			554 $rbl_class $rbl_what blocked using ZEN - see https://www.spamhaus.org/query/ip/$client_address for details
dqskey.dbl.dq.spamhaus.net			554 $rbl_class $rbl_what blocked using DBL - see $rbl_txt for details
dqskey.zrd.dq.spamhaus.net			554 $rbl_class $rbl_what blocked using ZRD - domain too young

Der Platzhalter dqskey wird hierbei durch den realen DQS-Schlüssel ersetzt. Nach einer Ausführung von Postmap:

postmap /etc/postfix/dnsbl-reply-map

geht es an die eigentliche Konfiguration:

nano /etc/postfix/main.cf

Dort muss im ersten Schritt die alte Spamhaus-Konfiguration (wenn vorhanden) entfernt werden. Nun kann die neue Konfiguration hinzugefügt werden:

smtpd_recipient_restrictions =
    ...
    reject_rbl_client dqskey.zen.dq.spamhaus.net=127.0.0.[2..11]
    reject_rhsbl_sender dqskey.dbl.dq.spamhaus.net=127.0.1.[2..99]
    reject_rhsbl_helo dqskey.dbl.dq.spamhaus.net=127.0.1.[2..99]
    reject_rhsbl_reverse_client dqskey.dbl.dq.spamhaus.net=127.0.1.[2..99]
    reject_rhsbl_sender dqskey.zrd.dq.spamhaus.net=127.0.2.[2..24]
    reject_rhsbl_helo dqskey.zrd.dq.spamhaus.net=127.0.2.[2..24]
    reject_rhsbl_reverse_client dqskey.zrd.dq.spamhaus.net=127.0.2.[2..24]
    ...

Damit die DQS-Schlüssel nicht per Reject-Nachricht nach außen geleakt werden, wird noch die Reply Map eingebunden:

rbl_reply_maps = hash:$config_directory/dnsbl-reply-map

Anschließend kann Postfix neu gestartet werden:

systemctl restart postfix

Getestet werden kann das Ganze dann z.B. mit dem Blocklist Tester von Spamhaus.

Speicher unter macOS bereinigen

Vor allem vor einem macOS-Update kann es vorkommen, dass auf den kleineren Speicherkonfigurationen eines Macs der Speicher knapp wird. Neben dem manuellen Ausmisten helfen hierbei auch Tools wie mac-cleanup-py. Das Tool kann über Homebrew installiert werden:

brew install mac-cleanup-py

Nach der Installation kann das Werkzeug über:

sudo mac-cleanup

aus dem Terminal heraus angestartet werden. Beim ersten Aufruf können die Module für die Bereinigung aktiviert werden. Später kann dies mittels:

mac-cleanup -c

wiederholt werden. Soll die Bereinigung ohne nachfragen durchgeführt werden kann der Parameter -f mit angehangen werden:

sudo mac-cleanup -f

Das Tool selbst ist freie Software unter der Apache License in Version 2.

Plötzliche FRITZ!Box DNS-Probleme beheben

Wenn von einer Sekunde auf die andere das Internet über die FRITZ!Box nicht mehr funktioniert, lohnt es sich ein Blick in die DNS-Konfiguration. Dazu ist ein kleiner Aufruf von dig im Terminal nötig:

dig example.org

Die Ausgabe zeigte dann das der DNS-Service auf der FRITZ!Box nicht mehr so arbeitete, wie er sollte.

;; WARNING: recursion requested but not available

Um auszuschließen, das es sich nicht um ein generelles Problem handelt, kann dig anschließend noch einmal mit einem manuell gesetzten DNS-Server aufgerufen werden:

dig @1.1.1.1 example.org

Liefert dieser Aufruf eine DNS-Auflösung, so ist die Ursache höchstwahrscheinlich in der FRITZ!Box zu finden. Hier lohnt es sich nach einem Login die DNS-Einstellungen unter InternetZugangsdatenDNS-Server aufzurufen.

Die DNS-Einstellungen der FRITZ!Box

Dort hilft es in vielen Fällen den Punkt Verschlüsselte Namensauflösung im Internet (DNS over TLS) zu deaktivieren. Meist kann die Einstellung anschließend, nachdem sie einmalig übernommen wurde, wieder aktiviert werden. In anderen Fällen muss sie komplett deaktiviert werden, damit die DNS-Auflösung wieder funktioniert.

Kiosk-System auf dem Raspberry Pi einrichten

Wer auf einem Raspberry Pi ein Kiosk-System einrichten möchte, kann hierfür mit dem Raspberry OS Lite beginnen. Dort sollte über einen Aufruf von raspi-config der Autologin aktiviert werden (System Options -> S6 Auto Login).

Im nächsten Schritt wird der Wayland Compositor Sway installiert:

apt install sway xwayland

Nach der Installation wird im lokalen Nutzer, welcher für den Kiosk-Modus benutzt werden soll, eine Konfiguration-Datei angelegt:

mkdir -p ~/.config/sway/
nano ~/.config/sway/config

Diese wird mit folgender Konfiguration befüllt:

# Sway kiosk configuration for Raspberry Pi + Raspberry Pi Touch Display 2

# Configure sway
default_border none
default_floating_border none

# Set and transform output
output DSI-2 transform 90

# Execute application
exec_always sh -c '/home/seeseekey/testapp'

Die Konfiguration sorgt dafür das Sway rahmenlos arbeitet und der Bildschirm des Raspberry Touch 2 Display um 90 Grad gedreht wird. Im letzten Schritt wird in der Konfiguration eine Applikation gestartet.

Für Debugzwecke können daneben bei Bedarf noch folgende Zeilen hinzugefügt werden:

# Debug (write outputs and tree into file)
exec_always sh -c 'sleep 4 && swaymsg -t get_outputs > /tmp/outputs.json'
exec_always sh -c 'sleep 4 && swaymsg -t get_tree > /tmp/tree.json'

Zwar ist mit dieser Konfiguration das Display gedreht, aber die Eingaben werden noch in der ursprünglichen Rotation übermittelt. Hierzu muss im ersten Schritt mittels libinput-tools das Gerät ermittelt werden:

apt install libinput-tools
libinput list-devices

Nachdem das Touchscreen-Gerät ermittelt wurde, kann der Name des Gerätes genutzt werden, um eine udev-Regel zu definieren:

nano /etc/udev/rules.d/99-touch-rotation.rules

Dort wird die Rotation ebenfalls um 90 Grad gedreht:

ATTRS{name}=="11-005d Goodix Capacitive TouchScreen", ENV{LIBINPUT_CALIBRATION_MATRIX}="0 1 0 -1 0 1"

Nachdem diese Konfiguration hinterlegt sind, wird eine lokale systemd-Unit erstellt:

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/sway.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Sway
After=graphical-session.target
Requires=graphical-session.target

[Service]
ExecStart=/usr/bin/sway
Restart=always
Environment=XDG_RUNTIME_DIR=/run/user/%U

[Install]
WantedBy=default.target

Anschließend kann die systemd-Unit aktiviert werden.

systemctl --user enable sway

Nun kann der Raspberry Pi neugestartet werden. Im Idealfall startet das System führt den Login durch und startet die Applikation. Sollte es hier Probleme geben, kann es an bestimmten Bibliotheken wie libxi6 liegen, welche noch nachinstalliert werden müssen.