Hallo, ein sehr interessantes Thema, weil man hier viel über CVS lernen kann. Mathias Bauer wrote:
Änderungen doch einmal cvs zu testen. Bisher kenne ich es nur für reine Programmiersachen, aber im wesentlichen dürfte es ja für alle Textdateien funktionieren.
Das tut es natürlich - Quellcode ist ja auch nur ASCII.
Allerdings gibt es ein Problem: Nachdem ich (natürlich testweise) zunächst ein Repository und einige Dateien soz. als Testprojekt angelegt habe verhält sich cvs beim "commit" von Änderungen an diesen Testdateien sehr merkwürdig:
Die Meldung lautet: cvs [commit aborted]: cannot commit files as 'root'
Ist gar nicht so merkwürdig. CVS akzeptiert kein commit als root, weil dieser Benutzername nicht eindeutig ist, wenn man remote arbeitet. Woher soll CVS denn wissen, ob der lokale Systemadmin und der auf der Client-Maschine als Personen identisch sind? Dann könnte ja jeder, der sich remote als root ausgibt dem Benutzer root auf dem CVS-Server Dateien unterschieben.
Kann mir jemand erklären, warum ich als root cvs nicht in dieser Weise einsetzen darf? (Natürlich arbeite ich normalerweise nicht unter root.)
Man darf es nicht mal lokal - das finde ich auch etwas seltsam.
Mein erster Gedanke, diesen Fehler bzw. dieses Feature zu umgehen bestand darin, einen separaten User "root2" anzulegen (mit einer uid != 0), diesen in die Gruppen root einzufügen, in welcher bisher nur root Mitglied war. Um "vernünftig" an meinen Konfigurationsdateien arbeiten zu können, müsste ich aber reihenweise permissions verändern, damit auch root2 diese Dateien bearbeiten darf. Vom Sicherheitsstandpunkt aus habe ich daher das root2-Vorhaben wieder abgebrochen.
Gute Entscheidung. Allerdings gibt es einen Trick um auch als root ein commit machen zu dürfen. Das geht aber nur lokal, d.h. auf der Maschine des CVS-Servers. Angenommen, Du hast dort einen Benutzer namens 'cvs', der natürlich Schreibrechte für das Repository haben muß. Dann startest Du als 'cvs' ein xterm o.ä. und wechselst in eines der Arbeitsverzeichnisse (wo sich ein Verzeichnis CVS mit einer Root-Datei mit dem Inhalt ':local:<Pfad-zum-Repository>' befindet). Jetzt ist es an der Zeit in dem xterm root zu werden. Dann sollte ein commit funktionieren.
Wie verwaltet ihr eure Systemkonfiguration? Ich nehme mal nicht an, dass ihr alle Einzelheiten im Kopf hat oder separat irgendwelche Protokolldateien führt, oder? Ich meine, der Ansatz von cvs ist dafür einfach zu genial. Und Kommentare und Konfiguration sind hier einfach "näher" beeinander!
Allerdings gibt es schon diverse Ansätze, um auch als Nicht-Root cvs für die Versionsverwaltung der Systemkonfigurationsdateien zu nutzen, insbesondere, wenn man remote arbeiten will: 1) Wenn man über ssh kommuniziert, muß die Umgebungsvariable CVS_RSH=cvs eportiert werden. CVSROOT ist schon richtig, wenn man sich in einem ausgecheckten Arbeitsverzeichnis befindet. 2a) Man macht einen Benutzer zum "sudoer" (man sudo bzw. man sudoers), d.h. man überträgt einem vertrauenswürdigen Benutzer gewisse hoheitliche Aufgaben, so daß er z.B. Dateien in /etc schreiben darf. 2b) Alternativ läßt man irgendeinen lokalen Benutzer (der auf dem CVS-Server auch vorhanden sein muß) ein Arbeitsverzeichnis auschecken. Auch den ganzen Rest der CVS-Geschichten erledigt dieser. root macht weiterhin die Systemkonfiguration. Nun muß root nur noch die veränderten Dateien in das Arbeitsverzeichnis der CVS-Verwalters kopieren, d.h. die Arbeitsdateien dort überschreiben. Dieser Vorgang kann vollautomatisch mit einem cron-Job erledigt werden. Wenn root sich "verkonfiguriert" hat muß der CVS-Verwalter die zuletzt als funktionierend bekannten Konfigurationsdateien aus dem Repository ins Arbeitsverzeichnis holen, von wo sich root die Dateien wieder abholt. Tip: Als root auf einer anderen Maschine sollte man statt 'scp' lieber 'rsync' verwenden, z.B. $> rsync -rlp -e ssh root@maschine:/home/cvs/<Pfad>/etc ./ Das geht für eine große Datenmenge (wie in /etc) viel schneller. Außer dem stolpert 'scp' über named pipes, 'rsync' nicht. Ich hoffe, meine Hinweise nützen Dir was. Ich kann jedenfalls, seitdem ich CVS für die Systemverwaltung benutze, jede ehemals funktionierende Konfiguration wiederherstellen. Auf eines muß ich aber noch hinweisen: Man sollte sich einen wesentlichen Unterschied zur Versionsverwaltung von Quellcode klarmachen: Während man bei letzterem ein commit i.d.R. dann macht, wenn eine Datei übersetzbar ist, d.h. sonst überhaupt nichts funktionieren muß, macht man ein commit bei Konfigurationsdateien erst dann, wenn man die Konfiguration ausgiebig getestet hat, weil es später sonst passieren kann, daß man sich eine nicht funktionierende Konfiguration aus dem Repository holt. Da bei vielen Konfigurationen mehrere Dateien beteiligt sind, sollte man sich sinnvolle Gruppierungen (modules) überlegen, und funktionierende Konfigurationen mit einem tag versehen. Denn, wer merkt sich schon die CVS-interne Versionsnummer für jede Datei, die zu einer bestimmten Konfiguration gehört? Wenn Du einen Vorschlag für das Anlegen von sinnvollen Modulen im Arbeitsverzeichnis möchtest, melde Dich nochmal. Du solltest dann auch etwas über das Editieren der Datei modules im Repository wissen. Viel Spaß, Thomas Michalka P.S.: Kennst Du "Version Mangement with CVS" von Cederqvist et al.? Ein sehr gute Anleitung, finde ich.