GNU Stow: Dotfiles bequem managen

GNU Stow löste zuletzt bei mir eine selbstgebaute zentrale Verwaltung von Konfigurations-Dateien ab. Etwas Kontext: Ich habe für viele Programme Konfigurationsdateien in meinem Home-Directory zu liegen. Diese Dateien – meist einfach Dotfiles genannt – möchte ich auf mehreren Rechnern synchron halten. Dies ermöglicht es, dass sich die damit konfigurierten Programme wie tmux, Vim oder auch Git überall gleich und vorhersagbar verhalten. Weitere Kandidaten neben reinen Konfigurationsdateien sind z. B. Shell-Skripte für die tägliche Arbeit.

Die erste Idee, die man haben würde: einfach ein Git-Repository[1] erstellen, in dem man die Konfigurations-Details verwaltet. Das unmittelbar auftauchende Problem: Man möchte/kann/soll kein VCS-Repository im Home-Verzeichnis haben, da dies eine ganze Menge Probleme mit sich bringt und schlicht nicht praktikabel ist.

Der nächste Schritt ist dann, alle diese Dateien in einem Unterverzeichnis zu sammeln und dieses mit einem VCS managen. Das Installieren der Dateien ins Home-Verzeichnis kann man dann mit einem simplen Shell-Skript oder auch mit einem Makefile erledigen. Diese Variante habe ich jetzt jahrelang erfolgreich im Einsatz gehabt. Sobald ich ein neues Dotfile benötigte, erstellte ich dieses zusammen mit einem Make-Target in meinem dotfiles-Verzeichnis. Der simple Aufruf von make kopierte die Datei dann ins Homeverzeichnis (bzw. erstellte dort einen Symlink).

Vor ein paar Tagen scrollte dann dieser Tweet an mir vorbei:

Relearning GNU stow to apply to dotfiles, as one does when @fink_ says to. (E.g. http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html …) — @jpmens

Das klang interessant und wurde noch besser als ich den verlinkten Blogpost las. GNU Stow ermöglicht es auf einfachste Weise die Dotfiles zentral zu verwalten und mit simplen Befehlen die gewünschten Dateien ins Home-Verzeichnis zu linken. Die Einsparung gegenüber dem vorhandenen Makefile sieht im ersten Moment nicht allzu groß aus, aber wenn ich mir das Schreiben von Make-Targets sparen kann, dann kostet das zum Einen weniger Zeit und eliminiert zum Anderen natürlich mögliche Fehlerquellen.

Ich musste in meinem dotfiles-Verzeichnis nur ein paar Sachen umbenennen bzw. verschieben und war innerhalb kürzester Zeit in der Lage meine Dotfiles mit Stow ins Home-Directory zu befördern.

Der im Tweet verlinkte Blog-Artikel erklärt sehr gut und abschließend, wie man seine Dotfiles Stow-kompatibel organisiert.

Bonus: Arbeitet man mit mehreren User-Accounts auf einer Maschine, reicht ein zentrales Dotfiles-Directory, aus welchem man dann mit der --target-Option von Stow Symlinks auf die Config-Files in die verschiedenen Home-Directories platziert.

[1] Jede andere Versionsverwaltungs-Software ist ebenfalls geeignet.

Western Digital WD Red 6 TB Benchmark

Die Tage haben sich zwei Western Digital WD Red Festplatten mit je 6 TB Kapazität (WD60EFRX) zu mir verirrt. Wie immer lasse ich einmal bonnie++ über die Platten laufen um zu sehen, ob und wie sie funktionieren.

Die Ergebnisse als HTML-Ausgabe von bonnie++: Benchmark Festplatte 1, Benchmark Festplatte 2

(macOS, bonnie++ 1.97, HFS+, USB 3-SATA-Adapter)

tl;dr Die WD Red Platten WD60EFRX schaffen an einem USB-3-SATA-Adapter beim Lesen und Schreiben jeweils bis zu ca. 165 MiB/s und ca. 130 IOPS.

VeloViewer Explorer Max Square – Radsport trifft Nerdsport

Das Hochladen und Herumzeigen der eigenen Radsport-Aktivitäten auf Strava macht zwar auch nach Jahren immer noch Spaß – wirklich beeindruckend wird es aber, wenn man sich anschaut, was VeloViewer dann mit den gesammelten Daten macht. VeloViewer erstellt und präsentiert unfassbar viele statistische Auswertungen der eigenen Radsport-Historie und führt dabei einige bisher nicht dagewesene Metriken ein. Ein Beispiel ist der Explorer Score und das Explorer Max Square:

The Explorer score is the total number of zoom level 14 map tiles you’ve passed through divided by the distance traveled rewarding those that like to visit new places, roads and trails.

Kleiner Exkurs: ein „Zoom Level 14 Map Tile“ ist eine Kartenkachel, wie sie z. B. auf der Website von OpenStreetMap zum Einsatz kommt. Es handelt sich um eine quadratische Grafik in den Abmessungen 256×256 Pixeln. Am Äquator entspricht 1 Pixel in der Zoomstufe 14 einer Länge von 9,547 m. In unseren Breitengraden (~52,5 °N) ergibt sich dann eine Kantenlänge einer Kachel von:

256 × 9,547 m × cos(52,5 °) = 1.488 m

Färbt man nun alle Kacheln ein, über die man bereits mit dem Rad gefahren ist, sieht das dann zum Beispiel so aus:

Explorer-Score 12×12

Auf der Karte sind mehrere blau umrandete, sich überlappende 12×12 Kacheln große Quadrate zu sehen. Jedes dieser Quadrate ist ein Explorer Max Square und besteht ausschließlich aus Kacheln, die man bereits besucht hat. Leicht zu erkennen ist die eine Kartenkachel südlich von Burig (nah der Bildmitte), welche die Bildung eines größeren Explorer-Quadrats verhindert. Die Lösung ist relativ einfach: Auf’s Rad setzen und einmal genau über diese Kachel fahren.

Et voilà:

… 17×17 :-)

Die Explorer Max Square-Rekordhalter spielen in einer ganz anderen Liga und werden in einem Blogbeitrag bei VeloViewer gewürdigt.

Das Pferd unterm Leibe erschossen

Hin und wieder nehme ich mir unseren Familienstammbaum zur Hand und blättere darin herum. Und manchmal finde ich interessante Geschichten aus vergangenen Zeiten:

Michael Ernst Preuß war 1809 beim Schill’schen Freiheitszuge beteiligt und am 31.5.1809 beim Fall Schills in Stralsund zugegen.
Er wurde eingeschlossen, schlug sich aber mit Kameraden durch, und schwamm mit ihnen über die Oder. In diesem Flusse wurde dem Hauptmann von Pirch das Pferd unterm Leibe erschossen. Preuß rettete Pirch. Von Pirch wurde später Besitzer von Hohendorf bei Reichenbach, Ostpreußen.
Es blieb während des Lebens dieser beiden Männer eine treue Freundschaft bestehen.

Infografik: Rad fahren in 2016

Wie auch im letzten Jahr kann man sich auf veloviewer.com eine schicke Infografik der vergangenen Radfahr-Saison erstellen lassen. Mein Ziel, mehr Strecke als im Vorjahr zurückzulegen habe ich nicht erreicht, zum Schluss fehlten knapp 300 km. Ist aber nicht schlimm, vielleicht klappt’s ja in diesem Jahr!

Zum Vergleich die 2015er Grafik:

Mailingliste nur mit Postfix betreiben

Ich hatte vor einer Weile die Aufgabe, eine Mailingsliste einzurichten. Die erwartete Funktionalität lässt sich einfach beschreiben:

  • die Mailingliste hat mehrere Empfänger/Empfängerinnen; diese werden manuell verwaltet und ändern sich selten, es wird daher keine Web- oder sonstige Schnittstelle zum An- und Abmelden benötigt
  • es gibt eine E-Mail-Adresse für die Mailingliste; alle Mails die an diese Adresse gesendet werden, werden zu allen Empfänger/Empfängerinnen der Mailingsliste weitergeleitet
  • ein beliebiger Empfänger/eine beliebige Empfängerin soll bei einer E-Mail der Mailingliste im Mailprogramm einfach auf Antworten/Reply klicken können um eine Mail wieder an alle Listenempfänger zu senden und nicht nur an den Absender/die Absenderin

Ich wollte nach Möglichkeit nicht mit Kanonen auf Spatzen schießen und mir den Administrationsaufwand eines Mailman o. Ä. ans Bein binden, also suchte ich nach einer Möglichkeit, eine Lösung nur mit Postfix zu bauen.

Das Weiterleiten einer E-Mail an mehrere Empfänger war kein Problem, diese Funktion ist wahrscheinlich sowie so auf jedem ernstzunehmenden Mailserver vorhanden. In Postfix nutzt man dafür Virtual Alias Maps (alternativ geht das auch mit „normalen“ Alias Maps).

Damit ein Klick auf den Antworten/Reply-Button an die Adresse der Mailingliste und nicht an die Absenderadresse geschickt wird, kann man den Reply-To Mail-Header nutzen. Dieser muss dazu in jede E-Mail eingefügt werden, die an die Mailinglisten-Empfänger gesendet wird.

Postfix bietet mit den sogenannten Header-Checks eine Möglichkeit, die Header einer E-Mail, die von Postfix zur Verarbeitung angenommen wurde, zu untersuchen und gegebenenfalls eine Aktion auszuführen. In meinem Fall sucht Postfix nach der Adresse der Mailingliste im To-Header. Wird diese Adresse gefunden, fügt Postfix den Reply-To-Header in die Mail ein.

Alles was man machen muss, ist eine Datei mit den entsprechenden Regeln anzulegen …

# /etc/postfix/header_checks
# poor man's mailing list
/^To: mailingliste@example.org/ PREPEND Reply-To: mailingliste@example.org

… und die header_checks-Option in der Postfix-Konfigurationsdatei zu setzen:

# /etc/postfix/main.cf
header_checks = regexp:/etc/postfix/header_checks

Ab jetzt erhalten alle Mails an die Mailinglisten-Adresse den passenden Reply-To-Header und die Billig-Mailingliste ist fertig.

Dieses Setup funktioniert hier seit zwei Jahren problemlos.