Wer einen im Internet verfuegbaren Fileserver braucht, verwendet Dropbox… besser nicht 😉 Es gibt einige gute Argumente, warum niemand bei einem Fileserver auf die Dienste von Dritten setzen sollte. Der wichtigste wohl: Potenziell sensible Daten haben auf fremder Leute Servern nichts zu suchen. Mag der Anbieter auch noch so vertrauenswuerdig erscheinen. Es waere nicht das erste Mal, dass Uebelwichte irgendeinen Kunden- oder Mitarbeiter-Account hacken und sich dann Zugriff auf die Daten anderer verschaffen.
einzelne Verzeichnisse lassen sich mit eigenen Passwort verschluesseln
Das Gegenmittel der Wahl ist weitgehend OwnCloud. Eine auf PHP basierende Loesung zum eigenen Hosten von Dateien, Kontakten, Kalendern. Wer schon einen LAMP-Server hat, kann sich mit OwnCloud schnell sein eigenes System hochziehen. Neuerdings sogar mit so feinen Features, dass sich mehrere Server miteinander verbinden lassen… Einziger Nachteil von Owncloud: Wird der eigene Server mal gehackt, ist die Vertraulichkeit der gespeicherten Daten auch wieder pfutsch. Dagegen hilft teilweise zwar die von OC angebotene Verschluesselung auf dem Server. Das hat aber auch so seine Tuecken und Nachteile. Auf alle einzugehen, wuerde hier den Rahmen sprengen. Der wichtigste aber sei genannt: Alle Accounts verwenden den gleichen Schluessel! Ist einer gehakt, sind es alle. Was tun?
Mit Seafile gibt es eine Alternative fuer den eigenen Fileserver. Die Software beschraenkt sich zwar ausschliesslich auf diese Funktionalitaet. Wer aber nicht die Eierlegende-Woll-Milch-Sau braucht, fuer den ist Seafile sicher die bessere Loesung. Denn fuer jedes einzelne Verzeichnis kann jeder Account-Inhaber ein eigenes Passwort vergeben! Okay, das kann OC fuer einzelne Freigaben auch. Aber eben nur ein Passwort fuer den Zugriff vergeben. Den direkte Zugriff fuer Systemadministratoren und/oder Uebelwichte auf dem Server kann das aber nicht verhindern. Das schafft nur die Verschluesselung, welche Seafile bietet. Noch sicherer geht nun wirklich kaum noch.
Klar, kann theoretisch ein Angreifer sich auf dem Server auch wieder eines Proxys bedienen und die Entschluesselung abfangen. Muss das im Zweifel dann aber fuer jede einzelne Datei tun. Und der eventuell von staatlichen Datendieben verpflichtete Hoster ist in dem Fall kein unfreiwilliger Helfer mehr, denn er kann zwar zur Freigabe des Zugriffs auf die Daten gezwungen werden, nicht aber zum Hacken der Software seines Hosting-Kunden. Im Zweifel uebersteigt das naemlich die fachliche Kompetenz des Hosters 😉 Nah und wer sein eigener Hoster ist, muss solch hinterhaeltiges Ansinnen eh nicht fuerchten. Aber es kommt noch besser: Seafile sendet/empfaengt immer nur die verschluesselten Daten. Damit muss sich ein Angreifer also zusaetzlich Zugriff auf jeden einzelnen Client verschaffen und im Extrem fuer jedes einzelne Verzeichnis das Passwort knacken.
Zumindest gefuehlt ist Seafile auch einiges performanter als OwnCloud und kommt mit wirklich grossen Dateien viel besser klar. Selber habe ich es nicht getestet, weil es schon gefuehlt sehr eindeutig war. Aber unter https://www.ionas-server.com/blog/owncloud-vs-seafile-performance/ hat sich mal jemand die Muehe gemacht, wobei ich natuerlich nichts zur Korrektheit der Messung sagen kann. Aber es deckt sich mit meinen Beobachtungen. Diesen Vorteil erkauft man sich allerdings auch damit, dass Seafile ein eigenes Binar-Format zum Speichern verwendet und beim Einrichten etwas aufwaendiger ist. Wenn Daten aber ohnehin gesichert auf dem Server abgelegt werden sollen, dann ist es auch voellig schnuppe, ob das nun in einem eigenen Format passiert oder nicht. Seafile ist OpenSource. Wer dem Format nicht traut, kann es selber checken. Aber in einer gesicherten Umgebung hat der Hostmaster eh keinen Einblick in die Daten. Oder sollte es zumindest nicht haben. Bei Inkonsistenzen hilft also nur das Einspielen eines kompletten Backups. Und was den etwas hoehere Einrichtungsaufwand betrifft: Das wird einmal gemacht! Danach braucht es nur noch simple Updates.
Ja, ja, ich vernehme schon den Aufschrei aller Admins, die sich mit den diversen Update-Problemen von OwnCloud rumschlagen mussten. Wer den Empfehlungen der Seafile-Community zum Update/Upgrade folgt, muss das gluecklicherweise nicht befuerchten. Persoenlich habe ich bestimmt schon um die zehn Minor-Versionen und drei Major-Updates gemacht, ohne jemals solche Probleme zu erleben, wie bei den Update-Routinen von OwnCloud. Das kann zugegebenermassen daran liegen, dass OwnCloud mit seinen Aenderungen an den Tabellenstrukturen in MySQL bei Updates schlicht anfaelliger fuer fehlgeschlagene Statements ist. Letztlich kann das dem Admin ohne Entwickler-Kenntnissen aber egal sein, was ihm das Update zerschiesst. Fuer beide Loesungen gilt trotzdem: Vor jedem Update ein aktuelles Backup alles Dateien und Datenbank-Eintraege machen! Aber das sollte eigentlich eine Selbstverstaendlichkeit sein.
Bei all den Vorteilen von Seafile, hinkt die Doku leider etwas dem Stand der Technik hinterher. Und die Anwenderbasis scheint auch nicht so gross wie bei OwnCloud, als das Postings im Support-Forum schnell einen Widerhall finden wuerden. Geschweige denn, dass sich die verhaeltnismaessig kleine Entwicklerschar zu einer Antwort berufen fuehl. Vielleicht sind sie aber auch selber nur frustiert ueber die etwas krude Forums-Software, die sie sich da verordnet haben. Egal, solange die eigentliche Software funktioniert 😉 Daher an dieser Stelle meine kleine Ergaenzung zur Doku fuer alle, die sich nicht mehr mit einem alten Apachen rumschlagen wollen sondern den aktuellen 2.4er einsetzen. Am besten auch gar nicht mehr in die offizielle Doku schauen. Die dort beschriebene Konfiguration fuer den Indianer ist nicht nur veraltet sondern dazu auch noch verwirrend, denn einiges davon haben die Apache-Entwickler gluecklicherweise in der aktuellen Version laengst beseitigt.
Waehrend OwnCloud eine Erweiterung ist, die auf das PHP-Modul des Indianers aufsetzt, kommt Seafile als eigener Server daher. Kann potenziell also auch auf einen eigenen Server innerhalb der DMZ ausgelagert werden, was sich aus Gruenden der verringerten Angriffsflaeche fuer Angreifer auch anbietet. Ein gehacktes Apache-Frontend bedeutet so nicht gleichzeitig auch ein gehackter Datei-Server! Der Apache ist also lediglich das Frontend fuer die Clients. Entsprechend laesst sich Seafile theoretisch auch mit seiner Frontend-Loesung nutzen, die gar keinen Webserver bereitstellt sondern sich nur um die Transportverschluesselung per https kuemmert. Aber das ist ein anderes Thema. Um den 2.4er Apachen zum Seafile-Frontend zu machen, muss lediglich das Proxy-Modul mit
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_http_module modules/mod_proxy_http.so Listen 127.0.0.127:443 <VirtualHost 127.0.0.127:443> ServerName seafile.example.com DocumentRoot /vol/www/seafile.example.com/htdocs/ ... </VirtualHost>
aktiviert werden. Falls es nicht ohnehin schon ist. Die „127.0.0.127“ ist hier nur ein Beispiel fuer den VHost. Da gehoert natuerlich die oeffentliche IP rein, unter welcher die hier ebenfalls nur als Beispiel gegebene Domain „seafile.example.com“ zu erreichen sein soll. Und in den VHost muessen natuerlich auch alle sonstigen Eintraege fuer einen https-Host rein, auf welche ich hier nicht weiter eingehe. Nur soviel: Eine im DocumentRoot /vol/www/seafile.example.com/htdocs/ abgelegte Datei „test.txt“ sollte sich per https://seafile.example.com/text.txt aufrufen lassen. Das auch mal per Browser zu testen, kann nicht schaden, bevor man verzweifelt in der Proxy-Konfiguration an voellig falscher Stelle nach Problemen sucht 😉
Die eigentlich Konfiguration kann dann im VHost erfolgen
ProxyPass /seafhttp http://10.0.0.10:8082
ProxyPassReverse /seafhttp http://10.0.0.10:8082
ProxyPass / http://10.0.0.10:8000/
ProxyPassReverse / http://10.0.0.10:8000/
Achtung: Der Seafile-Server besteht eigentlich aus zwei Instanzen, die sich um verschiedene Dinge kuemmern! Daher ist hier die Reihenfolge der ProxyPass/ProxyPassReverse-Direktiven wichtig, denn das Proxy-Modul des Apache arbeitet die Requests der Clients nach dem First-Match-Prinzip ab. Damit man jetzt aber nicht zwei zusaetzliche Ports im Internet verfuegbar machen muss, lassen sich auch beide innerhalb eines VHosts ueber einen Port abwickeln. Also ueblicherweise 443 fuer den https-VHost. Somit umgeht man auch eventuelle Probleme mit Firewalls, welche nur die „well known“ Ports freigeben.
Die IP 10.0.0.10 ist hier ebenfalls nur ein Beispiel. Selbstverstaendlich kann der Seafile-Server auch auf der selben Maschine zum Beispiel unter 127.0.0.1 zu erreichen sein. Das mal zu testen, kann nicht schaden. Einfach per telnet 10.0.0.10 8082 beziehungsweise telnet 10.0.0.10 8000 schauen, ob sich eine Verbindung zum Seafile-Server aufbauen laesst. Wenn nicht, erstmal diesen richtig konfigurieren.
Somit waeren wir auch schon bei der Konfiguration von Seafile selber. Natuerlich muss „FILE_SERVER_ROOT“ in der seahub_settings.py jetzt auch entsprechend auf den Apachen als Frontend angepasst sein. Denn Seafile baut bei seinen verschiedenen Antworten die URI danach zusammen. Und es macht ja keinen Sinn, den Client nach 10.0.0.10 zu schicken, wenn das Frontend doch eigentlich nur unter seafile.example.com im Internet zu erreichen ist. Also einfach noch
FILE_SERVER_ROOT = 'https://seafile.example.com/seafhttp'
rein und neu starten. Dann sollte unter https://seafile.example.com/ jetzt froehliches Austauschen von Dateien moeglich sein.