Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.
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 Zugriffsrechte zum
Projektarchiv korrekt eingerichtet werden.
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.
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 …
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 Befehlszeile.
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.
Einige Betriebssysteme stellen den Daemon
xinetd als Alternative zu
inetd zur Verfügung. Glücklicherweise
können Sie svnserve auch für die
Verwendung mit xinetd konfigurieren. Dazu
müssen Sie eine Konfigurationsdatei
/etc/xinetd.d/svn
mit dem folgenden
Inhalt anlegen:
# default: on
# description: Subversion-Server für das svn-Protokoll
service svn
{
disabled = no
port = 3690
socket_type = stream
protocol = tcp
wait = no
user = subversion
server = /usr/local/bin/svnserve
server_args = -i -r /path/to/repositories
}
Stellen Sie sicher, dass Ihre Konfigurationsdatei
/etc/services
die Definition für den
Port beinhaltet, der für das Protokoll
svn
verwendet wird (wie in
„svnserve über inetd starten“ beschrieben), da der Daemon ansonsten nicht korrekt
startet.
In Redhat-basierten Distributionen müssen Sie den neuen Dienst mit chkconfig --add svn aktivieren. Anschließend können Sie den Server unter Verwendung der graphischen Konfigurations-Werkzeuge ein- und ausschalten.
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 Fernzugriff – 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“.
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 Kommandozeilen-Aufrufes 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.
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-Netzwerkverkehr 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 | |
---|---|
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
|
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
Netzwerkverkehr auf dem svn
Netzwerk-Port
aufschlägt; es wird beendet nachdem der Verkehr abgewickelt
worden sein wird.
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 |
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 $
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 Authentifikation
(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 [61]. 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 Authentifikation. Lesen Sie „svnserve mit SASL verwenden“ weiter unten, um zu lernen, wie die einzelnen Möglichkeiten zur Authentifikation 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-Konfigurations-Bereich“): 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.
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.
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 „Pfad-basierte 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.
Die meisten Teams benötigen lediglich die eingebaute CRAM-MD5 Authentifikation 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 Authentifikation 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 Authentifikation 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.
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 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.
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 Passwort-Speicherung
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
Passwort-Anfragen 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.[62]
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-Konfigurations-Bereich“).
Nehmen wir beispielsweise an, dass Sie RSH statt SSH verwenden
möchten.[63]
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 | |
---|---|
Beachten Sie, dass wir beim Definieren eines RSH-basierten
Tunnels das |
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.
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.
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
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 Zugriffsberechtigung
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.
In den vorhergehenden Abschnitten erwähnten wir zahlreiche
Optionen, die Administratoren in ihren
svnserve.conf
Dateien verwenden können,
um das Verhalten von Subversion zu konfigurieren, so wie es
beim Zugriff über die Server-Option
svnserve geschieht. In diesem Abschnitt
wollen wir schnell alle von diesem Server
unterstützten Konfigurationsoptionen zusammenfassen.
Die Konfigurations-Datei svnserve.conf
verwendet ein typisches Format im INI-Stil mit Name-Wert
Paaren von Optionen, die in benannten Abschnitten
zusammengefasst werden. (Praktischerweise handelt es sich um
dasselbe Format, das im client-seitigen
Laufzeit-Konfigurations-Bereich des Netzes Verwendung findet.)
Wir werden hiermit jeden dieser benamten Abschnitte sowie die
darin verfügbaren Optionen beschreiben.
Standardmäßig untersucht svnserve
Konfigurations-Dateien pro Projektarchiv, die sich in
conf/svnserve.conf
innerhalb der
physischen Verzeichnisstruktur des Projektarchivs befinden. Um
stattdessen eine einzelne Konfigurations-Datei zu verwenden,
deren Werte für alle Projektarchive gelten, die von einer
Instanz von svnserve bedient werden,
verwenden Sie beim Start Ihres Servers die Option
--config-file
.
Anmerkung | |
---|---|
In den folgenden Abschnitten beziehen wir uns auf die
Konfigurations-Datei von svnserve unter
deren kanonischen Namen |
Der Abschnitt [general]
beinhaltet
die meist verwendeten und am weitesten wirksamen
Konfigurations-Optionen von
svnserve.
anon-access
Kontrolliert die Zugriffs-Ebene, die
nicht-authentifizierten (anonymen) Anwendern gewährt
wird. Gültige Werte sind write
,
read
, und none
,
wobei read
der Standardwert
ist.
auth-access
Kontrolliert die Zugriffs-Ebene, die
-authentifizierten Anwendern gewährt wird. Gültige
Werte sind write
,
read
, und none
,
wobei write
der Standardwert
ist.
authz-db
Gibt den Ort der Projektarchiv-Zugriffs-Datei an,
wie in
„Loslegen mit pfad-basierter Zugriffskontrolle“ beschrieben. Falls ein gewöhnlicher lokaler Pfad
verwendet wird, der nicht mit einem Schrägstrich
(/
) beginnt, wird er relativ zum
dem Verzeichnis interpretiert, in dem sich die
Konfigurations-Datei
svnserve.conf
befindet. Ist kein
Pfad angegeben, die pfad-basierte Zugriffskontrolle
abgeschaltet.
Als besondere Gegenleistung können Sie auch den
Ort einer Zugriffsdatei angeben, die innerhalb eines
Subversion-Projektarchivs versioniert ist. Verwenden
Sie einen lokalen URL (einen, der mit
file://
beginnt), um sich auf eine
absolute Zugriffsdatei zu beziehen, die durch
Subversion versioniert ist. Alternativ können Sie
einen URL relativ zum Projektarchiv angeben(einer, der
mit ^/
beginnt), um
svnserve dazu zu veranlassen, für
jedes Projektarchiv die unter dem bestimmten relativen
URL in diesem Projektarchiv gespeicherte Datei
heranzuziehen.
force-username-case
Gibt die Normalisierung der Groß- bzw.
Kleinschreibung von Anwendernamen an, bevor sie mit
den Regeln in der Zugriffsdatei (durch die Option
authz-db
spezifiziert) verglichen
werden. Gültige Werte sind upper
(Anwendernamen in Großbuchstaben umwandeln),
lower
(Anwendernamen in
Kleinbuchstaben umwandeln) und none
(keine Umwandlung vornehmen). Standardmäßig nimmt
svnserve keinerlei Umwandlung von
Anwendernamen vor.
groups-db
Gibt den Pfad der Gruppen-Datei an. Falls ein
gewöhnlicher lokaler Pfad verwendet wird, der nicht
mit einem Schrägstrich (/
) beginnt,
wird er relativ zum dem Verzeichnis interpretiert, in
dem sich die Konfigurations-Datei
svnserve.conf
befindet.
Sie können auch einen Ort einer Gruppen-Datei
angeben, die innerhalb eines Subversion-Projektarchivs
versioniert ist. Verwenden Sie einen lokalen URL
(einer, der mit file://
beginnt),
um eine absolute Datei unter Subversion-Versionierung
zu referenzieren. Alternativ verwenden Sie einen URL
relativ zum Projektarchiv (einer, der mit
^/
beginnt), um
svnserve dazu zu veranlassen, für
jedes Projektarchiv die Gruppen-Datei zu lesen, die am
angegebenen relativen URL innerhalb dieses
Projektarchivs liegt.
hooks-env
Gibt den Pfad zur Umgebungs-Konfigurations-Datei
für Hook-Skripte an. Diese Option überschreibt den
Standard-Ort für diese Datei pro Projektarchiv und
kann verwendet werden, um die Umgebung für
Hook-Skripte mehrerer Projektarchive in einer einzigen
Datei zu konfigurieren, falls ein absoluter Pfad
angegeben wird. Falls Sie keinen absoluten Pfad
angeben, wird der Ort der Datei relativ zu dem
Verzeichnis interpretiert, in dem sich die
Konfigurations-Datei
svnserve.conf
befindet.
Siehe „Konfiguration der Umgebung von Hook-Skripten“ für detaillierte Informationen zur Umgebungs-Konfigurations-Datei für Hook-Scripte.
password-db
Gibt den Pfad zur Passwort-Datei an. Sofern der
angegebene Pfad nicht mit einem Schrägstrich
(/
) beginnt, wird er relativ zum
Verzeichnis interpretiert, in dem sich die
Konfigurations-Datei
svnserve.conf
befindet.
Beachten Sie, dass diese Option ignoriert wird, falls
die SASL-Funktionalität verwendet wird.
realm
Gibt die Zugangsregion des Projektarchivs an. Dies wird primär vom Client verwendet, um zwischengespeicherte Authentisierungsdaten mit einem bestimmten Projektarchiv oder einer Menge von Projektarchiven zu verknüpfen. Daher sollte die angegebene Region über die Projektarchiv hinweg eindeutig sein, es sei denn, diese Projektarchive teilen sich dieselben Passwort-Daten. Standardmäßig wird der UUID des Projektarchivs als seine Zugangsregion verwendet.
Der Abschnitt [sasl]
beinhaltet die
Konfiguration, die spezifisch für die optionale Cyrus Simple
Authentication and Security Layer (SASL) Integration von
svnserve ist. Siehe
„svnserve mit SASL verwenden“ für eine
gründlichere Beschreibung dieser Funktionalität und die
hiermit verbundenen Vorteile.
max-encryption
Gibt die maximale Stärke des
Verschlüsselungs-Algorithmus der Sicherheitsschicht
als ganzzahlige Bit-Breite an.
Der besondere Wert
0
bedeutet "keine Verschlüsselung", und
der besondere Wert 1
bedeutet
"nur Integritäts-Überprüfung". Der Standardwert für
diese Option ist 256
(256-bit
Verschlüsselung).
min-encryption
Gibt die minimale Stärke des
Verschlüsselungs-Algorithmus der Sicherheitsschicht
als ganzzahlige Bit-Breite an. Der besondere Wert
0
bedeutet "keine Verschlüsselung",
und der besondere Wert 1
bedeutet
"nur Integritäts-Überprüfung". Der Standardwert für
diese Option ist 0
(keine
Verschlüsselung).
use-sasl
Gibt an (als true
oder
false
Wert), ob die the Cyrus SASL
Funktionalität aktiviert werden soll. Beachten Sie,
dass diese Funktionalität nur verfügbar ist, falls
dessen Unterstützung in svnserve
eingebaut wurde. Standardmäßig ist diese
Funktionalität deaktiviert.
[61] Siehe RFC 2195.
[62] Beachten Sie, dass die Verwendung irgendwelcher durch svnserve sichergestellten Zugriffskontrollen nur dann einen Sinn ergibt, falls die Anwender sie nicht umgehen und unter Verwendung anderer Werkzeuge (etwa cd und vi) direkt auf das Projektarchiv-Verzeichnis zugreifen können; die Einrichtung derartiger Einschränkungen wird in „Steuerung des aufgerufenen Befehls“ beschrieben.
[63] Wir empfehlen das natürlich nicht, da RSH deutlich unsicherer ist als SSH.