Sie haben gesehen, wie auf viele verschiedene Weisen auf ein Projektarchiv zugegriffen werden kann. Ist es aber möglich, oder sicher, wenn auf Ihr Projektarchiv gleichzeitig mit mehreren Methoden zugegriffen wird? Die Antwort lautet: ja, vorausgesetzt, sie handeln ein bisschen vorausschauend.
Diese Prozesse benötigen jederzeit Lese- und Schreibzugriff auf Ihr Projektarchiv:
Gewöhnliche Systemanwender, die einen Subversion-Client
mit ihrer Kennung verwenden, um direkt über
file:// URLs auf das Projektarchiv
zuzugreifen
Gewöhnliche Systemanwender, die sich über durch SSH gestartete private svnserve-Prozesse verbinden, die unter ihrer Kennung auf das Projektarchiv zugreifen
Ein svnserve-Prozess, entweder als Daemon oder von inetd gestartet, der unter einer bestimmten festen Kennung läuft
Ein Apache httpd-Prozess, der unter einer bestimmten festen Kennung läuft
Das häufigste Problem, in das Administratoren laufen,
besteht im Eigentumsverhältnis und den Zugriffsrechten des
Projektarchivs. Hat jeder Prozess (oder Anwender) aus der obigen
Liste die Rechte, die dem Projektarchiv zugrunde liegenden
Dateien zu lesen und zu schreiben? Unter der Annahme, dass Sie
ein Unix-ähnliches Betriebssystem haben, mag ein einfacher
Ansatz darin bestehen, jeden möglichen Anwender des
Projektarchivs in eine neue Gruppe svn
aufzunehmen und dieser Gruppe die Eigentumsrechte über das
Projektarchiv zu geben. Aber auch das reicht nicht, da ein
Prozess die Datenbankdateien unter Verwendung einer widrigen
umask schreiben könnte, so dass anderen Anwendern der Zugriff
verwehrt würde.
Nach dem Einrichten einer gemeinsamen Gruppe für
Projektarchiv-Anwender besteht der nächste Schritt darin, jeden
Prozess, der auf das Projektarchiv zugreift, zu zwingen, eine
passende umask zu verwenden. Für Anwender, die direkt auf das
Projektarchiv zugreifen, können Sie das Programm
svn in ein Skript umwandeln, das zunächst
umask 002 aufruft und dann das
eigentliche Client-Programm svn startet. Ein
ähnliches Skript können Sie für das Programm
svnserve schreiben, und in das Startskript
von Apache, apachectl, fügen Sie das
Kommando umask 002 ein. Zum
Beispiel:
$ cat /usr/bin/svn #!/bin/sh umask 002 /usr/bin/svn-real "$@"
Ein weiteres bekanntes Problem tritt häufig auf
Unix-ähnlichen Systemen auf. Wenn Ihr Projektarchiv
beispielsweise auf Berkeley-DB aufsetzt, werden gelegentlich
neue Dateien angelegt, um die Aktivitäten zu protokollieren.
Selbst wenn die Gruppe svn vollständiger
Eigentümer des Projektarchivs ist, müssen diese neu erstellten
Protokolldateien nicht notwendigerweise derselben Gruppe
gehören, was weitere Zugriffsprobleme für Ihre Anwender nach
sich zieht. Ein guter Behelf besteht darin, das Gruppen-SUID-Bit
für das Verzeichnis db des Projektarchivs
zu setzen, was dazu führt, das alle neu erstellten
Protokolldateien derselben Gruppe gehören wie das
Elternverzeichnis.
Sobald Sie diese Hürden genommen haben, sollten alle notwendigen Prozesse auf Ihr Projektarchiv zugreifen können. Es scheint vielleicht etwas chaotisch und kompliziert, doch die Probleme, die bei gemeinsamen Zugriff mehrerer Anwender auf gemeinsame Dateien entstehen, sind Klassiker, die sich oft nicht elegant lösen lassen.
Glücklicherweise werden die meisten Administratoren von
Projektarchiven niemals eine solch komplexe Konfiguration
benötigen. Anwender, die auf Projektarchive
des Rechners zugreifen möchten, an dem sie sich angemeldet
haben, sind nicht auf URLs der Form file://
beschränkt, sondern können den
Apache-Server oder svnserve mit
localhost als Server-Namen in deren
http:// oder svn:// URL
verwenden. Darüber hinaus wird das Betreiben mehrfacher
Server-Prozesse für Ihr Projektarchiv Ihnen mehr Kopfschmerzen
bereiten als nötig ist. Wir empfehlen, einen einzigen Server zu
wählen, der Ihren Bedürfnissen am nächsten kommt und dabei zu
bleiben!