Konfigurationen wie Netzwerk - mit Hilfe von git

[chrbr]

In der letzten Zeit gab es einige Threads mit dem Thema Netzwerk. Wenn man mit den verschiedenen Möglichkeiten experimentiert kann man schnell den Überblick über die vielen Dateien verlieren. Irgendwann sind es zu viele oder falsche für ein Tool oder es fehlen welche. Damit endet man schnell bei "gestern ging es noch..." . Mit dem Tool zur Versionsverwaltung git kann man sich das Leben erleichtern. Dazu brauch man nur einen Bruchteil der Funktionen, die git eigentlich bietet. Alles wie unten beschrieben wird als root ausgeführt.

Praktisch alles wichtige wird in /etc und den Unterordnern abgelegt. Also wechselt man in dieses Verzeichnis. Dort wird ein git Repository angelegt.

Code: Alles auswählen

git init

Das erzeugt ein verstecktes Verzichnis .git in dem git alles verwaltet. Man kann sich noch eine Datei /etc/.gitignore anlegen mit einer Liste von Dateien, die git ignorieren soll. Das brauchen wir aber nicht. Nach dem allerersten Starten von git werden einige Dinge abgefragt, die dann in einer Konfigurationsdatei abgelegt werden. Details habe ich vergessen, nur ist der Prozess problemlos.
Mit

Code: Alles auswählen

git add *

werden alle Dateien aus /etc und den Unterverzeichnissen in das Repository einbezogen. Nun müssen sie von git für das erste Commit noch versioniert werden. Am einfachsten geht das mit

Code: Alles auswählen

git commit -a -m "Ausgangspunkt oder etwas anderes ..."

Mit

Code: Alles auswählen

git status

bekommt man Meldungen über den Zweig vom Repository, in dem man gerade arbeitet und Unterschiede in Dateien im Vergleich zum letzten Einchecken. Nun ist mal zu Testzwecken /etc/resolv.conf geändert und eine neue Datei hinzugefügt. Außerdem wurde /etc/aliases gelöscht. Das Ergebnis ist

Code: Alles auswählen

/etc# git status
Auf Branch bonding
Änderungen, die nicht zum Commit vorgemerkt sind:
  (benutzen Sie "git add/rm <Datei>...", um die Änderungen zum Commit vorzumerken)
  (benutzen Sie "git restore <Datei>...", um die Änderungen im Arbeitsverzeichnis zu verwerfen)
	gelöscht:       aliases
	geändert:       resolv.conf

Unversionierte Dateien:
  (benutzen Sie "git add <Datei>...", um die Änderungen zum Commit vorzumerken)
	systemd/Ueberfluessig_aber_neu

keine Änderungen zum Commit vorgemerkt (benutzen Sie "git add" und/oder "git commit -a")

Wenn das so gewollt ist, dann kann mit mit

Code: Alles auswählen

git commit -a -m "Neuer Stand"

die Änderungen übernehmen. Wenn man sich aber nicht sicher ist kann man sich die genauen Unterschiede auch anzeigen lassen.

Code: Alles auswählen

/etc# git diff
diff --git a/aliases b/aliases
deleted file mode 100644
index b4e7371..0000000
--- a/aliases
+++ /dev/null
@@ -1,15 +0,0 @@
-# /etc/aliases
-mailer-daemon: postmaster
-postmaster: root
-nobody: root
-hostmaster: root
-usenet: root
-news: root
-webmaster: root
-www: root
-ftp: root
-abuse: root
-noc: root
-security: root
-fetchmail: root
-root: chris
diff --git a/resolv.conf b/resolv.conf
index bbc8559..d6e7e62 100644
--- a/resolv.conf
+++ b/resolv.conf
@@ -1 +1,2 @@
+# Ein Kommentar zum probieren
 nameserver 127.0.0.1

Die gelöschte Datei /etc/aliases kann ich mit

Code: Alles auswählen

/etc# git checkout aliases
1 Pfad vom Index aktualisiert

wieder aus dem Repository holen. Wenn ich dann noch /etc/resolv.conf editiere oder aus dem Repository hole sowie die überflüssige Datei lösche, dann ergibt git status keine Unterschiede mehr aus. Damit kann ich zum Beispiel networking konfigurieren Wenn alles funktioniert wird die Version mit einem passenden Kommentar comitten.

Wenn man jetzt etwas anderes ausprobieren will startet man am besten auf einem neuen Zweig , branch genannt. Das funktioniert zum Beispiel mit

Code: Alles auswählen

git branch networkd

Nun darf man nicht vergessen, auf den neuen Zweig zu wechseln mit

Code: Alles auswählen

git checkout networkd

Dann kann man beginnen, Dateien zu löschen oder umzubenennen, die man für diese Konfiguration nicht brauch oder sogar verschwinden müssen. Ein Beispiel ist /etc/network/interfaces. So etwas fundamentales muss man auch mal kontrollieren. Auf meinem System ist networking im Branch opensmtpd konfiguriert. Ich befinde mich aber in einem anderen Branch. Das sehe ich mit

Code: Alles auswählen

/etc# git branch
* bonding
  master
  networkd
  networkmanager
  next
  opensmtpd

Im Branch bondig ist networkd mit bonding konfiguriert. Dabei darf keine Datei /etc/network/interfaces existieren. Ein Vergleich der Verzeichnisse vom aktuellen Branch mit opensmtpd ergibt

Code: Alles auswählen

/etc# git diff opensmtpd network/
diff --git a/network/interfaces b/network/interfaces.org
similarity index 100%
rename from network/interfaces
rename to network/interfaces.org

Die Datei wurde also nur umbenannt. Nun hat man aber oft das Problem bei Netzwerkkonfigurationen, dass nicht alles auf Anhieb funktioniert und man noch etwas im Internet nachlesen will. Wenn man - um bei diesem Beispiel zu bleiben - den neuen Branch networkd temporär so lassen will, dann kontrolliert man den Status ein letztes mal mit

Code: Alles auswählen

git status

.
Neue Dateien werden mit

Code: Alles auswählen

git add *

hinzugefügt und das ganze mit

Code: Alles auswählen

git commit -a -m "Hier geht mir die Fantasie aus."

im Repository abgelegt. Mit

Code: Alles auswählen

git checkout master

kann ich den Zustand vom Branch master oder einem anderen Branch wieder herstellen. Nun kann man per Hand die entsprechenden Dienste stoppen und starten oder man startet einfach den Rechner neu. Damit hat man wieder ein lauffähiges System. Nun kann man wieder recherchieren und gegebenenfalls mit

Code: Alles auswählen

git diff ANDERER_BRANCH

und weiteren Optionen die notwendigen Änderungen im neuen Branch herausfinden. Den kann man dann wieder auschecken und die Änderungen implementieren.

Der Vorteil der Vorgehensweise ist

• Es ist möglich auf verschiedene Versionen zurückzugreifen

• Änderungen sind nachvollziehbar

• Es werden nur wenige git Optionen benötigt. Damit ist die Methode für jeden möglich.

Wenn man mit allem zufrieden ist, dann kann man das ganze git Repository durch das Löschen von /etc/.git entfernen. Man kann auch einzelne Branches löschen. Wer sich etwas mit git befasst hat wird außerdem Änderungen in Branches testen und die dann mit git merge in einem Hauptzweig integrieren. Das wäre dann für interessierte Nutzer der nächste Schritt.

Vielleicht ist das nützlich oder auch nur eine Motivation git auszuprobieren. Es gibt ja auch im home Verzeichnis viele Konfigurationen, an denen man das eine oder andere ausprobieren will.

[DeletedUserReAsG]

Ist das nicht etwas in der Art, das etckeeper macht?

[chrbr]

Den etckeeper kannte ich noch nicht. Aber es sieht zumindest danach aus.

Code: Alles auswählen

etckeeper ist ein Werkzeug, um /etc in einem Git-, Mercurial-, Brz- oder Darcs-Depot 
speichern zu können. Es hängt sich in APT ein und überträgt die Änderungen in /etc, 
die während der Paketaktualisierung gemacht wurden. Es macht die Metadaten der 
Dateien ausfindig, was Versionskontrollsysteme normalerweise nicht unterstützen. 
Dies ist allerdings wichtig für /etc, wie z.B. die Rechte von /etc/shadow. etckeeper 
ist recht modular und konfigurierbar, gleichzeitig auch einfach zu benutzen, 
wenn Sie die Grundlagen des Arbeitens mit Versionskontrolle verstehen. 

Andererseits scheint es "nur" Änderungen von apt zu handdhaben. Vielleicht äußert sich jemand, der etckeeper am Laufen hat.

Auf jeden Fall vielen Dank für die Info,
Christoph

[bluestar]

Andererseits scheint es "nur" Änderungen von apt zu handdhaben. Vielleicht äußert sich jemand, der etckeeper am Laufen hat.

Ich habe etckeeper im Einsatz und das funktioniert auch von Hand prima, du kannst ganz stressfrei mit git in /etc arbeiten lediglich am Ende benutzt du etckeeper commit statt git commit und bist happy.

[JTH]

Andererseits scheint es "nur" Änderungen von apt zu handdhaben.

Das ist wohl eher ein „händelt auch Änderungen durch Updates durch apt“, als „händelt nur Updates durch apt“. Das letztere wär doch ein sehr eingeschränkter Einsatzzweck. Um dich auf Änderung an Konfiguration durch Paketupdates hinzuweisen, gibts eh andere Mechanismen.

[chrbr]

Ich habe Debianetckeeper im Einsatz und das funktioniert auch von Hand prima, du kannst ganz stressfrei mit git in /etc arbeiten lediglich am Ende benutzt du etckeeper commit statt git commit und bist happy.

Das ist wohl eher ein „händelt auch Änderungen durch Updates durch apt“, als „händelt nur Updates durch apt“. Das letztere wär doch ein sehr eingeschränkter Einsatzzweck.

Dazu habe ich drei Fragen. Die dritte kann man wohl mit "ja" beantworten. Ich stelle sie trotzdem.
Was ist denn der Unterschied zwischen dem Einsatz von etckeeper und git?
Wenn der etckeeper mehr als Updates durch apt händelt, dann betrifft das auch Dateien und Verzeichnisse außerhalb von /etc?
Wäre der Einsatz von git in /etc dann nur eine Untermenge der Funktionalität von etckeeper?

[heisenberg]

Was ist denn der Unterschied zwischen dem Einsatz von etckeeper und git?

etckeeper ist so eine Art kleiner Wrapper um git. Es werden z. B. vor oder nach apt-Aufrufen automatisch commits erstellt, ebenso täglich.

Wenn der etckeeper mehr als Updates durch apt händelt, dann betrifft das auch Dateien und Verzeichnisse außerhalb von /etc?

Nein. etckeeper trackt nur Änderungen von /etc.

[chrbr]

Hallo @heisenberg,

Nein. etckeeper trackt nur Änderungen von /etc.

Vielen Dank für die Info. Dafür habe ich eigentlich erst mit dem git Repository auf /etc angefangen. Zu meiner Geschichte: Ich habe noch zu OS/2 Zeiten mit Suse angefangen. Nach einigen Jahren habe ich dann Debian ausprobiert. Damit war ich auch lange zufrieden. Noch bevor systemd eingeführt wurde in ich dann zu FreeBSD gewechselt. Das ist deutlich aufgeräumter als Linux, dafür hängt es mit den Treibern weit hinterher. Bei FreeBSD gibt es eine seht saubere Trennung zwischen dem Betriebssystem und dem, was der Benutzer so installiert. Konfigurationen für das Betriebssystem sind in /etc. Alles vom Benutzer landet in /usr/local/etc.

Nun ist mir letzten Jahres mein alter Laptop im wahrsten Sinne des Wortes abgeraucht. Dann habe ich mir beim Afb Shop einen "refurbishten" T470 von Lenovo gekauft. Für meine Zwecke reicht ein Griff in das unterste Regal . Vom T470 gibt es drei Varianten mit unterschiedlichen Prozessoren Leider gab es bei der Installation von FreeBSD-12.3-Release bei meinem Modell Probleme mit ACPI Fehlern. Debian läuft dagegen völlig problemlos. Nur wusste ich vorab, dass bei Debian fast alles in /etc konfiguriert wird. Um davon ein Bild zu bekommen habe ich sehr früh ein git Repository auf /etc angelegt. Letztendlich hat mir die Erfahrung mit dem Repository gerade bei Netzwerkfragen sehr geholfen. Deshalb habe ich auch die Zusammenfassung geschrieben.

Das etckeeper auch brauchbar gewesen wäre habe ich noch nicht gewusste. Das Tracken von apt Aktionen im Hintergrund ist aber sicher auch sehr praktisch. Und wenn sich eine Zeit lang nichts ändert, dann wird man das Repository nicht unnötig aufblasen.