PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : CVS Server einrichten



joshgalaxy
24.01.03, 22:55
Kennt jemand eine Anleitung (womöglich genaue Anleitung) zum Einrichten eines CVS-Servers (unter Debian). Ich hab's eingerichtet, Port 2401 ist auch offen und akzeptiert Verbindungen, doch irgendwie will's nicht so recht und deshalb habe ich das Gefühl was verbockt zu haben :D

Berufspenner
25.01.03, 15:29
Hi

Hab da mal was gefunden: http://www.mnd.fh-wiesbaden.de/%7Edreymann/linux/linux11.html

Cu
André

SeeksTheMoon
25.01.03, 16:08
ich habs grade gemach (die Tutorials im Internet sind alle BESCHISSEN)t:

einen user und eine gruppe im System anlegen, z.B. cvs und cvsuser. Den cvsadmin nehmen wir auch gleich als gruppe.

dann zum initialisieren:
cvs -d :local:/srv/cvs/Projekt/ init

und zum importieren bereits angelegter Daten:
cvs -d :local:/srv/cvs/Projekt/ import -m "initial Import" Modul-Name Hersteller-Name start

dieser Befehl importiert aus dem aktuellen Verzeichnis alles in das angegebene Repository.
Die Unterverzeichnisse von /srv/cvs/Projekt/ sollten cvs und cvsgroup gehören, mit Ausnahme des CVSROOT-Verzeichnisses (am besten nur für root und ja kein Schreibzugriff für andere)
In diesem Verzeichnis legt man (nicht per cvs sondern direkt per Editor) eine passwd Datei an, die so aussieht:
guest::cvsuser
Entwickler:VerschlüsseltesPasswort:cvsuser

guest ist natürlich optional. Man muss sich das Passwort allerdings selber generieren, cvs liefert kein Tool dazu. Ich hab die Passwortdatei genommen, die für meinen FTP-Server ist und für cvs zurechtgeschnitten.
Die Datei config sollte man sich auch anschauen und an eigenen Bedarf anpassen.

Die Datei cvswrappers ist auch wichtig, wenn man binärdaten im Projekt hat, z.B. Bilder:
Man trägt einfach Dateityp und die passenden Optionen ein; hier werden Bilder und Java-Dateien als binär behandelt:

*.gif -k 'b'
*.GIF -k 'b'
*.jpg -k 'b'
*.JPG -k 'b'
*.jpeg -k 'b'
*.JPEG -k 'b'
*.png -k 'b'
*.PNG -k 'b'
*.class -k 'b'
*.jar -k 'b'


So, jetzt wollen wir cvs als Server einrichten. Ich hab mich da dem xinetd bemächtigt, wo man folgendes einträgt:

service cvspserver
{
socket_type = stream
protocol = tcp
wait = no
user = root
passenv =
server = /usr/bin/cvs
server_args = -f --allow-root=/srv/cvs/Projekt1 --allow-root=/srv/cvs/Projekt2 pserver
}


Hier ist übrigens noch ein schönes Tool:
http://viewcvs.sourceforge.net/

Die Funktionsweise kann man direkt bei Sourceforge sehen. Man muss allerdings noch RCS instalieren, sonst zeigt es nur Verzeichnisse an.
Es ist übrigens wichtig, die aktuellste cvs-Version zu benutzen, denn vor 1.11.5 gibts nen üblen, sicherheitskritischen Bug.


Einloggen geht so:
cvs -d :pserver:Entwickler@www.cvsserver.de:/srv/cvs/Projekt login

oder Du exportierst die CVSROOT Variable:
export CVSROOT=:pserver:Entwickler@www.cvsserver.de:/srv/cvs/Projekt

dann kannst Du bei allen weiteren cvs-Kommandos diesen Rattenschwanz weglassen (und schreibst z.B. nur cvs login).

Wichtig ist auch die Variable CVSEDITOR. Man sollte sie dringend auf einen Texteditor seiner Wahl setzen (wieder mit export), sonst findet man sich beim commit im vi oder einem ähnlich grauenhaften Editor wieder...

Hellek
30.07.03, 18:39
Erstklassige Arbeit SeeksTheMoon.
Hat mir wirklich sehr geholfen.

Hoffe dass der Thread auch noch anderen hilft.

Jetzt fehlt nur noch eine Anleitung wie man ssh authentifizierung macht aber das werde ich sonst sicher auch noch selbst rausfinden:) (und in diesem fall hier posten)

LX-Ben
30.07.03, 21:50
Hoffe dass der Thread auch noch anderen hilft.
Ist es evtl. sinnvoll, das Thema nach Tipps+Tricks zu verschieben?

nobody0
30.07.03, 21:59
Original geschrieben von LX-Ben
Ist es evtl. sinnvoll, das Thema nach Tipps+Tricks zu verschieben?

Ja, besser wäre das.
Man findet zwar viele gute Anleitungen zum Connecten eines Servers oder zum lokalen CVS, aber einen Server einzurichten ist schwer zu finden.

SeeksTheMoon
31.07.03, 01:47
braucht man nicht, denn es ist bereits im "Hier Suchen und Finden, Links, Tutorials":
http://www.linuxforen.de/forums/showthread.php?s=&threadid=63144&highlight=CVS

Dort ist es ausführlicher und es wird auch geschrieben wie es mit SSH geht.

e2e4
03.08.03, 22:11
Danke feine Erläuterung :)

Grüße, e2e4

e2e4
08.08.03, 12:23
So, ich habe jetzt alles mal nachvollzogen und habe doch noch ein Problem :rolleyes:

Der Login an den CVS-Server gelingt, doch wenn ich mittels:

cvs add 1.jpg

eine Datei einfügen möchte erhalte ich folgende Fehlermeldung:

"Fatal error, aborting.
cvsuser: no such user"

In der Datei /CVSROOT/passwd befindet sich der User "cvs" [mit dem ich mich auch angemeldet habe] und im Linux-System ist der User "cvs" Mitglied der Gruppe "cvsuser".

Wo fehlt noch eine Authentifizierung?

Grüße, e2e4

SeeksTheMoon
10.08.03, 16:50
hat auch die ganze Welt an der cvs-passwd Leserecht?
Gehört das CVS-Verzeichnis dem cvs-user mit lese und schreibrecht?
Hast Du das add auch in der gleichen Konsolensession gemacht wie das login?

nobody0
10.08.03, 22:53
Also "Fatal error, aborting. cvsuser: no such user" bedeutet, dass dieser USER unbekannt ist; da hilft es nichts die GRUPPE cvsuser zu haben.
Statt cvs.cvsuser wird der user cvsuser.cvs benötigt oder die passwd muss umgestellt werden.

e2e4
13.08.03, 12:29
@SeeksTheMoon


hat auch die ganze Welt an der cvs-passwd Leserecht?

ja


Gehört das CVS-Verzeichnis dem cvs-user mit lese und schreibrecht?

es gehört dem user cvs mit rwx und der gruppe cvsuser


Hast Du das add auch in der gleichen Konsolensession gemacht wie das login?

ja

@nobody0


Statt cvs.cvsuser wird der user cvsuser.cvs benötigt oder die passwd muss umgestellt werden.

So sieht meine passwd aus:

cvs:verschlüsseltes_passwort

Meine Umgebungsvariable für CVSROOT ist die folgende:

CVSROOT=:pserver:cvs@xxx.xxx.xxx.xxx:/srv/cvs/Projekt

So richtig verstehe ich jetzt nicht - wieso ich den User in cvsuser umbenennen soll ...

Grüße, e2e4

SeeksTheMoon
13.08.03, 17:19
das lese ich ja jetzt erst:


Original geschrieben von e2e4

In der Datei /CVSROOT/passwd befindet sich

meinst Du wirklich /CVSROOT mit / am Anfang? Ist das korrekt? CVSROOT ist ein Unterverzeichnis des Repository (es liegt auf der gleichen Ebene wie die Module des Projektes). Wenn die passwd woanders liegt, dann wird das nix.

e2e4
19.08.03, 18:47
meinst Du wirklich /CVSROOT mit / am Anfang?

nein ;)

konnte das Problem jetzt beheben, war noch ein Fehler beim Anlegen des Repository ... danke für Eure Hinweise :)

Grüße, e2e4

stefaan
24.08.03, 00:11
Servus!

Eine "Alternative":
http://webpm.woltlab.info/

Nachdem ich mit WinCVS nicht ganz klar gekommen bin und Webinterfaces bevorzuge :D

Bin heute per Zufall darauf gestoßen und habe gerade ein kleines Projekt importiert... ist ganz nett :)

Grüße, Stefan

nobody0
24.08.03, 09:20
Original geschrieben von stefaan

Eine "Alternative":
http://webpm.woltlab.info/


Das ist aber kein alternativer Client sondern ein eigenes Revisionsverwaltungssystem mit einem anderen Server als einem CVS-Server.
Es ist anscheinend dem kommerziellen MKS ähnlich, denn das braucht auch ein separates RDBMS wie MYSQL.

stefaan
24.08.03, 18:07
Servus!

Weiß schon, dass das was Eigenes is :) Hab ja hingeschrieben, es ist eine Alternative und der Thread handelt um CVS Server :D

Für 1-User-Aktionen ist für mich nur eine Versionskontrolle interessant.

Grüße, Stefan

nebu
11.07.04, 23:22
Ich hab zur zeit das Problem das ich alles genau nach dem tut gemacht habe
und bekomme immer wenn ich nicht
$ cvs -d :pserver:nebu@localhost:/.../projekt/ login
mache nach der password eingabe ein
cvs [login aborted]: reading from server: Connection reset by peer

Habe es auch schon versucht wenn ich beim init
nicht :local: eingebe sprich
cvs -d /.../projekt/ init
aber gleiches ergebnis

es ist keine firewall installiert auf dem pc

hoffe jemand kann mir helfen
mfg
nebu

stokedfish
15.08.04, 21:36
Ich habe mich in den letzten Tagen intensiv mit CVS beschäftigt und nun auch diesen Thread und das Tutorial für die Servereinrichtung entdeckt. Einige Dinge sind mir noch unklar, deshalb frage ich mal hier nach!

Erstmal was zum Zugriff mit SSH als Alternative zu pserver. Wo legt man denn hier genau den Host-Key auf dem Server ab? Und wie erzeugt man überhaupt solche Keys?

Dann ist die Rede von cvsd und einer chroot Umgebung. Weil so ja (x)inetd nicht mehr nötig ist, läuft die ganze Zeit ein anderer Prozess auf dem Server oder wie? Ist da die Lösung über den Unix Internet daemon nicht ressourcenschonender? Chroot in Verbindung mit (x)inetd funktioniert nicht? Oder läuft eine chroot Umgebung über normale Unix Benutzer accounts mit den entsprechenden Rechten plus zum Beispiel SSH für den Zugriff auf den Server und gar kein Prozess? Ich bin total verwirrt...

Auch etwas in der cvsd FAQ wirft Fragen auf. Da steht SSH sei in erster Linie nötig für einen sicheren Zugriff für Entwickler während chroot eher für read-only access gedacht sei. Die "readers" und "writers" Dateien sind also nicht mehr nötig und man regelt es über normale Unix-Zugriffsrechte, richtig?

Noch was - am Schluss wird erklärt, wie man die pserver Methode über SSH tunnelt. Wo liegt genau der Vorteil dieses Ansatzes gegenüber der "SSH als Alternative zu pserver" Lösung?

Wir überlegen uns, für eine kleine Community CVS für Entwickler einzurichten. Da auf dem Rechner auch noch ein Forum mit Downloadbereich und Internet-Radio läuft, muss es absolut sicher und ohne grosse Belastung für den Server sein. Welches ist denn die beste Lösung?

Ich habe mir folgendes angedacht: CVS in einer chroot Umgebung aufsetzen und für jeden Entwickler einen Unix Benutzeraccount einrichten. Die Umgebungsvariable CVS_RSH auf SSH setzen und den ganzen pserver und (x)inetd Teil wegzulassen. Ist das so möglich? Ist es so sicher? Und auch Windows kompatibel?

Oder müssten wir da doch die letzte Variante mit den SSH Tunnels verwenden? Ich verstehe den Unterschied nicht so ganz. Wenn man doch so (x)inetd und pserver weglassen kann und wohl einiges weniger an Konfigurationsaufwand hat, warum das ganze überhaupt mit dem (komplizierten) SSH Tunnels einrichten?

Fragen über Fragen...

Ach ja, noch eine Anregung zu dem Tutorial. Es ist ab und zu von Unix Gruppen und Benutzeraccounts die Rede. Leider wird aber nie richtig erklärt, wie man die genau einrichtet bzw. verändert. Vielleicht könnte man das ein wenig ergänzen? Na gut, das sollte man wohl sowieso wissen, wenn man CVS aufsetzen will... :ugly:

SeeksTheMoon
16.08.04, 19:40
Erstmal was zum Zugriff mit SSH als Alternative zu pserver. Wo legt man denn hier genau den Host-Key auf dem Server ab? Und wie erzeugt man überhaupt solche Keys?
Dafür ist der ssh-Server zuständig. Ich denke mal dass das genauso funktioniert wie ein gewöhnlicher ssh-Login mit hinterlegtem key, so dass man kein Passwort braucht.
Wie das genau geht müsste man in der ssh-Doku lesen.


Dann ist die Rede von cvsd und einer chroot Umgebung. Weil so ja (x)inetd nicht mehr nötig ist, läuft die ganze Zeit ein anderer Prozess auf dem Server oder wie? Ist da die Lösung über den Unix Internet daemon nicht ressourcenschonender? Chroot in Verbindung mit (x)inetd funktioniert nicht? Oder läuft eine chroot Umgebung über normale Unix Benutzer accounts mit den entsprechenden Rechten plus zum Beispiel SSH für den Zugriff auf den Server und gar kein Prozess? Ich bin total verwirrt...
Der xinetd ist nur dann Ressourcenschonend, wenn man ber ihn noch mehrere andere Server betreibt. Bei vielen Zugriffen ist der xinetd aber eher nachteilig, er bremst dann die Zugriffe aus.[/quote]
Der cvsd läuft in einer chroot-Umgebung, dafür ist der xinetd nicht direkt ausgelegt, man könnte das mit gewissem Aufwand aber auch hinbekommen (man kann halt alles chrooten oder (noch sicherer) in eine VM packen).


Auch etwas in der cvsd FAQ wirft Fragen auf. Da steht SSH sei in erster Linie nötig für einen sicheren Zugriff für Entwickler während chroot eher für read-only access gedacht sei. Die "readers" und "writers" Dateien sind also nicht mehr nötig und man regelt es über normale Unix-Zugriffsrechte, richtig?
Jain. Also erstmal spricht gar nichts dagegen den cvsd auch bei ssh zu chrooten. Das muss/sollte man eh machen, wenn man noch readers hat.
Am besten wäre ein Zugriff mit PAM, wie das bei Subversion (z.B. über den Apache2) geht. chrooten kann man das noch zusätzlich um mehr Sicherheit zu haben.


Noch was - am Schluss wird erklärt, wie man die pserver Methode über SSH tunnelt. Wo liegt genau der Vorteil dieses Ansatzes gegenüber der "SSH als Alternative zu pserver" Lösung?
Man kann alles über SSh tunneln. Ob ich mich jetzt per ssh direkt am cvs anmelde oder einen Tunnel zum Server aufbaue und dann zum cvs connecte, kommt letztendlich aufs gleiche raus. Ich schätze mal, dass die ssh statt pserver-Methode einfacher zu benutzen ist, da kann ich mich aber auch irren.


Wir überlegen uns, für eine kleine Community CVS für Entwickler einzurichten. Da auf dem Rechner auch noch ein Forum mit Downloadbereich und Internet-Radio läuft, muss es absolut sicher und ohne grosse Belastung für den Server sein. Welches ist denn die beste Lösung?
subversion. Es ist wesentlich komfortabler zu benutzen (v.a. Plattformübergreifend; cvs unter win32 suckt), weniger fehleranfällig (mit cvs hab ich mich nur geärgert weil es ständig irgendeinen unerklärlichen Mist gemacht hat) und es ist mit mehr features gesegnet (Versionierung von Verzeichnissen, ab 1.1 auch Links, Dateien umbenennen usw.).
svn kann dann über webdav auf einem apache2-Server laufen, dann braucht man auch keine sonstigen daemons oder superserver.
Den apache kann man natürlich auch chrooten.
Die Authorisierung kann mit PAm ganz bequem gemacht werden und der Apache kann über ssl, also https arbeiten, was ebenfalls vesschlüsselt.
Funktioniert bei mir seit nem halben Jahr einwandfrei.


Ich habe mir folgendes angedacht: CVS in einer chroot Umgebung aufsetzen und für jeden Entwickler einen Unix Benutzeraccount einrichten. Die Umgebungsvariable CVS_RSH auf SSH setzen und den ganzen pserver und (x)inetd Teil wegzulassen. Ist das so möglich? Ist es so sicher? Und auch Windows kompatibel?
hört sich machbar an, nur ssh und cvs unter Windows sind ne kleine Krankheit, ganz besonders cvs. ssh geht noch wenn man Putty verwendet.


Oder müssten wir da doch die letzte Variante mit den SSH Tunnels verwenden? Ich verstehe den Unterschied nicht so ganz. Wenn man doch so (x)inetd und pserver weglassen kann und wohl einiges weniger an Konfigurationsaufwand hat, warum das ganze überhaupt mit dem (komplizierten) SSH Tunnels einrichten?
Brauchst Du nicht. ist wie gesagt nur eine andere Alternative, weil man über ssh einfach alles tunneln kann.


Ach ja, noch eine Anregung zu dem Tutorial. Es ist ab und zu von Unix Gruppen und Benutzeraccounts die Rede. Leider wird aber nie richtig erklärt, wie man die genau einrichtet bzw. verändert. Vielleicht könnte man das ein wenig ergänzen? Na gut, das sollte man wohl sowieso wissen, wenn man CVS aufsetzen will... :ugly:
Das geht ganz normal über Kommandos wie useradd oder groupadd. Diese Befehle sind in der manpage und im Sysadmin Guide auf www.tldp.org erklärt.

stokedfish
16.08.04, 21:42
Hey, DANKE, das hilft schon mal sehr! :)

Folgendes "setup" wäre also möglich:

Login geschieht über SSH Keys für eine beschränkten Entwicklerkreis. Jeder Coder hat einen Unix Account auf dem Server und ist in einer entsprechenden Benutzergruppe, über welche die Zugriffsrechte auf die Archive geregelt werden. Die pserver Methode kann man so weglassen, ebenso (x)inetd. Das ganze läuft in einer Chroot Umgebung. Geht, oder?

Ein paar Unklarheiten bleiben aber noch...

Der cvs daemon würde also mit chroot laufen. Nur, wie startet man ihn dann? Und er läuft so 24/7 durch, oder? cvspserver stream tcp nowait root /usr/bin/cvs --allow-root=/usr/local/archiv pserver in die /etc/xinetd.d/cvs ist ja für die pserver/xinetd Methode aber wie würde das jetzt gehen? Welchen Prozess muss man wie starten? Und wie ist das mit tcp wrapper?

Dann nochmal zu den "readers" und "writers" Dateien. Sie sind doch zwingend mit der pserver Methode verbunden, wie ich das verstanden habe. Wenn man es so wie oben macht und einer Benutzergruppe nur Leserechte gibt, kann man sie also weglassen (bzw. sie wären sowieso nutzlos, da ja nur für die pserver Methode) und erreicht genau das gleiche, richtig?

Und nochmals zu chroot. Dazu würde ich gemäss deiner Anleitung ja cvsd verwenden, aber; "cvsd is a wrapper program for cvs in pserver mode - it will run 'cvs pserver' under a special uid/gid in a chroot jail." - aber die pserver Methode möchte ich ja eben gar nicht verwenden. Wie "chroote" ich dann?

Habe schon x Tutorials und sogar ein ganzes Buch über CVS gelesen, finde aber irgendwie keine richtigen Antworten auf obige Fragen... :rolleyes:

SeeksTheMoon
17.08.04, 16:10
Login geschieht über SSH Keys für eine beschränkten Entwicklerkreis. Jeder Coder hat einen Unix Account auf dem Server und ist in einer entsprechenden Benutzergruppe, über welche die Zugriffsrechte auf die Archive geregelt werden. Die pserver Methode kann man so weglassen, ebenso (x)inetd. Das ganze läuft in einer Chroot Umgebung. Geht, oder?
Ja (ob ssh mit cvsd-chroot weiß ich nicht, s.u.)


Der cvs daemon würde also mit chroot laufen. Nur, wie startet man ihn dann? Und er läuft so 24/7 durch, oder? cvspserver stream tcp nowait root /usr/bin/cvs --allow-root=/usr/local/archiv pserver in die /etc/xinetd.d/cvs ist ja für die pserver/xinetd Methode aber wie würde das jetzt gehen? Welchen Prozess muss man wie starten? Und wie ist das mit tcp wrapper?
Du musst nur den cvsd (über sein runlevel-script) starten, der sorgt sich um das chroot und darum dass cvs läuft.
TCP-Wrapper habe ich noch nicht benutzt, das ist wieder ein eigenes Kapitel.


Dann nochmal zu den "readers" und "writers" Dateien. Sie sind doch zwingend mit der pserver Methode verbunden, wie ich das verstanden habe. Wenn man es so wie oben macht und einer Benutzergruppe nur Leserechte gibt, kann man sie also weglassen (bzw. sie wären sowieso nutzlos, da ja nur für die pserver Methode) und erreicht genau das gleiche, richtig?
weiß ich nicht, könnte aber stimmen. Vielleicht klappt auch beides zusammen.


Und nochmals zu chroot. Dazu würde ich gemäss deiner Anleitung ja cvsd verwenden, aber; "cvsd is a wrapper program for cvs in pserver mode - it will run 'cvs pserver' under a special uid/gid in a chroot jail." - aber die pserver Methode möchte ich ja eben gar nicht verwenden. Wie "chroote" ich dann?
Du musst dann ssh und alles nötige auch ins chroot schieben, vorausgesetzt, cvsd kann auch mit ssh+chroot umgehen und unterstützt nicht ausschließlich die pserver-Methode.

michaelstefan
09.09.04, 09:40
Hallo,

ich habe WinCVS auf meinem Rechner installiert und lassen einen CVS Dienst auf meinem Linux Server laufen. Will ich mich jetzt mittels WinCVS auf ein Repository auf dem Linux Server zugreifen bekomme ich immer folgende Fehlermeldung:

cvs [login aborted]: /srv/cvs/Projekt/: no such repository

Wo liegt da der Fehler. Weil den Server findet WinCVS ja scheints, und das Repository existiert auch unter diesem Verzeichnis

gruß dt

flanders
22.06.05, 22:49
hallo,

alle sagen das pserver ******e ist, da unsicher. ABER wenn ich :ext: verwende, mussen die cvsbenutzer doch einen shellaccout haben. wenn ich die anlege und ich als standartshell /bin/false eingebe, dann geht das nciht. die brauchen ne bash o.ä.. das will ich nciht, denn die sollen keinen shell zugriff haben.

was ist da die beste lösung?
ich möchte auf meinem server für 3 projekte von kumpels n cvs einrichten. es läuft auch alles. wie handhabt ihr das? oder gibt es da andere möglichkeiten?
sourceforge macht es ja auch über ssh, oder. hat da auch jeder user eines repository shellzugriff?

bitte um hilfe, da ich mir unsicher bin...

ps: ich will am besten die fast :) sicherste lösung!

nobody0
23.06.05, 00:20
Bei sourceforge ist man nur CVS-User.
Vielleicht macht man es dort so, wie Du beschrieben hast.

flanders
27.06.05, 00:08
aber so wie ich es beschrieben habe ist es doch unsicher, da ich ja immer shelluser mit shellzugriff anlegen muss, damit sie auf ihr cvs zugreifen können. es sollen ja mehere unabhänig voneinander laufende projekte drauf laufen.

nobody0
27.06.05, 04:00
Du kannst in /etc/passwd ja einfach /bin/false als Shell eintragen.

flanders
27.06.05, 08:11
[...]wenn ich die anlege und ich als standartshell /bin/false eingebe, dann geht das nciht. die brauchen ne bash o.ä.. das will ich nciht, denn die sollen keinen shell zugriff haben.[...]


wie schon geschrieben, dann können sich die guten nciht einlogen. oder hängt das mit was anderem zusammen? sonst hätte ich das so gemacht :cool: