Download Versionskontrolle mit Subversion - Version Control with Subversion

Konfiguration des Servers
[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 Authentifizierung (und die SASL-Unterstützung) von svnserve kann sehr praktisch sein, da es die
Notwendigkeit echter Systemkonten vermeidet. Andererseits haben einige Administratoren bereits etablierte SSHAuthentifikations-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
[email protected]'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
196