Montag, 4. Juni 2012
[*]
Samstag, 4. Dezember 2010
[*]

Mit dem Internet reden

, 19:31

Wer mich mal hören möchte (wie ich hauptsächlich „Ääääh“ sage), der kann sich Folge 14 des Digitalen Grundrauschens anhören. Dort spreche ich mit dem Gastgeber Andreas Zeitler (@Zettt) und mit Tobias Günther von Fournova (der Firma hinter Git-Tower) mehr als 1,5h über Versionsverwaltungssysteme.

Montag, 15. November 2010
[*]

Einrichtung eines SVN-Spiegelservers

, 12:01

Der Subversion-Server des Kunden ist der langsamste seiner Art. Das sorgt für Frust; nicht nur blickt man in Eclipse oft minutenlang auf „Pending…“, wenn man Teilbäume aufklappen möchte, es schlagen auch Hudson-Builds fehl, weil svn update nicht durchgelaufen ist.

Für Hudson könnte man sich behelfen, indem man mit svnsync eine lokale (readonly-)Kopie des Repositories einrichtete, aber in der Entwicklungsumgebung hilft das nicht weiter. Seit Subversion 1.5 ist es zum Glück möglich, das dav_svn-Modul im Apache so zu konfigurieren, dass schreibende Zugriffe direkt auf ein zentrales Repository (den Master) umgeleitet werden während lesende Operationen auf einer lokalen Kopie ausgeführt werden.

Die im Netz zu diesem Thema zu findenden Anleitungen gehen größtenteils davon aus, dass man Master- und Slaveserver unter seiner eigenen Kontrolle hat. Wir können aber am Master nichts konfigurieren und werden deshalb eine etwas sparsamere Variante einrichten müssen.

Voraussetzungen:

  • Apache (min. 2.2)
  • svn (min. 1.5)
  • Apache mod_dav_svn und mod_proxy (sowie Module, von denen die jeweils abhängen)
  • Apache mod_ssl (wenn das Master-Repository per https erreichbar ist)

Schritt 0:

Benutzer anlegen (nennen wir ihn mal svnsync), mit dessen Account später die Synchronisation laufen wird. Weil der sich den Zugriff auf das Repository mit dem Webserver teilen wird, habe ich ihn in einer gemeinsamen Gruppe angelegt.

Schritt 1:

Repository anlegen (als root):

svnadmin create /var/www/svn/projekt

Die einzelnen Benutzer müssen wir nicht anlegen, weil das Benutzermanagement und die Commitrechte weiterhin vom Masterserver verwaltet werden.

Schritt 2:

Schreibenden Zugriff aufs Repository für alle Benutzer außer svnsync verbieten. Das geht mit einem „pre-revprop-change“-hook:

#!/bin/sh
USER="$3"

if [ "$USER" != "svnsync" ]; then
    echo >&2 "Only the svnsync user can change revprops"
    exit 1
fi

exit 0

Schritt 3:

Synchronisation starten:

Als Benutzer svnsync muss man die Synchronisationsverbindung erst erstellen (init) und dann die erste Synchronisation durchführen (sync). Je nachdem, wieviele Revisionen es im Master-Repository schon gibt kann das seine Zeit dauern.

 svnsync init file:///var/www/svn/projekt https://subversion.kunde.de/svn/projekt
 svnsync sync file:///var/www/svn/projekt

Passwörter für das Master-Repository müssen in dieser Phase eventuell eingegeben werden und werden dann im Home-Verzeichnis des Synchronisationsbenutzers im .svn-Verzeichnis gespeichert — das ist also mit der notwendigen Vorsicht/Sicherheit zu behandeln.Ständige Synchronisation einrichten:

Da uns, wie gesagt, das Master-Repository nicht gehört, können wir es nicht dazu bringen, uns von Änderungen zu unterrichten. Den sync-Befehl lassen wir deshalb von cron einmal pro Minute ausführen:

* * * * * svnsync sync file:///var/www/svn/projekt > /dev/null 2>&1

Schritt 4:

Zugriff über Apache einrichten:

In schmerzhaften Versuchen musste ich feststellen, dass der Zugriff über den Spiegel nur dann zuverlässig funktioniert, wenn sich die beiden Server möglichst ähnlich sind. Mit verschiedenen Repository-URLs (also wenn der „Verzeichnisname“ des Spiegels sich vom Original unterschied) hatte ich z.T. seltsame Fehlermeldungen („405 Unsupported Operation“,…). Auch der Wechsel von https (auf dem Kundenserver) auf http sorgt für unerklärliches Verhalten bei Verschiebe- und Umbenennoperationen. Wenn das Master-Repository über https erreichbar ist, benötigt man aber ohnehin mod_ssl (und muss den Parameter „SSLProxyEngine“ auf „on“ stellen).

Module laden (dies ist der Mindestumfang, und die Syntax unterscheidet sich je nach Linux/Apache-Distribution):

LoadModule dav_svn_module mod_dav_svn.so
LoadModule proxy_module mod_proxy.so
LoadModule proxy_http_module mod_proxy_http.so
LoadModule ssl_module mod_ssl.so

Konfiguration (Schnipsel an für diesen Apache geeignete Stelle einfügen):

SSLProxyEngine on

<Location /svn/projekt>
    DAV svn
    SVNPath /var/www/svn/projekt
    SVNMasterURI https://subversion.kunde.de/svn/projekt
</Location>

Jetzt kann man mit dem schnellen lokalen Server statt mit der weit entfernten lahmen Ente arbeiten (aber Achtung: nur per http(s) zugreifen, sonst entsteht Chaos!).

Mittwoch, 5. März 2008
[*]

Subversion mit svn+ssh-Protokoll und Eclipse

, 13:45

Diese Anleitung muß ich für ein paar Kollegen im Moment sowieso schreiben, und vielleicht interessiert das ja noch irgendjemanden. Bevor ich also wieder so ein unkommunikatives Word-Dokument rumschicke:

1. Subclipse

Im Gegensatz zu CVS wird der Nachfolger Subversion von Eclipse (noch?) nicht direkt unterstützt — dabei hat Subversion viele Vorteile (z.B. atomare Transaktionen und Versionierung über Verschiebungen und Umbenennungen hinweg). Zuerst müssen wir das deshalb in Form eines Plugins nachrüsten: Subclipse gibt es bei tigris.org, und eine Installationsanleitung ist auch dort.

So, jetzt kann man in Eclipse die „SVN Repository Exploring perspective“ öffnen und dort die Adresse seines Repositories eintragen.

Add SVN Repository

Auf UNIXoiden Betriebssystemen wie Linux, Solaris und MacOS X kann man den folgenden Schritt überspringen. Dort ist ssh in der Regel installiert, im Pfad und kann als Tunnel gestartet werden ohne Fensterchen aufzumachen.

2. ssh-Tunnel aufbauen

Subversion unterstützt einen Haufen unterschiedlicher Protokolle. Neben dem direkten Dateizugriff auf das Repository und einem eigenen Protokoll für lokale Aufrufe unterstützt es WebDAV über http(s) durch ein Apache-Modul und kann über verschiedene Remote-Shell-Protokoll tunneln. Wenn man die Repositories (so wie wir) auf einem UNIX-Server lagert und keine Lust hat, sich mit dem svnDAV-Apache-Modul und seiner zweiten Benutzerverwaltung herumzuschlagen, dann ist das svn+ssh-Protokoll eine günstige Wahl. Leider kommt Windows ohne ssh-Client (im Repository Explorer sieht man unklare Fehlermeldungen wie „Das Verzeichnis ist nicht da.“), deshalb muß Abhilfe geschaffen werden. mehr…