Änderungswünsche, Ergänzungen, Erfahrungen, Diskussionen usw. dazu weiter hier bei diesem Thema schreiben
Hallo,
da ich per PN eine Anfrage zu diesem Themenkomplex bekommen habe will ich in diesem Thread die verschiedenen Möglichkeiten von Datenaustausch, gemeinsamer Datenzugriff und Multiuser-Zugriff mal zusammenfassen und gegenüberstellen, quasi als Versuch einer Referenz dazu. Eure Ergänzungen/Änderungsvorschläge will ich gerne einbauen.
Vorbemerkungen
Jameica, Hibiscus und JVerein sind offiziell nicht multiuserfähig und haben keine ernstzunehmende Benutzerverwaltung (d.h. mehrere Benutzer mit unterschiedlichen Berechtigungen). Alle nachfolgend hier vorgestellten Lösungen für gemeinsamen Datenzugriff setzen also Vertrauen und klare Absprachen/Zuständigkeiten der beteiligten Benutzer untereinander voraus, so dass Datenmissbrauch und inkonsistente Daten (z.B. durch Fehleingaben) ausgeschlossen/vernachlässigt werden können.
Ich setze ferner voraus dass das Thema Datenschutz von allen Beteiligten ernst genommen wird und sämtlicher Datenverkehr mit persönlichen Mitgliederdaten über öffentliche Netze stets geeignet verschlüsselt wird. Wenn ich von Netzwerkzugriff rede dann meine ich damit nicht nur den (unverschlüsselten) Zugriff aus einem LAN sondern schließe auch den geeignet verschlüsselten Fernzugriff über das Internet (z.B. mittels VPN, SSH-Tunnel, SSL) mit ein ohne diese jeweils einzeln zu erwähnen.
Wenn Jameica und JVerein auf mehreren Rechnern installiert werden, so sollten zur Vereinfachung und Fehlerquellenreduktion alle Installationen stets identisch sein, d.h. es sind insbesondere die gleichen Pfade/Ordner zu verwenden (z.B. C:\Vereinsname\Jameica für die Programme und C:\Vereinsname\Jameica-Daten als Datenordner) und die Plugins müssen auch überall am selben Ort (an Besten immer in den Datenordner) installiert werden.
1. Datenaustausch
Darunter verstehe ich dass z.B. unter Vorstandsmitgliedern die Daten weitergegeben werden.
1.1 Listenweitergabe
In dieser Variante benutzt nur einer JVerein und er stattet die anderen regelmäßig mit den Listen aus JVerein aus (z.B. Adressliste, Jubilarliste usw.).
Vorteile: sehr einfach und den Empfängern der Listen gibt man nicht mehr Informationen als sie auch bekommen sollen.
Nachteile: Listen sind nicht immer aktuell und viele JVerein-Features wie bspw. die Suche oder der Mailversand stehen nicht zur Verfügung.
1.2 Datenweitergabe
Hier haben alle Benutzer, die Daten benötigen, JVerein auf ihren Rechnern installiert und haben so den vollen Zugriff auf alle Daten und Funktionen. Alternativ kann auch die Portable-Version von Jameica+JVerein eingesetzt werden, damit muss auf den Benutzer-Rechnern nichts besonderes installiert werden.
Vorteile: Aktuelle Daten und alle Funktionen für alle.
Nachteile: Die regelmäßige Datenweitergabe kann lästig werden.
1.2.1 Mit Schreibrecht für alle
Nach jeder Änderung müssen die Daten an alle anderen Benutzer weitergegeben werden. Dazu eignet sich das manuelle Kopieren des Datenordners auf einen USB-Stick, bequemer dürfte aber der Versand per E-Mail sein.
Die Verwendung der JVerein-Funktion "Diagnose-Backup" eignet sich hier nicht weil der Import eine leere Datenbank voraussetzt, die nach dem ersten Import aber nicht mehr leer ist. Wo man den Datenordner standardmäßig findet, ist in den FAQ nachzulesen.
1.2.2 Ohne Schreibrecht für alle
Änderungen an den Daten dürfen per Definition nur von einem Verantwortlichen vorgenommen werden, er hat die 'Master'-Kopie der Daten. Alle anderen Benutzen erhalten von ihm zwar regelmäßig eine Kopie der Daten wie in 1.2.1, jede bleibende Änderung muss aber vom Verantwortlichen selber getätigt werden, die anderen Benutzer müssen Änderungswünsche an den Daten ggf. bei ihm einreichen. (siehe auch 3.1)
2. Gemeinsamer Datenzugriff
Hierbei haben alle Benutzer stets den vollen Zugriff auf den aktuellen Datenstand. Da Jameica und JVerein jedoch keinen gleichzeitigen Multiuser-Zugriff unterstützen, sind geeignete Absprachen oder technische Vorkehrungen für eine Nutzung nur nacheinander zu treffen (siehe dazu 3.1).
2.1 MySQL
In einem Netzwerk kann anstelle der sonst verwendeten H2-Datenbank ein zentraler MySQL-Datenbankservers genutzt werden. Jameica und JVerein werden auf allen Rechnern der Benutzer lokal (empfehlenswert bei Fernzugriff) oder auf einem Netzwerk-Share (besser bei LAN-Zugriff) entsprechend konfiguriert installiert. Mit MySQL können auch reine Nur-Lese-Zugriffe realisiert werden (siehe 3.1.2).
Vorteile: Bequemer Datenzugriff, auch anderweitig (insbesondere mit ODBC usw.), theoretisch Multiuser-Zugriff (wird offiziell aber nicht unterstützt).
Nachteile: MySQL-Server nötig, ein etwas besseres NAS (z.B. von QNAP oder Synology) genügt aber oft schon.
Hinweis: Eine MySQL-Datenbank aus dem Webhostingpaket ist i.d.R. ungeeignet da der Datenbankserver bei vielen Hostern von außen gar nicht direkt erreichbar ist (z.B. 1&1) oder falls doch kaum SSL-verschlüsselt sein dürfte. Eine Lösung für Amazon RDS mit Verschlüsselung beschreibt Stephan hier: http://www.onlinebanking-forum.de/forum ... #real99452
Mehr Infos zur Einrichtung einer MySQL-Datenbank gibt es im Wiki: http://www.jverein.de/wiki/index.php?ti ... QL-Support
2.2 Cloud-Computing
Bei einem Cloud-Anbieter der Wahl wird ein Konto (oder Space) eingerichtet, das dann von allen Benutzern verwendet wird. Ich verwende TeamDrive wegen der eingebauten Verschlüsselung schon vor der Übertragung und bin zufrieden damit, bei Cloud-Anbietern ohne solche Verschlüsselung kann man z.B. mit TrueCrypt zunächst lokal dafür sorgen.
Auf allen Rechnern der Benutzer müssen stets dieselben Ordner verwendet werden (z.B. C:\Vereinsname) und als lokaler Ordner zum Cloudspeicher eingerichtet werden. Jameica und JVerein zusammen mit den Daten am besten komplett dorthin installieren, dann liegt bereits eine so zentrale Speicherung vor dass Updates nur einmal eingespielt werden müssen.
Vorteile: günstig und recht einfach aufzusetzen
Nachteile: Setzt hinreichendes Vertrauen in Cloud-Anbieter voraus und kann Geld kosten falls man mit den kostenlosen Angeboten nicht auskommt.
Wichtiger Hinweis: Nachdem man den Cloud-Dienst-Clienten gestartet hat (bzw. nachdem man seinen Rechner eingeschaltet hat, falls dieser Dienst automatisch gestartet wird) muss man mit dem Start von Jameica+JVerein so lange abwarten bis der Cloud-Dienst-Client die lokal gespeicherten Daten gegen die in der Cloud gespeicherten vollständig abgeglichen hat. Werden Jameica+JVerein zu früh gestartet so sind einige lokale Dateien dadurch in Bearbeitung und werden zunächst nicht sondern erst später abgeglichen. Ebenso ist stets darauf zu achten, den Cloud-Dienst-Clienten erst zu beenden (oder den Rechner auszuschalten) nachdem alle neu geänderten Dateien auch vollständig in die Cloud übertragen wurden. Als Folge von Nichtbeachtung können Versionskonflike auftreten, die schlimmstenfalls eine inkonsistente Datenbank (d.h. verloren gegangene Änderungen) bedeuten können. Eine gewisse Disziplin ist hier also von Nöten.
Weitere Infos und Erfahrungsberichte zum Cloud-Computing mit JVerein gibt es hier im Forum (Suchbegriffe: z.B. Dropbox oder multiuser)
2.2.1 Mit Schreibrecht für alle
Das ist der Standard beim Speichern in der Cloud, alle Benutzer arbeiten mit Live-Daten und können sie auch ändern.
2.2.2 Ohne Schreibrecht für alle
Analog zu 1.2.2 führt nur eine Verantwortlicher Änderungen an den Daten durch. Der Verantwortliche hat dazu zwei Datenordner auf seinem Rechner: die 'Master'-Kopie der Daten, die nicht in der Cloud gespeichrt sein muss (aber kann), und die Benutzer-Kopie, die in der Cloud liegt. Nach jeder Änderung durch den Verantwortlichen kopiert dieser die Daten von seiner 'Master'-Kopie in die Benutzer-Kopie in der Cloud. (siehe auch 3.1)
2.3 Terminal-Server und Verwandte
Hat man die Möglichkeit einen (Windows) Terminal-Server zu nutzen (oder XTerminals bei Linux), so arbeiten alle Benutzer auf dem selben Rechner, mit zentral gespeicherten Daten und Programmen. Es ist nur eine Jameica und JVerein-Installation nötig, die allerdings nicht in einem Benutzerordner sondern in für alle zugänglichen Ordnern sein muss.
Vorteile: zentral administrierbar und kann die komplette Arbeitsumgebung (d.h. auch Office-Anwendungen) enthalten.
Nachteile: kräftiger Server, Betrieb und ggf. Lizenzen sowie ein guter Sysadmin nötig, damit wohl recht teuer und eher nur etwas für die Profiliga. Man kann einen Terminal-Server aber auch mieten....
2.3.1 Terminal-Server "light"
Man nehme einen gewöhnlichen Windows-PC, aktiviere dort den Remotedesktop und schalte den Benutzerwechsel ab.
Vorteile: Einfacher und günstiger (es wird nur ein PC und eine Lizenz benötigt) als ein echter Terminal-Server bei sonst gleichen Vorteilen
Nachteile: Eine Single-User-Lösung, aber für Jameica+JVerein ja genau richtig.
3. Strategien und technische Lösungen für so etwas wie einen Multiuser-Zugriff
3.1 Lese- und Schreibrecht
Benutzer mit unterschiedlichen Rechten unterstützen Jameica und JVereien nicht. Damit ist es auch nicht möglich Teilberechtigungen abzubilden (bspw. einzelnen Benutzern die Anzeige der Buchungen vorenthalten).
3.1.1 Mit der H2-Datenbank
Mit dem Rezept aus 1.2.2 und 2.2.2 lassen sich zwei Benutzergruppen realisieren: die einen haben Schreibrechte und arbeiten auf einer 'Master'-Kopie der Daten, die Benutzer der zweiten Gruppe arbeiten mit einer Benutzer-Kopie der Daten.
Nach jeder Änderung an der Master-Kopie der Daten wird die Benutzerkopie anschließend überschrieben, damit sind Änderungen, die die Benutzer der zweiten Gruppe eventuell gemacht haben stets flüchtig und de facto ist es damit ein reiner Lese-Zugriff. Änderungen an den Daten müssen den Benutzern der ersten Gruppe "zugerufen" werden damit diese sie in die Master-Kopie der Daten eintragen können.
Vorteile: immerhin so etwas ein kleine Benutzerverwaltung
Nachteile: Die Daten der Benutzerkopie können durch Änderungen der zweiten Benutzergruppe verfälscht werden (bis sie das nächste mal durch die Master-Kopie überschrieben werden) und die ständige Kopiererei von Master- auf Benutzer-Kopie der Daten ist lästig und kann auch mal vergessen werden.
3.1.2 Mit einer MySQL-Datenbank
Wird eine MySQL-Datenbank verwendet, dann kann man einen separaten MySQL-Benutzer anlegen und diesem nur Leserechte geben. Bei den Jameica+JVerein-Installation von Benutzern, die nur Lesen können sollen, muss dann dieser entsprechend beschränkte MySQL-Benutzer verwendet werden. [Danke dl7bmg für diesen Hinweis]
Sofern zeitgleich maximal ein (MySQL-)Benutzer mit Schreibrechten zugreift, sehe ich keinen Hinderungsgrund warum nicht weitere Benutzer mit Nur-Lese-Rechten gleichzeitig zugreifen können sollten. Denkbar wäre auch -mit ähnlicher Methode wie in 3.2- beim ersten Benutzer Jameica mit einer Konfiguration mit Schreibrecht in der MySQL-Datenbank zu starten und (solange der erste Benutzer online ist) alle folgenden Benutzer mit einer Nur-Lese-Konfiguration zu starten. Beides ist aber weder offiziell unterstützt noch von mir getestet, vielleicht postet hier aber jemand mal seine Erfahrungen dazu.
3.2 Der Nacheinander-MultiUser-Zugriff
Denkbar ist es zwar die Nutzung von Jameica+JVerein beim gemeinsamen Datezugriff (siehe 2.) durch Absprachen so zu festzulegen dass stets maximal ein Benutzer Jameica+JVerein geöffnet hat (z.B. Person A nutzt nur tagsüber, Person B darf nur abends ran), das ist aber sowohl fehleranfällig als auch unflexibel.
Eine technische Lösung ist folgende: Jameica wird mittels eines Batch (Windows, bzw. Shell-Script unter Linux & Co.) gestartet. Dieser Batch legt ein "Lockfile" an, startet Jameica und löscht das Lockfile anschließend wieder. Sollte jedoch das Lockfile existieren, so ist Jameica von einem anderen Benutzer bereits gestartet und es soll ein entsprechender Hinweis ausgegeben werden.
Vorteile: Simple Lösung um eine SingleUser-Nutzung in einer beliebigen MultiUser-Umgebung (einschließlich CloudComputing) sicherzustellen.
Nachteile: Durch (unbeabsichtigten) Batch-Abbruch oder einen Systemabsturz kann das Lockfile bestehen bleiben obwohl tatsächlich keiner (mehr) Jameica+JVerein nutzt. Nach einer kleinen Rückfrage beim Mitbenutzer kann das Lockfile ggf. händisch gelöscht werden und alles läuft wieder.
Beispiel für so einen Batch (ein entsprechendes Shell-Skript für Linux & Co. kann ganz ähnlich programmiert werden):
Code: Alles auswählen
@echo off
rem Nachfolgende drei set-Zeilen bitte anpassen
rem JAMEICA_DATADIR muss angegeben werden, selbst wenn der Standard-Pfad verwendet wird
rem JAMEICA_3264 muss -je nach eigener Umgebung- auf 32 oder 64 eingestellt werden
set JAMEICA_PROGDIR=C:\Vereinsname\Jameica
set JAMEICA_DATADIR=C:\Vereinsname\Jameica.data
set JAMEICA_3264=64
rem Ab hier keine Änderungen mehr nötig
set JAMEICA_BIN=jameica-win32.exe
set JAMEICA_JAR=jameica-win32.jar
if %JAMEICA_3264%==64 (
set JAMEICA_BIN=jameica-win64.exe
set JAMEICA_JAR=jameica-win64.jar
)
set LOCKFILE_MY="%JAMEICA_DATADIR%\my.lock"
rem Prüfen ob Lockfile exitiert
if exist %LOCKFILE_MY% goto jameica_in_use
goto jameica_start
:jameica_start
echo **********
echo * Jameica wird gestartet
echo **********
echo * ACHTUNG:
echo * Dieses Fenster NICHT schließen, es wird
echo * automatisch geschlossen sobald Jameica
echo * beendet wurde.
echo **********
echo %USERNAME%@%COMPUTERNAME% > %LOCKFILE_MY%
rem Jameica nicht mit der Starter-EXE aufrufen sondern mit javaw das JAR-Archiv aufrufen
rem da sonst der Batch gleich weiterläuft und nicht wartet bis Jameica beendet wurde.
javaw -jar "%JAMEICA_PROGDIR%\%JAMEICA_JAR%" -f "%JAMEICA_DATADIR%"
del %LOCKFILE_MY%
goto ende
:jameica_in_use
set /p %JAMEICA_USER%=<%LOCKFILE_MY%
echo **********
echo * Jameica wird gerade benutzt von
echo * %JAMEICA_USER%
echo **********
echo * Jameica kann erst gestartet
echo * werden wenn obiger Benutzer das
echo * Programm beendet hat.
echo **********
pause
goto ende
:ende
Da bist du meine Rettung 
