Ziel: 
manuelle Änderungen an den Einstellungen für an System zu sichern und reproduzierbar zu machen.

Vorteile Einsatz Subversion:
- Historie der Änderungen
- Vergleiche zwischen beliebigen Versionen
- netzwerkweit zur Verfügung
- Nachvollziehbarkeit von Änderungen (was, wann, wer)
- Kommentare, warum eine Änderung erfolgte können (und sollten) mit gepfelgt werden

Grundsätzlich ist zwischen Methoden zu unterscheiden:
Konfigurationsdateien werden
1. an ihrer normalen Position modifiziert, getestet und dann ins Subverion Repository kopiert
2. im Repository modifiziert und dann ins System eingespielt (ggf. noch Dienste neu starten)

Methode 2 ist eigentlich "sauberer", da Änderungen erst als Benutzer erfolgen und erst ihre Aktivierung durch root erfolgen muss. Damit ergibt sich auch der Vorteil, dass nicht 2 Leute gleichzeitig die selbe Datei modifizieren (bei einem Subversion checkin würde zumindest eine Warnmeldung erzeugt). Methode 1 hat aber den Vorteil, dass Änderungen direkt getestet werden können.
In beiden Fällen ist zu beachten, dass die Referenz immer (!) im Subversion liegt. D.h. lokale Änderungen, die nicht ins Subversion eingecheckt würden, werden ggf. überspielt.

Methode 1 benötigt i.d.R. das einloggen als root Benutzer.

Deshalb sollte die entsprechenden Subversion Checkouts unter 
/root/svn/$BENUTZERNAME erzeugt werden.
Um nur beim schreiben nicht aber beim jeden Lesevorgang aus dem Repository nach einem Passwort gefragt zu werden,
sollte eine Nur-Lese Kennung für den Benutzer root hinterlegt werden.
Im diesen Falle des LVermGeos bietet sich die Kennung "lvermgeo" (mit bekannten Passwort) an. Hinterlegt wird sie automatisch mit einem checkout OHNE die "--no-auth-cache" Option:

svn checkout --username lvermgeo https://dass-it.de/svn/lvermgeo/technical/config


z.B.
cd /root/svn/joergs
Proxy muss eingestellt sein (/etc/subversion/servers oder ~/.subversion/servers)
svn checkout --no-auth-cache --username joergs  https://dass-it.de/svn/lvermgeo/technical/config
(ggf. auch nur 
svn checkout --no-auth-cache --username joergs  https://dass-it.de/svn/lvermgeo/technical/config/server
bzw. 
svn checkout --no-auth-cache --username joergs  https://dass-it.de/svn/lvermgeo/technical/config/client)

Diese Verzeichnisse liegen unterhalb von root, da für den Zugriff auf einige Konfigurationsdateien root Rechte erforderlich sind, andererseits root nicht auf den Home Bereich des NFS Servers zugreifen kann. Ansonsten ist die Position des Subversion Checkouts aber nicht relevant und kann an jeder Stelle angelegt werden.
Achtung: das Zugriffspasswort für Subversion wird im Klartext im jeweiligen Verzeichnis gespeichert!

Die Verzeichnisstruktur unterhalb von 
svn/lvermgeo/technical/config/*/*/
sollte dem des Systems entsprechen.
D.h. wenn auf dem Client (9.1) die Datei /etc/sysconfig/cups angepasst wird, so ist diese im Subversion unter 
svn/lvermgeo/technical/config/client/9.1/etc/sysconfig/cups
zu pflegen.

Bevor eine Datei erstmalig modifiziert wird, 
ist eine .orig Kopie (cp -a) zu erzeugen.
Sollte die Datei neu erstellt werden, ist eine leere .orig Datei zu erstellen.

*** vor dem modifizieren einer Datei (Beispiel: /etc/sysconfig/cups)
0. Subversion auf den aktuellen Stand bringen (svn update)
1. cd /etc/sysconfig
2. cp -a cups cups.orig (falls eine neue Datei angelegt wird touch cups.orig)
4. cd /root/svn/joergs
7. svn commit -m "orig von Distribution XYZ"

*** weitere Modifikationen:
0. Subversion auf den aktuellen Stand bringen (svn update)
1. Datei in den Subversion Bereich kopieren
2. svn commit

*** dasscm
Das Skript "dasscm" vereinfacht die Handhabung.
1. Umgebungsvariable DASSCM_USER auf Subversion Benutzer setzen (DASSCM_USER=joergs)
2. Umgebungsvariable DASSCM_REPO setzen (DASSCM_REPO=/root/svn/joergs)
3. dasscm add /etc/sysconfig/cups

*** sc_chkconf.pl
Zur Vereinfachung existiert das Skript sc_chkconf.pl. 
Dieses Skript überprüft, ob die Dateien, die im Subversion eingecheckt sind auch denen im System entsprechen. Falls nicht, fragt es, ob sie diese zum Subversion Checkout kopieren soll.
Danach kann man sich nochmals mit "svn diff" alle Veränderungen anschauen und mit "svn commit" einchecken.


Referenz Clients:
Normalerweise werden Änderungen auf einen frisch aufgesetzten Rechner getestet. Wenn diese Modifikationen zufriedenstellend sind, werden diese auf dem Referenz Rechner durchgeführt.
Die Modifikationen sollten dann auch ins Subversion eingepflegt werden.

Server:
Server werden z.Zt. noch so gehandhabt wie oben beschrieben. Da ggf. der selben Dienst mit gleicher Konfiguration auf verschiedenen Systemen läuft, muss geschaut, ob eine Konfiguration nach Diensten Sinn macht. Ggf. mit Skripts zur Verteilung der Konfiguration auf verschiedene Server und aktivierung der Dienste.