cvs fuer Systemkonfiguration mit root
Hallo Liste, weil ich langsam Gefahr laufe, den Überblick über meine Konfigurationsdateien (speziell in /etc) zu verlieren, und ich nicht mehr weiß, warum ich damals (=vor laaaanger Zeit) dieses oder jenes eingestellt habe, ist mir die Idee gekommen, für die Ä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. 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' Kann mir jemand erklären, warum ich als root cvs nicht in dieser Weise einsetzen darf? (Natürlich arbeite ich normalerweise nicht unter root.) 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. 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! Viele Grüße, Mathias
Hallo Mathias, * Mathias schrieb am 31.01.2003:
Hallo Liste,
weil ich langsam Gefahr laufe, den Überblick über meine Konfigurationsdateien (speziell in /etc) zu verlieren, und ich nicht mehr weiß, warum ich damals (=vor laaaanger Zeit) dieses oder jenes eingestellt habe, ist mir die Idee gekommen, für die Ä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.
Diese Gedanken kenne ich *schmunzel*.
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'
Ich habe aus gegebenem Anlass pserver deaktiviert und lasse nur SSH zu, d.h. nur wer den SSH-Key zu seinem User kopiert hat, darf überhaupt zugreifen. Zusätzlich muss man auch in einer bestimmten Gruppe sein natürlich. Allerdings hat das den Nachteil, dass man z.B. keine Read-Only-User definieren kann, zumindest in meiner sehr auf Sicherheit bedachten Konfiguration, die "others" keine Rechte gibt.
Kann mir jemand erklären, warum ich als root cvs nicht in dieser Weise einsetzen darf? (Natürlich arbeite ich normalerweise nicht unter root.)
commit als root mit pserver geht nicht. Ich glaube, das irgendwo gelesen zu haben, oder ich bin selber mal darübergefallen. [alternativer User mit root-Rechten] Geht nicht, bzw. ist zu aufwendig.
Wie verwaltet ihr eure Systemkonfiguration? Ich nehme mal nicht
Leider nicht.
an, dass ihr alle Einzelheiten im Kopf hat oder separat
Wie, Du nicht? Das ist aber schade... :-(
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!
Ich mache mich gerne dafür stark, ich bin auf alle Fälle bereit, das auch einzusetzen, da ich das auch gebrauchen kann (privat/Arbeit). Gruesse, Thomas
On Sat, 1 Feb 2003, Thomas Preissler wrote:
* Mathias Bauer schrieb am 31.01.2003:
[Überblick über viele Konfigurationsdateien, potenzielle Lösung: cvs]
Diese Gedanken kenne ich *schmunzel*.
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'
Ich habe aus gegebenem Anlass pserver deaktiviert und lasse nur SSH zu, d.h. nur wer den SSH-Key zu seinem User kopiert hat, darf überhaupt zugreifen. Zusätzlich muss man auch in einer bestimmten Gruppe sein natürlich.
Allerdings hat das den Nachteil, dass man z.B. keine Read-Only-User definieren kann, zumindest in meiner sehr auf Sicherheit bedachten Konfiguration, die "others" keine Rechte gibt.
Ich verwende zum Konfigurieren aber gar kein ssh sondern arbeite direkt auf der Konsole unter root.
Kann mir jemand erklären, warum ich als root cvs nicht in dieser Weise einsetzen darf? (Natürlich arbeite ich normalerweise nicht unter root.)
commit als root mit pserver geht nicht.
Ich glaube, das irgendwo gelesen zu haben, oder ich bin selber mal darübergefallen.
[alternativer User mit root-Rechten]
Geht nicht, bzw. ist zu aufwendig.
Wie verwaltet ihr eure Systemkonfiguration? Ich nehme mal nicht
Leider nicht.
an, dass ihr alle Einzelheiten im Kopf hat oder separat
Wie, Du nicht? Das ist aber schade... :-(
Doch, natürlich ... irgendwie ... nach viel *Kopfzerbrech* ...
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!
Ich mache mich gerne dafür stark, ich bin auf alle Fälle bereit, das auch einzusetzen, da ich das auch gebrauchen kann (privat/Arbeit).
ACK
Gruesse, Thomas
Grüße, Mathias
Hallo Mathias, * Mathias schrieb am 01.02.2003:
On Sat, 1 Feb 2003, Thomas Preissler wrote:
* Mathias Bauer schrieb am 31.01.2003:
[Überblick über viele Konfigurationsdateien, potenzielle Lösung: cvs]
Diese Gedanken kenne ich *schmunzel*.
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'
[CVS via SSH, Vorteile, Nachteile]
Ich verwende zum Konfigurieren aber gar kein ssh sondern arbeite direkt auf der Konsole unter root.
Ich habe mir jetzt ein paar Gedanken gemacht. Ich habe nur das Problem, wie wir den "commit" als User "root" umgehen können. Manche Dateien darf ja nur "root" lesen. Dann müsste man halt den User, der aufs CVS zugreift, ändern in "cvsconfig". Somit liest "root" die Dateien und im CVS stehen sie als User "cvsconfig". Ein "checkout" funktioniert ähnlich. Habe ich da was falsch verstanden, oder könnte das so hinhauen? Oder bin ich nur CVS-SSH verwöhnt und obiges mit "pserver" gar nicht funktioniert? Ich habe nur so meinen Gedankengang notiert, "just brainstroming". Also zerpflückt mich bitte nicht :-)), da sich obiges irgendwie so banal anhört. [ ... ] Gruesse, Thomas
Hallo Rooter Am Freitag, 31. Januar 2003 17:23 schrieb Mathias Bauer:
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!
Ich verwende RCS für die Verwaltung von Konfigurationsdateien. CVS ist für sicherheitsrelevante Dateien zu unsicher. Die Dateirechte werden lax gehandhabt. Jedermann kann die Dateien ausschecken. Dafür einen CVS-Server zu verwenden, gibt ausserdem Probleme mit Konfigurationsdateien von verschiedenen Rechnern. Für alles andere ist CVS besser. Gruß Heiner -- Heiner Kuhlmann Unter den Eichen 30, D-28857 Syke, Germany Phone: +49(4240)95076 FAX +49(4240)95077 heiner.kuhlmann@t-online.de
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.
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
Hallo Mathias,
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!
Ich bin mir nicht zu 100% sicher, aber ich denke, daß CVS als Client/Server-SW immer einen Server laufen hat, auch lokal.
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?
T'schuldigung, die Datei heißt "Root" und liegt in jedem Verzeichnis "CVS" unter Deinen Arbeitsverzeichnissen.
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.
Ich finde die manpages für sudo und sudoers allerdings etwas kompliziert und daher aufwendig zum einarbeiten.
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.
Wenn root die Dateien im Arbeitsverzeichnis des CVS-Verwalters überschreibt, dann gehören sie natürlich auch root. Anschließend muß root sie noch dem CVS-Verwalter übereignen (z.B. mit 'chown -R cvs:cvs <Arbeitsverzeichnis>'). Wenn root im Falle der Wiederherstellung einer Konfiguration die Dateien aus dem Arbeitverzeichnis liest, gehören sie anschließend sowieso ihm. Er muß halt nur dem CVS-Verwalter voll vertrauen können bzw. beides in unam personam sein.
(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.
Wenn Du das alles eh nur lokal vorhast, dann ist das hoffentlich sowieso schon der Fall - aus Gründen der allgemeinen Sicherheit und der Privatsphäre. Ansonsten läßt sich das Repository wohl kaum besondes abschotten (siehe Posting von Heiner Kuhlmann), weil ja mindestens der CVS-Verwalter Schreib- und Lesezugriff haben muß. Und wenn dann dessen Account kompromittiert wird, dann gute Nacht ... Naja, eine Möglichkeit gibt es doch: Man setzt die Gruppe für alle Repository-Dateien z.B. auf 'cvs' (chown -R :cvs <Repository>). Dann setzt man das SGID-Bit (chmod -R g+s <Repository>). Fortan erhalten alle Dateien, die in das Repository neu gebracht werden, die Gruppenzugehörigkeit 'cvs'. Nun müssen nur noch alle CVS-Berechtigten exklusiv Mitgleider der Gruppe 'cvs' werden.
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.
commit -m "Kommentar" ... Viel Spaß weiterhin, Thomas Michalka
Hallo, Heiner Kuhlmann wrote:
Hallo Rooter
Am Freitag, 31. Januar 2003 17:23 schrieb Mathias Bauer:
Ich verwende RCS für die Verwaltung von Konfigurationsdateien. CVS ist für sicherheitsrelevante Dateien zu unsicher. Die Dateirechte werden lax gehandhabt. Jedermann kann die Dateien ausschecken.
Ganz so einfach ist es auch nicht, bzw. kann man nur bestimmte Personen zulassen (Gruppe cvs - siehe meine zweite Antwort auf Mathias Bauer).
Dafür einen CVS-Server zu verwenden, gibt ausserdem Probleme mit Konfigurationsdateien von verschiedenen Rechnern.
Man muß halt für eine klare Trennung verschiedene Repositories verwenden. Deshalb auch mein Hinweis auf rsync. Damit wird es für root bzw. für den CVS-Verwalter leicht, für mehrere Rechner die Versionen der Konfigurationsdateien zu kopieren bzw. zu verwalten. Gruß, Thomas
participants (4)
-
Heiner Kuhlmann -
Mathias Bauer -
Thomas Michalka -
Thomas Preissler