Die verwendete Konfiguration setzt auf der Verwendung des Apache im Zusammenwirken mit DAV auf. DAV steht für “Distributed Authoring and Versioning” und bildet die Schnittstelle zwischen dem Apachen und Subversion. Die Verbindung erfolgt über SSL.

Die Benutzerauthentifikation läuft über ein MySQL-Backend, die Benutzerauthorisierung über zentrale Dateien, sogenannte ACLs.

Das Basisverzeichnis lautet bei dieser Konfiguration /svn, die Repository-Struktur ist die folgende:

/svn/private

Jedes dieser Verzeichnisse bildet eine Art “Behälter” (technische Bezeichnung: “SVN-Parent-Path”) und stellt eine thematische Gliederung dar. Entsprechend der Ordnernamen können in diesen “Behältern” Repositories angelegt werden, also zB. /svn/private/repo1, wobei “repo1” das eigentliche Repository ist, “/svn/private” der “Behälter”.

Wichtig ist außerdem das Verzeichnis /svn/auth

apt-get install apache2 apache2.2-common openssl subversion subversion-tools libapache2-svn

• Die Location-Direktiven werden nicht in der apache2.conf gemacht, sondern in einem eigenen Virtual-Host-Container, welcher in einer Datei im Verzeichnis /etc/apache2/site-available/ gespeichert wird. Nebst den “üblichen” Einstellungen wie Root-Verzeichnis und Log-Directory wird in dieser Datei zusätzlich für jedes Repository eine Location-Direktive nach unten stehendem Muster angelegt:

<Location /svn/private/>
        DAV svn
        SVNParentPath /svn/private/
        AuthzSVNAccessFile /svn/auth/accesslist_private

        SSLRequireSSL

        AuthBasicAuthoritative Off
        AuthUserFile /dev/null
        AuthMySQL On
        AuthName "SVN"
        AuthType Basic
        Auth_MySQL_Host localhost
        Auth_MySQL_User svnauthdbuser
        Auth_MySQL_Password ************
        AuthMySQL_DB authdb
        AuthMySQL_Password_Table mysql_auth
        Auth_MySQL_Username_Field username
        Auth_MySQL_Password_Field passwd
        Auth_MySQL_Empty_Passwords Off
        Auth_MySQL_Encryption_Types PHP_MD5
        Auth_MySQL_Authoritative On
        require valid-user
</Location>

Außerdem müssen einige Module installiert, bzw. aktiviert werden:

apt-get install libapache2-mod-auth-mysql

a2enmod userdir auth_mysql

Je nachdem, wie man in der apache2.conf (s.o.) die Struktur für die Repository-Behältnisse vorgesehen hat, müssen entsprechend auch alle Ordner angelegt werden. Im Beispiel oben wird das Verzeichnis “/svn/private/” als Basisverzeichnis definiert und der Zugriff auf die Datei accesslist_private im Verzeichnis /svn/auth/ verlangt. Die hiesige Umsetzung basiert auf den folgenden Befehlen:

mkdir -p /svn/auth

Alle Verzeichnisse müssen www-data gehören (Benutzername des Apache2).

Entsprechend:

chown -R www-data /svn
chmod -R 750 /svn

Als nächstes müssen die Authorisierungslisten angelegt…

touch /svn/auth/accesslist_private

…und die Rechte angepasst werden:

chown www-data /svn/auth/*
chmod 660 /svn/auth/*

Dazu gibt es ein kleines, primitives Bash-Skript, welches im Verzeichnis /svn/scripts liegt und den Namen mkrepository trägt.

/svn/scripts/mkrepository /PATH/TO/REPO-LOCATION REPONAME USER SECONDUSER SECONDUSER-PERMS

Manuell können neue Repositories mit folgendem Befehl (per root) erzeugt werden:

svnadmin create /ABSOLUTE/PATH/TO/REPO

Allerdings müssen dann für jeden Ordner die Zugriffsrechte auf 750, für jede Datei auf 660 und der Besitzer und die Gruppe auf www-data:staff geändert werden. All dies nimmt das Skript ab.

Alle Zugriffsrechte für jedes Repository werden über die zentralen Dateien, die in /svn/auth liegen, gesteuert. Jeder Repository-Behälter hat eine solche Datei und entsprechend muss für ein Repository zB “/svn/private/person1” auch die access-Datei “/svn/auth/accesslist_private” editiert werden.

An dieser Stelle soll das Schema der “accesslist” anhand des Beispiels “/svn/private/person1” dargestellt werden.

Wichtige Vorbemerkung:
Jede Zeile in der Accesslist stellt eine Rechtevergabe dar. Wenn man die Rechtevergabe mit einem Semikolon versieht und/oder hinter die Rechtevergabe einen Kommentar mit der Raute (#) einleitet, wird beim Zugriff auf das Repository, für das man die Rechte editiert hat, ein “Permission Denied” vom Apache ausgegeben. Semikolons am Ende einer Rechtevergabezeile dürfen also nie gesetzt werden und Kommentare entweder über oder unter eine Rechtevergabezeile!
Person1 hat ein Repository im Repository-Behälter “/svn/private/” mit dem Namen “person1” (standardmäßig wird vom mkrepository-Skript der Repository-Name auf den Benutzernamen des Besitzers gesetzt). Da dieses Repository ein privates ist, soll entsprechend zunächst auch nur Person1 auf dieses Repository Zugriff haben, und zwar lesend und schreibend. Der Eintrag in der accesslist_private lautet demnach:

[person1:/]
Person1 = rw

In den eckigen Klammern steht der Name des Repositories, gefolgt von einem Doppelpunkt und einen Slash. Das bedeutet, dass die darauffolgenden Berechtigungen, in diesem Fall Person1 = rw, sich auf alle Unterverzeichnisse beziehen. Man kann das Slash auch als eine Art “Wurzel” verstehen, nämlich die Wurzel des Repositories “person1”. Person1 = rw bedeutet natürlich, dass “Person1” read- und write-Permissions in seinem Repository hat. “Person1” muss in jedem Fall ein Benutzername sein, der in der gleichen Schreibweise auch im LDAP steht!

Im Laufe der Zeit entwickelt Person1 mehrere Java-Projekte. In seinem Repository sind inzwischen mehrere Unterordner:

trunk/java-ftp-client
trunk/java-ftp-client-gui
trunk/java-google-mars

Jetzt hat Person1 die Kernanwendung seines Java-FTP-Clients beendet und möchte seine Arbeit nun veröffentlichen. Also erstellt er einen “branch” (ebenfalls mit Subversive), sodass seine Repository-Struktur nun so aussieht:

trunk/java-ftp-client
trunk/java-ftp-client-gui
trunk/java-google-mars
branch/java-ftp-client/v1.0

Damit auch allgemein Zugriff, natürlich nur lesend, auf sein Ergebnis zugegriffen werden kann, muss die accesslist_private wie folgt verändert werden:

[person1:/]
Person1 = rw
 
[person1:/branch]
* = r

Bedeutung: Im Unterverzeichnis /branch des Repositories “person1” hat nun jeder “*” lesend “r” Zugriff. Allerdings wäre es sicherer, wenn Person1 lieber einen allgemein nutzbaren Benutzer anlegt und entsprechend auch ein Passwort generiert, welches er natürlich veröffentlicht. Wichtig zu bemerken ist, dass nach wie vor nur Person1 auf alles lesend und schreibend Zugriff hat und lediglich erweiterte Leserechte auf ein Unterverzeichnis gegeben wurde.
ACHTUNG: Sollte der anonyme Zugriff auf ein Repository gewünscht sein, dann muss im Config-File des Apache in der Location-Direktive des jeweiligen SVN-Containers noch folgendes ergänzt werden:

Satisfy Any

Die komplette Location-Direktive - hier am Beispiel “projects” - sieht dann so aus:

<Location /svn/private/>
        DAV svn
        SVNParentPath /svn/private/
        AuthzSVNAccessFile /svn/auth/accesslist_private

        SSLRequireSSL

        AuthBasicAuthoritative Off
        AuthUserFile /dev/null
        AuthMySQL On
        AuthName "SVN"
        AuthType Basic
        Auth_MySQL_Host localhost
        Auth_MySQL_User svnauthdbuser
        Auth_MySQL_Password 6udCuuiLmRe8
        AuthMySQL_DB authdb
        AuthMySQL_Password_Table mysql_auth
        Auth_MySQL_Username_Field username
        Auth_MySQL_Password_Field passwd
        Auth_MySQL_Empty_Passwords Off
        Auth_MySQL_Encryption_Types PHP_MD5
        Auth_MySQL_Authoritative On
        Satisfy Any
        require valid-user
</Location>

Person1 möchte nun einen Kumpel an seiner Google-Mars-Arbeit mitwirken lassen, allerdings hat der gar nichts mit seinen anderen Projekten zu tun. Person1 erweitert erneut die accesslist wie folgt:

[person1:/]
Person1 = rw
 
[person1:/branch]
* = r
 
[person1:/trunk/java-google-mars]
kumpel1 = rw

Dadurch hat sein Kumpel1 nun lesend und schreibend Zugriff auf sein Google-Mars-Projekt. Wenn jetzt der kleine Bruder von Kumpel1 sich mit Java beschäftigen und anhand eines Beispiels dazulernen will, kann Person1 dem gerecht werden, in dem er die accesslist so editiert, dass der kleine Bruder von kumpel1 nur lesen kann (weil kleiner Bruder keinen Plan von Java hat und nix kaputt machen soll):

[person1:/]
Person1 = rw
 
[person1:/branch]
* = r
 
[person1:/trunk/java-google-mars]
kumpel1 = rw
kleinerBruderKumpel1 = r

Dieses Beispiel ließe sich beliebig fortsetzen. Kernaussage ist, dass man mithilfe dieser Listen äußerst feingranular Rechte setzen und wieder entziehen kann.

• SVN-Book (siehe unten)

SVN-Book