Mit Stow verwalten Sie selbst installierte Programme und halten Konfigurationsdateien auf allen genutzten PCs synchron.

Ordnung ist das halbe Leben, besagt ein deutsches Sprichwort. Daraus ließe sich folgern, dass Chaos die andere Hälfte abgibt. Letzteres sollten Sie auf Computern unbedingt im Zaum halten. Viele GNU-Tools widmen sich dieser Aufgabe; zu den weniger bekannten Werkzeugen dieser Gattung zählt Stow [1]. Der Symlink-Farm-Manager verwaltet verschiedene Sätze von Software oder Daten, die sich in separaten Verzeichnissen auf dem Dateisystem befinden, so, dass es nach außen scheint, als wären sie in einem einzigen Verzeichnisbaum installiert.

Stow kommt oft beim systemweiten Installieren von Software zum Einsatz, bietet jedoch zusätzlich einen sauberen Mechanismus zum Verwalten von Konfigurationsdateien und Skripten in den Home-Verzeichnissen der Installationen. Damit darf das Werkzeug als offizielle Lösung des GNU-Projekts gelten, um angepasste Konfigurationsdateien zu separieren und auf andere Systeme zu verteilen.

Ursprünglich entstand Stow, um die Kontrolle über auf dem System kompilierte Software zu behalten, die gemeinhin in Unterverzeichnissen von /usr/local/ landet. Bei Weitem nicht alle selbstkompilierte Software enthält ein Target uninstall im Makefile oder einen vergleichbaren Mechanismus, um sie bei Bedarf wieder loszuwerden.

Das erzwingt gegebenenfalls eine umständliche manuelle Deinstallation: Man muss etwa per whereis Software herausfinden, auf welche Unterverzeichnisse die betreffende Software sich verteilt hat, und die Dateien dann in jedem betroffenen Verzeichnis per rm -rf entfernen.

Dreisprung mit Prefix

Stow legt bei der Installation ein separates Verzeichnis mit dem Namen stow/ unter /usr/local/ an. Das geben Sie beim Kompilieren einer Anwendung im ersten Schritt des klassischen Dreisprungs an, um die Software unterhalb von /usr/local/stow/ zu installieren. Der Befehl dazu sieht dann etwa wie in Listing 1 aus.

$ ./configure --prefix=/usr/local/stow/Software
$ make
# make install

Oft kommt im ersten Schritt auch Cmake zum Einsatz. Durch den --prefix als zusätzliche Anweisung landet die Software nun komplett in stow/Software.Version. Um sie nun auf die vom Filesystem Hierarchy Standard (FHS) [2] vorgesehene Verzeichnisstruktur umzusetzen, wechseln Sie mit cd /usr/local/stow/ ins Stow-Verzeichnis und stoßen mit stow Software das Erstellen der Symlinks nach /usr/local/ an.

Wollen Sie die Software später komplett entfernen, genügt ein stow -D Software gefolgt von rm -rf Software.Version. Nach einem Paket-Update aktualisieren Sie die Symlinks mit --restow.

Im Test dienten die Quellen zum gerade erschienenen Curl 7.66.0 als Beispiel. Die Installation der Software erledigen die Befehle aus Listing 2. Danach lagen im Verzeichnis /usr/local/stow/curl-7.66.0 die Verzeichnisse bin/, include/, lib/ und share/. Wäre mit dem Prefix nicht ../stow/curl-7.66.0/ als Installationsort festgelegt, hätte das Makefile das Programm also auf die genannten Ordner verteilt.

$ ./configure --prefix=/usr/local/stow/curl-7.66.0
$ make
# make install

Per Symlink umgebogen

Um dem System die erwarteten Orte vorzugaukeln, legen Sie aus dem Verzeichnis /usr/local/stow/ heraus mit dem Befehl stow curl-7.66.0 entsprechende Symlinks an (Abbildung 1). Ein hinterhergeschicktes ldconfig registriert neue Bibliotheken im System. Wenn Sie nun in /usr/local/include ein ls -la absetzen, sehen Sie den Symlink auf curl -> ../stow/curl-7.66.0/include/curl. Dasselbe gilt für die anderen Verzeichnisse.

Abbildung 1: Durch die Installation der Anwendung in ein eigenes Verzeichnis kapselt Stow die Daten vom System. Dann setzt es Symlinks in die Verzeichnisse, auf die sich die Software üblicherweise verteilt.

Bei der Herangehensweise, Software in ein einziges Verzeichnis zu installieren und dem System FHS-Konformität über Symlinks zu erreichen, ähnelt Stow Distributionen wie NixOS oder GoboLinux, die ein ähnliches Verfahren seit Langem als generelles Konzept zum Verwalten von Software einsetzen.

Dotfiles verwalten

Aber die Zeiten ändern sich: Software kommt heute hauptsächlich via Paketmanager oder in Form von Flatpaks und Snaps ins System. Stow hat mit der Zeit über den ursprünglichen Zweck hinaus andere Anwendungsgebiete erobert. Das spiegelt sich in der Selbstdarstellung des als Perl-Skript realisierten Helfers wider: Stand noch 2013 in der Manpage von Stow als Beschreibung Software Package Installation Manager, findet sich heute an gleicher Stelle generisch der Begriff Symlink Farm Manager, der für den privaten Gebrauch erweiterte Anwendungsmöglichkeiten bietet.

Dazu gehört das Verwalten der sogenannten Dotfiles, also der versteckten Konfigurationsdateien im Home-Verzeichnis einer Installation. Sie heißen Dotfiles, da sie einen Punkt vor dem Namen tragen. Möchten Sie diese Dateien oder eine Sammlung immer wieder eingesetzter Skripte auf mehreren Rechnern einsetzen, so hilft Stow Ihnen dabei.

Ein gutes Beispiel hierfür ist die Datei .bashrc. Diese Konfigurationsdatei tritt jedes Mal in Aktion, wenn Sie ein Terminal öffnen. Sie enthält unter anderem nützliche Einträge wie von Ihnen erstellte Aliase für oft verwendete Befehlsfolgen oder Anweisungen für das individuelle Aussehen des Prompts. Die Datei des Autors befindet sich mittlerweile weit über zehn Jahre im Einsatz und wird in jede neue Installation eingebunden.

Schnell aufgesetzt

Gerade wenn man beruflich viele Rechner installiert oder Distributionen in virtuellen Maschinen testet, spart es viel Zeit, wenn Anwendungen sich verlässlich gleich verhalten. Der Aufwand der Einrichtung von Stow für diesen Zweck bleibt überschaubar, denn Sie verwalten mit Stow nur die Dotfiles, die Ihnen für diesen Zweck sinnvoll erscheinen.

Zunächst erstellen Sie in Ihrem Home-Verzeichnis einen Ordner, den Sie der Einfachheit halber dotfiles/ nennen. Darin erstellen Sie Verzeichnisse für alle Programme, deren Dotfiles Sie mit Stow verwalten möchten. Dabei orientieren Sie sich an der vorgegebenen Struktur des Home-Verzeichnisses (Abbildung 2).

Abbildung 2: Mithilfe des Befehls tree -a sehen Sie sich die Verzeichnishierarchie als Baumstruktur an. So überprüfen Sie, ob die nachgebildete Struktur tatsächlich den Gegebenheiten im Home-Verzeichnis entspricht.

Laut der XDG Base Directory Specification [3] sollten Konfigurationsdateien in $HOME/.config/ liegen. Längst nicht alle Entwickler halten sich daran, und so verteilen sich die Dateien über das Home. Ein schlechtes Vorbild gibt hier unter anderem auch Mozilla ab.

Mehr Ordnung

Um zunächst beim Beispiel mit der Datei .bashrc zu bleiben: Sie liegt üblicherweise direkt im Home-Verzeichnis. Um sie mit Stow zu verwalten, verschieben Sie sie in den vorher im Home erstellten Ordner dotfiles/. Falls Sie die Dateien .bash_profile und .bash-logout ebenfalls dort verwalten möchten, lohnt es sich, zur besseren Übersicht unter dotfiles/ den Ordner bash/ anzulegen und die drei Dateien dorthin zu verschieben.

Anschließend führen Sie die Befehlsfolge cd ~/dotfiles && stow -v bash aus, um die nötigen Symlinks zu erzeugen (Abbildung 3). Mit ls -la | grep "\->" überprüfen Sie den Erfolg: Der Befehl zeigt die drei von Stow erstellten symbolischen Verweise. Mit stow * behandeln Sie mehrere Verzeichnisse auf einen Rutsch.

Abbildung 3: Die eigentliche Arbeit erledigt der Befehl stow, gefolgt von der zu bearbeitenden Anwendung. Der Zusatz --verbose oder -v zeigt auch gleich die angelegten Symlinks. Deren Vorhandensein an den richtigen Stellen lässt sich mit dem List-Befehl greppen.

Stow verlinkt ohne weitere Angaben direkt in das darüberliegende Verzeichnis, also in der Regel das eigene Home-Directory. Möchten Sie ins Home-Verzeichnis eines anderen Users verlinken, nutzen Sie den Parameter --target oder kurz -t. Nach Änderungen an Konfigurationsdateien liest der Parameter --restow oder -R diese neu ein.

Viel Freiheit

Wer viel im Terminal arbeitet, hat unter Umständen mehrere Profile seiner bevorzugten Terminalemulation angelegt, die unter anderem den Schriftsatz, dessen Größe und die Farbe des Hintergrunds festlegen. Der Autor pflegt beispielsweise einige Profile von Konsole und zusätzlich eines von Yakuake.

Die entsprechenden Dateien liegen im Fall von Konsole unter .config/ und .config/share/; es gilt also, die Struktur in dotfiles/ nachzubilden. Da hier eine gute Handvoll Dateien zu sichern sind, erscheint es ratsam, zunächst einen Unterordner namens konsole/ zu erstellen und die Verzeichnisstruktur darin nachzubilden.

Die Verzeichnisstruktur dürfen Sie beliebig erweitern, um etwa Dateien, die private Informationen enthalten, separat zu speichern oder Dateien thematisch zu sortieren. Egal, wie verschachtelt die Struktur ausfällt: Solange Sie am Ende den Stow-Befehl aus dem richtigen Verzeichnis absetzen, erledigt das Tool den Rest. Wenn Sie alle zu sichernden Dotfiles so behandeln, haben Sie diese immer schnell im Zugriff.

Eine andere Möglichkeit ist es, Dotfiles per Git zu verwalten. Das gelingt von Hand in wenigen Minuten oder mittels eines Skripts wie Yadm (Yet Another Dotfile Manager) [4] automatisiert (Abbildung 4). Das ermöglicht es außerdem, Verzeichnisse zu verschlüsseln, die unter Versionskontrolle stehen, aber auf Github nicht offen zugänglich sein sollen. Github widmet dem Thema Dotfiles eine eigene Seite [5].

Abbildung 4: Wenn Sie Dotfiles per Git verwalten möchten, erstellen Sie zunächst ein lokales Repository und fügen diesem die zu verwaltenden Dateien hinzu.

Fazit

GNU Stow hat sich, ganz der Unix-Philosophie folgend, auf das vereinfachte Verwalten von Dateien spezialisiert. Es leistet gute Dienste, wenn Sie Dotfiles zwischen Benutzern oder Rechnern lokal verteilen möchten. Geht es darum, über das eigene Netzwerk hinaus Dotfiles anderen Anwendern bereitzustellen, bietet es sich an, Stow etwa mit dem Skript home von Github [6] zu erweitern (Abbildung 5). Die Dokumentation von Stow gibt sich, wie bei GNU-Projekten üblich, sehr ausführlich, liegt allerdings nur auf Englisch vor [7]. Ansonsten macht das Tool bei minimalem Aufwand genau das, was es verspricht. Fehler traten im Test nicht auf. 

Abbildung 5: Ein Repository auf Github oder beim Anbieter Ihres Vertrauens wird mit dem lokalen Repository verbunden. Es versioniert dann privat oder öffentlich Änderungen an den Dotfiles.