Sparkleshare – Dateien synchron halten, aber sicher!

Dropbox ist toll: auf vielen Systemen unterstützt, einfach zu benutzen, bis zu einem gewissen Volumen kostenlos und irrsinnig zuverlässig.

Aber man vertraut seine Dateien eben doch fremden Leuten an (mit den üblichen Implikationen), und dass die Größe geteilter Ordner jedem Teilnehmer einzeln vom Konto abgezogen wird, ist zumindest schwierig zu verstehen. Google Drive ist ungefähr dasselbe in blau-rot-gelb-blau-grün-rot.

An dieser Stelle tritt Sparkleshare auf den Plan. Damit kann man Ordner über mehrere Rechner (Windows, Mac und Desktop Linux sind im Moment unterstützt) und mit mehreren Personen synchron halten, ohne die Daten bei irgendeiner fremden Firma herumliegen haben zu müssen. Als Speicher fungiert die verteilte Versionsverwaltung git.

Ich will hier mal kurz vorführen, wie man sich das, sofern man einen Rootserver (oder virtuellen Server) mit ssh-Zugang hat, autark aufsetzen kann.

Erst installieren wir mal den Client. Ich nehme hier die Windows-Installation als Beispiel, denn sie hat ein  paar Fallstricke, die Mac-Installation bekommt wirklich jeder Mac-Benutzer auf die Reihe, und die Linux-Benutzer wissen sich sowieso zu helfen ;-).

Client-Installation

Der Installationsprozess beginnt normal mit Runterladen und Weiter,Weiter,Weiter:

Wenn man das schöne neue Programm dann aber starten will, dann wird man eventuell von dieser hässlichen Fehlermeldung aufgehalten:

Das überraschend fehlende Framework kann von Microsoft hier heruntergeladen werden. Nach der Installation geht es damit weiter, Sparkleshare zu erzählen, wer wir sind (dient nur der Identifikation auf unserem eigenen Server), und wo die geteilten Ordner auf dem Client liegen sollen:

 

So, jetzt brauchen wir erstmal einen Server.

Server-Installation

Als git-Server benutzen wir gitolite, dessen Installation hier genauer erläutert wird. Unser Beispielserver läuft mit Debian squeeze. Der Server muss von außen per ssh erreichbar sein (openssh), git muss vorher installiert sein, und außerdem wird noch Perl benötigt (alles eventuell mit apt, yum oder dem Lieblingspaketmanager nachinstallieren, Versionen bitte der aktuellen Installationsanleitung entnehmen).

Zuerst brauchen wir einen ssh-Schlüssel für den Administrator. Der sollte als root oder mit dem eigenen Useraccount erzeugt werden (in diesem älteren Artikel habe ich das schon einmal beschrieben, auch die sicherheitsrelevante Überlegung, ob der Schlüssel eine Passphrase haben sollte oder nicht):

host:~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
41:4a:bf:0f:1d:1d:cd:33:c7:e1:a8:e3:ba:e8:34:6e root@host
The key's randomart image is:
+--[ RSA 2048]----+
|      . .   .o o.|
|     . +   . .B o|
|      . o . .. = |
|         + ..    |
|        S .o     |
|         o. .    |
|       o  ..     |
|      oEo .      |
|      o+ o.      |
+-----------------+
host:~#

Jetzt erzeugen wir, wenn es den noch nicht gibt, einen (Pseudo-)Benutzer git und holen die Gitolite-Software. Als root:

host:~# adduser --system --group --home /var/lib/git --shell /bin/bash --disabled-password git
Adding system user `git' (UID 113) ...
Adding new group `git' (GID 115) ...
Adding new user `git' (UID 113) with group `git' ...
Creating home directory `/var/lib/git' ...
host:~# cd ~git
host:/var/lib/git# git clone git://github.com/sitaramc/gitolite
Cloning into gitolite...
remote: Counting objects: 8349, done.
remote: Compressing objects: 100% (2901/2901), done.
remote: Total 8349 (delta 5741), reused 7878 (delta 5325)
Receiving objects: 100% (8349/8349), 2.53 MiB | 1.09 MiB/s, done.
Resolving deltas: 100% (5741/5741), done.
host:/var/lib/git# mkdir bin
host:/var/lib/git# gitolite/install -ln ~git/bin
host:/var/lib/git#

Jetzt brauchen wir den vorhin erzeugten ssh-Schlüssel. Den erklären wir zum Meister der git-Repositories:

host:/var/lib/git# cp ~/.ssh/id_rsa.pub root.pub
host:/var/lib/git# chown -R git:git .
host:/var/lib/git# su - git
git@host:~$ bin/gitolite setup -pk root.pub 
Initialized empty Git repository in /var/lib/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /var/lib/git/repositories/testing.git/
WARNING: /var/lib/git/.ssh missing; creating a new one
WARNING: /var/lib/git/.ssh/authorized_keys missing; creating a new one
git@host:~$ exit
logout
host:/var/lib/git#

Server-Konfiguration

Jetzt folgen ein paar Schritte, bei denen unpraktischerweise Dateien vom Client zum Server bewegt werden müssen, ohne dass uns Sparkleshare bisher dabei helfen würde.

Gitolite speichert seine Konfiguration in einem speziellen Repository, dass mit entsprechenden Hooks versehen ist (die Älteren unter uns werden sich an das magische CVSROOT-Verzeichnis erinnert fühlen).
Als der Benutzer, dessen ssh-Schlüssel wir gerade zum Admin erklärt haben:

host:/var/lib/git# cd
host:~# git clone git@localhost:gitolite-admin
Cloning into gitolite-admin...
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 86:79:81:9d:93:9a:57:6b:36:e4:d0:62:be:10:81:46.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
host:~# ls -Rl gitolite-admin
gitolite-admin:   
total 8
drwxr-xr-x 2 root root 4096 Jun 23 17:11 conf
drwxr-xr-x 2 root root 4096 Jun 23 17:11 keydir

gitolite-admin/conf:
total 4
-rw-r--r-- 1 root root 76 Jun 23 17:11 gitolite.conf

gitolite-admin/keydir:
total 4
-rw-r--r-- 1 root root 390 Jun 23 17:11 root.pub
host:~#

In der Datei gitolite.conf sind die existierenden git-Repositories konfiguriert. Um nicht jedes Sparkleshare-Verzeichnis umständlich konfigurieren zu müssen, bauen wir dort einen Trick ein:

repo gitolite-admin
    RW+     =   root

repo testing
    RW+     =   @all

repo sparkleshare/CREATOR/..*
    C   =   @all
    RW+ =   CREATOR

Diese sogenannten Wildrepos entstehen automatisch, wenn man sie clone-t, sie sind deshalb ideal für unsere Zwecke geeignet (mehr dazu gleich).

Client und Server verbinden

Um dem Client Rechte und einen lokalen Benutzernamen zu geben, nehmen wir den praktischerweise von Sparkleshare für uns erzeugten Schlüssel,…

…bewegen ihn irgendwie auf den Server (ftp, scp,…) und kopieren ihn in das keydir unserer gitolite-config. Dabei nennen wir ihn [BENUTZERNAME].pub. Jetzt schicken wir die Änderungen an den git-Server:

host:~/gitolite-admin# git add .
host:~/gitolite-admin# git commit -m "Sparkleshare-Init"
[master 0663ee9] Sparkleshare-Init
 3 files changed, 14 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf~
 create mode 100644 keydir/dentaku.pub
host:~/gitolite-admin# git push
Counting objects: 10, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 842 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
To git@localhost:gitolite-admin
   82c2d97..0663ee9  master -> master
host:~/gitolite-admin#

Jetzt können wir (wegen der Wildrepos) ohne weiteren Konfigurationsaufwand unterhalb von git@host:sparkleshare/BENUTZERNAME/ beliebige Verzeichnisse als Projekt benutzen:

Fertig. Über die Verteilung zwischen mehreren Rechnern und das Teilen von Ordnern mit anderen Leuten schreibe ich demnächst noch einen weiteren Artikel.

Abschließende Bemerkungen

Gegenüber den Standard-Clouddiensten hat dieser Ansatz natürlich einige Nachteile:

• Die Administration ist deutlich komplexer als bei Dropbox oder Google — jedenfalls wenn man seinen eigenen Server aufsetzt.
• Um Dateien vom Arbeitsplatz auszulagern ist Sparkleshare in der Standardkonfiguration komplett ungeeignet, weil git die vollständige Historie aller Dateien in den Metadaten der Arbeitskopie speichert (auf dem Server braucht man dementsprechend auch genug Platz). Eine Unterstützung anderer Backends ist aber angedacht.
• Daraus folgt, dass derjenige, dem eine Arbeitskopie in die Hände fällt, auch jede gelöschte Datei wieder herstellen kann — selbst wenn man ihn auf dem Server aussperrt. Laufwerksvollverschlüsselung ist in diesen Szenarien immer eine gute Idee.
• Backups für den Server muss man selbst organisieren (hier ist aber git wieder von Vorteil, weil man die Historie auch aus jeder Arbeitskopie wiederherstellen kann).
• Eine mobile Applikation oder eine Einbindung in solche (wie z.B. die 1Password-Synchronisation mit Dropbox) gibt es bisher nicht.
• Kommunikation zum Server über ssh klappt nicht in allen abgeschotteten Firmen- und Hotelnetzen.

Dem stehen aber folgende Vorteile gegenüber:

• Sichere, verschlüsselte Kommunikation. Niemand kann in die Daten gucken.
• Beliebig viele Verzeichnisse können mit beliebig vielen Leuten geteilt werden, ohne dass jeder getrennt für den Platz bezahlen muss.
• Verschiedene Verzeichnisse können dabei auf verschiedene Server verteilt werden (github und gitosis bieten Speicherplatz für öffentliche Daten).
• Wer mutig ist, der kann auch das gitolite-admin-Projekt als Sparkleshare-Ordner auschecken und erhält dann eine verhältnismäßig einfache Konfigurationsmöglichkeit.