Konfigurationsdateien via SVN verwalten?

tux18

Member
Hallo,

ich würde gerne die Konfigurationsdateien unserer Router, Switche und Linux-Systeme via Subversion verteilen (haben für die Entwicklung bereits ein SVN und ich möchte nicht alles auf GIT umbauen).

Hat jemand eine Art HowTo? Wie rotiert ihr die Logs im SVN?
 
Ich selbst mache es nicht so (noch nicht genuegend "Leidensdruck" dafuer bei mir...)
Allerdings wuerde ich es nur fuer sinnvoll erachten, die Konfigurationsdateien und nicht die Logs per SVN zu verwalten.
Zum zentralen "Verwalten" der Logs wuerde sich wohl eher ein Log-Host eignen.
 
Für Router und Switches hab ich in größeren Umgebungen (>20 Geräte) immer den "Really Awesome New Cisco confIg Differ" benutzt (net-mgmt/rancid).
Der hat komplett automatisiert die Konfigs ausgelesen und auch schön nen diff geschickt, für Änderungen. Sehr interessant für die running-config :-).
Vorraussetzung sind allerdings die passenden Geräte: 3COM/HP und natürlich Cisco.

Auf Servern nehm ich (immer noch) RCS. Das ist schön dezentral, die Versionen liegen direkt neben den Originalen, d.h. ich kann sehr schnell mal ins commit log gucken, etc. Und mit im Backup sind die Versionen auch gleich.
 
RCS sollte zu FreeBSD 10.0 rausfliegen, aber der Flamewar war viel zu heißt. Also blieb es drin und damit rückte das Ziel eines GPL-freien BSDs wieder weiter nach hinten. *grrr*
 
Auf Servern nehm ich (immer noch) RCS. Das ist schön dezentral, die Versionen liegen direkt neben den Originalen, d.h. ich kann sehr schnell mal ins commit log gucken, etc. Und mit im Backup sind die Versionen auch gleich.

Ich bevorzuge den zentralen Ansatz; mit einer steigenden Anzahl Server wird es mit dezentraler Verwaltung und RCS schnell unhandlich und fehlerträchtig.

Je nach gewünschtem Automatisierungsgrad und Anwendungsfall lohnt sich der Einsatz eines ordentlichen Configuration-Management-Tools wie puppet. Das würde sich mit SVN (oder git) auch sehr gut ergänzen.
 
RCS sollte zu FreeBSD 10.0 rausfliegen, aber der Flamewar war viel zu heißt. Also blieb es drin und damit rückte das Ziel eines GPL-freien BSDs wieder weiter nach hinten. *grrr*
Um hier etwas Kontext dazu zu geben. RCS wurde als Ersatz für das Unix Versionstool SCCS entwickelt. Hauptsächlich, weil SCCS nicht unter einer freien Lizenz war.

Leider hatte RCS ein paar Nachteile gegenüber SCCS. Der größte, dass es keine Prüfsummen verwaltet mit denen man erkennen kann das ein Repository kaputt ist.

Wenn man so etwas früh merkt, kann man das zeitnah aus dem Backup reparieren. Wenn nicht macht man im schlimmsten Fall über einen langen Zeitraum Änderungen an einem kaputten Repo. Wenn es einem dann um die Ohren fliegt - keine Ahnung wie man dann noch erkennt wann es kaputt gegangen ist.
 
Ich bevorzuge den zentralen Ansatz; mit einer steigenden Anzahl Server wird es mit dezentraler Verwaltung und RCS schnell unhandlich und fehlerträchtig.

Seh ich auch so, bei überschaubarer Anzahl von Servern mit sehr unterschiedlichen Konfigs, klappt es noch grade so mit RCS.
Bei vielen gleichartigen Servern ist es zentral natürlich besser, auch wenn man im Team arbeitet, weil man so die komplette Änderungshistory im Idealfall an einer Stelle hat.

RCS ist mir übrigens noch nie um die Ohren geflogen. Bei ner rc.conf mit wenig Änderungen im Lebenszyklus des Servers geht es mir primär um das commit log: warum hatte ich das nochmal geändert...
Da sind die Anforderungen geringer als bei der Verwaltung von komplexem Quellcode. :-)
 
Hoi,

ich mach das bärig mit git - wobei ich von dem ganzen Mist wie git und subversion und co koi Fan bin - abär das is noch halbwegs bärentauglich.

Gruß Bummibaer
 
Zurück
Oben