Adventskalender 17. Dezember 2024 - überall local

[mn77de]

Einleitung
Gerade wenn man viel und intensiv mit Debian arbeitet, sammeln sich mit der Zeit so einige Dinge an. Ich meine hier speziell:

• Konfigurationsdateien, die man mühsam ausgearbeitet und verfeinert hat
• Skripte, also kleine Helferchen, die natürlich auch irgendwohin müssen
• Aliase und Abbreviations
• Schriften
• Themes, Icons, ...

Evtl. hat man dann noch mehrere Rechner (Workstation, Laptop, Server, ...) und will diese Sachen natürlich überall synchron verfügbar haben.
Vielleicht kennt ja der/die ein oder andere dieses Problem.

Anfangs kopierte ich dies alles einfach von Rechner zu Rechner.
Heutzutage lässt sich das allerdings sehr viel eleganter lösen.

In diesem Türchen geht es also um benutzerdefinierte Anwendersoftware und alle dazu benötigten Ressourcen. Wo kann man diese ablegen und wie hält man dies auf mehreren Rechnern synchron.

local vs. local
Für das heutige Türchen befassen wir uns mit "/usr", einem sehr wichtigen Systemverzeichnis, in dem zentral die gesamte Anwendersoftware und alle dazu benötigten Ressourcen liegen. Das Verzeichnis wird von dpkg/apt verwaltet, weshalb man hier besser nichts manuell ändern sollte. Für Änderungen gibt es zwei Verzeichnisse, welche "/usr" sozusagen überlagern:

Code: Alles auswählen

1. /usr       # Systemverzeichnis, von dpkg/apt verwaltet
2. /usr/local # Systemverzeichnis, benutzerdefiniert (root), systemweit verfügbar
3. ~/.local   # Benutzerverzeichnis, benutzerdefiniert (user), für einen einzelnen Benutzer verfügbar

Für benutzerdefinierte Programme/Ressourcen kann man also sagen:

• Soll etwas für alle Benutzer am Rechner verfügbar sein: "/usr/local"
• Soll etwas nur für einen selbst verfügbar sein: "~/.local"

Eigene Skripte und Programme
In den zuvor genannten 3 Verzeichnissen existiert jeweils ein Verzeichnis namens "bin", in welchem eigene Skripte/Programme abgelegt werden können.

Das Programm zu einem eingegebenen Befehl wird dann der Reihe nach wie folgt gesucht (vereinfacht dargestellt):

Code: Alles auswählen

1. ~/.local/bin
2. /usr/local/bin
3. /usr/bin

So sind die eigenen Programme/Skripte gut vom restlichen System isoliert.

Für die Verwendung von "~/.local/bin" muss meist noch die PATH-Variable manuell angepasst werden.
Dies kann z.B. in der ".bashrc" oder ".zshrc" geschehen:

Code: Alles auswählen

PATH=~/.local/bin:$PATH

Unterverzeichnisse
Neben "bin" gibt es noch weitere Unterverzeichnisse, welche man gut nutzen kann. Ggf. müssen diese erst angelegt werden:

Code: Alles auswählen

├── bin       # Ausführbare Skripte/Programme
├── etc       # Konfigurationsdateien
├── games     # Spiele
├── include   # Header-Dateien für Programmierung
├── lib       # Bibliotheken
├── share     # Architekturunabhängige Daten
├── src       # Quellcode

Weitere Verzeichnisse können natürlich noch nach belieben hinzugefügt werden. So verwende ich unter "/usr/local" z.B. "etc" und "config" getrennt.
Hier ein paar konkrete Beispiele:

Code: Alles auswählen

/usr/local/bin                  # Systemweit verfügbare Skripte
/usr/local/share/color/icc      # Benutzerdefinierte ICC-Farbprofile
/usr/local/share/fonts/truetype # Benutzerdefinierte TrueType-Fonts
/usr/local/share/fonts/opentype # Benutzerdefinierte OpenType-Fonts
/usr/local/share/icons          # Benutzerdefinierte Icons
/usr/local/etc                  # Globale Konfigurationsdateien, welche von /etc verlinkt werden können
/usr/local/config               # Konfigurations-Dateien welche von ~/.config verlinkt werden können

Teils ist es zum Gruppieren sinnvoll, noch ein entsprechendes Unterverzeichnis zu verwenden.
Z.B.: "/usr/local/share/fonts/truetype/google" oder "/usr/local/config/helix"

Ist man der einzige Benutzer oder Admin eines Rechners, so kann ich die Arbeit mit "/usr/local" sehr empfehlen. Neben einem selbst können so natürlich auch andere Benutzer von den dort abgelegten Sachen profitieren. Sollte hingegen kein Root-Zugriff bestehen, nutzt man eben "~/.local".

Zentrale Konfigurations-Dateien
Hat man seine Konfigurationen zentral unter "/usr/local/config" liegen, so kann bei Bedarf einfach darauf verlinkt werden.
Als Beispiel erwähnt, meine Helix-Konfiguration liegt unter "/usr/local/config/helix" worauf ich im Homeverzeichnis einfach verlinke:

Code: Alles auswählen

cd ~/.config
ln -s /usr/local/config/helix

Synchronisieren
Anfangs (so vor 15 Jahren) versuchte ich, "/usr/local" mittels "rsync" zwischen den Rechnern zu synchronisieren. Dies ist zwar möglich, allerdings auch etwas mühsam wenn Änderungen an mehreren Rechnern vorgenommen wurden. Versuche mit "unison" funktionierten da besser, jedoch ist dieses Tool auch etwas unhandlich. Heutzutage verwende ich "git", was wirklich einwandfrei läuft. Alternativ kann natürlich "svn", "cvs" oder jedes beliebige Versionsmanagement verwendet werden.

Es gibt Leute, die ihr gesamtes Home-Verzeichnis in einem Git-Repository haben. Meist reicht es aber, eines der beiden "local"-Verzeichnisse mittels Versionsmanagement zu verwalten.

Ich persönlich nutze einen kleinen OrangePi-Zero als Git-Server, über den ich alle Rechner und Laptops im Haus synchron halten kann. Änderungen sind so überall schnell verfügbar und es gibt kaum Probleme, wenn an mehreren Rechnern etwas geändert wurde.

Auf die Verwendung von Git gehe ich hier nicht weiter ein, auf Wunsch kann ich gerne noch etwas als Kommentar hinzufügen.

Schlusswort
Wie habt Ihr eure Skripte/Konfigurationen organisiert?
Nutzt ihr "~/.local" oder "/usr/local"?

Eine weitere Möglichkeit zur Verwaltung der Konfigurationsdateien bietet "chezmoi", welches im Türchen vom 9. vorgestellt wurde:
Adventskalender 9. Dezember 2024 - Was tun mit den ganzen gepunkteten Dateien?

[Livingston]

Auch Seiner Lordschaft "root" kann man diese Struktur aufdrücken und hat dann exklusive Admin-Skripte im selben übersichtlichen Schema vorliegen, wie die anderen Accounts.
Danke für das Türchen.

[uname]

Danke für das Türchen. Als ich mit UNIX bzw. Linux in den 1990er-Jahren angefangen habe, da hat man meistens NFS (Wikipedia) und damit eine zentrale Verwaltung verwendet. Auf den damaligen Clients waren dann einfach an etlichen Pfaden NFS-Shares reingemountet. Einige nur lesbar andere auch vom Anwender schreibbar. Sofern man bereit ist eine zentrale Verwaltung zu nutzen, ist das wohl immer noch die beste Lösung unter Linux. Lässt aber wohl nur als "Cloud-Lösung" verkaufen, was es ja im Prinzip auch ist. Sonst will es keiner haben: Viel zu alt und praktisch keinen administrativen Aufwand.

https://wiki.debianforum.de/NFSv4-Mini-Howto

[mn77de]

Auch Seiner Lordschaft "root" kann man diese Struktur aufdrücken ...

LOL!
Aber ja, von "/root/config" verlinke ich ebenso nach "/usr/local/config" und hab' so die selbe Konfiguration wie beim normalen Benutzer.

Danke für das Türchen. Als ich mit UNIX bzw. Linux in den 1990er-Jahren angefangen habe, da hat man meistens NFS (Wikipedia) und damit eine zentrale Verwaltung verwendet.

Da bist du wirklich schon lange dabei!
Ich bin "erst" 2003 richtig umgestiegen.

NFS nutze ich für die zentrale Dateiablage. Bei sich häufig ändernden Textdateien und Laptops, welche öfters außer Haus unterwegs sind, ist so etwas wie Git schon echt fein.

[Liffi]

Wir hatten mal eine NFS-Lösung für alle Heimatverzeichnisse im Betrieb, aber wenn das NFS stand (kam nicht super oft vor, aber passierte), konnte halt niemand mehr arbeiten.

[uname]

Wir hatten mal eine NFS-Lösung für alle Heimatverzeichnisse im Betrieb, aber wenn das NFS stand (kam nicht super oft vor, aber passierte), konnte halt niemand mehr arbeiten.

Heutzutage nutzt man dafür Cloud-Lösungen mit Synchronisation wie z. B. Nextcloud oder Microsoft 365. Aber wenn die Cloud kaputt ist, dann gibt es meinstes trotzdem Probleme trotz lokaler Datenhaltung. Zudem sind Nextcloud und Microsoft 365 weit anfälliger für Ausfälle als seinerzeit NFS. Der Vorteil ist heute jedoch, dass die Daten asynchron auch offline vorliegen.

[GregorS]

Vielen Dank für dieses Kalendertürchen!

Eine Zeit lang hatte ich nur ein /home, das von verschiedenen Rechnern meines kleinen Heim-Netzes per NFS von einem zentralen Rechner gemounted wurde. Das ist für Rechner mit identischen (oder nahezu identischen) Programmen sicherlich praktisch. Im Laufe der Zeit ergaben sich bei mir aber immer wieder und immer öfter Unterschiede, die eine zentrale Datenhaltung schwierig, wenn nicht gar unmöglich machten. Ein Beispiel ist mein Notebook: Das ist nunmal nicht immer in Reichweite meines WLANs.
Bei einer überschaubaren Zahl an Rechnern ist es auf lange Sicht meiner Erfahrung nach günstiger, individuelle Konfigurationen zu pflegen.

[mn77de]

Bei einer überschaubaren Zahl an Rechnern ist es auf lange Sicht meiner Erfahrung nach günstiger, individuelle Konfigurationen zu pflegen.

Das kann ich absolut nachvollziehen.
Der Vorteil bei der Nutzung von "/usr/local" via Git (es kann auch gerne ein anderes Verzeichnis verwendet werden) ist:

• Die meistgenutzten Konfigurationen sind auf jedem Rechner immer aktuell vorhanden.
• Man verlinkt nur darauf, wenn man sie benötigt.
• Selbst mehrere Nutzer (inkl. Root) können die ausgefeilten Config's nutzen.
• Ggf. kann auch nur ein Teil verwendet werden, oder man legt sich eine lokale Kopie an.
• Aber, alle eigenen Skripte/Programme/Configs sind generell auf dem Rechner vorhanden und ggf. schnell zur Hand.

Ich spreche hier z.B. von Configs für Helix, lf, awesomewm, tmux, caja, redshift, zsh, ...
Es macht natürlich keinen Sinn "/etc/fstab" oder die Config für einen rsync-Server so zentral zu speichern. Die sind einfach zu individuell.