Mit etwas Verspätung (hauptsächlich dem Oneiric-Release geschuldet) bringe ich nun hiermit den letzten Teil meiner SparkleShare-Serie auf den Weg:
Zusätzlich zum eigentlichen Thema möchte ich am Ende des Artikels außerdem mein Fazit zu SparkleShare und der Serie ziehen…
Wie ihr in den vergangenen Artikeln ja schon erfahren habt, synchronisiert SparkleShare die Dateien nicht auf einen speziellen SparkleShare-Server, sondern auf ein gewöhnliches GIT-Repository.
Demnach kann man für den Browser-Zugriff auf das Repository natürlich auch jedes beliebige Produkt verwenden, das diese Funktionalität für GIT-Repositories bietet (z.B. ein in Perl entwickeltes GitWeb oder ein unter PHP lauffähiges git-php). In diesem Artikel möchte ich allerdings die Basis-Installation von ViewGit beschreiben.
ViewGit installieren und konfigurieren
Wie auf der Webseite des ViewGit-Projektes zu sehen, wird für den Einsatz der Software lediglich PHP5, Apache (mit dem Modul mod_rewrite) und natürlich GIT verausgesetzt.
Die Installation ist dementsprechend einfach und schnell erledigt:
Zunächst der Download: von der Projektseite wird man über den Download-Link auf die Sourceforge-Seite des Projektes verwiesen. Dort sucht man sich dann die aktuellste Version und lädt das .tar.gz-Paket, am besten direkt auf den Server, herunter.
Entpackt man nun dieses Paket ins httpdocs-Verzeichnis des Apache-Servers erhält man ein Unterverzeichnis viewgit.
Dort hinein wechselt man nun und führt erst einmal die folgenden grundlegenden Befehle aus:
cp doc/example-htaccess .htaccess
cp inc/example-localconfig.php inc/localconfig.php
Der erste Befehl erstellt die Datei .htaccess aus einer Beispieldatei. Diese enthält ein paar Angaben bzgl. PHP und dem mod_rewrite. Der zweite Befehl kopiert eine Beispiel-Konfigurationsdatei auf den Namen der tatsächlich verwendeten Konfigurationsdatei um. Diese Konfigurationsdatei (inc/localconfig.php) muss nun noch an die Gegebenheiten des eigenen Servers angepasst werden.
Öffnet nun also die Datei inc/localconfig.php im Editor. Ihr findet darin folgenden Block:
$conf['projects'] = array(
'foo' => array('repo' => '/home/user/projects/foo/.git'),
'bar' => array(
'repo' => '/home/user/projects/foo/.git',
'description' => 'Optional overridden description, otherwise it is taken from .git/description'
),
);
Ersetzt diesen Block durch einen solchen Block:
$conf['projects'] = array(
'meinrep' => array('repo' => '/var/sparkleshare/meinrep.git'),
);
Die Repository-Übersicht in ViewGit
Das definiert ein Repository namens meinrep, dessen Repository-Verzeichnis unter /var/sparkleshare/meinrep.git zu finden ist (den Pfad habe ich aus meinem Artikel zur Server-Konfiguration übernommen; ihr müsst ihn natürlich an eure Konfiguration anpassen).
Das war es schon! Nun kann man das ViewGit-Interface im Browser aufrufen und in eurem Repository browsen.
Ganz wichtig: denkt daran, das Interface bei Bedarf mit einem Kennwort zu versehen (Stichwort: htaccess/htpasswd) , damit nicht jeder auf eure Dateien zugreifen kann!
Der Haken mit der Verschlüsselung…
Einen Haken gibt es da (zumindest habe ich dafür bisher keine Lösung gefunden): wer sein Repository verschlüsselt hat, der kann ViewGit leider nur zum Browsen im Verzeichnisbaum benutzen.
Tree-Anzeige des Repository-Inhalts
Denn wenn man per ViewGit eine Datei aus dem verschlüsselten Repository herunterlädt (im rechts gezeigten Bild würde man dazu z.B. auf den blob-Link in der Downloadspalte klicken), dann wird diese nicht automatisch entschlüsselt. Somit müsste man jederzeit seinen Schlüssel dabei haben – inkl. GnuPG zur Entschlüsselung – und die Datei nach dem Herunterladen manuell entschlüsseln.
Auch kann man nicht einfach über das Webinterface in eine verschlüsselte Textdatei sehen. Per Klick auf den Dateinamen bekommt man natürlich auch nur den Inhalt in verschlüsselter Form zu sehen.
Man muss sich also leider entscheiden. Zwischen verschlüsseltem Repository und “wenig Webinterface” einerseits und unverschlüsseltem Repository und “viel Webinterface”.
Fazit zu Sparkleshare
Nachdem ich mich nun im Zuge meiner Blog-Artikel eine Zeit lang mit SparkleShare beschäftigt habe, möchte ich nun zum Schluss der Serie ein kleines Fazit dazu ziehen – auch in Bezug auf die geposteten Leser-Kommentare:
- Dass man einerseits eine automatische Datei-Synchronisation bekommt und andererseits alles selbst unter Kontrolle hat finde ich nach wie vor sehr reizvoll.
- Was mir am “Prinzip SparkleShare” extrem gut gefällt ist, dass die Server-Seite in kürzester Zeit und mit minimalem Aufwand eingerichtet werden kann. Auch sind die Anforderungen an den Server angenehm überschaubar.
- Ganz klar für SparkleShare spricht die Tatsache, dass man seine Daten eben nicht irgendwo hin aus der Hand gibt, sondern auf dem eigenen Server speichert. Auch die offene Möglichkeit der Verschlüsselung ist nett.
- Wie “dAnjou” richtigerweise zu meinem ersten Artikel geschrieben hat, ist SparkleShare für große, sich oft ändernde Datenmengen eher ungeeignet. Der Grund dafür ist, dass GIT ein Versionskontrollsystem ist, das jede Änderung einer Datei protokolliert. Somit wird mit jeder Dateiänderung immer mehr Speicherplatz “verbraten”, obwohl die Datei selbst vielleicht gar nicht größer geworden ist.
- Eine Besserung wäre dann in Sicht, wenn sich der SparkleShare-Client in Zukunft z.B. auch mit einem WebDav-Server unterhalten könnte. Als Alternative werde ich noch versuchen, automatisch alte Versionen aus dem Repository entfernen zu lassen. Sobald ich hierzu etwas “handfestes” haben sollte, werde ich euch das natürlich nicht vorenthalten und einen Artikel dazu schreiben.
- SparkleShare scheint also seine Stärken in eher kleineren Dateien zu haben – ich denke da an Konfigurationsdateien oder den eigenen Shellscripts, Dokumente o.ä. In diesem Fall ist die Verwendung von GIT ggfs. sogar von Vorteil. Denn, wie gesagt, ist jede Version rekonstruierbar.
- “Freundhansen” hatte Bedenken geäußert, dass SparkleShare vielleicht nur “eine weitere OpenSource Krücke” sein könnte. Das wird man natürlich abwarten müssen. Meine Hoffnung ist natürlich, dass sich noch einiges in der Entwicklung tun wird. Aber: who knows?! Trotzdem kann ich dem Programm in der jetzigen Version auch schon vieles abgewinnen – warum sollte man es also nicht probieren?
- Auch wurden ein paar Alternativen von den Kommentatoren genannt, z.B. rsync (“Platz da, hier komm ich”) oder OwnCloud (“Poapfel”). Beides sicher auch wirklich gute Alternativen. Wobei mir bei OwnCloud im Vergleich zu SparkleShare die automatische Synchronisation fehlt.
- “Georg” hat schließlich zum vorigen Artikel einen interessanten Kommentar beigetragen. Dabei hat er auf diesen Blog-Beitrag verwiesen, in dem eine andere Art und Weise der Verschlüsselung beschrieben ist. Das sieht mir sehr interessant aus – ich werde mir mal die Zeit nehmen müssen, um es mal selbst auszuprobieren.
Letztendlich komme ich auf positives Endergebnis und für mich zu dem Schluss, dass ich SparkleShare vermutlich für die bisher in Ubuntu One synchronisierten Dateien (eher geringes Volumen) verwenden werde – in der Hoffnung, dass das Produkt fleißig weiterentwickelt wird (übrigens ist in den letzten Tagen ein Android-Client veröffentlicht worden)…
pssst, weitersagen!
Dieses HowTo ist eine Step-by-Step Anleitung um 
Über meinen 
Seit einiger Zeit funktionierte das Öffnen von Links aus Thunderbird nicht mehr. In der Datei prefs.js (Profilordner) war alles richtig eingetragen. Mit ein bisschen Suche wurde ich dann noch in der Datei mimeTypes.rdf (Profilordner) mehrfach fündig. Dort die Aufruf-Pfade für Firefox korrigiert und schon werden die Links wieder brav geöffnet.
