httpd, der Apache HTTP-Server

httpd, der Apache HTTP-Server
Zurück	Kapitel 6. Konfiguration des Servers	Weiter

Voraussetzungen

Um Ihr Projektarchiv im Netz über HTTP zur Verfügung zu stellen, brauchen Sie grundsätzlich vier Komponenten, die in zwei Paketen verfügbar sind. Sie benötigen Apache httpd 2.0 oder neuer, das dazu gelieferte DAV-Modul mod_dav, Subversion und das mitgelieferte Dateisystem-Modul mod_dav_svn. Sobald Sie über all diese Komponenten verfügen, ist die Bereitstellung Ihres Projektarchivs über das Netz ganz einfach:

Inbetriebnahme von httpd mit dem Modul mod_dav
Installation des mod_dav_svn-Backends zu mod_dav, das die Bibliotheken von Subversion für den Zugriff auf das Projektarchiv verwendet
Konfiguration Ihrer Datei httpd.conf, um das Projektarchiv zu exportieren (oder sichtbar zu machen)

Sie können die ersten beiden Punkte bewerkstelligen, indem Sie entweder httpd und Subversion aus den Quellen übersetzen oder als vorgefertigte Binärpakete auf Ihrem System installieren. Die aktuellsten Informationen zur Übersetzung von Subversion in Verbindung mit dem Apache HTTP-Server sowie die Übersetzung und Konfigurierung von Apache zu diesem Zweck finden Sie in der Datei INSTALL in der obersten Verzeichisebene des Quelltextes von Subversion.

Grundlegende Konfiguration von Apache

Sobald alle notwendigen Komponenten auf Ihrem System installiert sind, bleibt nur noch die Konfiguration von Apache über seine Datei httpd.conf. Weisen Sie Apache mit der Direktive LoadModule an, das Modul mod_dav_svn zu laden. Diese Direktive muss vor allen Konfigurationseinträgen in Verbindung mit Subversion stehen. Falls Ihr Apache mit dem vorgegebenen Aufbau installiert wurde, sollte sich das Modul mod_dav_svn im Unterverzeichnis modules des Apache-Installationsverzeichnisses befinden (oft /usr/local/apache2). Die Direktive LoadModule hat eine einfache Syntax, wobei ein benanntes Modul auf den Ort einer Shared-Library auf der Platte abgebildet wird:

LoadModule dav_svn_module     modules/mod_dav_svn.so

Apache interpretiert den Bibliothekspfad des Konfigurationseintrags LoadModule als relativ zum Wurzelverzeichnis seines eigenen Servers. Falls er wie gezeigt konfiguriert ist, wird Apache in seinem eigenen modules/ Unterverzeichnis nach der Shared-Library des Subversion DAV-Moduls suchen. Abhängig davon, wie Subversion auf Ihrem System installiert wurde, kann es sein, dass Sie einen ganz anderen Pfad für diese Bibliothek angeben müssen, vielleicht sogar einen absoluten Pfad wie im folgenden Beispiel:

LoadModule dav_svn_module     C:/Subversion/libexec/mod_dav_svn.so

Falls mod_dav als Shared-Objekt übersetzt wurde (statt statisch direkt in die httpd-Binärdatei gelinkt worden zu sein), benötigen Sie hierfür ebenfalls einen ähnlichen LoadModule-Eintrag. Stellen Sie sicher, dass er vor der mod_dav_svn-Zeile steht:

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

Weiter unten in der Konfigurationsdatei sollten Sie Apache nun mitteilen, wo Sie Ihr Subversion-Projektarchiv (oder Ihre Projektarchive) aufbewahren. Die Direktive Location besitzt eine XML-ähnliche Notation, beginnend mit einem öffnenden Tag, endend mit einem schließenden Tag und verschiedener anderer Konfigurations-Direktiven dazwischen. Der Zweck der Direktive Location besteht darin, Apache anzuweisen, etwas Besonderes zu tun, falls Anfragen bearbeitet werden, die an einen bestimmten URL oder dessen Kinder gerichtet sind. Im Fall von Subversion möchten Sie, dass Apache die Unterstützung für URLs, die auf versionierte Ressourcen zeigen, einfach an die DAV-Schicht weiterleitet. Sie können Apache anweisen, die Bearbeitung aller URLs, deren Pfadteile (der Teil des URL, der nach dem Servernamen und der optionalen Portnummer steht) mit /repos/ beginnen, an einen DAV-Provider zu delegieren, dessen Projektarchiv unter /var/svn/repository liegt, indem Sie die folgende httpd.conf-Syntax verwenden:

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
</Location>

Falls Sie planen, mehrere Subversion-Projektarchive zu unterstützen, die sich unterhalb eines gemeinsamen Elternverzeichnisses auf Ihrer lokalen Platte befinden, können Sie eine alternative Direktive, SVNParentPath, verwenden, um auf das gemeinsame Elternverzeichnis hinzuweisen. Wenn Sie beispielsweise wissen, dass Sie mehrere Subversion-Projektarchive in einem Verzeichnis /var/svn anlegen möchten, auf die über URLs wie http://my.server.com/svn/repos1, http://my.server.com/svn/repos2 usw. zugegriffen werden soll, könnten Sie die Konfigurations-Syntax von httpd.conf aus dem folgenden Beispiel verwenden:

<Location /svn>
  DAV svn

  # Automatisch irgendein "/svn/foo" URL auf Projektarchiv /var/svn/foo abbilden
  SVNParentPath /var/svn
</Location>

Die Verwendung dieser Syntax veranlasst Apache, die Bearbeitung aller URLs, deren Pfadteil mit /svn/ beginnt, an den Subversion-DAV-Provider weiterzuleiten, der dann davon ausgeht, dass alle Objekte in dem durch die SVNParentPath-Direktive spezifizierten Verzeichnis tatsächlich Subversion-Projektarchive sind. Dies ist insofern eine besonders bequeme Syntax, da Sie im Gegensatz zur Direktive SVNPath Apache nicht neu starten müssen, wenn Sie Projektarchive hinzufügen oder entfernen.

Achten Sie beim Definieren Ihrer neuen Location darauf, dass sie sich nicht mit anderen bereits exportierten überschneidet. Wenn beispielsweise Ihre Haupt-DocumentRoot nach /www exportiert wird, sollten Sie ein Subversion-Projektarchiv nicht in <Location /www/repos> exportieren. Falls eine Anfrage für den URI /www/repos/foo.c hereinkommt, weiß Apache nicht, ob die Datei repos/foo.c in DocumentRoot gesucht wird oder ob es die Herausgabe von foo.c aus dem Projektarchiv an mod_dav_svn delegieren soll. Das Ergebnis ist oftmals ein Fehler vom Server der Form 301 Moved Permanently.

Server-Namen und die COPY-Anfrage

Subversion verwendet den COPY-Anfragetyp, um serverseitige Kopien von Dateien und Verzeichnissen anzufertigen. Als Teil der von den Apache-Modulen durchgeführten Plausibilitätsprüfung wird erwartet, dass sich die Quelle der Kopie auf demselben Rechner befindet wie das Ziel. Um diese Anforderung zu erfüllen, kann es notwendig sein, dass Sie mod_dav den von Ihnen verwendeten Namen für den Server mitteilen müssen. Im Allgemeinen können Sie hierfür die Direktive ServerName in httpd.conf verwenden.

ServerName svn.example.com

Falls Sie Apaches Unterstützung für virtuelles Hosting über die Direktive NameVirtualHost nutzen, müssen Sie eventuell die Direktive ServerAlias verwenden, um weitere Namen anzugeben, unter denen Ihr Server bekannt ist. Wenden Sie sich auch hier für alle Details an die Dokumentation von Apache.

An dieser Stelle sollten Sie ernsthaft über Berechtigungen nachdenken. Falls Sie Apache schon eine Zeit lang als Ihren regulären Web-Server in Betrieb haben, werden Sie wahrscheinlich bereits eine Ansammlung von Inhalt haben, etwa Webseiten, Skripte usw. Diese Dinge sind bereits mit einer Menge an Berechtigungen versehen, die es ihnen erlauben, mit Apache zusammen zu arbeiten, oder passender, die es Apache erlauben, mit diesen Dateien zu arbeiten. Wenn Apache als Subversion-Server eingesetzt wird, braucht er ebenfalls die richtigen Berechtigungen zum Lesen und Schreiben Ihres Subversion-Projektarchivs.

Sie werden ein Berechtigungssystem festlegen müssen, das die Anforderungen von Subversion erfüllt, ohne dabei bestehende Webseiten oder Skript-Installationen zu beeinträchtigen. Das kann bedeuten, dass die Berechtigungen für Ihr Projektarchiv an die anderen Dinge angepasst werden müssen, die Apache für Sie zur Verfügung stellt, oder dass Sie die Direktiven User und Group in httpd.conf verwenden, um Apache mit denjenigen Anwender- und Gruppenkennungen laufen zu lassen, die auch das Subversion-Projektarchiv besitzt. Es gibt keine einzig richtige Methode, um die Berechtigungen zu vergeben, und jeder Administrator wird bestimmte Gründe haben, um es auf eine bestimmte Art zu tun. Seien Sie sich lediglich bewusst, dass Probleme im Zusammenhang mit den Berechtigungen am häufigsten übersehen werden, wenn ein Subversion-Projektarchiv für die Verwendung mit Apache eingerichtet wird.

Authentifikationsoptionen

Falls Sie httpd.conf dergestalt konfiguriert haben, so dass sie etwa den folgenden Eintrag enthält:

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

kann die Welt „anonym“ auf Ihr Projektarchiv zugreifen. Bis Sie Authentifikations- und Autorisierungsrichtlinien konfiguriert haben, sind die über die Direktive Location zur Verfügung gestellten Projektarchive allgemein für jedermann zugreifbar. Mit anderen Worten:

Jeder kann mit einem Subversion-Client eine Arbeitskopie eines Projektarchiv-URLs (oder irgendeines der Unterverzeichnisse) auschecken.
Jeder kann interaktiv die letzte Revision des Projektarchivs durchstöbern, indem der Projektarchiv-URL einfach mit einem Web-Browser geöffnet wird.
Jeder kann an das Projektarchiv übertragen.

Natürlich kann es sein, dass Sie schon längst ein pre-commit-Hook-Skript bereitgestellt haben, um Übergaben zu verhindern (siehe „Erstellen von Projektarchiv-Hooks“). Sie werden jedoch beim Weiterlesen feststellen, dass es möglich ist, die eingebauten Methoden von Apache zu verwenden, um den Zugriff auf bestimmte Art und Weise einzuschränken.

	Tipp
	Die erforderliche Authentifikation verhindert zwar, dass unerlaubte Anwender direkt auf das Projektarchiv zugreifen, schützt aber nicht die Vertraulichkeit der Netzwerkaktivitäten erlaubter Anwender. Siehe „Schutz des Netzwerkverkehrs durch SSL“ zur Konfiguration Ihres Servers mit SSL-Verschlüsselung, die eine zusätzliche Sicherheitsschicht bietet.

Einfache Authentifikation

Die einfachste Methode, einen Client zu authentifizieren geht über den HTTP-Basic-Authentifikations-Mechanismus, der einfach einen Anwendernamen und ein Passwort verwendet, um die Identität eines Anwenders sicherzustellen. Apache stellt das Dienstprogramm htpasswd^[66] zur Verfügung, welches die Verwaltung von Dateien übernimmt, die Anwendernamen und Passwörter beinhalten.

	Warnung
	Die einfache Authentifikation ist extrem unsicher, da Passwörter fast im Klartext über das Netz geschickt werden. Siehe „Digest Authentifikation“ für Details zur Verwendung des wesentlich sichereren Digest Mechanismus.

Legen Sie zunächst eine Passwort-Datei und erlauben Sie den Zugriff für die Anwender Harry und Sally:

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

Stellen Sie als nächstes sicher, dass Apache Zugriff auf die Module hat, die die einfache Authentifikation und damit zusammenhängende Funktionalität liefern: mod_auth_basic, mod_authn_file und mod_authz_user. Vielfach sind diese Module in httpd selbst hineinkompiliert worden, aber falls nicht, könnte es sein, dass Sie explizit eins oder mehrere von ihnen mit der Direktive LoadModule laden müssen:

LoadModule auth_basic_module   modules/mod_auth_basic.so
LoadModule authn_file_module   modules/mod_authn_file.so
LoadModule authz_user_module   moduels/mod_authz_user.so

Nachdem sichergestellt ist, dass Apache Zugriff auf die benötigte Funktionalität hat, müssen Sie noch ein paar Direktiven innerhalb des Blocks <Location> hinzufügen, um Apache mitzuteilen, welche Art der Authentisierung Sie verwenden möchten, und wie das gemacht werden soll:

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

  # Authentication: Basic
  AuthName "Subversion repository"
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /etc/svn-auth.htpasswd
</Location>

Diese Direktiven funktionieren wie folgt:

AuthName ist ein beliebiger Name, den Sie für Ihre Authentifikationsdomäne wählen. Die meisten Browser zeigen diesen Namen im Dialog an, wenn der Browser den Anwender nach seinem Namen und dem Passwort fragt.
AuthType spezifiziert den Typ der zu verwendenden Authentifikation.
AuthBasicProvider gibt den Anbieter für die einfache Authentifikation an, der für den Ort verwendet werden soll. In unserem Beispiel möchten wir in einer lokalen Datei mit Passwörtern nachsehen.
AuthUserFile spezifiziert den Ort der zu verwendenden Passwortdatei.

Allerdings bewirkt dieser <Location>-Block 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. (Wenn eine Autorisierung erforderlich ist, benötigt Apache auch eine Authentifikation.) Was hier jedoch noch fehlt, sind Direktiven, die Apache sagen, welche Arten von Client-Anfragen eine Autorisierung erfordern; momentan sind das keine. Das Einfachste ist es, anzugeben, dass alle Anfragen eine Autorisierung erfordern, indem dem Block die Anweisung Require valid-user hinzugefügt wird:

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

  # Authentication: Basic
  AuthName "Subversion repository"
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /etc/svn-auth.htpasswd

  # Authorization: Authenticated users only
  Require valid-user
</Location>

Zu Details über die Direktive Require und anderen Möglichkeiten, Autorisierungsrichtlinien festzulegen, sehen Sie unter „Autorisierungs-Optionen“ nach.

	Anmerkung
	Der Standardwert für die Option `AuthBasicProvider` ist `file`, also werden wir es in künftigen Beispielen nicht anführen. Sie sollten sich aber bewusst sein, dass, wenn Sie diesen Wert in einem erweiterten Kontext auf etwas anderes gesetzt haben, ihn ausdrücklich wieder auf `file` in Ihrem `<Location>`-Block zurücksetzen müssen, falls Sie dieses Verhalten wünschen.

Digest Authentifikation

Digest-Authentifikation ist eine Verbesserung der Basic-Authentifikation, die es dem Server ermöglicht, die Identität des Clients zu bestätigen, ohne das Passwort ungeschützt durch das Netz zu schicken. Sowohl Client als auch Server erzeugen einen nicht rückgängig zu machenden MD5-Hashwert des Anwendernamens, Passwortes, verlangter URI und einer Einwegnummer, die vom Server vergeben wird und jedes Mal geändert wird, wenn eine Authentifikation benötigt wird. Der Client sendet seinen Hash an den Server und der Server verifiziert dann, dass die Hashes zusammenpassen.

Die Konfigurierung von Apache für die Digest-Authentifikation ist unkompliziert. Sie müssen sicher stellen, dass das Modul mod_auth_digest (statt mod_auth_basic) verfügbar ist, und dann nur noch ein wenig von unserem vorangegangenen Beispiel abweichen:

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

  # Authentication: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthDigestProvider file
  AuthUserFile /etc/svn-auth.htdigest

  # Authorization: Authenticated users only
  Require valid-user
</Location>

Beachten Sie, dass AuthType nun auf Digest gesetzt ist, und wir einen unterschiedlichen Pfad für AuthUserFile angegeben haben. Digest-Authentifikation verwendet ein unterschiedliches Dateiformat als einfache Authentifikation, erzeugt und verwaltet mit Apaches Dienstprogramm htdigest ^[67] statt mit htpasswd. Digest-Authentifikation besitzt auch das zusätzliche Konzept eines Bereichs, realm, der dem Wert der Direktive AuthName entsprechen muss.

Anmerkung

Für die Digest-Authentifikation wird der Anbieter mit der Direktive AuthDigestProvider ausgewählt, wie im vorangegangenen Beispiel gezeigt. Wie bei der Direktive AuthBasicProvider, ist auch hier file der Standardwert der Option AuthDigestProvider, so dass diese Zeile nicht unbedingt notwendig ist, es sei denn, Sie müssen einen aus einem weiteren Konfigurations-Kontext ererbten unterschiedlichen Wert angeben.

Die Passwort-Datei kann wie folgt erzeugt werden:

$ ### Beim ersten Mal: -c zum Erzeugen der Datei verwenden
$ htdigest -c /etc/svn-auth.htdigest "Subversion repository" harry
Adding password for harry in realm Subversion repository.
New password: *****
Re-type new password: *****
$ htdigest /etc/svn-auth.htdigest "Subversion repository" sally
Adding user sally in realm Subversion repository
New password: *******
Re-type new password: *******
$

Autorisierungs-Optionen

An diesem Punkt haben Sie die Authentifikation eingerichtet, nicht jedoch die Autorisierung. Apache kann Clients auffordern und Identitäten bestätigen, aber es wurde ihm noch nicht gesagt, wie er den Zugriff von Clients mit diesen Identitäten erlauben oder einschränken soll. Dieser Abschnitt beschreibt zwei Strategien, um den Zugriff auf Ihre Projektarchive zu kontrollieren.

Pauschale Zugriffskontrolle

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 Require valid-user direkt dem <Location>-Block hinzufügen. Das Beispiel von „Digest Authentifikation“ erlaubt nur Clients, die sich erfolgreich authentifiziert haben, um irgendetwas mit dem Subversion-Projektarchiv zu machen:

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

  # Authentifikation: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthUserFile /etc/svn-auth.htdigest

  # Autorisierung: Nur für authentifizierte Anwender
  Require valid-user
</Location>

Manchmal müssen Sie gar nicht so ein strenges Regiment führen. So erlaubt beispielsweise der Server, der das eigene Projektarchiv von Subversion unter http://svn.collab.net/repos/svn beherbergt, allen auf der Welt lesende Operationen (wie etwa das Auschecken von Arbeitskopien und das Stöbern im Projektarchiv), beschränkt jedoch Schreiboperationen auf authentifizierte Nutzer. Die Direktiven Limit und LimitExcept erlauben diese Art der selektiven Einschränkung. Ä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 von diesem Block beeinflusst werden. Falls Sie beispielsweise anonyme Nur-Lese-Zugriffe erlauben wollen, so würden Sie die Direktive LimitExcept (mit den Anfrage-Parametern GET, PROPFIND, OPTIONS und REPORT) verwenden und die vorher erwähnte Direktive Require valid-user im Block <LimitExcept> statt nur innerhalb des <Location>-Blocks einfügen.

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

  # Authentifikation: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthUserFile /etc/svn-auth.htdigest

  # Autorisierung: Nur authentifizierte Anwender für nicht Nur-Lese
  #                (Schreib-) Operationen; anonymes Lesen zulassen
  <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.

Verzeichnisweise Zugriffskontrolle

Es ist möglich, detailliertere Zugriffsrechte mithilfe von mod_authz_svn einzurichten. Dieses Apache-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 einzelne Datei mit Zugriffs-Richtlinien für Pfade in Ihren Projektarchiven bezeichnet. Beginnend mit Subversion 1.7 können Sie auch die Direktive AuthzSVNReposRelativeAccessFile verwenden, um eine Zugriffsdatei per Projektarchiv zu spezifizieren. (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 Autorisierungs-Optionen von Apache zu erfahren.)

Der offenste Ansatz besteht aus Zugriff für jeden. Das bedeutet, dass Apache niemals Aufforderungen zur Authentifikation sendet, so dass alle Anwender als „anonymous“ behandelt werden. (Siehe Beispiel 6.2, „Eine Beispielkonfiguration für anonymen Zugriff“.)

Beispiel 6.2. Eine Beispielkonfiguration für anonymen Zugriff

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

  # Authentifikation: keine

  # Autorisierung: pfad-basierte Zugriffskontrolle
  AuthzSVNAccessFile /path/to/access/file
</Location>

Am anderen Ende der Paranoia-Skala können Sie Apache dergestalt konfigurieren, dass er alle Clients authentifiziert. Dieser Block verlangt eine unbedingte Authentifikation durch die Direktive Require valid-user und definiert wie berechtigte Anwender authentifiziert werden sollen. (Siehe Beispiel 6.3, „Eine Beispielkonfiguration für authentifizierten Zugriff“.)

Beispiel 6.3. Eine Beispielkonfiguration für authentifizierten Zugriff

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

  # Authentifikation: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthUserFile /etc/svn-auth.htdigest

  # Autorisierung: pfad-basierte Zugriffskontrolle; nur für authentifizierte Anwender
  AuthzSVNAccessFile /path/to/access/file
  Require valid-user
</Location>

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

Beispiel 6.4. Eine Beispielkonfiguration für gemischten authentifizierten/anonymen Zugriff

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

  # Authentifikation: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthUserFile /etc/svn-auth.htdigest

  # Autorisierung: pfad-basierte Zugriffskontrolle; zunächst anonymen Zugriff
  #                versuchen, doch wenn nötig authentifizieren
  AuthzSVNAccessFile /path/to/access/file
  Satisfy Any
  Require valid-user
</Location>

Der nächste Schritt ist, eine Autorisierungsdatei zu erstellen, die Zugriffsregeln für bestimmte Pfade innerhalb des Projektarchivs enthält. Wie, beschreiben wir später in „Pfad-basierte Autorisierung“.

Unterbinden pfad-basierter Prüfungen

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 (-v)), 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.5, „Abstellen aller Pfadüberprüfungen“ gezeigt.

Beispiel 6.5. Abstellen aller Pfadüberprüfungen

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

  SVNPathAuthz off
</Location>

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

Im Projektarchiv versionierte Zugriffs-Dateien

Beginnend mit Subversion 1.8 können Zugriffs-Dateien innerhalb eines Subversion-Projektarchivs gespeichert werden. Es ist möglich, die Zugriffs-Datei im selben Projektarchiv auf das die Zugriffsregeln angewendet werden zu speichen, oder in einem ganz anderen Projektarchiv. Dieser Ansatz ermöglicht die Versionierungs-Funktionalität von Subversion für die pfad-basierte Autorisierungs-Konfiguration.

Die Konfigurations-Direktiven AuthzSVNAccessFile und AuthzSVNReposRelativeAccessFile erlauben beide, einen Pfad innerhalb des Projektarchivs für die Zugriffs-Datei anzugeben. Die Direktiven akzeptieren absolute file://-URLs und URLs relativ zum Projektarchiv (solche, die mit ^/ beginnen).

Es ist beispielsweise möglich, einen absoluten URL zu einer Zugriffs-Datei in einem Projektarchiv anzugeben, wie in Beispiel 6.6, „Einzelne im Projektarchiv versionierte Zugriffs-Datei“ gezeigt.

Beispiel 6.6. Einzelne im Projektarchiv versionierte Zugriffs-Datei

<Location /repos>
  DAV svn
  SVNParentPath /var/svn
  AuthzSVNAccessFile file:///var/svn/authzrepo/authz
</Location>

Sie können auch einen relativen URL zu einer Zugriffs-Datei im Projektarchiv angeben, wie in Beispiel 6.7, „Verwendung von im Projektarchiv versionierten authz-Dateien pro Projektarchiv“ gezeigt.

Beispiel 6.7. Verwendung von im Projektarchiv versionierten authz-Dateien pro Projektarchiv

<Location /repos>
  DAV svn
  SVNParentPath /var/svn
  AuthzSVNReposRelativeAccessFile ^/authz
</Location>

Schutz des Netzwerkverkehrs durch SSL

Die Verbindung zu einem Projektarchiv über http:// bedeutet, dass alle Subversion-Aktivitäten im Klartext über das Netzwerk geschickt werden. Dass heißt, dass Operationen wie das Auschecken, Übergaben und Aktualisierungen potentiell durch Unbefugte, die den Netzwerkverkehr „abschnorcheln“, abgefangen werden können. Die Verschlüsselung des Verkehrs mit SSL ist eine gute Maßnahme, um möglicherweise heikle Informationen im Netzwerk zu schützen.

Wird ein Subversion-Client für die Verwendung von OpenSSL übersetzt, erlangt er die Fähigkeit, mit einem Apache-Server über https://-URLs zu kommunizieren, wobei sämtlicher Verkehr durch einen Sitzungsschlüssel pro Verbindung verschlüsselt wird. Die vom Subversion-Client verwendete WebDAV-Bibliothek kann nicht nur Server-Zertifikate verifizieren, sondern nach Aufforderung auch Client-Zertifikate liefern.

Konfiguration von Subversion-Server SSL-Zertifikaten

Es würde den Rahmen dieses Buches sprengen, wenn beschrieben würde, wie Client- und Server SSL-Zertifikate erzeugt werden und wie Apache für ihre Verwendung konfiguriert wird. Viele andere Bücher, darunter Apaches eigene Dokumentation (http://httpd.apache.org/docs/current/ssl/), erläutern diese Aufgabe.

	Tipp
	SSL-Zertifikate von wohlbekannten Instanzen sind in der Regel kostenpflichtig, doch können Sie als Minimallösung Apache so konfigurieren, das er ein selbstgezeichnetes Zertifikat verwendet, dass durch ein Werkzeug wie etwa OpenSSL erzeugt wurde (http://openssl.org).^[68]

Subversion-Client SSL-Zertifikat-Verwaltung

Bei einer Verbindung zu Apache über https:// kann ein Subversion-Client zwei unterschiedliche Arten von Antworten empfangen:

Ein Server-Zertifikat
Eine Aufforderung zur Vorlage eines Client-Zertifikats

Server-Zertifikat

Wenn der Client ein Server-Zertifikat empfängt, muss er sicherstellen, dass der Server derjenige ist, für den er sich ausgibt. OpenSSL 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-Befehlszeilen-Client, 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 ist im Wesentlichen dieselbe Frage, die Sie 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 Subversion das Server-Zertifikat in Ihrem privaten Laufzeitbereich auth/ zwischengespeichert, ebenso wie Ihr Anwendername und Passwort (siehe „Client-Zugangsdaten“), und diesem Zertifikat bei künftigen Protokollverhandlungen vertrauen.

Ihre Laufzeit-Datei servers ermöglicht es Ihrem Subversion-Client ebenso, 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.

Client-Zertifikat-Abfrage

Falls der Client eine die Aufforderung erhält, ein Client-Zertifikat vorzulegen, ersucht Apache den Client, sich zu identifizieren. Der Client muss ein Zertifikat zurückschicken, das von einer CA signiert wurde, der Apache vertraut, zusätzlich mit einer Aufforderungserwiederung (Challenge Response), die beweist, dass der Client in Besitz des zum Zertifikat gehörigen privaten Schlüssels ist. Für gewöhnlich wird der private Schlüssel und das Client-Zertifikat, durch eine lokale Passphrase geschützt, verschlüsselt auf Platte gespeichert. Wenn Subversion diese Aufforderung erhält, fragt es Sie nach dem Pfad zum Zertifikat und der Passphrase, das jenes schützt:

$ 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 die Zugriffsdaten des Clients in einer .p12-Datei gespeichert werden. Um ein Client-Zertifikat mit Subversion verwenden zu können, muss es im PKCS#12-Format vorliegen, was einem portablen Standard entspricht. Die meisten Web-Browser können Zertifikate in diesem Format im- und exportieren. Eine weitere Option ist es, die OpenSSL-Befehlszeilenwerkzeuge zu verwenden, um bestehende Zertifikate in PKCS#12 zu überführen.

Die Laufzeitdatei servers erlaubt Ihnen auch, diese Aufforderung pro Host zu automatisieren. Falls Sie die Variablen ssl-client-cert-file und ssl-client-cert-password setzen, kann Subversion automatisch auf Client-Zertifikat-Anforderungen antworten, ohne bei Ihnen nachzufragen:

[groups]
examplehost = host.example.com

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

Sicherheitsbewusstere Leute lassen möglicherweise ssl-client-cert-password weg, um zu vermeiden, die Passphrase im Klartext auf Platte zu speichern.

Auf Leistung abstimmen

Der Apache HTTP-Server ist zwar für Leistungsfähigkeit gebaut worden, jedoch können Sie seine Standard-Konfiguration verbessern, um noch bessere Ergebnisse beim Anbieten Ihrer Subversion-Dienste zu erhalten. In diesem Abschnitt empfehlen wir einige zielgerichtete Konfigurations-Änderungen zu erwägen. Seien Sie sich jedoch bewusst, das einige der hier erörterten Konfigurations-Optionen von httpd.conf Auswirkungen auf das allgemeine Verhalten Ihres Servers haben, nicht bloß für den Subversion-Dienst. Insofern müssen Sie die gesamte Breite Ihrer HTTP-Dienste berücksichtigen, um festzustellen, welche Auswirkungen Änderungen an diesen Einstellungen wegen Subversion auf Ihre anderen Dienste haben werden.

KeepAlive

Standardmäßig ist der Apache HTTP-Server so eingestellt, dass er es erlaubt, eine einzelne Verbindung zum Server für mehrere Anfragen wiederzuverwenden. Für Subversion ist das sehr vorteilhaft, da, anders als bei vielen HTTP=basierten Anwendungen, Subversion schnell für eine einzelne Operation hunderte oder tausende von Anfragen an einen Server erzeugen kann, und die Kosten beim Öffnen einer neuen Verbindung zum Server nicht trivial sind. Subversion versucht, so viele Anfragen wie möglich aus einer Verbindung herauszuquetschen, bevor der Server sie beendet. Die Direktive KeepAlive ist der boolesche Schalter, der diese Möglichkeit zur Wiederverwendung einer Verbindung ermöglicht oder unterbindet. Wie bereits erwähnt ist deren Wert standardmäßig On.

Es gibt aber noch eine weitere Direktive, die die Anzahl von Anfragen einschränkt, die ein Client über einer einzelne Verbindung übermitteln darf: die Direktive MaxKeepAliveRequests. Der Standardwert für diese Option ist 100. Das war wahrscheinlich ausreichend für ältere Subversion-Versionen, doch Subversion 1.8 setzt eine unterschiedliche Bibliothek für die HTTP-Kommunikation ein (Serf genannt), die es vorzieht, mehrere kleinere Anfragen für bestimmte Informationsschnipsel zu versenden, anstatt den Server darum zu bitten, große Datenbrocken mit einer einzelnen Antwort zu übertragen. Wir empfehlen, den Wert der Option MaxKeepAliveRequests auf mindestens 1000 zu erhöhen.

#
# KeepAlive: Durchgehende Verbindungen erlauben oder verbieten (mehr
# als eine Anfrage pro Verbindung). Zum verbieten auf "Off" setzen.
#
KeepAlive On

#
# MaxKeepAliveRequests: Die Maximalanzahl erlaubter Anfragen während
# einer durchgehenden Verbindung. Auf 0 setzen, um eine unbegrenzte
# Anzahl zu erlauben.
# Wir empfehlen, diese Zahl hoch zu halten, um maximale
# Leistungsfähigkeit zu gewährleisten.
#
MaxKeepAliveRequests 1000

Massen-Aktualisierungen

Der größte Unterschied im Verhalten von Subversion 1.8 Clients und älteren Clients besteht in der Behandlung von Operationen ähnlich einer Aktualisierung (svn checkout, svn update, svn switch usw.). Ältere Clients, die die Bibliothek Neon HTTP zur Kommunikation verwendeten, bevorzugten es, vom Server die gesamte Informations-Nutzlast mit einer Abfrage anzufordern. Administratoren werden bemerkt haben, dass in den Protokolldateien des Servers zunächst einige Vermittlungsoperationen auftraten und dann eine REPORT-Anfrage mit einer massiven Antwort folgte. Diese Antwort umfasste den kompletten Datenumfang des Checkouts bzw. der Aktualisierung!

Subversion Clients, die die Bibliothek Serf HTTP verwenden – zu denen alle auf Subversion 1.8 gebauten Clients gehören – senden immer noch die REPORT-Anfrage, allerdings mit etwas anders gesetzten Schaltern innerhalb der Abfrage. Diese Schalter fordern den Server auf, nicht alle Daten für die Operation zu senden, sondern stattdessen nur eine Checkliste mit anderen, spezifischeren Dingen, die der Client im Folgenden vom Server abrufen muss, um die Operation zu vervollständigen. Im access_log des Servers folgen diesem REPORT viele kleinere Anfragen (GETs und, in älteren Versionen von Subversion, PROPFINDs).

Jeder dieser Ansätze hat Vor- und Nachteile. Wie bereits erwähnt, erzeugen sogenannte Massen-Aktualisierungen wesentlich weniger Information in den Protokolldateien des Servers, jedoch wird ein gegebener Kindprozess eines Apache-HTTP-Servers für die Dauer einer eventuell längeren Operation vollständig in Anspruch genommen. Normale Aktualisierungen bieten die Gelegenheit, Zwischenspeicher für Inhalte anzulegen (die an sich die Leistung erhöhen können), erzeugen jedoch eine Protokollnachrichten-Aufkommen auf dem Server, dass erheblich umfangreicher ist als bei dem Ansatz mit den Massen-Aktualisierungen. Aus verschiedenen Gründen könnten Administratoren etwas mehr Einfluss auf den clientseitig verwendeten Ansatz nehmen wollen. Subversion 1.6 führte die mod_dav_svn-Direktive SVNAllowBulkUpdates – ein einfacher boolescher Schalter – ein, damit Administratoren angeben können, ob der Server Anfragen für Massen-Aktualisierungen zulassen darf. In Subversion 1.8 wurde diese Direktive zusätzlich zu den bereits unterstützten Werten On und Off um den Wert Prefer erweitert. Wenn SVNAllowBulkUpdates auf Prefer gesetzt wird, versuchen Clients, die er unterstützen (1.8 oder neuer) den Ansatz der Massen-Aktualisierung, wenn nicht etwas anderes konfiguriert wurde.

Extra Schmankerl

Die meisten Authentifikations- und Autorisierungsoptionen für Apache und mod_dav_svn haben wir abgehandelt. Es gibt jedoch noch ein paar weitere nette Dinge, die Apache zu bieten hat.

Stöbern im Projektarchiv

Einer der nützlichsten Vorteile eines Apache/WebDAV Aufbaus für Ihr Subversion Projektarchiv besteht darin, dass Ihre 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.

URL Syntax

Falls die URLs keinerlei Informationen über die Ressourcenversion enthalten, die Sie sehen möchten, wird mod_dav_svn stets mit der jüngsten Version antworten. 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.

Seit Subversion 1.6 unterstützt mod_dav_svn eine öffentliche URI Syntax zur Untersuchung älterer Revisionen sowohl von Dateien als auch Verzeichnissen. Die Syntax verwendet den Teil des Query-Strings des URL, um entweder die Peg-Revision oder die operative Revision oder beide anzugeben, die Subversion dann verwendet, um die in Ihrem Browser darzustellende Version zu ermitteln. Fügen Sie dem Query-String das Namens-Wert-Paar p=PEGREV, hinzu, wobei PEGREV eine Revisionsnummer ist, die die Peg-Revision festlegt, die Sie für die Abfrage anwenden möchten. Verwenden Sie r=REV, wobei REV eine Revisionsnummer ist, die die operative Revisionsnummer festlegt.

Wenn Sie beispielsweise die letzte Version einer Datei README.txt in /trunk Ihres Projektes sehen möchten, zeigen Sie mit Ihrem Webbrowser auf die Projektarchiv-URL dieser Datei, die ähnlich der folgenden aussehen sollte:

http://host.example.com/repos/project/trunk/README.txt

Falls Sie nun eine ältere Version dieser Datei sehen wollten, fügen Sie dem Query-String der URL eine operative Revision hinzu:

http://host.example.com/repos/project/trunk/README.txt?r=1234

Was ist, falls das Objekt, das Sie sehen möchten, nicht mehr in der letzten Revision des Projektarchivs vorhanden ist? Hierbei ist eine Peg-Revision sehr hilfreich:

http://host.example.com/repos/project/trunk/deleted-thing.txt?p=321

Natürlich können Sie Peg-Revisions- und Angaben für operative Revisionen kombinieren, um genau anzugeben, was genau Sie sehen möchten:

http://host.example.com/repos/project/trunk/renamed-thing.txt?p=123&r=21

Der obige URL würde Revision 21 des Objekts anzeigen, das in Revision 123 an der Stelle /trunk/renamed-thing.txt im Projektarchiv lag. Siehe „Peg- und operative Revisionen“ für eine detaillierte Erörterung dieser Konzepte von „Peg-Revision“ und „operativer Revision“. Sie könnten etwas schwer verständlich sein.

Seit Subversion 1.8 kann mod_dav_svn Schlüsselworte ersetzen. Wenn mod_dav_svn im Query-String des URL einer Datei den benannten Parameter kw=1 findet, werden beim Ausliefern des Dateiinhaltes Schlüsselworte ersetzt. Wird der Parameter kw weggelassen oder hat er einen anderen Wert als 1, verhält sich Subversion standardmäßig, d.h., der Dateiinhalt wird ohne ersetzte Schlüsselworte ausgeliefert.

Da die Schlüsselwort-Ersetzung normalerweise im Rahmen der Arbeitskopie-Verwaltung vom Subversion-Client vorgenommen wird, ist dies eine praktische Möglichkeit, den Server dazu zu bringen, ein Format Ihrer versionierten Datei mit expandierten Schlüsselworten abzuliefern, ohne eine Arbeitskopie zu verwenden.

Wenn Sie beispielsweise die letzte Version einer Datei README.txt im /trunk Ihres Projektes mit ersetzten Schlüsselworten sehen möchten, fügen Sie dem URL den Query-Parameter kw=1 hinzu:

http://host.example.com/repos/project/trunk/README.txt?kw=1

Ebenso wie bei der client-seitigen Ersetzung von Schlüsselworten, werden nur diejenigen Schlüsselworte ersetzt, die über die sich an der Datei befindlichen Eigenschaft svn:keywords ausdrücklich hierfür vorgesehen sind. Siehe „Ersetzung von Schlüsselworten“ für eine detaillierte Beschreibung der Schlüsselwort-Ersetzung.

Zur Erinnerung: Diese Funktionalität von mod_dav_svn bietet nur ein eingeschränktes Stöbererlebnis im Projektarchiv. Sie können Verzeichnislisten und Dateiinhalte sehen, jedoch keine Revisionseigenschaften (wie etwa Protokollnachrichten) oder Datei- oder Verzeichniseigenschaften. Für Leute, die weitergehende Informationen zum Projektarchiv und seiner Geschichte benötigen gibt es hierfür mehrere Softwarepakete von Drittanbietern. Hierzu zählen beispielsweise ViewVC (http://viewvc.org), Trac (http://trac.edgewall.org) und WebSVN (http://websvnphp.github.io). Diese Werkzeuge von Drittanbietern beeinträchtigen nicht die eingebaute „Stöberfähigkeit“ von mod_dav_svn und bieten im Allgemeinen weitergehende Funktionalität, wozu die Anzeige der eben erwähnten Mengen von Eigenschaften, die Anzeige von Unterschieden zwischen Dateirevisionen u.a. gehört.

Passender MIME-Typ

Während des Durchstöberns eines Subversion-Projektarchivs bekommt der Web-Browser Hinweise zur Darstellung des Inhalts einer Datei, indem er in den Content-Type:-Header von Apaches Antwort auf die HTTP GET-Anfrage schaut. Der Wert dieses Headers ist eine Art MIME-Typ. Standardmäßig teilt Apache den Web-Browsern mit, dass alle Dateien des Projektarchivs den „Standard“-MIME-Typen besitzen, normalerweise text/plain. Das kann jedoch frustrierend sein, wenn ein Anwender möchte, dass Dateien aus dem Projektarchiv etwas aussagekräftiger dargestellt werden; beispielsweise wäre es nett, wenn eine Datei foo.html aus dem Projektarchiv auch als HTML-Datei angezeigt würde.

Um das zu erreichen, müssen Sie nur sicherstellen, dass Ihre Dateien den passenden svn:mime-type gesetzt haben. Im Detail besprechen wir das in „Datei-Inhalts-Typ“. Sie können Ihren Client sogar so konfigurieren, dass er automatisch passende svn:mime-type-Eigenschaften an Dateien hängt, wenn sie das erste Mal in das Projektarchiv eingebracht werden (siehe „Automatisches Setzen von Eigenschaften“).

Um mit unserem Beispiel fortzufahren, wenn also jemand die Eigenschaft svn:mime-type mit dem Wert text/html an die Datei foo.html hänge, würde Apache Ihrem Browser wahrscheinlich mitteilen, dass die Datei als HTML darzustellen sei. Man könnte auch passende image/*-MIME-Type-Eigenschaften an Bilddateien hängen und somit eine komplette Webpräsenz direkt aus dem Projektarchiv heraus sichtbar machen! Solange die Webpräsenz keinen dynamisch erzeugten Inhalt hat, gibt es damit im Allgemeinen kein Problem.

Anpassung der Darstellung

Gemeinhin werden Sie mehr Nutzen aus URLs auf versionierte Dateien ziehen – hier liegt schließlich der interessante Inhalt. Gelegentlich werden Sie beim Durchstöbern eines Subversion-Verzeichnisinhalts feststellen, dass das zur Darstellung verwendete HTML sehr einfach ist und bestimmt nicht ästhetisch ansprechend (oder gar interessant). Um eine Anpassung dieser Verzeichnisdarstellungen zu ermöglichen, stellt Subversion einen XML-Index-Mechanismus zur Verfügung. Eine einzelne SVNIndexXSLT-Direktive im Location-Block des Projektarchivs in httpd.conf fordert mod_dav_svn auf, bei der Anzeige von Verzeichnisinhalten XML auszugeben und ein XSLT-Stylesheet Ihrer Wahl zu verwenden:

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

Wenn Sie die Direktive SVNIndexXSLT zusammen mit einem gestalterischen XSLT-Stylesheet verwenden, können Sie die Verzeichnisinhalte an das Farbschema und die bildliche Darstellung anderer Teile Ihrer Webpräsenz anpassen. Sollten Sie es vorziehen, können Sie auch die Beispiel-Stylesheets aus dem Verzeichnis tools/xslt/ des Subversion-Quelltextpakets verwenden. Beachten Sie, dass die Pfadangabe des Verzeichnisses SVNIndexXSLT tatsächlich um einen URL-Pfad handelt – Browser müssen Ihre Stylesheets lesen können, um sie zu verwenden!

Anzeige von Projektarchiven

Falls Sie mit einem einzelnen URL eine Ansammlung von Projektarchiven über die Direktive SVNParentPath verfügbar machen, ist es auch möglich, dass Apache einem Web-Browser alle verfügbaren Projektarchive anzeigt. Sie müssen nur die Direktive SVNListParentPath aktivieren:

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

Falls ein Anwender nun mit dem Web-Browser auf den URL http://host.example.com/svn/ geht, sieht er eine Liste aller Projektarchive unterhalb von /var/svn. Offensichtlich kann dies ein Sicherheitsproblem sein, so dass dieser Mechanismus standardmäßig abgestellt ist.

Protokollierung von Apache

Da Apache im Grunde genommen ein HTTP-Server ist, beinhaltet er fantastisch anpassungsfähige Protokollierungs-Möglichkeiten. Es würde den Rahmen dieses Buches sprengen, alle Protokollierungs-Einstellungen 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
[26/Jan/2007:22:25:29 -0600] - status /trunk/foo r1729 depth=infinity
[26/Jan/2007:22:25:31 -0600] sally commit r1730

Zusätzlich zur Umgebungsvariablen SVN-ACTION besetzt mod_dav_svn auch die Variablen SVN-REPOS und SVN-REPOS-NAME, die den Dateisystempfad zum Projektarchiv bzw. dessen Basisnamen beinhalten. Es sei empfohlen, Referenzen auf eine oder beide dieser Variablen in Ihre CustomLog Formatbeschreibung einzufügen; besonders dann, falls Sie Informationen aus mehreren Projektarchiven in einer einzelnen Protokolldatei sammeln. Eine vollständige Liste mit allen protokollierten Aktionen finden Sie unter „Protokollierung auf hohem Niveau“.

Es leuchtet ein, dass je mehr Informationen Apache über Ihre Aktivitäten mit Subversion protokolliert, desto mehr Speicherplatz durch diese Protokolldateien auf Ihrem Server beansprucht wird. Es ist nicht ungewöhnlich für Subversion-Server mit hohem Verkehrsaufkommen, dass sie täglich mehrere Gigabytes an Protokollinformationen erzeugen. Es ist klar, dass Protokolldateien nur dann von Wert sind, wenn sie auch sinnstiftend ausgewertet werden können, und umfangreiche Protokolldateien können schnell unhandlich werden. Es gibt verschiedene Standardansätze für die Verwaltung der Apache HTTP-Server Protokollierung, die durch dieses Buch nicht behandelt werden. Den Administratoren wird nahegelegt, denjenigen Ansatz mit rotierenden und archivierten Protokolldateien zu wählen, der für sie am besten funktioniert.

Doch was ist, wenn Subversion einfach zu viel Protokolldaten erzeugt, um von Nutzen zu sein? So erwähnten wir beispielsweise in „Massen-Aktualisierungen“, dass bestimmte Ansätze, die Subversion-Clients bei Checkouts und anderen Aktualisierungsoperationen wählen könnten, einen rasanten Zuwachs Ihrer Protokolldateien auf dem Server zur Folge haben kann, da Anfragen für individuelle Teile des Aktualisierungs-Datensatzes individuell protokolliert werden (wobei das in früheren Versionen von Subversion nicht geschah). In diesem Fall sollten Sie etwas Apache-Konfigurations-Magie anwenden, um selektiv Teile dieser Protokollaktivitäten ruhig zu stellen.

Das Modul mod_setenvif des Apache HTTP-Servers stellt eine Direktive SetEnvIf zur Verfügung, die praktisch ist, um bedingt Umgebungsvariablen zu setzen. Und wie sich herausstellt, kann der Direktive CustomLog mitgeteilt werden, Anfragen je nach Zustand von Umgebungsvariablen zu protokollieren. Das Folgende ist eine Beispiel-Konfiguration, die den Server auffordert, keine GET- und PROPFIND-Anfragen zu protokollieren, die an private Subversion URLs gerichtet sind.

# Passt auf alles, nur zur Initialisierung von "in_repos".
SetEnvIf Request_URI "^" in_repos=0

# "in_repos" setzen, falls Anfrage für private Subversion URL.
SetEnvIf Request_URI "/!svn/" in_repos=1

# "do_not_log" für nicht-öffentliche Anfragetypen, die nicht protokolliert werden sollen.
SetEnvIf Request_Method "GET" do_not_log
SetEnvIf Request_Method "PROPFIND" do_not_log

# "do_not_log" zurücksetzen für nicht-private Subversion URLs
SetEnvIf in_repos 0 !do_not_log

# Anfragen protokollieren, nuer wenn "do_not_log" nicht gesetzt
CustomLog logs/access_log env=!do_not_log

Bei Verwendung dieser Konfiguration würde httpd immer noch GET-Anfragen an öffentliche Subversion URLs protokollieren. Das sind die Art Anfragen, wie sie von einem Web-Browser erzeugt werden, wenn jemand direkt im Projektarchiv navigiert. Jedoch werden GET- und PROPFIND-Anfragen nicht protokolliert, die an sogenannte „private“ Subversion-URLs gehen – das sind genau die Anfragen, die Verwendet werden, um jede einzelne Datei während einer Checkout-Operation zu holen.

Proxy mit Weiterleitung beim Schreiben

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 Netzwerkverkehr 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.

Anmerkung

Unseres ist nur ein Beispiel, wie Sie eine Konfiguration für einen durchreichenden Subversion-Proxy einrichten können. Es gibt auch andere Ansätze. Anstatt den Master-Server Änderungen an jeden Slave-Server schicken zu lassen, könnten beispielsweise diese Slave-Server periodisch diese Änderungen vom Master abrufen. Oder vielleicht könnte der Master Änderungen an einen einzigen Slave schicken, der dann dieselbe Änderung an den nächsten Slave weitergibt, und so der Reihe entlang weiterreicht. Administratoren sei nahegelegt, diesen Abschnitt zu verwenden, um ein grundsätzliches Verständnis darüber zu erlangen, was in einem Subversion-WebDAV-Proxy Szenario vor sich geht, und denjenigen Lösungsansatz zu wählen, der für ihre Organisation am besten funktioniert.

Einrichtung der Server

Konfigurieren Sie zunächst die Datei httpd.conf des Master-Servers auf die übliche Art. Stellen Sie das Projektarchiv unter einem bestimmten URI zur Verfügung und richten Sie nach ihren Wünschen die Authentifikation sowie Autorisierung ein. Sobald dies erledigt ist, konfigurieren Sie jeden Ihrer „Slave“-Server auf exakt dieselbe Art, fügen jedoch die besondere Direktive SVNMasterURI dem Block hinzu:

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

Diese neue Direktive teilt dem Slave-Server mit, alle Schreibanfragen an den Master weiterzuleiten. (Dies geschieht durch das Apache-Modul mod_proxy automatisch.) Gewöhnliche Leseanfragen werden jedoch immer noch von den Slaves bedient. Stellen Sie sicher, dass Ihre Master- und Slave-Server die gleichen Authentifikations- und Autorisierungs-Konfigurationen haben; falls sie nicht mehr synchron sein sollten, kann das zu heftigen Kopfschmerzen führen.

Als nächstes müssen wir uns um das Problem unendlicher Rekursion kümmern. Stellen Sie sich vor, was unter der gegenwärtigen Konfiguration passiert, wenn ein Subversion-Client eine Übergabe an den Master-Server vornimmt. Wenn die Übergabe abgeschlossen ist, benutzt der Server svnsync, um die neue Revision nach jedem Slave zu replizieren. Da sich aber svnsync wie ein gewöhnlicher Subversion-Client bei einer Übergabe verhält, wird der Slave sofort versuchen, die hereinkommende Schreibaufforderung zurück an den Master weiterzuleiten! Da kommt Freude auf.

Die Lösung des Problems besteht darin, den Master Revisionen an eine unterschiedliche <Location> auf den Slaves senden zu lassen. Dieser Ort ist dergestalt konfiguriert, dass Schreibanfragen nicht weitergeleitet werden, sondern normale Übergaben von der IP-Adresse des Masters (und nur von dort) angenommen werden:

<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>

Einrichten der Replizierung

Nachdem Sie nun Ihre Location-Blöcke auf Mastern und Slaves konfiguriert haben, müssen Sie nun Ihren Master für die Replizierung zu den Slaves einrichten. Unser Anwendungsbeispiel verwendet svnsync, welches detailliert in „Replizierung mit svnsync“ behandelt wird.

Stellen Sie zunächst sicher, dass jedes Slave-Projektarchiv ein pre-revprop-change-Hook-Skript hat, das Änderungen an Revisions-Eigenschaften aus der Ferne ermöglicht. (Das ist Standard, wenn von svnsync empfangen wird.) Melden Sie sich dann auf dem Master-Server an und konfigurieren jede der Slave-Projektarchiv-URIs, so dass sie Daten vom Master-Projektarchiv auf der lokalen Platte empfangen:

$ 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 \
$              file:///var/syn/repos 
Ü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 \
               file:///var/svn/repos  
Ü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 \
               file:///var/svn/repos 
Übertrage Daten ....
Revision 1 übertragen.
Eigenschaften für Revision 1 kopiert.
Übertrage Daten ....
Revision 2 übertragen.
Eigenschaften für Revision 2 kopiert.
…

Nachdem das erledigt ist, wird das post-commit-Hook-Skript des Master-Servers konfiguriert, damit svnsync auf jedem Slave-Server aufgerufen wird:

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

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

Die zusätzlichen Stückchen am Ende jeder Zeile sind zwar nicht notwendig, erlauben es aber den Sync-Befehlen, auf eine leise Art und Weise im Hintergrund zu laufen, so dass der Subversion-Client keine Ewigkeit auf den Abschluss der Übergabe warten muss. Zusätzlich zu diesem post-commit-Hook werden Sie außerdem einen post-revprop-change-Hook benötigen, damit, wenn ein Anwender beispielsweise eine Protokollnachricht verändert, die Slave-Server diese Änderung ebenfalls mitbekommen:

#!/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 \
                      file:///var/svn/repos \
                      -r ${REV} > /dev/null 2>&1 &
svnsync copy-revprops http://slave2.example.com/svn-proxy-sync \
                      file:///var/svn/repos \
                      -r ${REV} > /dev/null 2>&1 &
svnsync copy-revprops http://slave3.example.com/svn-proxy-sync \
                      file:///var/svn/repos \
                      -r ${REV} > /dev/null 2>&1 &

Das Einzige, was wir hier ausgelassen haben, ist die Behandlung von Sperren auf Anwenderebene (der Sorte svn lock). Sperren werden vom Master-Server während der Übergabeoperationen durchgesetzt; alle Informationen zu Sperren werden jedoch während Leseoperationen wie svn update und svn status durch den Slave-Server verteilt. An und für sich müsste eine voll funktionsfähige Proxy-Umgebung die Sperrinformationen vom Master-zum Slave-Server perfekt replizieren. Leider sind die meisten der hierfür eingesetzten Mechanismen auf die eine oder andere Art unzureichend^[69]. Viele Teams verwenden die Sperrfunktionalität von Subversion überhaupt nicht, so dass es Sie gar nicht betreffen könnte. Leider können wir den Teams, die Sperren verwenden, keine Empfehlungen aussprechen, wie diese Schwäche umgangen werden kann.

Warnungen

Nun sollte Ihr Master-Slave-Replizierungssystem einsatzbereit sein. An dieser Stelle sind einige Worte zur Warnung angebracht. Bedenken Sie, dass diese Replizierung nicht vollständig robust gegenüber Rechner- und Netzwerkausfällen ist. Wenn beispielsweise einer der automatisierten svnsync-Befehle aus irgendeinem Grund nicht vollständig abgeschlossen wird, beginnen die Slaves, hinterher zu hinken. Ihre entfernten Anwender werden sehen, dass sie Revision 100 übertragen haben; wenn sie allerdings svn update aufrufen, wird ihr lokaler Server ihnen mitteilen, dass Revision 100 noch nicht existiert! Natürlich wird das Problem automatisch mit der nächsten Übergabe behoben wenn das folgende svnsync erfolgreich ist – alle wartenden Revisionen werden dann repliziert. Trotzdem möchten Sie vielleicht eine zusätzliche Überwachung einrichten, um auf Synchronisierungsfehler hingewiesen zu werden, damit Sie in diesem Fall svnsync erneut aufrufen können.

Eine weitere Einschränkung des Modells eines durchreichenden Proxy-Einsatzes betrifft nicht übereinstimmende Versionen – und zwar der installierten Subversion-Version – zwischen dem Master und den Slave-Servern. Jede neue Veröffentlichung von Subversion kann dem Netzwerkprotokoll, das zwischen den Clients und den Servern verwendet wird neue Funktionalität hinzufügen (und macht dies auch oftmals). Da die Aushandlung der Funktionalität mit dem Slave erfolgt, wird hier das Protokoll und der Funktionalitätsumfang des Slaves benutzt. Allerdings werden Schreiboperationen ziemlich wörtlich an den Master-Server weitergereicht. Daher besteht die Gefahr, dass der Slave-Server eine Funktionalitäts-Anfrage auf eine Art beantwortet, die für den Slave zutrifft, für den Master aber nicht, sofern er eine ältere Version von Subversion betreibt. Das kann dazu führen, dass der Client eine neue Funktionalität verwenden möchte, die der Master nicht versteht, und somit zu einem Fehler.

Subversion 1.8 hilft, dieses Problem durch die Einführung einer neuen Apache Konfigurations-Direktive zu entschärfen: SVNMasterVersion. Indem Sie jeden Ihrer Slave-Server so konfigurieren, dass SVNMasterVersion auf die Version der Subversion-Instanz gesetzt wird, die auf dem Master-Server läuft, können die Slave-Server viel genauer die unterstützten Funktionalitäten mit dem Client aushandeln.

Leider unterstützt Subversion 1.7 die Konfigurations-Direktive SVNMasterVersion nicht und hat bekanntermaßen einige Probleme in diesem Zusammenhang. Falls Sie einen Slave mit Subversion 1.7 vor einem Master mit einer älteren Version als 1.7 betreiben, sollten Sie den Subversion <Location>-Block Ihres Slave-Servers mit der Direktive SVNAdvertiseV2Protocol Off konfigurieren.

	Tipp
	Für ein bestmögliches Ergebnis sollten Sie versuchen, dieselbe Version von Subversion auf dem Master- und Slave-Server laufen zu lassen.

Können wir eine Replizierung mit svnserve aufsetzen?

Falls Sie svnserve statt Apache als Server verwenden, können Sie sicherlich die Hook-Skripte Ihres Projektarchivs dergestalt konfigurieren, dass sie svnsync wie hier gezeigt aufrufen und somit eine Replizierung vom Master zu den Slaves bewirken. Leider besteht zum gegenwärtigen Zeitpunkt nicht die Möglichkeit, Slave-svnserve-Server dazu zu veranlassen, Schreibanfragen automatisch an den Master weiterzuleiten. Das bedeutet, dass Ihre Anwender nur Lesekopien von den Slave-Servern auschecken können. Sie müssten Ihre Slave-Server so konfigurieren, dass sie Schreibanfragen vollständig verbieten. Das könnte für die Bereitstellung von „Spiegeln“ mit Lesezugriff beliebter Open-Source-Projekte nützlich sein, jedoch stellt es kein transparentes Proxy-System dar.

Andere Funktionen von Apache

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 einer ausführlichen Behandlung nicht Wert sind. Für diejenigen, die es interessiert, stellen wir jedoch eine vollständige Liste aller httpd.conf Direktiven, auf die mod_dav_svn reagiert, unter „mod_dav_svn Konfigurations-Direktiven“ zur Verfügung.

Subversion Apache HTTP-Server Konfigurations~Referenz

In den vorhergehenden Abschnitten erwähnten wir eine Vielzahl an Direktiven, die Administratoren in Ihren httpd.conf-Dateien verwenden können, um die Angebote ihres Subversion-Servers zu ermöglichen und zu konfigurieren, wobei wir bei der Einführung jeder Direktive auch die Funktionalität vorstellten, die dadurch umgeschaltet wird. In diesem Abschnitt werden wir schnell alle Direktiven zusammenfassen, die von beiden Apache HTTP-Server-Modulen unterstützt werden, die als Teil des Standardpaketes von Subversion mitgeliefert werden.

mod_dav_svn Konfigurations-Direktiven

Die folgenden Konfigurations-Direktiven werden von Subversions Apache HTTP-Server-Modul mod_dav_svn erkannt und unterstützt.

DAV svn

Muss in jedem Directory- oder Location-Abschnitt für ein Subversion-Projektarchiv enthalten sein. Sie fordert httpd auf, das Subversion-Backend von mod_dav zur Auftragsabwicklung zu verwenden.

SVNActivitiesDB directory-path

Bestimmt den Ort im Dateisystem, an dem die Datenbank für Aktivitäten abgelegt werden soll. Standardmäßig erzeugt und verwendet mod_dav_svn ein Verzeichnis im Projektarchiv namens dav/activities.d. Der durch diese Option angegebene Pfad muss absolut sein.

Falls ein SVNParentPath-Bereich angegeben wurde, hängt mod_dav_svn den Basisnamen des Projektarchivs an diesen Pfad an, beispielsweise:

<Location /svn>
  DAV svn


  # jeder "/svn/foo" URL wird auf ein Projektarchiv in
  # /net/svn.nfs/repositories/foo abgebildet
  SVNParentPath         "/net/svn.nfs/repositories"


  # jeder "/svn/foo" URL wird auf eine Aktivitäten-Datenbank in
  #  /var/db/svn/activities/foo abgebildet
  SVNActivitiesDB       "/var/db/svn/activities"
</Location>

SVNAdvertiseV2Protocol On|Off

Neu in Subversion 1.7. Schaltet die Benachrichtigung ein oder aus, dass mod_dav_svn die neue Version seines ebenfalls in dieser Version vorgestellten HTTP-Protokolls unterstützt. Die meisten Administratoren werden diese Direktive nicht verwenden wollen (deren Standardwert On ist), da sie lieber die Leistungsverbesserung des neuen Protokolls nutzen möchten. Falls jedoch ein Server als Durchschreib-Proxy für einen anderen Server, der das neue Protokoll nicht unterstützt, eingerichtet werden soll, ist der Wert dieser Direktive auf Off zu setzen.

SVNAllowBulkUpdates On|Off|Prefer

Ändert die Unterstützung für vollständige Antworten auf Anfragen im Stil von Aktualisierungen. Subversion-Clients verwenden REPORT-Anfragen, um von mod_dav_svn Informationen über Checkouts und Aktualisierungen von Verzeichnisbäumen zu erhalten. Dabei kann vom Server verlangt werden, diese Information auf zwei mögliche Weisen zu senden: entweder mit den Informationen zum gesamten Teilbaum in einer umfangreichen Antwort (Masse) oder als ein Skelta (eine skelettierte Repräsentation eines Baum-Deltas), das dem Client gerade genug Informationen liefert, so dass er weiß, welche zusätzlichen Daten er mittels weiterer Anfragen vom Server holen muss. Wird diese Direktive mit dem Wert Off versehen, werden REPORT-Anfragen von mod_dav_svn ausschließlich mit Skeltas beantwortet, egal welche Art der Antwort vom Client verlangt wurde.

Der Standardwert dieser Direktive ist On, um dem Server zu erlauben, auf Aktualisierungs-Anfragen im vom Client gewünschten Stil (Masse oder Skelta) zu antworten. Beginnend mit Subversion 1.8, akzeptiert diese Direktive auch den Wert Prefer, der ähnlich dem zu On ist, jedoch zusätzlich dazu führt, dass der Server Clients mitteilt, dass er Massen-Aktualisierungs-Anfragen bevorzugt.

Die Meisten werden diese Direktive überhaupt nicht benötigen. Sie existiert hauptsächlich für Administratoren, die – aus Gründen der Sicherheit oder Nachprüfbarkeit – Subversion-Clients dazu zwingen möchten, alle für Checkouts oder Aktualisierungen benötigten Dateien und Verzeichnisse individuell abzurufen, um somit eine Spur aus GET- und PROPFIND-Anfragen in den Protokolldateien von Apache zu hinterlassen.

SVNAutoversioning On|Off

Wenn der Wert On ist, führen Schreibanfragen von WebDAV-Clients zu automatischen Übergaben ins Projektarchiv. Eine automatisch erzeugte, generische Protokollnachricht wird mit jeder Revision verknüpft. Falls Sie automatische Versionierung ermöglichen, werden Sie sicherlich auch ModMimeUsePathInfo On setzen wollen, so dass mod_mime svn:mime-type automatisch auf den richtigen MIME-Typen setzen kann (natürlich nur so gut, wie es mod_mime kann). Für weitere Informationen, siehe Anhang C, WebDAV und Autoversionierung. Der Standardwert dieser Direktive ist Off.

SVNCacheFullTexts On|Off

Der Wert On teilt Subversion mit, Volltextinhalt zwischenzuspeichern, sofern ausreichend Zwischenspeicherplatz vorhanden ist, was dem Server einen deutlichen Leistungsvorteil bescheren könnte. (Siehe hierzu auch die Direktive SVNInMemoryCacheSize.) Der Standardwert dieser Direktive ist Off.

SVNCacheTextDeltas On|Off

Der Wert On teilt Subversion mit, Deltas von Inhalten zwischenzuspeichern, sofern ausreichend Zwischenspeicherplatz vorhanden ist, was dem Server einen deutlichen Leistungsvorteil bescheren könnte. (Siehe hierzu auch die Direktive SVNInMemoryCacheSize.) Der Standardwert dieser Direktive ist Off.

SVNCompressionLevel level

Spezifiziert den Kompressionsgrad wenn Dateiinhalte über das Netz gesendet werden. Der Wert 0 unterbindet die Kompression vollständig und 9 ist der Maximalwert. 5 ist der Standardwert.

SVNHooksEnv file-path

Gibt den Ort der Konfigurationsdatei für die Subversion Hook-Script-Umgebung an. Diese Datei wird verwendet, um die anfängliche Umgebung zu beschreiben, in der Hook-Skripte ausgeführt werden. Für weitere Informationen hierzu, siehe „Konfiguration der Umgebung von Hook-Skripten“.

SVNIndexXSLT directory-path

Spezifiziert den URI einer XSL-Transformation für Verzeichnisindexe. Diese Direktive ist optional.

SVNInMemoryCacheSize size

Spezifiziert die Maximalgröße des Zwischenspeichers von Subversion (in kBytes) pro Prozess. Der Standardwert ist 16384; verwenden Sie den Wert 0, um die Zwischenspeicherung vollständig zu unterbinden.

SVNListParentPath On|Off

Wenn sie auf On gesetzt ist, wird ein GET von SVNParentPath erlaubt, was zu einer Auflistung aller Projektarchive unter diesem Pfad führt. Der Standardwert ist Off.

SVNMasterURI url

Der URI des Master-Subversion-Projektarchivs (verwendet für einen Proxy, über den geschrieben wird).

SVNMasterVersion X.Y

Gibt die Versionsnummer der Subversion-Instanz an, die das Master-Projektarchiv betreut (verwendet für einen Proxy mit Schreib-Weiterleitung).

SVNParentPath directory-path

Spezifiziert den Ort im Dateisystem, an dem ein Elternverzeichnis liegt, dessen Kindverzeichnisse Subversion-Projektarchive sind. In einem Konfigurationsblock für ein Subversion-Projektarchiv muss entweder diese Direktive oder SVNPath vorhanden sein, jedoch nicht beide.

SVNPath directory-path

Gibt den Ort im Dateisystem an, an dem die Dateien eines Subversion-Projektarchivs liegen. In einem Konfigurationsblock für ein Subversion-Projektarchiv muss entweder diese Direktive oder SVNParentPath vorhanden sein, jedoch nicht beide.

SVNPathAuthz On|Off|short_circuit

Kontrolliert pfad-basierte Autorisierung, indem Unteranfragen ermöglicht (On) oder abgeschaltet (Off; siehe „Unterbinden pfad-basierter Prüfungen“) werden oder bei mod_authz_svn direkt nachgefragt wird (short_circuit). Der Standardwert dieser Direktive ist On.

SVNReposName name

Spezifiziert den Namen eines Subversion-Projektarchivs zur Verwendung für HTTP GET-Antworten. Dieser Wert wird dem Titel aller Verzeichnisauflistungen vorangestellt (die übertragen werden, wenn Sie mit einem Browser zu einem Subversion-Projektarchiv navigieren). Diese Direktive ist optional.

	Anmerkung
	Beim Suchen nach passenden Regeln in Zugriffskontroll-Dateien wird Subversion den über diese Direktive konfigurierten Namen des Projektarchivs nicht verwenden. Die in der Syntax dieser Datei verwendeten Projektarchiv-Namen werden stets vom URL des Projektarchivs abgeleitet. Zu Details, siehe „Loslegen mit pfad-basierter Zugriffskontrolle“.

SVNSpecialURI component

Spezifiziert die URI-Komponente (Namensraum) für besondere Subversion-Ressourcen. Der Standardwert ist !svn, und die meisten Administratoren werden diese Direktive nie verwenden. Setzen Sie sie nur, falls die dringende Notwendigkeit besteht, eine Datei namens !svn in Ihrem Projektarchiv zu haben. Falls Sie diese Direktive auf einem Server ändern, der bereits in Gebrauch ist, werden alle offenstehenden Arbeitskopien unbrauchbar gemacht, und Ihre Benutzer werden Sie mit Mistgabeln und Fackeln zur Strecke bringen.

SVNUseUTF8 On|Off

Wenn auf On gesetzt, kommuniziert mod_dav_svn mit Hook-Skripten unter Verwendung von Projektarchiv-Wurzel-Pfaden, die UTF-8-kodiert sind und erwartet, dass diese Skripte ebenso UTF-8-kodierte Ausgaben (etwa Fehlermeldungen) erzeugen. Der Standardwert dieser Option ist Off, was bedeutet, dass mod_dav_svn für seine Kommunikation mit Hook-Skripten von einer 7-Bit-ASCII-Kodierung ausgeht. Diese Option ist seit Subversion 1.8 verfügbar.

Anmerkung

Administratoren sollten sicherstellen, dass die Erwartungen bezüglich Zeichensatz und Kodierung von Hook-Skripten zu allen möglichen Aufruf-Szenarien passen. Wenn beispielsweise ein Projektarchiv sowohl von httpd als auch von svnserve bedient wird, sollte svnserve ebenfalls so konfiguriert sein, dass es UTF-8 verwendet (durch Einstellung der passenden Locale in seiner Umgebung), falls diese Option für mod_dav_svn aktiviert ist. Lokale Dateisystem-Pfade mit nicht-ASCII Zeichen, auf die von diesen Skripten zugegriffen wird (wie etwa Projektarchiv-Wurzel-Pfade) müssen passend im Dateisystem kodiert sein, damit sie den Erwartungen der Skripte entsprechen.

mod_authz_svn Konfigurations-Direktiven

Die folgenden Konfigurations-Direktiven werden geliefert von mod_authz_svn, Subversions Apache HTTP-Server-Modul für pfad-basierte Autorisierung. Für eine erschöpfende Beschreibung der Verwendung pfad-basierter Autorisierung in Subversion, siehe „Pfad-basierte Autorisierung“.

AuthzForceUsernameCase Upper|Lower

Entweder Upper oder Lower, um die entsprechende Umwandlung des authentifizierten Anwendernamens vor der Autorisierungsprüfung in Klein- oder Großschreibung vorzunehmen. Während Anwendernamen unter Beachtung der Klein- oder Großschreibung mit denjenigen in der Autorisierungs-Regel-Datei verglichen werden, kann diese Direktive zumindest gemischt geschriebene Anwendernamen in irgendetwas konsistentes normalisieren.

AuthzSVNAccessFile file-path

Für Zugriffsregeln, die Rechte auf Pfaden im Subversion-Projektarchiv beschreiben, soll in file-path nachgesehen werden. In einem Konfigurations-Block für ein Subversion-Projektarchiv oder eine Ansammlung von Projektarchiven kann entweder diese Direktive oder AuthzSVNReposRelativeAccessFile verwendet werden, jedoch nicht beide.

Beginnend mit Subversion 1.8 akzeptiert AuthzSVNAccessFile einen URL zu einer innerhalb eines Subversion-Projektarchivs gespeicherten Datei – entweder dasselbe Projektarchiv auf das die Zugriffsregeln angewendet werden, oder ein ganz anderes Projektarchiv.

AuthzSVNAnonymous On|Off

Um zwei besondere Verhaltensweisen dieses Moduls zu unterbinden, sollte diese Direktive auf Off gesetzt werden: Die Interaktion mit der Satisfy Any-Anweisung und das Durchsetzen des Autorisierungsverfahrens auch dann, wenn keine Require-Direktiven vorhanden sind. Der Standardwert dieser Direktive ist On.

AuthzSVNAuthoritative On|Off

Auf Off gesetzt, wird die Weiterleitung der Zugriffskontrolle an tiefere Module erlaubt. Der Standardwert dieser Direktive ist On.

AuthzSVNNoAuthWhenAnonymousAllowed On|Off

Auf On setzen, um die Authentifikation und Autorisierung von Anfragen zu unterbinden, die anonyme Benutzer durchführen dürfen. Der Standardwert dieser Direktive ist On.

AuthzSVNReposRelativeAccessFile file-path

Für Zugriffsregeln, die die Rechte auf Pfaden im Subversion-Projektarchiv beschreiben, soll unter file-path nachgesehen werden. Anders als bei AuthzSVNAccessFile, ist der für AuthzSVNReposRelativeAccessFile angegebene Pfad relativ zum /conf-Verzeichnis im Projektarchiv auf dem Dateisystem. Mit anderen Worten gibt file-path eine Datei pro Projektarchiv an, die über den relativen Pfad für alle Projektarchive eines Konfigurations-Blocks zugänglich sein muss. Im Konfigurations-Block eines Subversion-Projektarchivs oder einer Gruppe von Projektarchiven kann entweder diese Direktive oder AuthzSVNAccessFile verwendet werden, jedoch nicht beide. Diese Option ist seit Subversion 1.7 verfügbar.

Beginnend mit Subversion 1.8 akzeptiert AuthzSVNReposRelativeAccessFile einen URL auf eine Datei, die innerhalb der Subversion-Projektarchivs gespeichert ist – entweder dasselbe Projektarchiv auf das die Zugriffsregeln angewendet werden oder in ein ganz anderes Projektarchiv.

Zurück	Nach oben	Weiter
svnserve, ein maßgefertigter Server	Zum Anfang	Pfad-basierte Autorisierung