Die einfachste Methode, einen Client zu authentifizieren geht über den HTTP-Basic-Authentifikationsmechanismus, der einfach einen Anwendernamen und ein Passwort verwendet, um sicherzustellen, das ein Anwender auch derjenige ist, für den er sich ausgibt. Apache stellt ein Dienstprogramm zur Verwaltung der Liste zulässiger Anwendernamen und Passwörter namens htpasswd zur Verfügung. Lassen Sie uns Sally und Harry die Berechtigung zur Übergabe erteilen. Zunächst müssen wir sie der Passwortdatei hinzufügen:

$ ### Beim 1. Mal: -c verwenden, um die Datei anzulegen
$ ### -m für die sicherere MD5-Verschlüsselung des Passworts verwenden
$ htpasswd -cm /etc/svn-auth-file harry
New password: *****
Re-type new password: *****
Adding password for user harry
$ htpasswd -m /etc/svn-auth-file sally
New password: *******
Re-type new password: *******
Adding password for user sally
$

Als nächstes müssen Sie innerhalb Ihres Location-Blocks ein paar weitere httpd.conf-Direktiven hinzufügen, um Apache zu sagen, was mit Ihrer neuen Passwortdatei zu tun ist. Die Direktive AuthType spezifiziert den Typ des zu verwendenden Authentifikationssystems. In diesem Fall möchten wir das Basic-Authentfikationssystem spezifizieren. AuthName ist ein beliebiger Name, den Sie Ihrer Authentifikationsdomäne geben. Die meisten Browser zeigen diesen Namen in einem Dialog an, wenn der Browser den Anwender nach seinem Namen und dem Passwort fragt. Verwenden Sie schließlich die Direktive AuthUserFile, um den Ort der Passwortdatei zu spezifizieren, die sie mit htpasswd erstellt haben.

Nachdem Sie diese Direktiven hinzugefügt haben, sollte Ihr <Location>-Block etwa so aussehen:

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/svn-auth-file
</Location>

Dieser <Location>-Block ist noch unvollständig und bewirkt noch nichts sinnvolles. Er teilt Apache lediglich mit, dass es sich den Anwendernamen und das Passwort vom Subversion-Client besorgen soll, falls eine Autorisierung benötigt wird. Was hier jedoch noch fehlt, sind Direktiven, die Apache sagen, welche Arten von Client-Anfragen eine Autorisierung erfordern. Überall dort wo eine Autorisierung verlangt wird, erwartet Apache auch eine Authentifikation. Das Einfachste ist es, alle Anfragen zu schützen. Durch Hinzufügen von Require valid-user wird Apache mitgeteilt, dass alle Anfragen einen authentifizierten Anwender erfordern:

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/svn-auth-file
  Require valid-user
</Location>

Stellen Sie sicher, dass Sie für weitere Details zur Require-Direktive und anderen Wegen, Autorisierungsrichtlinien festzulegen, den nächsten Abschnitt („Autorisierungsoptionen“) lesen.

Ein Wort zur Warnung: HTTP-Basic-Auth-Passwörter werden nahezu im Klartext durch das Netz geschickt und sind deshalb in höchstem Maße unsicher.

Eine weitere Option besteht darin, statt der Basic-Authentifizierung die Digest-Authentifizierung zu verwenden. Digest-Authentifizierung erlaubt es dem Server, die Identität des Clients zu bestätigen, ohne das Passwort als Klartext durch das Netz zu schicken. Unter der Voraussetzung, dass sowohl dem Client als auch dem Server das Passwort des Anwenders bekannt ist, können sie verifizieren, dass das Passwort dasselbe ist, indem sie eine Hashfunktion auf ein Einweg-Informationshäppchen anwenden. Der Server sendet eine kleine zufällige Zeichenkette an den Client. Der Client verwendet das Passwort des Anwenders, um die Zeichenkette zu hashen, und der Server prüft dann, ob der gehashte Wert dem erwarteten Ergebnis entspricht.

Es ist auch ziemlich einfach, Apache für die Digest-Authentifizierung zu konfigurieren und lediglich eine kleine Abweichung des vorangegangenen Beispiels. Für weitere Einzelheiten wird die Dokumentation zu Apache empfohlen.

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  AuthType Digest
  AuthName "Subversion repository"
  AuthDigestDomain /svn/
  AuthUserFile /etc/svn-auth-file
  Require valid-user
</Location>

Falls Sie maximale Sicherheit anstreben, ist ein asymmetrisches Kryptosystem das Mittel der Wahl. Am besten sollte eine Art der SSL-Verschlüsselung eingesetzt werden, so dass Clients sich über https:// statt http:// authentisieren; als Minimallösung können Sie Apache so einstellen, dass ein selbstsigniertes Server-Zertifikat verwendet wird. ^[43] Wie das bewerkstelligt wird, ist der Dokumentation von Apache (und OpenSSL) zu entnehmen.

Unternehmen, die ihre Projektarchive für den Zugriff von außerhalb der Firewall freigeben müssen, sollten sich bewusst sein, dass Unbefugte den Netzverkehr „abhören“ könnten. SSL lässt diese Art unerwünschte Aufmerksamkeit weniger anfällig für heikle Datenlecks werden.

Ist ein Subversion-Client für die Verwendung von OpenSSL übersetzt worden, ist er in der Lage, mit einem Apache-Server über https://-URLs zu kommunizieren. Die vom Subversion-Client verwendete Neon-Bibliothek kann nicht nur Server-Zertifikate zertifizieren, sondern nach Aufforderung auch Client-Zertifikate liefern. Wenn der Client und der Server SSL-Zertifikate ausgetauscht und sich gegenseitig erfolgreich authentifiziert haben, wird jede weitere Kommunikation durch einen Sitzungsschlüssel verschlüsselt.

Es würde den Rahmen dieses Buches sprengen, wenn beschrieben würde, wie Client- und Server-Zertifikate erzeugt werden und wie Apache für ihre Verwendung konfiguriert wird. Viele andere Bücher, darunter Apaches eigene Dokumentation, erläutern diese Aufgabe. Was wir an dieser Stelle jedoch behandeln können, ist die Verwaltung der Client- und Server-Zertifikate durch einen gewöhnlichen Subversion-Client.

Wenn über https:// mit Apache gesprochen wird, kann ein Subversion-Client zwei unterschiedliche Arten von Informationen empfangen:

Wenn der Client ein Server-Zertifikat empfängt, muss er sicherstellen, dass er dem Zertifikat vertrauen kann: handelt es sich bei dem Server wirklich um denjenigen, für den er sich ausgibt? Die OpenSSL-Bibliothek macht das, indem der Unterzeichner des Server-Zertifikats, die sogenannte Certificate Authority (CA), oder Zertifizierungsstelle, untersucht wird. Falls OpenSSL der CA nicht automatisch vertrauen kann, oder falls ein anderes Problem auftaucht (etwa ein abgelaufenes Zertifikat oder ein nicht übereinstimmender Rechnername), fragt Sie der Subversion-Kommandozeilenclient, ob Sie dem Server-Zertifikat dennoch vertrauen möchten:

$ svn list https://host.example.com/repos/project

Fehler bei der Validierung des Serverzertifikats für »https://host.example.com:443«:
 - Das Zertifikat ist nicht von einer vertrauenswürdigen Instanz ausgestellt
   Überprüfen Sie den Fingerabdruck, um das Zertifikat zu validieren!
Zertifikats-Informationen:
 - Hostname: host.example.com
 - Gültig: von Jan 30 19:23:56 2004 GMT bis Jan 30 19:23:56 2006 GMT
 - Aussteller: CA, example.com, Sometown, California, US
 - Fingerabdruck: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b

Ve(r)werfen, (t)emporär akzeptieren oder (p)ermanent akzeptieren?

Dieser Dialog sollte Ihnen bekannt vorkommen; im Wesentlichen ist es dieselbe Frage, die Sie wahrscheinlich bei Ihrem Web-Browser gesehen haben (der auch bloß ein weiterer HTTP-Client ist, so wie Subversion). Falls Sie die Option (p)ermanent auswählen, wird das Server-Zertifikat in Ihrem privaten Laufzeit-auth/-Bereich zwischengespeichert, ebenso wie Ihr Anwendername und Passwort (siehe „Zwischenspeicherung der Client-Zugangsdaten“). Falls es zwischengespeichert ist, wird Subversion diesem Zertifikat bei künftigen Protokollverhandlungen vertrauen.

Ihre Laufzeit-Datei servers ermöglicht es Ihrem Client auch, automatisch bestimmten CAs zu vertrauen, entweder global oder pro Host. Setzen Sie die Variable ssl-authority-files auf eine durch Semikolons getrennte Liste PEM-kodierter CA-Zertifikate:

[global]
ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem

Viele OpenSSL-Installationen besitzen auch eine vordefinierte Menge von „Standard“-CAs, denen nahezu allgemein vertraut wird. Damit der Subversion-Client diesen Standard-Zertifizierungsstellen automatisch vertraut, setzen Sie die Variable ssl-trust-default-ca auf true.

Bei der Kommunikation mit Apache kann ein Subversion-Client die Aufforderung erhalten, ein Client-Zertifikat vorzulegen. Apache ersucht den Client, sich zu identifizieren; ist der Client wirklich derjenige, als der er sich ausgibt? Wenn alles richtig funktioniert, schickt der Client ein privates Zertifikat zurück, das von einer CA signiert wurde, der Apache vertraut. Für gewöhnlich wird ein Client-Zertifikat, durch ein lokales Passwort geschützt, verschlüsselt auf Platte gespeichert. Wenn Subversion diese Aufforderung erhält, fragt es Sie nach dem Pfad zum Zertifikat und dem Passwort:

$ svn list https://host.example.com/repos/project

Anmeldebereich: https://host.example.com:443
Client Zertifikatsdatei: /path/to/my/cert.p12
Passphrase für »/path/to/my/cert.p12«:  ********
…

Beachten Sie, dass das Client-Zertifikat eine „p12“-Datei ist. Um ein Client-Zertifikat mit Subversion verwenden zu können, muss es im PKCS#12-Format sein, was einem portablen Standard entspricht. Die meisten Web-Browser können bereits Zertifikate in diesem Format im- und exportieren. Eine weitere Option ist es, die OpenSSL-Kommandozeilenwerkzeuge zu verwenden, um bestehende Zertifikate in PKCS#12 zu überführen.

Auch hier erlaubt Ihnen die Laufzeitdatei servers, diese Aufforderung pro Host zu automatisieren. Diese Informationen lassen sich für sich oder gemeinsam in Laufzeitvariablen beschreiben:

[groups]
examplehost = host.example.com

[examplehost]
ssl-client-cert-file = /path/to/my/cert.p12
ssl-client-cert-password = somepassword

Sobald die Variablen ssl-client-cert-file und ssl-client-cert-password gesetzt sind, kann der Subversion-Client automatisch auf eine Anforderung eines Client-Zertifikats antworten, ohne eine Eingabe von Ihnen zu verlangen. ^[44]

Die einfachste Form der Zugriffskontrolle besteht darin, bestimmten Nutzern entweder nur Lesezugriff oder Lese- und Schreibzugriff auf ein Projektarchiv zu gewähren.

Sie können den Zugriff auf alle Operationen im Projektarchiv einschränken, indem Sie die Direktive Require valid-user Ihrem <Location>-Block hinzufügen. Für unser vorheriges Beispiel würde das bedeuten, dass es nur Clients, die sich entweder als harry oder sally ausgeben und das korrekte Passwort für den entsprechenden Anwendernamen liefern, erlaubt wird, irgendetwas mit dem Subversion-Projektarchiv zu machen:

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # wie ein Nutzer authentifiziert wird
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file

  # nur authentifizierte Nutzer dürfen an das Projektarchiv
  Require valid-user
</Location>

Manchmal müssen Sie gar nicht so ein strenges Regiment führen. So erlaubt beispielsweise das eigene Projektarchiv von Subversion unter http://svn.collab.net/repos/svn allen auf der Welt lesende Operationen (wie etwa das Auschecken von Arbeitskopien und das Stöbern mit einem Web-Browser), beschränkt jedoch Schreiboperationen auf authentifizierte Nutzer. Um diese abgestufte Einschränkung einzurichten, können Sie die Konfigurationsdirektiven Limit und LimitExcept verwenden. Ähnlich der Direktive Location haben diese Blöcke Start- und Ende-Tags, die Sie innerhalb Ihres <Location>-Blocks unterbringen.

Die für die Direktiven Limit und LimitExcept verfügbaren Parameter sind HTTP-Anfrage-Typen, die durch diesen Block berührt werden. Falls Sie beispielsweise alle Zugriffe auf Ihr Projektarchiv unterbinden möchten, außer die momentan unterstützten Leseoperationen, so würden Sie die Direktive LimitExcept mit den Anfrage-Parametern GET, PROPFIND, OPTIONS und REPORT verwenden. Dann wird die eben erwähnte Direktive Require valid-user im <LimitExcept>-Block statt innerhalb des <Location>-Blocks eingefügt.

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # wie ein Nutzer authentifiziert wird
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file

  # nur authentifizierte Nutzer dürfen mehr als die angegebenen Operationen
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

Dies sind nur ein paar einfache Beispiele. Für tiefer gehende Informationen über Apaches Zugriffskontrolle und die Direktive Require sollten Sie im Abschnitt Security der Apache Lehrbuchsammlung unter http://httpd.apache.org/docs-2.0/misc/tutorials.html nachlesen.

Es ist möglich, mithilfe eines zweiten Apache http-Moduls – mod_authz_svn – detailliertere Zugriffsrechte einzurichten. Dieses Modul schnappt sich die verschiedenen undurchsichtigen URLs, die vom Client zum Server gereicht werden, fordert mod_dav_svn auf, sie zu dekodieren, und unterbindet dann möglicherweise Anforderungen entsprechend in einer Konfigurationsdatei definierter Zugriffsregeln.

Falls Sie Subversion aus Quellcode gebaut haben, ist mod_authz_svn automatisch neben mod_dav_svn gebaut und installiert worden. Viele binäre Distributionen installieren es ebenfalls automatisch. Um die korrekte Installation zu überprüfen, müssen Sie sicherstellen, dass es direkt hinter der LoadModule-Direktive von mod_dav_svn in httpd.conf auftaucht:

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

Zur Aktivierung dieses Moduls müssen Sie Ihren Location-Block mit der Direktive AuthzSVNAccessFile konfigurieren, die eine Datei mit Zugriffsrichtlinien für Pfade in Ihren Projektarchiven bezeichnet. (Gleich werden wir auf das Format dieser Datei eingehen.)

Da Apache flexibel ist, haben Sie die Wahl, Ihren Block auf eine von drei Arten zu konfigurieren. Fangen Sie mit der Auswahl eines dieser grundlegenden Konfigurationsmuster an. (Die folgenden Beispiele sind sehr einfach gehalten; sehen Sie sich die mitgelieferte Apache-Dokumentation an, um wesentlich mehr Einzelheiten zu den Authentifikations- und Autorisierungsoptionen von Apache zu erfahren.)

Der einfachste Block besteht aus einem völlig offenen Zugang. In diesem Szenario schickt Apache niemals Aufforderungen zur Authentifikation, so dass alle Anwender als „anonymous“ behandelt werden. (Siehe Beispiel 6.1, „Eine Beispielkonfiguration für anonymen Zugang“.)

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  # unsere Zugangsrichtlinie
  AuthzSVNAccessFile /path/to/access/file
</Location>
          

Am anderen Ende der Paranoia-Skala können Sie Ihren Block so konfigurieren, dass sich jedermann authentisieren muss. Alle Clients müssen sich ausweisen. Ihr Block verlangt eine unbedingte Authentifikation mit der Direktive Require valid-user; diese Direktive definiert auch, wie die Authentifizierung erfolgen soll. (Siehe Beispiel 6.2, „Eine Beispielkonfiguration für authentifizierten Zugang“.)

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  # unsere Zugangsrichtlinie
  AuthzSVNAccessFile /path/to/access/file

  # nur authentifizierte Anwender haben Zugriff auf das Projektarchiv
  Require valid-user

  # wie ein Anwender zu authentifizieren ist
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file
</Location>
          

Ein drittes sehr verbreitetes Muster ist es, eine Kombination aus authentifizierten und anonymen Zugriff zu erlauben. So möchten beispielsweise viele Administratoren den Lesezugriff auf bestimmte Verzeichnisse des Projektarchivs für anonyme Anwender freigeben, während in heiklen Bereichen nur authentifizierte Anwender lesen (oder schreiben) dürfen. Bei dieser Einstellung greifen alle Anwender zunächst anonym auf das Projektarchiv zu. Falls Ihre Zugangsrichtlinien an einer Stelle einen echten Anwendernamen erfordern sollte, fordert Apache den Client auf, sich zu authentisieren. Eingestellt wird dieses Verhalten mit den gemeinsam verwendeten Direktiven Satisfy Any sowie Require valid-user. (Siehe Beispiel 6.3, „Eine Beispielkonfiguration für gemischten authentifizierten/anonymen Zugang“.)

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  # unsere Zugangsrichtlinie
  AuthzSVNAccessFile /path/to/access/file

  # erst anonymen Zugang, nach Bedarf
  # echte Authentifizierung
  Satisfy Any
  Require valid-user

  # wie ein Anwender zu authentifizieren ist
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file
</Location>
          

Sobald Sie sich für eine dieser drei grundsätzlichen httpd.conf-Vorlagen entschieden haben, müssen Sie Ihre Datei mit den Zugangsregeln für bestimmte Pfade innerhalb des Projektarchivs erstellen. Wir beschreiben später in „Pfadbasierte Autorisierung“ wie das funktioniert.

Das Modul mod_dav_svn unternimmt einen hohen Arbeitsaufwand, um sicherzustellen, dass Daten, die Sie als „nicht lesbar“ markiert haben, nicht versehentlich nach draußen geraten. Das bedeutet, dass es aufmerksam alle Pfade überwachen muss, die von Befehlen wie svn checkout und svn update zurückgegeben werden. Begegnen diese Befehle einem Pfad, der aufgrund einer Autorisierungsrichtlinie nicht lesbar ist, wird dieser Pfad üblicherweise vollständig unterdrückt. Im Fall der Historien- oder Umbenennungsverfolgung, z.B. mit einem Befehl wie svn cat -r OLD foo.c auf einer Datei, die vor langer Zeit umbenannt wurde, bleibt die Umbenennungsverfolgung einfach stehen, wenn einer der früheren Namen des Objektes als lesebeschränkt erkannt wird.

All diese Pfadüberprüfungen können manchmal sehr teuer werden, besonders mit svn log. Wenn eine Liste mit Revisionen erstellt wird, sieht der Server bei jedem geänderten Pfad in jeder Revision nach, ob er lesbar ist. Falls ein nicht lesbarer Pfad entdeckt wird, taucht er in der Liste der geänderten Pfade dieser Revision nicht auf (normalerweise sichtbar mit der Option --verbose), und die gesamte Protokollnachricht wird unterdrückt. Es bedarf wohl keiner Erwähnung, dass dies bei Revisionen, die eine große Anzahl an Pfaden betreffen, sehr zeitaufwändig sein kann. Das ist der Preis für Sicherheit: selbst wenn Sie überhaupt kein Modul wie mod_authz_svn konfiguriert haben, fordert das Modul mod_dav_svn Apache httpd auf, Autorisierungsüberprüfungen für jeden Pfad vorzunehmen. Das Modul mod_dav_svn weiß nicht, welche Autorisierungsmodule installiert wurden, also kann es lediglich Apache auffordern, all das aufzurufen, was vorhanden sein könnte.

Auf der anderen Seite gibt es auch eine Art Notausgang, der es Ihnen erlaubt, Sicherheitsmerkmale gegen Geschwindigkeit zu tauschen. Falls Sie nicht irgendeine Art verzeichnisbasierter Autorisierung durchsetzen möchten (d.h., mod_authz_svn oder ähnliche Module nicht verwenden), können Sie die gesamte Pfadüberprüfung abstellen. Verwenden Sie die Direktive SVNPathAuthz in Ihrer Datei httpd.conf wie in Beispiel 6.4, „Abstellen aller Pfadüberprüfungen“ gezeigt.

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  SVNPathAuthz off
</Location>
          

Standardmäßig steht die Direktive SVNPathAuthz auf „on“. Auf „off“ gesetzt, wird die gesamte pfadbasierte Autorisierungsüberprüfung abgestellt. mod_dav_svn beendet den Aufruf von Autorisierungsüberprüfungen für jeden entdeckten Pfad.

Einer der nützlichsten Vorteile eines Apache/WebDAV Aufbaus für Ihr Subversion Projektarchiv besteht darin, dass die jüngsten Versionen Ihrer versionierten Dateien und Verzeichnisse unmittelbar mit einem gewöhnlichen Webbrowser betrachtet werden können. Da Subversion zur Identifizierung versionierter Ressourcen URLs verwendet, können diese URLs für den HTTP-basierten Zugriff direkt im Webbrowser eingetippt werden. Ihr Browser verschickt daraufhin für diesen URL eine HTTP GET-Anfrage; je nachdem, ob dieser URL ein versioniertes Verzeichnis oder eine Datei repräsentiert, antwortet mod_dav_svn mit der Auflistung eines Verzeichnisinhalts oder mit dem Inhalt einer Datei.

Da die URLs keinerlei Informationen über die Ressourcenversion enthalten, die Sie sehen möchten, antwortet mod_dav_svn stets mit der jüngsten Version. Diese Funktionalität hat den wundervollen Nebeneffekt, dass Sie Subversion-URLs als Dokumentverweise an Ihre Mitarbeiter weitergeben können, die stets auf die neuesten Ausprägungen dieser Dokumente zeigen werden. Natürlich können Sie diese URLs auch aus anderen Webseiten heraus verwenden.

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  SVNIndexXSLT "/svnindex.xsl"
  …
</Location>

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  SVNListParentPath on
  …
</Location>

Da Apache im Grunde genommen ein HTTP-Server ist, beinhaltet er fantastisch anpassungsfähige Protokollierungsmöglichkeiten. Es würde den Rahmen dieses Buches sprengen, alle Protokollierungseinstellungen zu erörtern, doch soll darauf hingewiesen werden, dass selbst die gewöhnlichste httpd.conf-Datei Apache veranlasst, zwei Protokolldateien anzulegen: error_log und access_log. Diese Protokolldateien können an unterschiedlichen Orten liegen, werden normalerweise aber im Protokollbereich Ihrer Apache-Installation angelegt. (Unter Unix liegen sie oft in /usr/local/apache2/logs/.)

Die Datei error_log zeichnet sämtliche internen Fehler beim Betrieb von Apache auf. Die Datei access_log protokolliert jede von Apache empfangene eingehende HTTP-Abfrage. Das macht es einfach, festzustellen, von welchen IP-Adressen Subversion-Clients kommen, wie oft bestimmte Clients den Server benutzen, welche Anwender sich richtig anmelden und welche Abfragen erfolgreich sind oder fehlschlagen.

Da HTTP ein zustandsloses Protokoll ist, erzeugt selbst die einfachste Funktion eines Subversion Clients leider mehrere Netzwerkabfragen. Es ist sehr schwer, anhand der Datei access_log herzuleiten, was der Client tat; die meisten Funktionen sehen aus wie eine Folge kryptischer PROPPATCH-, GET-, PUT- und REPORT-Abfragen. Und, was alles noch komplizierter macht: viele Client-Funktionen schicken fast identische Anfragen, was ein Auseinanderhalten erschwert.

mod_dav_svn kann Ihnen jedoch helfen. Durch die Aktivierung einer „operativen Protokollierung“ können Sie mod_dav_svn veranlassen, eine gesonderte Protokolldatei anzulegen, die festhält, welche Art von Funktionen Ihre Clients auf höherer Ebene ausführen.

Um das zu bewerkstelligen, müssen Sie die Apache-Direktive CustomLog verwenden (die detailliert in der Dokumentation zu Apache beschrieben wird). Stellen Sie sicher, dass Sie die Direktive außerhalb Ihres Subversion Location-Blocks verwenden:

<Location /svn>
  DAV svn
  …
</Location>

CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION

In diesem Beispiel veranlassen wir Apache, die spezielle Protokolldatei svn_logfile im standardmäßigen Verzeichnis für Apache Protokolldateien, logs, anzulegen. Die Variablen %t und %u werden durch die Zeit bzw. den Anwendernamen der Anfrage ersetzt. Die wirklich wichtigen Teile sind die zwei Instanzen von SVN-ACTION. Wenn Apache diese Variable sieht, ersetzt er den Wert der Umgebungsvariablen SVN-ACTION, die automatisch von mod_dav_svn belegt wird, wenn eine Client-Funktion auf hoher Ebene feststellt wird.

Statt also eine traditionelle access_log-Protokolldatei auswerten zu müssen, die etwa so aussieht:

[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/vcc/default HTTP/1.1" 207 398
[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/bln/59 HTTP/1.1" 207 449
[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc HTTP/1.1" 207 647
[26/Jan/2007:22:25:29 -0600] "REPORT /svn/calc/!svn/vcc/default HTTP/1.1" 200 607
[26/Jan/2007:22:25:31 -0600] "OPTIONS /svn/calc HTTP/1.1" 200 188
[26/Jan/2007:22:25:31 -0600] "MKACTIVITY /svn/calc/!svn/act/e6035ef7-5df0-4ac0-b811-4be7c823f998 HTTP/1.1" 201 227
…

können Sie eine weit verständlichere Datei svn_logfile durchgehen, die so aussieht:

[26/Jan/2007:22:24:20 -0600] - get-dir /tags r1729 props
[26/Jan/2007:22:24:27 -0600] - update /trunk r1729 depth=infinity send-copyfrom-args
[26/Jan/2007:22:25:29 -0600] - status /trunk/foo r1729 depth=infinity
[26/Jan/2007:22:25:31 -0600] sally commit r1730

Eine vollständige Liste mit allen protokollierten Aktionen finden Sie unter „Protokollierung auf hoher Ebene“.

Einer der netten Vorteile von Apache als Subversion-Server ist die Möglichkeit zur Einrichtung eines einfachen Abgleichs. Nehmen wir zum Beispiel an, dass Ihr Team über vier Standorte auf der Welt verteilt ist. Da das Subversion-Projektarchiv nur an einem davon untergebracht sein kann, ist es für die anderen drei Standorte kein Vergnügen, darauf zuzugreifen, da sie wahrscheinlich eine spürbar langsamere Verbindung und längere Antwortzeiten beim Aktualisieren und Abliefern von Code erdulden müssen. Eine leistungsfähige Lösung besteht darin, ein System aufzusetzen, das aus einem Master-Apache-Server und mehreren Slave-Apache-Servern besteht. Falls Sie an jedem Standort einen Slave-Server aufstellen, können die Anwender eine Arbeitskopie vom nächstgelegenen Slave auschecken. Alle Leseanfragen gehen an den Server vor Ort. Schreibanfragen werden automatisch an den einzigen Master-Server weitergeleitet. Wenn die Übergabe abgeschlossen ist, „schiebt“ der Master automatisch die neue Revision mithilfe des Abgleichswerkzeugs svnsync auf jeden Slave-Server.

Diese Konfiguration bewirkt eine riesige, für Ihre Anwender deutlich wahrnehmbare Geschwindigkeitszunahme, da der Netzverkehr von Subversion-Clients normalerweise zu 80—90% aus Leseabfragen besteht. Und wenn diese Abfragen von einem lokalen Server kommen, ist das ein Riesengewinn.

In diesem Abschnitt begleiten wir Sie durch eine Standard-Einrichtung dieses Ein-Master/Mehrere-Slaves-Systems. Denken Sie jedoch daran, dass auf Ihren Servern mindestens Apache 2.2.0 (mit geladenem mod_proxy) und Subversion 1.5 (mod_dav_svn) laufen muss.

<Location /svn>
  DAV svn
  SVNPath /var/svn/repos
  SVNMasterURI http://master.example.com/svn
  …
</Location>

<Location /svn-proxy-sync>
  DAV svn
  SVNPath /var/svn/repos
  Order deny,allow
  Deny from all
  # Nur Zugriffe auf diese Location von der IP-Adresse des Servers erlauben:
  Allow from 10.20.30.40
  …
</Location>

$ svnsync init http://slave1.example.com/svn-proxy-sync file://var/svn/repos
Eigenschaften für Revision 0 kopiert.
$ svnsync init http://slave2.example.com/svn-proxy-sync file://var/svn/repos
Eigenschaften für Revision 0 kopiert.
$ svnsync init http://slave3.example.com/svn-proxy-sync file://var/svn/repos
Eigenschaften für Revision 0 kopiert.

# Die initiale Replizierung durchführe

$ svnsync sync http://slave1.example.com/svn-proxy-sync
Übertrage Daten ....
Revision 1 übertragen.
Eigenschaften für Revision 1 kopiert.
Übertrage Daten ....
Revision 2 übertragen.
Eigenschaften für Revision 2 kopiert.
…

$ svnsync sync http://slave2.example.com/svn-proxy-sync
Übertrage Daten ....
Revision 1 übertragen.
Eigenschaften für Revision 1 kopiert.
Übertrage Daten ....
Revision 2 übertragen.
Eigenschaften für Revision 2 kopiert.
…

$ svnsync sync http://slave3.example.com/svn-proxy-sync
Übertrage Daten ....
Revision 1 übertragen.
Eigenschaften für Revision 1 kopiert.
Übertrage Daten ....
Revision 2 übertragen.
Eigenschaften für Revision 2 kopiert.
…

#!/bin/sh
# Post-Commit-Skript zum Replizieren der neu übergebenen Revision an die Slaves

svnsync sync http://slave1.example.com/svn-proxy-sync > /dev/null 2>&1
svnsync sync http://slave2.example.com/svn-proxy-sync > /dev/null 2>&1
svnsync sync http://slave3.example.com/svn-proxy-sync > /dev/null 2>&1

#!/bin/sh
# Post-revprop-Change-Skript zur Weitergabe der Änderung an den Revisionseigenschaften an die Slaves

REV=${2}
svnsync copy-revprops http://slave1.example.com/svn-proxy-sync ${REV} > /dev/null 2>&1
svnsync copy-revprops http://slave2.example.com/svn-proxy-sync ${REV} > /dev/null 2>&1
svnsync copy-revprops http://slave3.example.com/svn-proxy-sync ${REV} > /dev/null 2>&1

Einige der Funktionen, die Apache als robuster Webserver mitbringt, können auch zur Verbesserung der Funktionalität und Sicherheit in Subversion verwendet werden. Der Subversion-Client kann SSL (den bereits besprochenen Secure Sockets Layer) verwenden. Falls ihr Subversion-Client mit SSL-Unterstützung gebaut wurde, kann er auf Ihren Apache-Server mit https:// zugreifen und sich einer verschlüsselten Netzwerksitzung von hoher Qualität erfreuen.

Gleichermaßen nützlich sind andere Funktionen der Beziehung zwischen Apache und Subversion, wie etwa die Möglichkeit, einen besonderen Port zu spezifizieren (statt des HTTP Standard-Ports 80), oder einen virtuellen Domain-Namen, unter dem das Subversion-Projektarchiv erreichbar sein soll, oder die Möglichkeit, das Projektarchiv über einen HTTP-Proxy zu erreichen.

Da mod_dav_svn eine Teilmenge des WebDAV/DeltaV-Protokolls spricht, ist es möglich, auf das Projektarchiv über DAV-Clients von Drittanbietern zuzugreifen. Die meisten modernen Betriebssysteme (Win32, OS X und Linux) besitzen die eingebaute Fähigkeit, einen DAV-Server als eine Standard-Netz-„Freigabe“ einzuhängen. Das ist eine komplizierte Angelegenheit, doch ebenso erstaunlich, wenn es implementiert ist. Zu Einzelheiten, siehe Anhang C, WebDAV und Autoversionierung.

Beachten Sie, dass es noch eine Anzahl weiterer kleiner Schräubchen gibt, an denen man bei mod_dav_svn drehen kann, die aber zu verworren sind, um sie hier im Kapitel aufzuführen. Eine vollständige Liste aller httpd.conf Direktiven, auf die mod_dav_svn reagiert, finden Sie unter „Anweisungen“.