CVS-Server einrichten.

[SeeksTheMoon]

Es mag sein, dass mal einer von euch einen CVS Server nicht nur benutzen, sondern auch einrichten muss. Die Tutorials im Internet sind sehr bescheiden und gerade die Knackpunkte werden überall ausgelassen.

Dieses Tutorial wird sich der Problematik widmen, wie man einen CVS-Server mit Passwortautentifizierung einrichtet.

Vorerst noch ein Link zu einem anderen Tutorial von SuSE:
http://www.suse.de/de/private/suppor...cvs/index.html


cvs besorgt ihr euch von www.cvshome.org
Das Kompilieren/Installieren folgt den üblichen Regeln: configure && make && make install, schaut euch aber vorher mit configure --help an, ob ihr vielleicht ein paar Spezialeinstellungen wollt.
Client und Server werden standardmäßig kompiliert.
Sinnvoll ist vor allem die Option für den Editor, den CVS öffnen soll, wenn es einen Kommentar beim Einchecken verlangt. Standardmäßig ist das vi oder was sonst so an Steinzeiteditoren bei euch schlummert - damit können die wenigsten umgehen (ich gehöre dazu). Man kann jeden beliebigen Editor eintragen.
Dies kann man auch nachher über die Variable CVSEDITOR beeinflussen.

EDIT:
Wichtig (und möglicherweise neu) ist, dass man bei cvs noch UNBEDINGT ein --prefix=INSTALLPFAD mitgeben muss, sonst wird es nicht richtig installiert, d.h. das Kommando "cvs" ist im System nicht vorhanden. Das configure-script sagt zwar, dass es nach /usr/local installiert, aber das stimmt nicht!
Wer also sichergehen will, kompiliert so (ggf mit weiteren Parametern): configure --prefix=/usr/local && make && make install
Hat mich einige Nerven gekostet bis ich das herausgefunden habe..
/EDIT

Benutzt auf jeden Fall die aktuellste Version. Im Moment ist das 1.11.5. Alle Versionen vorher haben (mindestens) einen Bug so wie diesen:
http://www.heise.de/newsticker/data/pab-21.01.03-000/
Die Versionen bei den Distributionen sind relativ alt und somit davon betroffen.
Das Kompilieren verläuft eigentlich schnell und problemlos.


Jetzt wollen wir die ersten Vorbereitungen treffen; wir legen im System einen User und eine Gruppe an, z.B. cvs und cvsuser. Den cvsadmin nehmen wir auch gleich als Gruppe. Im SuSE-Tutorial (s.o.) stehen die Befehle dafür. Gebt dem User auch gleich /bin/false als Shell, denn er darf nur die cvs-Funktionen benutzen und sich nicht auf eurem System austoben.


Nun erstellen wir das Verzeichnis, in dem die ganzen Daten (das "Repository") liegen sollen (falls noch nicht geschehen) und initialisieren es:

mkdir /srv/cvs/Projekt/
cvs -d :local:/srv/cvs/Projekt/ init

cvs legt ein Verzeichnis (CVSROOT) mit config-Dateien an, durch die das Repository nachher konfiguriert werden kann.

Falls es schon Daten gibt, die direkt ins Repository aufgenommen werden sollen, dann könnt ihr den import Befehl benutzen:

cvs -d :local:/srv/cvs/Projekt/ import -m "initial Import" Modul-Name Hersteller-Name start

-m Gibt einen Kommentar an, den man beliebig wählen kann. Das Verzeichnis, in dem ihr euch jetzt befindet, wird als Modul mit dem Namen Modul-Name ins Repository importiert.
Dahinter könnt ihr euren Namen oder den der Firma schreiben, wie auch immer.
"start" ist das Tag, das alle importierten Dateien bekommen. Ihr könnt also später immer die Dateien in diesem Urzustand auschecken, wenn ihr wollt.


Die Unterverzeichnisse von /srv/cvs/Projekt/ sollten dem Benutzer cvs und der Gruppe cvsgroup gehören, mit Ausnahme des CVSROOT-Verzeichnisses und dessen Inhalt (am besten nur für root freigeben und ja kein Schreibzugriff für andere Leute!)
In diesem Verzeichnis legt man (nicht per cvs sondern direkt per Editor) eine passwd Datei an, die z.B. so aussieht:

guest::cvsuser
Entwickler:VerschlüsseltesPasswort:cvsuser


guest ist hier ein Benutzer, der ohne Passwort auf das Repository zugreifen kann. Damit ihr das Passwort-System damit nicht aushebelt, solltet ihr guest in die Datei readers im CVSROOT eintragen! Dann hat er nur Lesezugriff.

Vergibt man ein Passwort, muss man es sich allerdings selber verschlüsseln cvs liefert kein Tool dazu. Ich hab die Passwortdatei genommen, die für meinen FTP-Server (pureftpd) ist und für cvs zurechtgeschnitten (also alles bis auf Name und Passwort rausgeschmissen). Ich hab von einem Perl-Script gelesen, das das macht (ich weiß aber nicht mehr wo; wenn jemand den Namen oder einen Link zu so einem Tool posten könnte, wäre das der Knaller)

Die Datei config sollte man sich auch anschauen und an eigenen Bedarf anpassen. Dort sollte man dann auch austragen, dass die /etc/passwd für die Anmeldung benutzt werden darf, dazu setzt man
SystemAuth=no
Standardmäßig ist davor noch ein # eingetragen, der muss weg!

Die Datei cvswrappers ist auch wichtig, wenn man binärdaten im Projekt hat, wie z.B. Bilder oder executables:
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'

Hat man dies erledigt, dann muss man nicht mehr darauf achten, ob eine Datei binär ist oder nicht.
Das ist wichtig, weil es Schlüsselwörter für CVS gibt, die es automatisch ersetzt, wenn sie in Dateien vorkommen, z.B. $Author$ oder (was viel häufiger vorkommt) $Id$.
Wenn in einer Binärdatei nun statt $Id$ irgendein Text steht, den CVS eingesetzt hat, dann kann man sich leicht ausmalen, dass die binary sofort unbrauchbar wird.
Man kann Dateien auch nachträglich mit diesem Schutz versehen. Mehr Infos dazu gibt der cvs admin Befehl.

So, jetzt haben wir den Dateikram erledigt und wollen cvs nun als Server einrichten. Wir bedienen uns da eines Superservers, z.B. dem xinetd. In die /etc/xinetd.conf tragen wir folgendes ein:

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

Hat man mehrere CVS Projekte, so sieht server_args so aus (einfach --allow-root für jedes Repository wiederholen):
server_args = -f --allow-root=/srv/cvs/Projekt1 --allow-root=/srv/cvs/Projekt2 pserver

In der /etc/services sollte der Eintrag

cvspserver 2401/tcp

zu finden sein und öffnet diesen Port auch in eurer Firewall


Starten wir den xinetd und versuchen wir uns einzuloggen:

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

oder man exportiert die CVSROOT Variable um sich tipparbeit zu sparen:
export CVSROOT=:pserver:Entwickler@www.cvsserver.de:/srv/cvs/Projekt

dann kann man bei allen weiteren cvs-Kommandos diesen Rattenschwanz weglassen (und schreibt z.B. nur cvs login, cvs update, cvs commit, etc).

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... (oder man kompiliert direkt ein, welcher Editor benutzt werden soll, s.o.)

Aber das fällt alles eher unter Benutzung von cvs, nicht zum Einrichten des Servers.


=========================================

Folgendes ist absolut optional; eine hübsche Spielerei. Wenn ihr euch nicht in die Quelltexte schauen lassen wollt, dann müsst ihr euren Webserver entsprechend absichern.
Ich gehe sowieso mal davon aus, dass ihr einen lauffähigen http-Server (z.B. apache) am Start habt und ihn auch für cgi-Ausführung eingestellt habt.


Wenn wir unser Repository so schön im Blick haben wollen wie auf sourceforge, dann laden wir uns viewcvs runter (http://viewcvs.sourceforge.net/) und installieren es wie in der INSTALL-Datei von viewcvs beschrieben.

Damit das Programm funktioniert, braucht man Python und RCS. Ohne RCS funktioniert es nicht (es zeigt nur Verzeichnisse an) und die Zeile, in der es als Voraussetzung erwähnt wird, überliest man schonmal sehr leicht.
In der INSTALL und auf der Homepage von viewcvs gibts einen Hyperlink zu RCS (worauf ich im folgenden nicht eingehen will).

Jetzt editieren wir die viewcvs.conf, die mit Kommentaren gespickt ist.

Wo liegt das Repository?
cvs_roots = Name-für_mein_Repository : /srv/cvs/Projekt, Name-für_ein_weiteres_Repository : /srv/cvs/Projekt2

Wo liegt RCS?
rcs_path = /usr/bin/

Dateityperkennung anhand einer mime-type-Datei aktivieren (optional):
mime_types_file = /usr/local/apache2/conf/mime.types

Mailadresse des Admins:
address = Mail an den bösen Admin

Titel für die Webseite auf der das Repository angezeigt wird:
main_title = Mein krasses CVS Repository

Verzeichnisse, die nicht angezeigt werden sollen:
forbidden = CVSROOT

Es gibt noch unzählige weitere Optionen, wie z.B. tarballgenerierung etc. Lest euch die config durch.


Habt ihr alles so gemacht wie hier beschrieben, habt ihr einen CVS-Server, der wie der von Sourceforge funktioniert.



Einen Fragethread gibt es hier:
http://www.linuxforen.de/forums/show...threadid=63038

[RapidMax]

#!/usr/bin/perl

srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
my $plaintext = shift;
my $crypttext = crypt ($plaintext, $salt);

print "${crypttext}\n";

Quelle: The CVS Book, Open Source developpment with CVS
Ist übrigens sowieso lesenswert. Wenn nicht sogar Kaufenswert

Ergänzung von k.k:

Ein weiterer Befehl zum generieren einer passwd-Datei ist der Befehl htpasswd.

Beispiel: Neue Datei und gleich einen Nutzer anlegen:

htpasswd -bc /pfad/zur/passwd/im/CVSROOT name passwort

Neuen User anfügen:

htpasswd -b /pfad/zur/passwd/im/CVSROOT name passwort.

Ist vielleicht einfacher als das Perl-Script.

Weitere Möglichkeit: Ich generiere die Passwörter mittlerweile mit OpenSSL:

$ openssl passwd -crypt
Password: 
mqQ5lPy/5YM4w

[RapidMax]

Als Alternative zur pserver Authentifikations-Methode bietet sich SSH an. Die Kommunkation verläuft dann verschlüsselt ab. Damit wird auch gleich das Sicherheitsproblem mit pserver umgangen.

Ursprünglich hat CVS den Zugriff auch übe rsh erlaubt (und erlaubt es immernoch). Da die r-Tools aber ein grossen Sicherheitsrisiko sind, sollte man diesen Weg auf keinen Fall einschlagen!

Glücklicherweise ist SSH ein kompletter Ersatz für die r-Tools. Um nun Zugriff auf den SSH-Server zu erhalten, müssen im wesentlichen drei Schritte durchgeführt werden.
[list=1][*]User muss als Unix-User auf dem CVS-Server vorhanden und der Zugriff mit ssh möglich sein.[*]Die Umgebungsvariable CVS_RSH muss auf ssh zeigen: export CVS_RSH=ssh[*]CVSROOT muss diese Zugriffsvariante enthalten: export CVSROOT=:ext:username@server:/repositority/[/list=1]
Die Authentifikations-Methode :ext: sagt cvs, dass es die Remote-Shell verwenden soll, die in CVS_RSH definiert worden ist.

Wenn nun noch der Host-Key auf dem Server abgelegt wird, ist nicht einmal mehr ein Passwort-Eingabe notwendig. Zudem muss nur der ssh Port geöffnet sein.

Gruss, Andy

[SeeksTheMoon]

Eine (bessere) Methode als diese (x)inetd-Geschichte von oben ist der cvsd.
Dabei handelt es sich um einen Dienst, der in einer chroot-Umgebung läuft, in der das Repository liegt.
Dadurch kann schonmal niemand über den CVS-Dienst ins System gelangen (und ich bin eh kein Freund vom (x)inetd).
CVSd bietet auch den Vorteil, dass man ganz einfach Benutzer mit ihren Passwörtern einrichten kann (cvsd-passwd Kommando) und dafür keine externe Methode wie das Perl-Script braucht.
Es editiert direkt die passwd-Datei im CVSROOT-Verzeichnis.

Man kann auch ein bereits existierendes Repository importieren (man kopiert nur das Verzeichnis mit dem Repository in das chroot)

Die Homepage ist hier: http://tiefighter.et.tudelft.nl/~arthur/cvsd/
Das Kompilieren/Installieren läuft nach dem gewohnten 3 Satz-Schema, danach gehts mit dem Einrichten los:

Zuerst legt man ein Verzeichnis an, in dem die chroot-Umgebung eingerichtet werden soll. Dann startet man das Kommando
cvsd-buildroot (chroot-verzeichnis)

Es kopiert ein paar wichtige Dateien und Verzeichnisse in das angegebene Verzeichnis, denn aus dem chroot kann man ja nicht die Programme des Systems benutzen (aus diesem Grund darf man übrigens auch keine Sym- oder Hard-Links verwenden, die zeigen sonst nach nirgendwo).

In dem chroot haben wir nun bin, etc, lib, dev und noch ein paar weitere Verzeichnisse.
Dort können wir auch gleich ein Verzeichnis "cvs" anlegen, wo dann unser Repository reinwandert (das können auch mehrere sein).
Legt man ein neues an, dann geht das wie gewohnt mit cvs init.

Jetzt kommt die cvsd.conf an die Reihe:
Dort gibt man als erstes das RootJail an; das ist das gleiche Verzeichnis, das wir beim cvsd-buildroot angegeben haben (absolute Pfadangabe).
Jetzt wird ein Benutzer und die Gruppe angegeben.
In der Readme vom cvsd steht drin, wie man eine passende Gruppe und einen User dafür anlegt, sofern wir nicht schon den cvsuser aus dem ersten Tutorial verwendet haben.

Dann kommt irgendwann ein nice-Level, d.h. mit welcher Priorität der Dienst laufen soll. Nice kennt einen Grad von -20 (maximale Priorität) bis 19 (niedrigste Priorität). 10 ist eigentlich Standard für jedes Programm; in der config-Datei ist aber 1 eingetragen.
Das ist für einen reinen CVS-Server sicher ok, für einen Dienst, der nebenbei auf dem Rechner läuft, ist das aber zu viel (dort lieber 10 eintragen).

Dann kommen noch Dinge wie Adresse, Port usw., das ist selbsterklärend.
Ganz unten stehen dann die absoluten Pfadangaben zu den Repositories. Die Beispiele dort sollten natürlich angepasst/rausgeschmissen werden.


Jetzt muss man nur noch in das CVSROOT-Verzeichnis seiner Repositories gehen und die Datei config öffnen:
SystemAuth muss auf "no" gestellt werden (aus dem chroot kann man ja eh nicht die passwd lesen; oder man kopiert die /etc/passwd ins chroot/etc Verzeichnis).
Den Pfad bei LockDir sollte man auch anpassen und daran denken, dass die Lock-Dateien im chroot liegen. Ich hab dort /var angegeben, dann wird das var-Verzeichnis aus dem chroot benutzt.

Jetzt nur noch den xinetd (bzw die CVS-Einträge in seiner config) kicken, den cvsd als Dienst starten und einen Checkout versuchen.

Viewcvs, ssh-Zugriff funktionieren damit ebenfalls (genauso wie mit dem xinetd auch), denn damit hat der cvsd ja nichts zu tun.

[RapidMax]

In meinem letzten Beitrag oben habe ich erklärt, wie CVS über ssh aufgerufen wird. Diese Variante funktioniert nur, wenn alle User einer Hauptgruppe angehören (Wie bei SuSE üblich, bei Debian jedoch nicht). CVS wird hier einfach über ssh aufgerufen.

Um die Vorzüge der pserver-Methode mit der Sicherheit von SSH zu verbinden, kann der CVS-Server an das lokale Loopback-Device gebunden werden und mittels den SSH Port-Forward-Mechanismen über einen sicheren Tunnel darauf zugegriffen werden. Wie das funktioniert, ist im folgenden HOWTO beschrieben:

http://www.cycom.co.uk/howto/cvssshtunnel.html - Securing CVS by pserver Port Forwarding using an SSH Tunnel

Ich bin dabei so vorgegangen: cvsuser und cvsgroup angelegt, im xinetd cvs als cvsuser ausgeführt und dort wie beschrieben an das Loopback-Device gebunden. Die User in der $CVSROOT/CVSROOT/passwd eingetragen und die Zugehörigkeit cvsuser.cvsgroup bei den Dateien im Repositority gesetzt.

Gruess, Andy