On Sun, 2 Feb 2003, Thomas Michalka wrote: Hallo,
ein sehr interessantes Thema, weil man hier viel über CVS lernen kann.
Ja, das möchte ich schon.
Mathias Bauer wrote:
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.
Ok, das leuchtet mir ein. Ich dachte nur, dass auf einem Stand-alone Rechner für CVS root genauso ein "normaler" Benutzer ist wie jeder andere auch. Außerdem habe ich für meinen CVS-Einsatz nur die Umgebungsvariable CVSROOT im globalen Profile gesetzt -- ein Server läuft bei mir nicht! Daher fand ich das commit-Verhalten "merkwürdig". Aber wenn cvs in komplexeren Systemumgebungen (viele Rechner, viele Benutzer) betrieben wird, hast Du natürlich recht.
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.
Eben, s.o.
[User "root2" anzulegen, viele Permissions von Konfig-Dateien verändern: zuviel Aufwand, zu unsicher]
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.
Werde ich durchtesten. Ist es egal wie diese Root-Datei heißt?
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.
Das scheint mir der praktischste Ansatz für lokales Arbeiten zu sein. Werde ich auch ausprobieren.
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. [...] 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.
Ich sehe dabei nur zwei kritische Punkte: (i) Root muss nur(!) bei den Permissions aufpassen, wenn er Dateien des CVS-Verwalters verwendet. (ii) Das Repository muss sich irgendwie "abgeschotten" lassen, damit nicht die ganze Konfiguration offengelegt wird. Aber dazu muss ich mich in CVS erst nochmal richtig einarbeiten.
Ich hoffe, meine Hinweise nützen Dir was. Ich kann jedenfalls, seitdem ich CVS für die Systemverwaltung benutze, jede ehemals funktionierende Konfiguration wiederherstellen.
Ich bin für jeden Hinweis dankbar. Das Wiederherstellen ist auch mein Hauptanliegen. Daneben möchte ich manche Dinge etwas ausführlicher kommentieren und zwar nicht direkt *in* den Konfigurationsdateien.
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?
Ist eigentlich klar. Zwischen einer funktionierende Modem-Konfiguration und nicht funktionierendem X möchte ich auch keine Abhängigkeiten haben....
Wenn Du einen Vorschlag für das Anlegen von sinnvollen Modulen im Arbeitsverzeichnis möchtest, melde Dich nochmal.
Danke schon im Voraus. Ich möchte mir das aber erst einmal selbst überlegen. Dann melde ich mich sicher nochmal.
Viel Spaß, Thomas Michalka
P.S.: Kennst Du "Version Mangement with CVS" von Cederqvist et al.? Ein sehr gute Anleitung, finde ich.
Danke, die werde ich mir demnächst vornehmen. Gruß, Mathias