Versionskontrolle für /etc Unter *bsd?

Welche schlüsselfertigen Lösungen gibt es, um /etc unter Versionskontrolle, unter verschiedenen Unices? Schlüsselfertig bedeutet nicht unbedingt Teil der Basisinstallation, aber die folgenden Funktionen wären nett:

• Hängt sich in VCS-Befehle ein, um Metadaten zu verwalten (Eigentum, Berechtigungen);
• Integration mit dem Paketmanager (automatische Ausführung vor und nach Installationen, intelligente Handhabung von Upgrades);
• Upstream-Dateiversionen als Zweig behandeln;
• eine vorausgefüllte Ignorierliste;
• Unterstützung für mehrere zugrunde liegende VCS (insbesondere verteilte).

Ich verwende etckeeper unter Debian und Derivaten. Es hat alle oben genannten Funktionen, außer dass es die Upstream-Versionen nicht verfolgt. Ich möchte mehr über Alternativen erfahren, insbesondere zu *BSD.

Akzeptierte Antwort:

Unter Gentoo das Tool zum Verwalten von paketinduzierten Änderungen an /etc (genannt dispatch-conf ) unterstützt rcs, um Änderungen zu verfolgen, aber das ist nicht wirklich leistungsfähig.

Ich tendiere dazu, mein /etc zu versionieren über git , zumal ich durch die Verwendung verschiedener Zweige meine /etc behalten kann so ähnlich wie möglich über verschiedene Distributionen hinweg, während so viel Zeug wie möglich an einem Ort bleibt (für einige Bereiche, die offensichtlich fehlschlagen, ist zum Beispiel die Apache-Konfiguration zwischen verschiedenen Distributionen wirklich unterschiedlich). So funktioniert es:

• Ich habe meinen master repo mit meinen Standardkonfigurationsdateien.

• Jetzt komme ich in Kontakt mit einer neuen Distribution, also erstelle ich einen neuen Zweig, der auf meinem master basiert branch basierend auf dem Namen der Distribution (in diesem Beispiel debian).

• Debian speichert einige Konfigurationsdateien an einem anderen Ort als meinem master also mache ich eine git mv file new_loc . Und alles ist in Ordnung.

• Ich wechsle zurück zu master und ändere diese Datei, weil ich einige spezifische Konfigurationsanweisungen hinzugefügt habe.

• Wenn ich master zusammenführe in mein debian branch wird die verschobene Datei geändert, also kann ich im Grunde nur die meisten Dinge in meinem master ändern Zweig und muss nur Änderungen in meinen „Distributions“-Zweigen zusammenführen (normalerweise sind sie eher eine Mischung aus Verteilungs- und Zweckzweigen, ein Debian-Server hat offensichtlich einige Unterschiede zu einer Debian-Workstation, aber die Funktionen funktionieren immer noch).

Also im Grunde habe ich eine „generische Konfiguration“ in master und (um es in Begriffen der objektorientierten Programmierung zu sagen) diese in meine Branches vererben (die auch voneinander erben können).

Abgesehen davon, git ’s-Mechanismen zum „Rosinenpicken“ von Commits (in diesem Fall Änderungen an /etc/ ) hat mir manchmal sehr geholfen, wenn ich nur Teile einer bestimmten Konfiguration benötigte.

Verwandte:Führen Sie den Unix-Befehl genau in sehr kurzen Intervallen aus, OHNE dass sich im Laufe der Zeit Zeitverzögerungen ansammeln?

Nun zu einigen Ihrer Ideen:

• Wenn ich mehr Paketmanager-Integration bräuchte, würde ich wahrscheinlich Wrapper-Skripte dafür verwenden (im Moment tue ich das nicht).
• Upstream-Versionen als Zweig zu behandeln, würde mit git gut funktionieren , es ist nur ein weiterer Zweig, den Sie manchmal (teilweise) in master zusammenführen
• Die Ignore-Liste in Git ist die Datei .gitignore in Ihrem Repo, damit das abgedeckt ist.