an dieser Stelle möchte ich vorab dem JVerein-Entwicklungsteam aber auch der Community für diese super Opensource-Software danken.
tl;dr / Management Summary:
Zentrales Subersion-Respository enthält jverein.h2.db. Working-Copy sitzt auf Benutzerordner/jameica/jverein/h2db. Anwender führen Lock-Modify-Write-Workflow aus.
Wir setzen JVerein jetzt seit über einem Jahr ein und die Arbeit damit ist wirklich großartig. Aber genauso lange versuchen wir schon ein stabiles Multiuser-Setup hinzubekommen.
Dieser Post soll den Ansatz per zentralem Subversion-Repository vorstellen und als Erfahrungsbericht dienen. Ich würde mich aber auch sehr freuen, wenn von der Community noch Feedback kommt. Evtl. haben wir bei unseren Überlegungen ja noch etwas Entscheidendes vergessen/übersehen. Falls dieser Ansatz Euch geeignet erscheint, kann man ihn gerne in die Multiuser-Seite im JVerein-Wiki integrieren.
Bezüglich dem Multiuser von JVerein gibt es bekanntlich schon einigen Input:
- http://www.jverein.de/wiki/index.php?title=Multiuser
- http://www.jverein.de/forum/viewtopic.php?f=4&t=1085
Um die darin enthaltenen Vorschläge zum Multiuser-Einsatz(MySQL, Cloud, USB-Stick, etc.) besser bewerten zu können, haben wir bei uns erst mal unsere Anforderungen erfasst:
- Es gibt mehrere Personen, die schreibenden Zugriff benötigen, da die Aufgaben der Mitgliederverwaltung, der Kasse/Schatzmeister auf mehrere Personen verteilt sind.
- Darüber hinaus gibt es mehrere Personen, die Nur-Lese-Zugriff z.B. für umfangreiche Auswertungen benötigen
- Der Zugriff auf die Daten muss personalisiert erfolgen und für einzelne Personen leicht entzogen werden können (Ausrollen eines Master-Passworts sollte vermieden werden).
- Der Zugriff auf die Daten muss aus mehreren Städten in Deutschland (und außerhalb) funktionieren.
- Die Daten müssen mehrmals die Woche verteilt werden, da Änderungen mehrmals die Woche vorgenommen werden.
- Es muss sicher gestellt sein, dass immer nur eine Person zu einem Zeitpunkt schreibenden Zugriff auf die Master-JVerein-Datenbank hat (Lock-Modify-Write-Workflow).
- Es soll einfach möglich sein alte Stände der Datenbank wiederherzustellen. Dabei soll nachvollziehbar sein, welcher Anwender welchen Stand der Datenbank erzeugt hat.
- Die Daten sollen vor allem aus Gründen des Datenschutzes (personenbezogene Daten wie Adressen, Geburtstage, Teilnahme an Veranstaltungen etc) aber auch zum Schutz der Daten des Vereins (Buchführung wird genutzt) nicht irgendwo (Cloud) gespeichert sein, sondern bei einem Hoster mit Serverstandort in Deutschland.
- MySQL: Eine von außen erreichbare MySQL-Datenbank haben wir bei unserem Webhoster, aber:
- Der parallel schreibende Zugriff auf die Datenbank kann nicht (sinnvoll) ausgeschlossen werden. Und wenn eine Software, das in ihrer Architektur nicht vorsieht, halte ich das für keine gute Idee.
- Die Performance gerade bei Mitgliederabfragen (> 600) Datensätze war nicht tragbar.
- Zugriff per SSL wird vom Provider nicht unterstützt ("have_openssl -> DISABLED und have_ssl -> DISABLED").
- Der Aufbau einer verschlüsselten Verbindung ohne SSL (use:encryption) hat die Performance noch weiter in den Keller getrieben.
- Verbindung durch einen VPN-Tunnel, war von der Performance nicht geeignet.
- Eine MySQL-Datenbank bei einem anderen Provider (AWS) würde zwar das Verschlüsselungsproblem lösen, aber vermutlich nicht die Performanzprobleme und sicher nicht das des parallel schreibenden Zugriff.
- DropBox / SharedDrive / Cloud-Lösungen: Parallel schreibender Zugriff kann nicht ausgeschlossen + aus Datenzschutzgesichtspunkten teilweise nicht zu empfehlen.
- Austausch per Email/USB-Sticks: Funktioniert bei Anwendern in unterschiedlichen Städten in Deutschland nicht / Ist für die Anwender zu aufwändig.
- Terminal-Server und Co: Vom Administrationsaufwand vom Verein nicht zu leisten.
Wenn man dann noch auf einen Lock-Modify-Write-Workflow besteht und bedenkt, dass die jverein.h2.db eigentlich wie eine Binärdatei behandelt werden muss, kann man dezentrale VCS (Git, Mecurial, Bazaar) ausschließen, da diese keinen Lock-Mechanismus haben und man mit Mergen nicht weiterkommt haben. Am Ende sind wir also bei Subversion gelandet.
Unser Subversion-Setup sieht wie folgt aus:
- Das Repository liegt bei einem deutschen SVN-Hoster und enthält nur die jverein.h2.db. (Das Repository könnte auch auf einem beliebigen anderen SVN-Server z.B. NAS daheim, bestehender Vereinsserver liegen)
- Die jverein.h2.db erhält die Property svn:needs-lock. Damit kann ein Commit(Hochladen) auf diese Datei nur erfolgen, wenn vorher ein Lock auf die Datei gesetzt wurde. Für den Zeitraum, während dessen ein Anwender den Lock gesetzt hat, kann kein anderer den Lock setzen und damit auch keinen neuen Stand der jverein.h2.db "zwischendrin" hochladen. Dies führt übrigens zumindest unter Mac OSX und Windows auch dazu, dass ohne einen Lock Speichern in JVerein selbst nicht mehr möglich ist. D.h. die Benutzer bekommen auch ein Feedback, dass ohne Lock keine Änderungen durchführen können.
- Bei jedem Anwender wird das Verzeichnis Benutzerordner/jameica/jverein/h2db als Working-Copy eingerichtet und dem zentralen Repository verbunden.
- Als Client kommt SmartSVN zum Einsatz, da es unter Mac OSX und Windows läuft, eine kostenlose Lizenzversion gibt und für uns mit am benutzerfreundlichsten ist. Generell kann man aber auch jeden anderen SVN-Client verwenden, der Locking unterstützt.
- Die Benutzerverwaltung erfolgt durch personalisierte Accounts im SVN-Repository, dort kann man schreibende und Nur-Lese-Zugriffe vergeben. Außerdem kann man einzelnen Benutzer so leicht den Zugriff wieder entziehen und es ist immer nachvollziehbar von welchem Nutzer welcher Stand der Datenbank stammt.
- Wir haben das Subversion schon einige Zeit im Einsatz. Der Speicherplatzverbrauch im Repository und die Upload-/Downloadzeiten halten sich in Grenzen, da das SVN Binär-Diffs erstellt. Damit machen einzelne Commits (Upload) / Updates (Download) nur wenige KB aus, natürlich in Abhängigkeit davon wieviel in der DB geändert wurde.
Für uns stellt diese Setup bisher die Lösung dar, die die meisten unserer Anforderungen (siehe oben) erfüllt. Natürlich sehen wir auch noch einige Nachteile dieser Lösung:
- Die Benutzer müssen den SVN-Workflow und ein extra Programm beherrschen: Diesen Nachteil hat man bei Cloud/Dropbox-Diensten an sich auch. Aber zum einen haben wir dies durch eine umfangreiche Anleitung für SmartSVN unter Mac OSX und Windows gelöst (Bei Interesse einfach melden). Zum anderen hat dieser explizite Workflow den Vorteil, dass eigentlich keine Datenmissstände (halbe Uploads auf denen andere weiterarbeiten, Konflikte) auftreten können.
- Man hat zwei Brüche im Arbeitsworklow: Vor dem Starten von JVerein und nach dem Beenden von JVerein muss man jeweils den SVN-Client bedienen. Dabei muss man beachten, dass man JVerein nicht zu früh startet und man muss das saubere Beenden von JVerein abwarten.
- Man braucht Zugriff auf ein zentrales SVN-Repository auf einem SVN-Server: Wie oben beschrieben kam für uns eine Self-Hosting-Lösung (Vereinsserver, NAS/Server bei Vereinsmitglied daheim) nicht in Frage. Aber neben vielen kostenlosen SVN-Hostern (vor allem in den USA) gibt es auch Hoster mit deutschem Serverstandort, die ein einzelnen Repository für einen kleinen einstelligen Euro-Betrag im Monat anbieten.
- Die jverein.h2.db mit allen Daten (Mitgliederdaten, Buchführung) liegen in einer ungesicherten Datenbank im Netz. Der Zugriff ist nur durch die Zugriffsteuerung des SVN geschützt.
Wie Eingangs beschrieben, soll diese Vorstellung als Inspiration für alle dienen, die ähnliche Anforderungen an ein Multiuser-Setup haben. Aber ich freue mich auch sehr über Feedback oder Fragen, falls die nach diesem langen Beitrag doch noch aufkommen
Viele Grüße
Philipp
