Diese Dokumentation wurde zur Beschreibung der Serie 1.7.x von Apache™ Subversion® erstellt. Falls Sie eine unterschiedliche Version von Subversion einsetzen, sei Ihnen dringend angeraten, bei http://www.svnbook.com/ vorbeizuschauen und stattdessen die zu Ihrer Version von Subversion passende Version dieser Dokumentation heranzzuiehen.

svnserve, ein maßgefertigter Server

Das Programm svnserve ist ein leichtgewichtiger Server, welcher für die Kommunikation mit den Clients ein auf TCP/IP basierendes, zustandsorientiertes Protokoll verwendet. Um sich mit dem Server zu verbinden, verwenden die Clients entweder das svn://- oder das svn+ssh://-Schema. In diesem Abschnitt behandeln wir die unterschiedlichen Möglichkeiten, svnserve einzusetzen, wie sich die Clients am Server authentisieren und wie die passenden Zugangsrechte zum Projektarchiv korrekt eingerichtet werden.

Der Serverstart

Es gibt mehrere Möglichkeiten, svnserve zu starten:

  • svnserve als eigenständigen Dienst (engl. daemon) starten und auf Anfragen von Clients reagieren lassen.

  • svnserve bei Bedarf mit Hilfe des Unix-Dienstes inetd starten, wenn auf einem festgelegten Port Anfragen eines svn-Clients ankommen.

  • Einen SSH-Server verwenden, um svnserve fallweise über einen verschlüsselten SSH-Tunnel zu betreiben.

  • svnserve als Microsoft-Windows-Dienst laufen lassen.

  • svnserve als launchd-Job laufen lassen.

Die folgenden Abschnitte werden diese Einsatzoptionen für svnserve detailliert erörtern.

svnserve als Unix-Dienst

Die einfachste Variante ist, svnserve als eigenständigen (Unix-)Dienst laufen zu lassen. Verwenden Sie hierfür die -d Option beim Aufruf:

$ svnserve -d
$               # svnserve läuft nun als Dienst und lauscht auf Port 3690

Wird svnserve als Dienst betrieben, können Sie mit den Optionen --listen-port und --listen-host festlegen, auf welchem Port und unter welchem Hostnamen er lauschen soll.

Wurde svnserve auf diese Weise erfolgreich gestartet, stehen nun alle Projektarchive auf dem Server für Nutzer im Netzwerk zur Verfügung. Für einen Zugriff muss ein Client den absoluten Pfad zum Projektarchiv im URL angeben. Ist das Projektarchiv beispielsweise im Verzeichnis /var/svn/project1 gespeichert, so sieht ein entsprechender URL für den Zugriff folgendermaßen aus: svn://host.example.com/var/svn/project1. Um die Sicherheit zu erhöhen, kann svnserve beim Start mit der Option -r auf ein bestimmtes Verzeichnis beschränkt werden, so dass nur noch die darin liegenden Projektarchive im Netz verfügbar sind. Ein Beispiel:

$ svnserve -d -r /var/svn
…

Mit der -r-Option wird festgelegt, welches Verzeichnis vom svnserve bei Anfragen als Wurzelverzeichnis (engl. root) verwendet wird. Ein Client muss nun in seiner URL nur noch den Pfad relativ zum neuen Wurzelverzeichnis angeben, was die URL erheblich verkürzt und die Verzeichnisstruktur etwas verschleiert:

$ svn checkout svn://host.example.com/project1
…

svnserve über inetd starten

Wenn Sie inetd zum Starten des Prozesses verwenden wollen, so übergeben Sie svnserve beim Aufruf die Option -i (--inetd). Im folgenden Beispiel sehen wir die Ausgaben beim Aufruf von svnserve -i auf der Kommandozeile. Beachten Sie aber, dass dies nicht der Weg ist, wie der Dienst normalerweise gestartet wird – eine genaue Beschreibung, wie svnserve über inetd gestartet wird, folgt anschließend.

$ svnserve -i
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops d\
epth log-revprops atomic-revprops partial-replay ) ) )

Mit der --inetd-Option versucht svnserve mit dem Subversion-Client unter Verwendung eines speziellen Protokolls via stdin und stdout zu sprechen. Dies ist der normale Weg für ein Programm, welches über inetd gestartet wurde. Die IANA (Internet Assigned Numbers Authority) hat für das Subversion-Protokoll den Port 3690 reserviert – auf einem Unix-ähnlichen System fügen Sie einfach folgende Zeilen (wenn noch nicht vorhanden) in die Datei /usw/services ein:

svn           3690/tcp   # Subversion
svn           3690/udp   # Subversion

Wenn Sie den klassischen Unix-inetd verwenden, können Sie die folgende Zeile in die Datei /usw/inetd.conf einfügen:

svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i

Stellen Sie sicher, dass svnowner der Nutzer ist, welcher alle notwendigen Zugriffsrechte auf ihre Projektarchive hat. Kommt nun eine Anfrage eines Subversion-Clients auf Port 3690 herein, so wird inetd einen svnserve-Prozess starten, um die Anfrage zu bedienen. Wahrscheinlich möchten Sie noch die -r-Option zur oben genannten Zeile hinzufügen, um einzuschränken, welche Projektarchive exportiert werden dürfen.

svnserve über einen Tunnel

Eine weitere Möglichkeit ist, svnserve mittels der -t-Option im Tunnel-Modus aufzurufen. Bei diesem Aufruf wird vorausgesetzt, dass ein anderes Programm für den Remote-Zugriff – etwa rsh oder ssh – den Nutzer bereits erfolgreich authentisiert hat, um nun einen privaten svnserve-Prozess als dieser Nutzer zu starten. (Beachten Sie, dass für Sie als Nutzer selten bis nie die Notwendigkeit bestehen wird, svnserve mit der -t-Option von Hand auf der Kommandozeile aufzurufen – der SSH-Dienst wird dies in der Regel für Sie machen.) svnserve wird sich nun normal verhalten (Abwicklung der Kommunikation über stdin und stdout) und davon ausgehen, dass alle Daten mit Hilfe des Tunnels zum Client weitergeleitet werden. Wird svnserve wie in diesem Fall durch ein Tunnel-Programm aufgerufen, ist es notwendig, dass der aufrufende Nutzer volle Lese- und Schreibrechte auf die Dateien der Projektarchiv-Datenbank hat. Es verhält sich dabei im Grunde genommen so, als wenn der Nutzer mit einem file://-URL auf ein Projektarchiv zugreifen würde.

Wir werden diese Option noch genauer in diesem Kapitel behandeln, und zwar in „Tunneln über SSH“.

svnserve als ein Dienst unter Windows

Gehört ihr Windows zur NT-Familie (Windows oder neuer), so können Sie svnserve auch als normalen Windows-Dienst laufen lassen. Dies ist wesentlich sinnvoller, als die Option --daemon (-d) zu verwenden und ihn als selbstständigen Dienst zu betreiben. Sie müssten dann immer eine Konsole (cmd) öffnen, den passenden Befehl aufrufen und die Konsole anschließend die ganze Zeit geöffnet lassen. Ein Windows-Dienst dagegen läuft im Hintergrund, kann bereits beim Hochfahren automatisch starten und lässt sich wie jeder andere Windows-Dienst mit demselben Administrationsprogramm starten und stoppen.

Es ist notwendig, den neuen Windows-Dienst unter Verwendung des Kommandozeilenprogramms SC.EXE einzurichten. Ähnlich der inetd-Konfigurationszeile müssen Sie den genauen Aufruf für den Start von svnserve festlegen:

C:\> sc create svn
        binpath= "C:\svn\bin\svnserve.exe --service -r C:\repos"
        displayname= "Subversion Server"
        depend= Tcpip
        start= auto

Hiermit erzeugen Sie einen neuen Windows-Dienst mit dem Namen svn, welcher jedes Mal das Programm svnserve.exe startet (und in diesem Fall C:\repos als Wurzelverzeichnis verwendet). In diesem Beispiel müssen jedoch einige wichtige Punkte beachtet werden.

Als erstes ist es wichtig, dass das Programm svnserve.exe immer mit der Option --service aufgerufen wird. Alle weiteren Optionen müssen in derselben Zeile folgen, allerdings dürfen sich widersprechende Option nicht verwendet werden – wie etwa --daemon (-d), --tunnel oder --inetd (-i). Optionen wie -r oder --listen-port sind hingegen in Ordnung. Zweitens, seien Sie beim Aufruf von SC.EXE mit Leerzeichen vorsichtig: Beim Schreiben der Schlüssel= Wert-Zeile darf zwischen Schlüssel und = kein Leerzeichen stehen, vor Wert muss genau ein Leerzeichen stehen. Seien Sie zuletzt auch bei der Verwendung von Leerzeichen innerhalb ihres Kommandozeilenaufrufes vorsichtig. Sollten Verzeichnisangaben etwa Leerzeichen (oder andere zu schützende Zeichen) enthalten, so umschließen Sie sie mit zusätzlichen doppelten Anführungszeichen:

C:\> sc create svn
        binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\repos"
        displayname= "Subversion Server"
        depend= Tcpip
        start= auto

Beachten Sie bitte auch, dass das Wort binpath etwas irreführend ist – sein Wert ist eine Kommandozeile und nicht der Pfad zu einem Programm. Dies ist der Grund, warum Sie vorhandene Leerzeichen mit doppelten Anführungszeichen schützen müssen.

Ist der Dienst erst einmal eingerichtet, können Sie ihn mit Hilfe von grafischen Programmen (etwa der Microsoft Management Console) stoppen, starten oder seinen Status abfragen. Alternativ steht ihnen auch die Kommandozeile zur Verfügung:

C:\> net stop svn
C:\> net start svn

Der Dienst kann natürlich auch wieder deinstalliert werden, indem Sie den Befehl sc delete svn aufrufen. Stoppen Sie den Dienst aber vorher! Das Programm SC.EXE kennt noch etliche andere nützliche Optionen und Parameter, ein Aufruf von sc /? verrät ihnen, welche das sind.

svnserve als ein launchd-Job

Mac OS X (10.4 und höher) verwendet launchd zur Prozessverwaltung (einschließlich Dämonen) sowohl systemweit als auch pro Anwender. Ein launchd-Job wird durch Parameter in einer XML-Datei als Eigenschaftsliste spezifiziert, und der Befehl launchctl wird verwendet, um den Lebenszyklus dieser Jobs zu verwalten.

Ist es als launchd-Job eingerichtet, wird svnserve bei Bedarf automatisch gestartet, sobald eingehender Subversion-Netzverkehr mit svn:// abgewickelt werden muss. Das ist viel einfacher als eine Konfiguration, die voraussetzt, dass svnserve als ein langlaufender Hintergrundprozess manuell gestartet wird.

Um svnserve als einen launchd-Job einzurichten, erstellen Sie zunächst eine Job-Definitions-Datei namens /Library/LaunchDaemons/org.apache.subversion.svnserve.plist. Beispiel 6.1, „Eine Beispieldefinition für einen svnserve launchd Job“ liefert ein Beispiel für eine solche Datei.

Beispiel 6.1. Eine Beispieldefinition für einen svnserve launchd Job

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>org.apache.subversion.svnserve</string>
        <key>ServiceDescription</key>
        <string>Host Subversion repositories using svn:// scheme</string>
        <key>ProgramArguments</key>
        <array>
            <string>/usr/bin/svnserve</string>
            <string>--inetd</string>
            <string>--root=/var/svn</string>
        </array>
        <key>UserName</key>
        <string>svn</string>
        <key>GroupName</key>
        <string>svn</string>
        <key>inetdCompatibility</key>
        <dict>
            <key>Wait</key>
            <false/>
        </dict>
        <key>Sockets</key>
        <dict>
            <key>Listeners</key>
            <array>
                <dict>
                    <key>SockServiceName</key>
                    <string>svn</string>
                    <key>Bonjour</key>
                    <true/>
                </dict>
            </array>
        </dict>
    </dict>
</plist>

[Warnung] Warnung

Das Erlernen des launchd-Systems kann ein wenig herausfordernd sein. Glücklicherweise gibt es Dokumentation zu den in diesem Abschnitt beschriebenen Befehlen. Rufen Sie beispielsweise man launchd von der Kommandozeile auf, um die Handbuchseite zu launchd selbst zu sehen, man launchd.plist, für das Format der Job-Definition, usw.

Sobald die Job-Definitions-Datei erstellt ist, können Sie den Job mit launchctl load aktivieren:

$ sudo launchctl load \
       -w /Library/LaunchDaemons/org.apache.subversion.svnserve.plist

Zur Klarstellung: Diese Aktion startet svnserve noch nicht. Sie teilt launchd bloß mit, wie svnserve gestartet werden soll, falls Netzverkehr auf dem svn Netzwerk-Port aufschlägt; es wird beendet nachdem der Verkehr abgewickelt worden sein wird.

[Anmerkung] Anmerkung

Da wir möchten, dass svnserve ein systemweiter Dämon-Prozess ist, müssen wir sudo verwenden, um diesen Job als Administrator zu verwalten. Beachten Sie ebenfalls, dass die Schlüssel UserName und GroupName in der Definitionsdatei optional sind — werden sie weggelassen, wird der Job unter dem Konto des Anwenders laufen, den ihn geladen hat.

Den Job abzustellen ist ebenso einfach — mit launchctl unload:

$ sudo launchctl unload \
       -w /Library/LaunchDaemons/org.apache.subversion.svnserve.plist

launchctl bietet Ihnen auch eine Möglichkeit, den Zustand von Jobs abzufragen. Falls der Job geladen ist, gibt es eine Zeile, die zum Label in der Job-Definitions-Datei passt:

$ sudo launchctl list | grep org.apache.subversion.svnserve
-       0       org.apache.subversion.svnserve
$

Integrierte Authentifizierung und Autorisierung

Wenn sich ein Subversion-Client mit einem svnserve-Prozess verbindet, geschieht folgendes:

  • Der Client wählt ein bestimmtes Projektarchiv.

  • Der Server liest die zum Projektarchiv gehörende Datei conf/svnserve.conf und führt die darin enthaltenen Regeln für die Authentifizierung (Legitimation, Identitätsprüfung) und die Autorisierung (Berechtigungen, Befugnisse) aus.

  • Je nach festgelegten Regeln und Einstellungen geht es mit einem der folgenden Punkte weiter:

    • Der Client kann seine Anfragen anonym, also ohne eine vorhergehende Authentifikationsanfrage, senden.

    • Der Client kann jederzeit eine Anmeldeaufforderung erhalten.

    • Läuft die Verbindung über einen Tunnel, so erklärt der Client, dass eine externe Anmeldung stattgefunden hat (meistens durch SSH).

Der svnserve-Server beherrscht als Standardeinstellung nur den CRAM-MD5-Anmeldedialog [52]. Im Kern läuft dieser wie folgt ab: Der Server sendet einen kleinen Datensatz als Anfrage an den Client. Dieser erzeugt mittels des MD5-Hash-Algorithmus einen Fingerabdruck/Hash des Passwortes zusammen mit dem Datensatz und sendet diesen Fingerabdruck als Antwort zurück an den Server. Der Server vollzieht nun dieselbe Operation mit dem Passwort und dem Datensatz und vergleicht anschließend seinen Fingerabdruck mit dem des Clients. Während des gesamten Vorgangs wird das eigentliche Passwort nie über das Netzwerk gesendet.

Enthält ihr svnserve-Server Unterstützung für SASL, so beherrscht er nicht nur die CRAM-MD5-Anmeldung, sondern noch eine Menge anderer Verfahren zur Authentifizierung. Lesen Sie svnserve mit SASL verwenden“ weiter unten, um zu lernen, wie die einzelnen Möglichkeiten zur Authentifizierung und Verschlüsselung in SASL eingerichtet werden.

Es ist selbstverständlich auch möglich, dass sich der Client über ein eigenständiges Tunnel-Programm anmeldet, etwa ssh. In einem solchem Fall stellt der Server nur fest, unter welchem Anwenderkonto er gestartet wurde, und verwendet dieses für die weitere Anmeldung. Mehr dazu im Kapitel „Tunneln über SSH“.

Wie Sie sicher bereits bemerkt haben, ist die Datei svnserve.conf in jedem Projektarchiv die zentrale Anlaufstelle für die Zugangskontrolle zum Projektarchiv. In Verbindung mit anderen in diesem Abschnitt beschriebenen zusätzlichen Dateien bietet diese Konfigurationsdatei dem Administrator eine vollständige Lösung zur Steuerung der Authentifizierungs- und Autorisierungs-Richtlinien für Anwender. Jede der zu erörternden Dateien verwendet das übliche Format wie andere Konfigurationsdateien (siehe „Laufzeit-Konfigurationsbereich“): Die Bezeichnungen der Abschnitte sind von eckigen Klammern umschlossen ([ und ]), Kommentare werden durch Doppelkreuze (#) eingeleitet, und jeder Abschnitt enthält spezielle Variablen, denen Werte zugewiesen werden (variable = value). Lassen Sie uns einen Blick in diese Dateien werfen, um zu sehen wie sie verwendet werden.

Erstellen einer Passwortdatei und festlegen der Authentifikationsumgebung (Realm)

Zu Beginn enthält der Abschnitt [general] in der Datei svnserve.conf alle Einstellungen, welche für den Start notwendig sind. Lassen Sie uns anfangen und den Variablen Werte zuweisen: Wählen Sie den Namen der Datei, welche die Namen ihrer Nutzer und deren Passwörter enthält, und entscheiden Sie sich für den Namen der Authentifikationsumgebung:

[general]
password-db = passwortdatei
realm = Anmeldedomäne

Den Namen des realm können Sie frei wählen. Er teilt den Clients mit, an welcher Authentifikationsumgebung sie sich anmelden. Der Subversion-Client zeigt diesen Namen im Anmeldedialog und verwendet ihn auch (zusammen mit dem Namen und Port des Servers) als Schlüssel, welcher als Teil des Anmeldenachweises auf der Festplatte des Nutzers gespeichert wird (siehe dazu „Zwischenspeichern von Zugangsdaten“). Die Variable password-db enthält den Namen der Passwortdatei, die vom Aufbau her gleich ist und die Namen der Nutzer und deren Passwörter speichert. Als Beispiel:

[users]
harry = geheimespasswort
sally = undnocheins

Der Wert von password-db kann den absoluten oder relativen Pfad zur Anwenderdatei enthalten. In der Regel, ist es am einfachsten diese Datei ebenfalls im conf/-Verzeichnis des Projektarchivs zu speichern – also dort, wo auch svnserve.conf liegt. Andererseits möchten Sie vielleicht eine Passwortdatei für mehrere Projektarchive verwenden; in diesem Fall sollten Sie die Datei an einem zentraleren Ort ablegen. Die Projektarchive, die sich die Anwenderdatei teilen, sollten so konfiguriert sein, dass sie derselben Authentifikationsumgebung angehören, da die Anwenderliste im Wesentlichen einen Authentifikations-Bereich definiert. Wo die Datei auch liegen mag, stellen Sie sicher, die Lese- und Schreibrechte entsprechend zu setzen. Falls Sie wissen, unter welchem Konto svnserve laufen wird, sollten Sie den Lesezugriff zur Anwenderdatei auf das Notwendige beschränken.

Setzen von Zugriffsbeschränkungen

Es sind noch zwei weitere Variablen in der Datei svnserve.conf zu setzten: Sie legen fest, was nicht authentifizierten (anonymen) und authentifizierten Nutzern erlaubt ist. Die Variablen anon-access und auth-access können auf die Werte none, read oder write gesetzt werden. Wenn Sie den Wert auf none setzen, so unterbinden Sie sowohl den Lese- als auch den Schreibzugriff – read erlaubt den Nur-Lese-Zugriff auf das Projektarchiv und write gibt auf das gesamte Projektarchiv Lese- und Schreibzugriff.

[general]
password-db = Anwenderdatei
realm = Ihr realm

# Anonyme Anwender können nur lesend zugreifen
anon-access = read

# Authentifizierte Anwender können sowohl lesen als auch schreiben
auth-access = write

Tatsächlich sind die in diesem Beispiel gezeigten Einstellungen, auch die Standardwerte der Variablen, falls Sie vergessen sollten, sie zu setzten. Für den Fall, dass Sie noch zurückhaltender sein möchten, können Sie den anonymen Zugriff auch komplett unterbinden:

[general]
password-db = Anwenderdatei
realm = Ihr realm

# Anonyme Anwender sind nicht erlaubt
anon-access = none

# Authentifizierte Anwender können sowohl lesen als auch schreiben
auth-access = write

Der Serverprozess versteht nicht nur diese pauschalen Zugriffseinstellungen für ein Projektarchiv, sondern auch feiner granulierte Zugriffsrechte auf einzelne Dateien und Verzeichnisse innerhalb des Projektarchive. Um diese Funktion nutzen zu können, müssen Sie eine Datei anlegen, welche die umfangreicheren Regeln enthält und anschließend die Variable authz-db mit folgenden Wert setzten:

[general]
password-db = Anwenderdatei
realm = Ihr realm

# Zum Festlegen von umfangreicheren Zugriffsregeln für bestimmte Bereiche
authz-db = Auth-Datei

Wir werden die Syntax der Auth-Datei noch später in diesem Kapitel besprechen, und zwar in „Pfadbasierte Autorisierung“. Beachten Sie, dass die authz-db-Variable die Verwendung der anon-access- und auth-access-Variablen nicht ausschließt – wenn alle diese Variablen gleichzeitig gesetzt sind, so müssen auch alle diese Regeln erfolgreich greifen, bevor ein Zugriff erlaubt wird.

svnserve mit SASL verwenden

Die meisten Teams benötigen lediglich die eingebaute CRAM-MD5 Authentifizierung von svnserve. Falls Ihr Server (und Ihre Subversion Clients) jedoch mit der Cyrus Simple Authentication and Security Layer (SASL) Bibliothek gebaut wurde, stehen Ihnen eine Reihe von Authentifikations- und Verschlüsselungsoptionen zur Verfügung.

Wenn ein Subversion-Client sich mit svnserve verbindet, sendet der Server normalerweise eine Begrüßung, die eine Auflistung der von ihm unterstützten Fähigkeiten umfasst, woraufhin der Client mit einer ähnlichen Liste von Fähigkeiten antwortet. Falls der Server so konfiguriert wurde, dass er eine Authentifikation benötigt, sendet er eine Aufforderung, die die verfügbaren Authentifikationsmechanismen auflistet; der Client antwortet, indem er einen der Mechanismen auswählt und die Authentifizierung erfolgt dann mittels eines Nachrichtenaustausches. Selbst falls keine SASL-Fähigkeiten vorhanden sind, verstehen Client und Server von sich aus die CRAM-MD5- und ANONYMOUS-Mechanismen (siehe „Integrierte Authentifizierung und Autorisierung“). Falls Client und Server mit SASL gebaut wurden, könnten eine Anzahl weiterer Authentifikationsmechanismen verfügbar sein. Trotzdem müssen Sie serverseitig ausdrücklich SASL konfigurieren, um es anbieten zu können.

Authentifikation mit SASL

Um bestimmte SASL-Mechanismen auf dem Server zu aktivieren, müssen Sie zwei Dinge tun. Erstellen Sie zunächst einen Abschnitt [sasl] in der Datei svnserve.conf Ihres Projektarchivs mit einem Schlüssel-Wert-Paar:

[sasl]
use-sasl = true

Erstellen Sie zweitens eine SASL-Hauptkonfigurationsdatei namens svn.conf dort, wo die SASL-Bibliothek sie finden kann – typischerweise in dem Verzeichnis, wo Sie müssen das Plug-in-Verzeichnis auf Ihrem System lokalisieren, etwa /usr/lib/sasl2/ oder /etc/sasl2/. (Beachten Sie, dass es sich hierbei nicht um die Datei svnserve.conf handelt, die innerhalb eines Projektarchivs liegt!)

Auf einem Windows-Server müssen Sie außerdem die Systemregistratur anpassen (mit einem Werkzeug wie regedit), um SASL mitzuteilen, wo es Dinge finden kann. Erstellen Sie einen Registraturschlüssel namens [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library] und legen zwei weitere Schlüssel hinein: einen Schlüssel namens SearchPath (dessen Wert ein Pfad zum Verzeichnis bezeichnet, in dem die SASL sasl*.dll-Plug-in-Bibliotheken liegen) und einen Schlüssel namens ConfFile (dessen Wert ein Pfad zum Elternverzeichnis der von Ihnen erstellten Datei svn.conf ist).

Da SASL so viele unterschiedliche Arten von Authentifikationsmechanismen zur Verfügung stellt, wäre es töricht (und würde den Rahmen dieses Buches sprengen), wenn wir versuchen würden, jede mögliche Server-Konfiguration zu erläutern. Stattdessen empfehlen wir Ihnen, die Lektüre der Dokumentation aus dem Unterverzeichnis doc/ des SASL Quelltextes. Sie beschreibt detailliert jeden Mechanismus und die entsprechende Konfiguration des Servers. Für die Erörterung an dieser Stelle zeigen wir ein einfaches Beispiel der Konfiguration des DIGEST-MD5 Mechanismus. Wenn Ihre Datei svn.conf beispielsweise folgenden Inhalt hat:

pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/my_sasldb
mech_list: DIGEST-MD5

haben Sie SASL aufgefordert, Clients den DIGEST-MD5 Mechanismus anzubieten und Anwenderpasswörter mit einer privaten Passwort-Datenbank in /etc/my_sasldb abzugleichen. Ein Systemadministrator kann dann mit dem Programm saslpasswd2 Anwendernamen und Passwörter in der Datenbank eintragen oder bearbeiten:

$ saslpasswd2 -c -f /etc/my_sasldb -u realm username

Ein paar Worte zur Warnung: Stellen Sie zunächst sicher dass das Argument realm für saslpasswd2 demselben Bereich entspricht, den Sie in der Datei svnserve.conf Ihres Projektarchivs definiert haben; falls diese Werte nicht übereinstimmen, wird die Authentifikation fehlschlagen. Darüber hinaus muss aufgrund einer Unzulänglichkeit in SASL der gemeinsame Bereich aus einer Zeichenkette ohne Leerzeichen bestehen. Falls Sie sich entscheiden, die standardmäßige SASL-Passwort-Datenbank zu verwenden, sollten Sie schließlich sicherstellen, dass das Programm svnserve die Datei lesen (und möglicherweise auch schreiben) kann, wenn Sie einen Mechanismus wie OTP verwenden).

Dies ist lediglich eine einfache Art, SASL zu konfigurieren. Viele andere Authentifikationsmechanismen stehen zur Verfügung, und Passwörter können an anderer Stelle gespeichert werden, etwa in LDAP oder in einer SQL-Datenbank. Details hierzu finden Sie in der Dokumentation zu SASL.

Wenn Sie Ihren Server so konfigurieren, dass er nur bestimmte SASL-Authentifikationsmechanismen erlaubt, müssen Sie beachten, dass damit auch alle Clients gezwungen sind, SASL zu unterstützen. Kein Subversion-Client ohne SASL-Unterstützung (u.a. alle Clients vor Version 1.5) kann sich authentisieren. Andererseits möchten Sie vielleicht gerade diese Einschränkung (Meine Clients müssen sämtlich Kerberos verwenden!). Wenn Sie jedoch möchten, dass sich auch Nicht-SASL-Clients authentisieren können, stellen Sie sicher, dass optional der CRAM-MD5-Mechanismus angeboten wird. Alle Clients können CRAM-MD5 verwenden, egal, ob sie SASL verstehen oder nicht.

SASL Verschlüsselung

SASL kann auch Daten verschlüsseln, sofern ein bestimmter Mechanismus das unterstützt. Der eingebaute CRAM-MD5-Mechanismus unterstützt keine Verschlüsselung, jedoch DIGEST-MD5, und Mechanismen wie SRP erfordern sogar die Verwendung der OpenSSL-Bibliothek. Um verschiedene Verschlüsselungsstufen zu aktivieren oder abzustellen, können Sie zwei Werte in der Datei svnserve.conf Ihres Projektarchivs einstellen:

[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256

Die Variablen min-encryption und max-encryption kontrollieren die vom Server verlangte Verschlüsselungsstufe. Um Verschlüsselung vollständig abzustellen, setzen Sie beide Werte auf 0. Um die einfache Erstellung von Prüfsummen für Daten zu ermöglichen (etwa, um Manipulationen zu verhindern und Datenintegrität ohne Verschlüsselung zu garantieren), setzen Sie beide Werte auf 1. Falls Sie Verschlüsselung erlauben, jedoch nicht voraussetzen, setzen Sie den Minimalwert auf 0 und den Maximalwert auf irgendeine Bitlänge. Um unbedingte Verschlüsselung zu verlangen,, setzen Sie beide Werte auf Zahlen größer 1. Im vorangegangenen Beispiel verlangen wir, dass Clients mindestens 128-Bit- aber höchstens 256-Bit-Verschlüsselung vornehmen.

Tunneln über SSH

Die eingebaute Authentifikation (und die SASL-Unterstützung) von svnserve kann sehr praktisch sein, da es die Notwendigkeit echter Systemkonten vermeidet. Andererseits haben einige Administratoren bereits etablierte SSH-Authentifikations-Frameworks im Einsatz. In diesen Fällen haben die Anwender des Projektes bereits Systemkonten, um sich damit über SSH mit dem Server zu verbinden.

Es ist einfach, SSH in Verbindung mit svnserve zu verwenden. Der Client benutzt zum Verbinden einfach das svn+ssh:// URL-Schema:

$ whoami
harry

$ svn list svn+ssh://host.example.com/repos/project
harryssh@host.example.com's password:  *****

foo
bar
baz
…

In diesem Beispiel ruft der Subversion-Client einen lokalen ssh-Prozess auf, der sich mit host.example.com verbindet, sich (gemäß der SSH-Anwenderkonfiguration) als Anwender harryssh authentisiert und dann auf dem entfernten Rechner einen privaten svnserve-Prozess unter der Anwenderkennung harryssh startet. Der Befehl svnserve wird im Tunnelmodus (-t) aufgerufen und dessen Netzprotokoll wird über die durch den Tunnelagenten ssh verschlüsselte Verbindung getunnelt. Falls der Client eine Übergabe macht, wird der authentifizierte Anwendername harryssh als Autor der neuen Revision verwendet.

An dieser Stelle ist es wichtig, zu verstehen, dass der Subversion-Client sich nicht mit einem laufenden svnserve-Dämonen verbindet. Diese Zugriffsmethode benötigt keinen Dämonen und merkt auch nicht, wenn einer vorhanden ist. Sie verlässt sich vollständig auf die Fähigkeit von ssh, einen temporären svnserve-Prozesses zu starten, der nach dem Schließen der Netzverbindung beendet wird.

Denken Sie daran, dass beim Zugriff auf ein Projektarchiv über URLs der Form svn+ssh:// die Abfrage zur Authentifikation von ssh kommt und nicht vom svn-Client. Das bedeutet, dass es keine automatische Passwortspeicherung gibt (siehe „Zwischenspeichern von Zugangsdaten“). Der Subversion-Client stellt häufig mehrere Verbindungen mit dem Projektarchiv her, wenngleich Anwender das wegen der zwischengespeicherten Passwörter normalerweise gar nicht mitbekommen. Jedoch könnten Anwender bei Verwendung von svn+ssh://-URLs durch die wiederholten Passwortanfragen für ausgehende Verbindungen von ssh etwas genervt sein. Die Lösung besteht darin, ein zusätzliches Passwort-Speicherungs-Werkzeug wie etwa ssh-agent auf einem Unix-ähnlichen System oder pageant auf Windows zu verwenden.

Bei der Verwendung eines Tunnels wird die Autorisierung größtenteils durch die Betriebssystem-Berechtigungen auf die Datenbankdateien des Projektarchivs gesteuert, als ob Harry direkt über einen file://-URL auf das Projektarchiv zugreifen würde. Falls mehrere Anwender direkt auf das Projektarchiv zugreifen sollen, möchten Sie sie vielleicht in eine gemeinsame Gruppe zusammenfassen; Sie sollten auch auf umasks achten (lesen Sie auf alle Fälle „Unterstützung mehrerer Zugriffsmethoden auf das Projektarchiv“ später in diesem Kapitel). Doch selbst beim Tunneln können Sie immer noch die Datei svnserve.conf zum Blockieren des Zugriffs verwenden, indem Sie einfach auth-access = read oder auth-access = none setzen.[53]

Vielleicht glauben Sie, dass die Geschichte mit dem SSH-Tunneln hier endet. Es ist aber nicht so. Subversion erlaubt es Ihnen, selbstdefinierte Verhaltensweisen für das Tunneln in Ihrer Laufzeit-Datei config zu definieren (siehe „Laufzeit-Konfigurationsbereich“). Nehmen wir beispielsweise an, dass Sie RSH statt SSH verwenden möchten.[54] Definieren Sie einfach im Abschnitt [tunnels] Ihrer Datei config:

[tunnels]
rsh = rsh --

Ab jetzt können Sie diese neue Tunneldefinition verwenden, indem Sie ein URL-Schema benutzen, welches dem Namen Ihrer neuen Variablen entspricht: svn+rsh://host/path. Bei Verwendung des neuen URL-Schemas führt der Subversion-Client im Hintergrund eigentlich den Befehl rsh host svnserve -t aus. Falls Sie einen Anwendernamen im URL angeben (z.B. svn+rsh://username@host/path), wird der Client das auch mit in seinen Befehl übernehmen (rsh -- username@host svnserve -t).

[Warnung] Warnung

Beachten Sie, dass wir beim Definieren eines RSH-basierten Tunnels das ---Optionsende-Argument der Tunnel-Bwfehlszeile hinzugefügt haben. Das geschieht, um zu vermeiden, dass ein falsch gebildeter Host-Name als eine weitere Option des Tunnel-Befehls behandelt wird. Das gleiche sollten Sie für andere Tunnel-Befehle machen (zum Beispiel SSH).

Sie können jedoch auch viel raffiniertere neue Tunnel-Schemata definieren:

[tunnels]
joessh = $JOESSH /opt/alternate/ssh -p 29934 --

Dieses Beispiel verdeutlicht einige Dinge. Erstens zeigt es, wie der Subversion-Client angewiesen wird, ein bestimmtes Tunnelprogramm (/opt/alternate/ssh) mit speziellen Optionen zu starten. In diesem Fall würde der Zugriff auf einen URL wie svn+joessh:// das bestimmte SSH-Programm mit den Argumenten -p 29934 aufrufen – was nützlich ist, wenn Sie möchten, dass sich das Tunnelprogramm mit einem Nicht-Standard-Port verbindet.

Zweitens zeigt es, wie eine eigene Umgebungsvariable definiert werden kann, die den Namen des Tunnelprogramms überschreibt. Durch das Setzen der Umgebungsvariablen SVN_SSH besteht eine bequeme Methode, den Standard-SSH-Tunnelagenten zu ersetzen. Falls Sie jedoch für unterschiedliche Server verschiedene Werte überschreiben müssen, wobei jeder vielleicht einen anderen Port verwendet oder unterschiedliche Optionen an SSH übergeben werden müssen, können Sie die in diesem Beispiel vorgestellte Methode verwenden. Falls wir nun die Umgebungsvariable JOESSH setzten, würde deren Wert den gesamten Wert der Tunnelvariablen überschreiben – statt /opt/alternate/ssh -p 29934 würde $JOESSH ausgeführt.

SSH-Konfigurationstricks

Es ist möglich, nicht nur die Art und Weise zu steuern, auf die der Client ssh aufruft, sondern auch das Verhalten von sshd auf dem Server. In diesem Abschnitt zeigen wir, wie der von sshd ausgeführte svnserve-Befehl genau festgelegt wird sowie sich mehrere Anwender ein einzelnes Systemkonto teilen können.

Erstmalige Einrichtung

Ermitteln Sie zunächst das Heimatverzeichnis des Kontos, welches Sie zum Starten von svnserve verwenden möchten. Stellen Sie sicher, dass für das Konto ein Paar bestehend aus einem öffentlichen und einem privaten SSH-Schlüssel installiert ist und dass sich der Anwender über die Authentifikation mit einem öffentlichen Schlüssel anmelden kann. Die Authentifikation mit Passwort wird nicht funktionieren, da sich alle folgenden SSH-Tricks um die Verwendung der SSH-Datei authorized_keys drehen.

Falls noch nicht geschehen, erzeugen Sie die Datei authorized_keys (unter Unix üblicherweise ~/.ssh/authorized_keys). Jede Zeile dieser Datei beschreibt einen öffentlichen Schlüssel, der sich verbinden darf. Die Zeilen sehen normalerweise so aus:

  ssh-dsa AAAABtce9euch… user@example.com

Das erste Feld beschreibt die Art des Schlüssels, das zweite ist der eigentliche in Base64 codierte Schlüssel und das dritte Feld ist ein Kommentar. Es ist jedoch weniger bekannt, dass die gesamte Zeile mit einem command-Feld beginnen kann:

  command="program" ssh-dsa AAAABtce9euch… user@example.com

Falls das Feld command definiert ist, wird der SSH-Daemon das angegebene Programm starten anstatt wie üblich den vom Subversion-Client geforderten Aufruf von svnserve im Tunnelmodus auszuführen. Das öffnet die Tür für eine Reihe von serverseitigen Tricks. In den folgenden Beispielen werden wir die Zeilen der Datei wie folgt abkürzen:

  command="program" TYPE KEY COMMENT

Steuerung des aufgerufenen Befehls

Da wir den durch den Server ausgeführten Befehl angeben können, ist es leicht, ein bestimmtes svnserve-Programm zu benennen und ihm zusätzliche Argumente mitzugeben:

  command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT

In diesem Beispiel könnte es sich bei /path/to/svnserve um ein maßgeschneidertes Wrapper-Skript für svnserve handeln, das die umask setzt (siehe „Unterstützung mehrerer Zugriffsmethoden auf das Projektarchiv“). Es wird außerdem veranschaulicht, wie svnserve in einem virtuellen Wurzelverzeichnis verankert wird, so wie es oft gemacht wird, wenn svnserve als Daemon-Prozess läuft. Das könnte entweder geschehen, um den Zugriff auf Teile des Systems einzuschränken oder um dem Anwender die Bürde abzunehmen, einen absoluten Pfad im URL svn+ssh:// angeben zu müssen.

Es besteht weiterhin die Möglichkeit, dass sich mehrere Anwender ein einzelnes Konto teilen. Statt ein gesondertes Konto für jeden Anwender zu erstellen, generieren Sie für jede Person jeweils ein Paar aus einem öffentlichen und einem privaten Schlüssel. Tragen Sie dann jeden öffentlichen Schlüssel in eine eigene Zeile der Datei authorized_keys ein und verwenden die Option --tunnel-user:

  command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.com
  command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.com

Dieses Beispiel erlaubt sowohl Harry als auch Sally, sich über die Authentifikation durch einen öffentlichen Schlüssel mit demselben Konto zu verbinden. Beide verfügen über einen angepassten Befehl, der ausgeführt wird. Die Option --tunnel-user teilt svnserve mit, das benannte Argument als den authentifizierten Anwender zu akzeptieren. Ohne --tunnel-user sähe es so aus als kämen alle Übergaben vom gemeinsamen Konto.

Ein letztes Wort zur Warnung: Die Zugangsberechtigung für einen Anwender über einen öffentlichen Schlüssel und ein gemeinsames Konto könnte noch weitere SSH-Zugänge erlauben, selbst wenn Sie einen Wert für command in in authorized_keys angegeben haben. So kann der Anwender beispielsweise Shell-Zugang über SSH erlangen oder X11 oder allgemeine Portweiterleitung über Ihren Server einrichten. Um Ihrem Anwender die geringstmögliche Erlaubnis zu erteilen, sollten Sie unmittelbar nach command eine Reihe einschränkender Optionen angeben:

  command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-forw
arding,no-X11-forwarding,no-pty TYPE1 KEY1 harry@example.com

Beachten Sie, dass alles auf einer Zeile stehen muss – tatsächlich auf einer Zeile – da die SSH-Dateien authorized_keys nicht einmal das übliche Backslash-Zeichen (\) zur Zeilenfortsetzung erlauben. Der einzige Grund für den von uns eingefügten Zeilenumbruch ist die Unterbringung auf der Breite einer Buchseite.



[52] Siehe RFC 2195.

[53] Beachten Sie, dass die Verwendung irgendwelcher durch svnserve sichergestellten Zugriffskontrollen sinnlos ist, da der Anwender ohnehin direkten Zugriff auf die Projektarchiv-Datenbank hat.

[54] Wir empfehlen das natürlich nicht, da RSH deutlich unsicherer ist als SSH.