Der vielseitigste aller Server für Subversion ist der auf Apache basierende Server. Obwohl er ein wenig schwieriger einzurichten ist, bietet er den anderen Varianten gegenüber einige Vorteile:

Für die Installation von Apache unter Windows benötigen Sie zumindest Windows2000 / WinXP+SP1 oder Windows2003,Vista oder Server 2008.

Jetzt haben Sie Apache und Subversion eingerichtet, aber Apache weiß noch nicht, wie mit Subversion-Clients wie TortoiseSVN umzugehen ist. Um Apache beizubringen, welche URL für Subversion-Projektarchive benutzt werden soll, müssen Sie die Apache-Konfigurationsdatei (für gewöhnlich platziert in c:\Programme\apache group\apache2\conf\httpd.conf) mit einem beliebigen Texteditor (z.B. Notepad) bearbeiten:

Eine kurze Erklärung dessen was Sie gerade eingegeben haben:

Aber das ist nur ein Beispiel. Der Apache Web-Server bietet Ihnen viele weiter Möglichkeiten.

Wenn Sie die SVNParentPath-Direktive benutzt haben, brauchen Sie die Apache-Konfigurationsdatei nicht jedes Mal zu ändern, wenn Sie ein neues Subversion-Projektarchiv erstellt haben. Erstellen Sie das neue Projektarchiv einfach an der gleichen Stelle wie das erste Projektarchiv und Sie sind fertig! In meiner Firma habe ich über SMB (normaler Windows-Dateizugriff) direkten Zugriff auf diesen speziellen Ordner auf dem Server. Also erstelle ich dort einfach einen neuen Ordner, führe den TortoiseSVN-Befehl TortoiseSVN → Projektarchiv hier erstellen... aus und ein neues Projekt hat ein Zuhause...

Wenn Sie Subversion 1.3 oder neuer benutzen, können Sie die SVNListParentPath on Direktive verwenden, damit Apache eine Liste aller verfügbaren Projekte erzeugt, falls Sie auf den SVNParentPath anstatt auf ein Projektarchiv zugreifen.

Das mod_authz_svn Modul ermöglicht fein gegliederte Zugriffsberechtigungen basierend auf Benutzernamen und Pfaden im Projektarchiv. Diese Funktionen stehen seit jeher mit dem Apache Server und seit Subversion 1.3 auch mit svnserve zur Verfügung.

Eine Beispieldatei könnte folgendermaßen aussehen:

[groups]
Admin = john, kate
Entwickler1 = john, rachel, sally
Entwickler2 = kate, peter, mark
Doku = bob, jane, mike
Training = zak
# Standardzugriffsrechte für alle Projektarchive
# Jeder erhält Lesezugriff, Admins können schreiben,
# Karl Napf wird ausgeschlossen
[/]
* = r
@Admin = rw
karlnapf =
# Die Entwickler erhalten Vollzugriff auf ihre Projektarchive
# Hans Dampf arbeitet bei dem großen Projekt noch mit
[Projekt1:/]
@Entwickler1 = rw
[Projekt2:/]
@Entwickler2 = rw
[Riesenprojekt:/]
@Entwickler1 = rw
@Entwickler2 = rw
hansdampf = rw
#Die Doku Gruppe erhält Vollzugriff auf die doc Unterverzeichnise
[/trunk/doc]
@Doku = rw
# Anfänger dürfen nur im Training Projektarchiv wüten
[TrainingRepos:/]
@Training = rw

Beachten Sie, dass die Überprüfung aller Pfade, besonders wenn das Log angezeigt wird, eine teure Operation sein kann. Der Server prüft jeden geänderten Pfad in jeder Revision auf Lesbarkeit, was bei Revisionen, die eine große Anzahl Dateien betreffen, sehr Zeitaufwändig sein kann.

Anmeldung und Zugriffsberechtigung (Autorisierung) sind separate Prozesse. Damit ein Anwender auf einen Pfad im Projektarchiv zugreifen kann, muss er beide Bedingungen erfüllen. Er muss angemeldet sein und die Berechtigung zum Zugriff auf den gewünschten Pfad besitzen.

Wie Sie bestimmt bemerkt haben, benötigen Sie für jeden Anwender einen eigenen Eintrag in der passwd Datei. Falls Sie aus Sicherheitsgründen verlangen, dass die Benutzerpasswörter regelmäßig geändert werden, müssen Sie das jedes Mal von Hand machen.

Falls Sie auf das Projektarchiv in einem Windows Netzwerk mit einem Domänencontroller zugreifen, gibt es eine einfache Lösung: mod_auth_sspi!

Das Original SSPI Modul wurde von Syneapps inklusive Quellcode zur Verfügung gestellt. Das Modul wurde jedoch nicht mehr weiterentwickelt. Aber keine Angst, die Open-Source Gemeinde hat sich des Moduls angenommen und es weiterentwickelt. Das Projekt hat ein neues Zuhause auf SourceForge.

Beachten Sie, dass Sie bei Verwendung von SSPI keine AuthUserFile Zeile mehr benötigen, um eine Passwortdatei zu definieren. Apache wird Ihren Namen und Ihr Passwort gegen den Windows Domänencontroller verifizieren. Sie müssen die Benutzerliste in svnaccessfile anpassen, um Anmeldungen der Form DOMÄNE\username ebenfalls zuzulassen.

Es ist auch möglich, mehr als eine Anmeldequelle für Ihr Subversion Projektarchiv zu haben. Um dies zu erreichen, müssen Sie jeden Anmeldetyp als unmaßgeblich („non-authoritative‚) festlegen, so dass Apache mehrere Quellen auf eine korrekte Name/Passwort Kombination überprüft.‘“

Ein übliches Szenario ist es, sowohl die Windows Domänenanmeldung als auch eine passwd Datei zu verwenden, so dass Sie Benutzern, die kein Domänenkonto besitzen, Zugriff auf das Projektarchiv gewähren können.

Hier ist ein Beispiel einer vollständigen Apache Konfiguration für gemeinsamen Windows Domänenzugriff und passwd Dateianmeldung:

<Location /svn>
  DAV svn
  SVNListParentPath on
  SVNParentPath D:\SVN

  AuthName "Subversion repositories"
  AuthzSVNAccessFile svnaccessfile.txt

# NT Domain Logins.
  AuthType SSPI
  SSPIAuth On
  SSPIAuthoritative Off
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On

# Htpasswd Logins.
  AuthType Basic
  AuthBasicAuthoritative Off
  AuthUserFile passwd

  Require valid-user
</Location>

Obwohl Apache 2.2.x OpenSSL unterstützt, ist diese Option standardmäßig nicht genutzt und muss manuell aktiviert werden.

<Location /svn>
  DAV svn
  SVNParentPath D:\SVN
  SSLRequireSSL
  AuthType Basic
  AuthName "Subversion Projektarchive"
  AuthUserFile passwd
  #AuthzSVNAccessFile svnaccessfile
  Require valid-user
</Location>

Danke an Nigel Green für diesen Beitrag an die TortoiseSVN Mailingliste!

In manchen Serverkonfigurationen müssen Sie einen einzelnen Server mit zwei virtuellen Hosts einrichten: Den ersten für öffentlichen Web-Zugriff ohne Zertifikat, den zweiten, auf dem ein Subversion Server läuft, durch ein für den Client erforderliches Zertifikat abgesichert.

Durch das Hinzufügen einer SSLVerifyClient Optional Anweisung in die per-server Sektion der Apache Konfiguration (d.h. außerhalb aller VirtualHost und Directory Blöcke) zwingen Sie Apache, ein Client-Zertifikat während des ersten SSL Handshake anzufordern. Aufgrund eines Fehlers in mod_ssl ist es wichtig, dass das Zertifikat zu diesem Zeitpunkt angefordert wird, da es nicht funktioniert, wenn die SSL Verbindung neu ausgehandelt wird.

Die Lösung besteht darin, dem Virtual Host Verzeichnis, dass sie für Subversion absichern wollen, die folgende Anweisung hinzuzufügen:

SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

Diese Anweisung ermöglicht nur dann den Zugriff auf das Verzeichnis, falls ein Client-Zertifikat empfangen und erfolgreich verifiziert wurde.

Zusamengefasst sehen die relevanten Zeilen der Apache Konfiguration folgendermaßen aus:

SSLVerifyClient Optional

### Virtual Host Konfiguration für den ÖFFENTLICHEN Host 
### (ohne dass ein Zertifikat benötigt wird)

<VirtualHost 127.0.0.1:443>
  <Directory "pathtopublicfileroot">
  </Directory>
</VirtualHost>

### Virtual Host Konfiguration für SUBVERSION
### (ein Client-Zertifikat wird benötigt)
<VirtualHost 127.0.0.1:443>
  <Directory "subversion host root path">
    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
  </Directory>

  <Location /svn>
    DAV svn
    SVNParentPath /pathtorepository
  </Location>
</VirtualHost>