git für /usr/local/etc

schorsch_76

FreeBSD Fanboy
Hallo zusammen,

leider hat meine Suchmaschine hier jede Menge ausgespuckt, nur nichts passendes ..... ;)

Macht es Sinn für /usr/local/etc und /etc eine Versionsverwaltung einzusetzen?

Den es scheint für mich das diese zwei Verzeichnisse das wichtigste im ganzen System sind das im Falle einer Neuinstallation das System wieder zum laufen zu bekommen.
 
Macht es Sinn für /usr/local/etc und /etc eine Versionsverwaltung einzusetzen?
Als Backup?
Ansonsten: Ich hab das so gelöst, dass das Dateisysteme sind die man snapshoten kann.

Den es scheint für mich das diese zwei Verzeichnisse das wichtigste im ganzen System sind das im Falle einer Neuinstallation das System wieder zum laufen zu bekommen.
Hindert Dich ja auch niemand daran mit git ein Backup zu machen. Ich versteh jetzt nicht ganz, worauf Du hinaus willst.
 
Ich wollte etc ein git Repository machen und dass dann auf meinen git server pushen um es immer gesichert zu haben. Ich kann mich daran erinnern dass unter Linux das nicht so eine gute Idee war.... :confused: .... Jetzt wollte ich wissen ob das unter FreeBSD geht. Deshalb brauchte man unter Linux etwas wie https://joeyh.name/code/etckeeper/
 
Naja mit ner passenden .gitignore könnte man so etwas schon für die Configs machen, aber ob es schlau ist weiß ich nicht.
Das einzige was ich so "sichere"/bearbeite sind die Configs/vHosts vom Apache, von allen anderen habe ich ein diff um zu wissen was ich geändert habe. Erleichtert auch bei einem upgrade von Software $X die Arbeit, falls neue Parameter dazu gekommen sind oder entfernt wurden.
 
Ich wollte etc ein git Repository machen und dass dann auf meinen git server pushen um es immer gesichert zu haben.
Das würde ich dann vielleicht doch nicht machen (zumindest nicht unverschlüsselt). Immerhin enthält /etc auch sensible Informationen.

Und um es dabei zu haben, kann man auch ne Kopie auf nem USB-Stick mit herum tragen.

Ich kann mich daran erinnern dass unter Linux das nicht so eine gute Idee war.... :confused:
Hab ich noch nie gehört und wüsste jetzt auch nicht, worin das Problem besteht.

Deshalb brauchte man unter Linux etwas wie https://joeyh.name/code/etckeeper/
Ehrlich gesagt weiß ich immer noch nicht so ganz, was Du vor hast.
Rein für Backup-Zwecke muss man /etc jetzt nicht irgendwie anders handhaben als andere Backups auch.
 
ich glaube ich hatte mich geistig "verrannt".
Ich weiß nicht. Also so ein Repository (muss ja auch nicht online sein) kann ja durchaus Sinn machen, wenn man z.B. mehrere Rechner betreut und man irgendwo ne Option zufügt und sich denkt "hey; die könnte auch bei anderen Rechnern sinnvoll sein".
Dann kann so ne Versionsverwaltung mit Änderungsverfolgung ja durchaus Sinn machen. Das Backup für /etc würde dann sogar einfach mit abfallen, ohne das man sich da drum kümmern muss.
 
Ich weiß nicht. Also so ein Repository (muss ja auch nicht online sein) kann ja durchaus Sinn machen, wenn man z.B. mehrere Rechner betreut und man irgendwo ne Option zufügt und sich denkt "hey; die könnte auch bei anderen Rechnern sinnvoll sein".
Dann kann so ne Versionsverwaltung mit Änderungsverfolgung ja durchaus Sinn machen. Das Backup für /etc würde dann sogar einfach mit abfallen, ohne das man sich da drum kümmern muss.
In der Theorie ist das nett, in der Praxis stolperst du darüber, dass die unterschiedlichen Rechner dann doch unterschiedliches machen. So ist es zwar nett die neue Option "XYZ" in der rc.conf überall zu verteilen, aber die Netzwerkeinstellungen, Hostname etc. was du noch in der Datei hast willst du dann doch nicht unbedingt überall identisch haben.

Ich mache seit einiger Zeit das Ganze per restic. Inkrementell, verschlüsselt und über SSH abzuwickeln.
 
Ich weiß nicht. Also so ein Repository (muss ja auch nicht online sein) kann ja durchaus Sinn machen, wenn man z.B. mehrere Rechner betreut und man irgendwo ne Option zufügt und sich denkt "hey; die könnte auch bei anderen Rechnern sinnvoll sein".
Dann kann so ne Versionsverwaltung mit Änderungsverfolgung ja durchaus Sinn machen. Das Backup für /etc würde dann sogar einfach mit abfallen, ohne das man sich da drum kümmern muss.

Allein aus Gründen der Reproduzierbarkeit würde ich die Konfiguration unter Ansible o.ä. verwalten und dort versionieren. Das vermeidet ganz nebenbei noch Probleme wie Configuration Drift.

Sofern keine persistenten Daten auf dem Server gespeichert werden, kann man dann im zweiten Schritt komplett auf die Sicherung des Servers verzichten und im Katastrophenfall einfach den Server neu aufbauen.
 
Falls du deine Konfiguration wirklich separat in Git haben willst, dann würde ich dabei darauf achten nur die von dir geänderten Konfigurationen dort zu speichern, wobei in den meisten Fällen sowas wie Ansible und Co. wohl besser klappen wird. Allerdings ist das auch nicht das Allheilmittel und man kann da andere Problemchen[1] haben. Es kommt aber stark auf den genauen Anwendungsfall an, wie groß der Vorteil davon ist.

In den meisten Fällen wirst du dir aber immerhin mit /usr/local/etc leichter tun, als mit /etc. Da zerhaust du dir im Fall des Falles nicht gleich das Basissystem. Wenn du tatsächlich Git verwendest wäre wenn du das magst noch ein Shell-Skript mit sysrc-Befehlen ganz gut. Dann kannst du nachdem du ein Basissystem hast den Rest dynamischen ändern.

Wenn das ohnehin Teil eines Komplett-Backup ist willst du das vielleicht wirklich generisch machen. Da sei nur anzumerken, dass im laufenden Betrieb ein zfs-snapshot immer besser ist, weil du da keine Zustände haben kannst, wo Dateien während des Backups geändert werden können. Das heißt für solche Dinge immer extra was überlegen. Der Klassiker da ist ein DB-Dump wenn du eine Datenbank hast oder ähnliches. Aber es ging dir ja ohnehin speziell um Konfiguration. Da gibt's im Grunde nur so Sachen, wie: Vergiss beim Restore, wenn das nicht Teil des Backups ist so Dinge wie newaliases für /etc/aliases oder cap_mkdb für /etc/login.conf auszuführen. Für solche Dinge ist Ansible nett. Alternativ könntest du die .db-Files einfach mit ins Backup packen.

[1] Templates sind okay, aber dann tut's potentiell auch Git, wen du aber mit Blöcken oder einzelnen Zeilen arbeitest ist aber Testen angesagt und je nach Setup kann dann eine Git-Lösung oder eben Copy und Paste in ein Repo weniger Wartung brauchen. Ansible bzw. Configuration Management ist meiner Erfahrung netter wenn du auf einander aufbauende Sachen hast, wie das meist auf Servern ist, auf einem Desktop (oder auf einem einzelnen, sehr kleinen Server) kann es schnell mal sein, das Ansible ein wenig Overkill ist und du damit mehr Arbeit hast als an ein paar einfachen Files und ggf. ein oder zwei kleinen Skripts.
 
Ich habe das jahrelang so gemacht. Zwar nicht mit "git" dafür aber mit "svn". Es war sehr praktisch. Sollte sich ein Wert z.B. in der Apache Config nicht als tauglich erweisen, konnte man ihn schnell wieder zurücksetzen. Heute verwende ich es nicht mehr, da ich sämtliche VMs per Saltstack/Ansible hochziehe und verwalte.
 
Zurück
Oben