Nerdy Talk - Entries from October 2013

Seafile Server-Update (2.0.x)

Aktuell steht der Seafile-Server in der Version 2.0.2 auf www.seafile.com zum kostenlosen Download bereit.
Erst die Tage hob ich meine Installation von 1.8.4 auf 2.0.1 und versuchte dabei, dem zu folgen was im Seafile-Wiki hinsichtlich eines Updates geschrieben steht. Aber um ehrlich zu sein: ich hab's nur zur Hälfte verstanden. Als Windows-User blickt man dort erstmal nur halbwegs durch. Also versuchte ich mir selbst zu helfen, was dann auch erstaunlicherweise erfolgreich war. ;-)
Das Update vollzog ich dabei ganz einfach:

1. Ich wechselte zum root User und in mein Seafile-Installationsverzeichnis auf dem RPi: /home/seafile/seafile-server-1.8.5
Jaaa, ich weiß, das hätte man damas vielleicht anders nennen sollen, aber hinterher ist man ja immer schlauer. ;-)
2. Danach lud ich einfach das aktuelle Paket mit wget http://seafile.googlecode.com/files/seafile-server_2.0.1.pi.tar.gz herunter und entpackte es mit: tar -xvf seafile-server_2.0.1.pi.tar.gz
3. Weil der Upgradebefehl dann scheiterte, kopierte ich kurzerhand die benötigten Dateien von a nach b: cp seafile-server-2.0.1/upgrade/sql/2.0.1 -R /home/seafile/seafile-server.1.8.5/upgrade/sql und cp seafile-server-2.0.1/upgrade/add_collate.sh /home/seafile/seafile-server.1.8.5/upgrade
4. Danach klappte es auch mit cd /home/seafile/seafile-server.1.8.5/upgrade/2.0.1 und ./upgrade_1.8_2.0.sh

Das Ergebnis war entsprechend:

migrating avatars ...
DONE

Updating seafile/seahub databases ...

fix seafile database case issues...
sqlite3 /home/seafile/ccnet/PeerMgr/usermgr.db .dump > /tmp/user-db.sql
sqlite3 /home/seafile/ccnet/GroupMgr/groupmgr.db .dump > /tmp/group-db.sql
sqlite3 /media/usbstick16gb/seafile.db .dump > /tmp/seafile-db.sql
sqlite3 /home/seafile/seahub.db .Dump | tr -d '
' | sed 's/;/;
/g' > /tmp/seahub-db.sql
DONE

Anschließend einmal Seafile und Seahub neu starten:

cd /home/seafile/seafile-server-1.8.5/
./seafile.sh start
./seahub.sh start 8000


Im Anschluss lief alles: Server, Client, Up- und Downloads und der Zugriff auf die Libraries am angeschlossenen USB-Stick (dient als externer Speicher). Das Webinterface aber zeigte mir immer noch Version 1.8 an.
Der Grund dafür war, dass sich meine neue Installation jetzt unter ./seafile-server.1.8.5 lag, aber direkt unter ./seafile liegen musste.
Also führte ich die obigen Schritte erneut durch, nur dass ich das Paket diesmal nach ./seafile herunterlud, extrahiert und dort ausführte. Erneut war alles erfolgreich und auch das Webinterface zeigt jetzt Version 2 an.

Ob auch das Upgrade auf Version 2.0.2 so problemlos funktioniert werde ich heute abend sehen. Wenn ja, dann ist's echt easy - wenn man weiß wie. :-)

Seafile auf dem Raspberry Pi: Setup und Betrieb mit Hürden

Dass "Seafile" als Cloudlösung zwar schlank und flott, aber noch nicht ausgereift ist, zeigt sich bei den Hürden während der Installation und im Betrieb.
Was die Installation des Servers unter Wheezy angeht, so ist diese eigentlich recht schnell und problemlos gemacht. Anleitungen und How-Tos hierzu finden sich zahlreiche wie z.B.:

http://jankarres.de/2013/06/raspberry-pi-owncloud-alternative-seafile-server-installieren/
http://thomas-leister.de/allgemein/die-eigene-cloud-dropbox-alternative-seafile-installieren-ubuntu-12-04/

E-Mail-Versand aus Seafile
---------------------------------

Nach der Installation stellte ich schnell fest, dass der E-Mail-Versand aus Seafile nicht funktioniert. Links zu freigegebenen Datein oder Kennwörter ließen sich nicht verschicken. Die lapidare Meldung Seafiles lautete nur, dass der Mailservice noch nicht korrekt konfiguriert worden sei.
Also installierte ich mir die Pakete ssmtp und heirloom-mailx und passte die Konfiguration entsprechend an. Aber auch das half nichts.
Vielmehr galt es, der "seahub_settings.py" folgende Zeilen gemäß der Anleitung hinzuzufügen:

QUOTE:

EMAIL_USE_TLS = False
EMAIL_HOST = 'smtp.domain.com' # smpt server
EMAIL_HOST_USER = 'username@domain.com' # username and domain
EMAIL_HOST_PASSWORD = 'password' # password
EMAIL_PORT = '25'
DEFAULT_FROM_EMAIL = EMAIL_HOST_USER
SERVER_EMAIL = EMAIL_HOST_USER


Da ich für den Versand einen GMX-Account nutze, musste ich die Zugangsdaten wie folgt hinterlegen:

QUOTE:

EMAIL_USE_TLS = False
EMAIL_HOST = 'mail.gmx.net' #smtp server
EMAIL_PORT = '25'
EMAIL_HOST_USER = 'name@gmx.de' # username and domain
EMAIL_HOST_PASSWORD = 'password' # password
DEFAULT_FROM_EMAIL = 'name@gmx.de'
SERVER_EMAIL = 'name@gmx.de'
SITE_NAME = 'MySeafile'
SITE_TITLE = 'MySeafile'
USE_PDFJS = True
HTTP_SERVER_ROOT = 'http://myname.dyndns.com:PORT' #PORT = Seahub-Port (muss durch den Port ersetzt werden)
SITE_BASE = 'http://myname.dyndns.com'


Nach dem Setzen dieser Einstellungen war dann auch der E-Mail-Versand möglich.


Download freigegebener Datei von extern
-----------------------------------------------------

Das nächste Problem, das ich hatte, war, dass beim Versand eines Downloadlinks immer nur die private IP des Servers verschickt wurde, was externen Nutzern nichts bringt.
Wie konnte ich Seafile also dazu bringen, die öffentliche IP (in meinem Fall die DynDNS-Adresse inkl. Port) zu verschicken ?
Dazu musste ich die ccnet.conf unter /home/seafile anpassen und den Eintrag SERVICE_URL setzen.
Danach fügte ich der "seahub_settings.py" noch die Zeile "HTTP_SERVER_ROOT" hinzu und ergänzte sie durch meine externe Adresse inkl. Port: HTTP_SERVER_ROOT = 'mydomain.dyndns.org:8082'
Nach einem Neustart des Seahubs über ./seahub.sh stop und ./seahub.sh start funktionierte es dann. Wichtig war hier noch, dass das Stoppen und Starten nicht ohne erweiterte Rechte vonstatten ging, weshalb ich mit "sudo su" zunächst den User zu root wechselte, Seahub neu startete und anschließend über "su pi" wieder zurück zum von mir angelegten Raspberry-User "pi" wechselte.


Zugriff von intern nicht mehr möglich
----------------------------------------------

Nachdem jetzt also die korrekte Serveradresse verschickt wurde und der Zugriff von außen auch möglich war (Wichtig: Port-Forwarding im Router nicht vergessen !), konnte ich aber von intern keine Dateien mehr hoch- und runterladen. Der Zugriff auf das Webinterface funktionierte zwar noch, aber der Upload über den Webbrowser oder die Smartphone-App eben nicht mehr.
Was hatte sich geändert ?
Nun, damit man Dateien von außen herunterladen kann, musste ich alle Serveradressen in den Konfigurationsdateien durch die externe DynDNS-Adresse ersetzen.
Während ich das Webinterface weiterhin per IP aufrief, konnte ich aber nichts mehr hoch- und runterladen, was daran liegt, dass für das Repository Seahub zuständig ist (Webinterface = Seafile) und selbiges eben nur noch über die DynDNS-Adressen erreichbar ist ! Jetzt war ich in einer Zwickmühle. Auf der einen Seite konnten meine Kontakte jetzt runterladen, ich im Gegenzug aber nichts mehr hochladen.
Die Ursache war, dass mein bisheriger Router, ein Speedport W723V, der ohnehin der letzte Schrott ist, DNS Rebinding (oder auch NAT Haiprinning genannt) verbot ! Auch aktuelle Fritz!Boxen hätten nach einem Firmwareupdate dieses Problem, weshalb ich die Idee des Routertauschs wohl vergessen konnte.
Ich stellte jedoch fest, dass der Upload von Datein über einen anderen Weg klappte; nämlich über den Windows Desktop-Client von Seafile. Dieser verbindet sich weiterhin über die IP und den festgelegten Port mit dem Repository und mach ein Up- und Download per Synchronisation möglich. Perfekt ! Also lud ich mir zunächst die entsprechenden Libraries über das Webinterface herunter und legte die Dateien in die angelegten Ordner auf meiner Platte ab. Jetzt konnte ich Seafile wieder vollständig nutzen.

Nachdem ich aufgrund weiterer Einschränkungen des Speedports geärgert hatte, schaffte ich diesen ab und eine Fritz!Box 7360 an. Die darauf installierte Firmware überraschte mich, da diese zwar auch DNS Rebinding untersagt, dem Nutzer aber die Möglichkeit bietet, Adressen als Ausnahmen hinzuzufügen. Und so kann ich mich jetzt auch per Smartphone-App daheim auf den Seafile-Server verbinden und Dateien hoch- und runterladen.


Downloads nicht mehr möglich
--------------------------------------

Nach zwei Tagen der Funktionalität berichteten mir meine Kontakte, dass sie beim Versuch, freigegebene Dateien herunterzuladen, eine Fehlermeldung erhielten: "Internal Server Error".
Hm.....was war jetzt schon wieder los ?
Die Ursache war schnell gefunden und der Fehler behoben, wenn man weiß, was zu tun ist.
Aufgrund weiterer Anpassungen der Konfiguration hatte ich unter HTTP_SERVER_ROOT die Serveradresse ohne führendes "http" (walhweise auch https, wenn entsprechend konfiguriert) eingetragen.
Nach dem Hinzufügen von "http" und einem Serverneustart (./seafile.sh restart) funktionierte alles wieder.


Verbindungsprobleme des Seafile-Clients
----------------------------------------------------

Die nächsten Probleme machte dann der Seafile-Client. Bis zum Austausch meines Router verweigerte er für einige Bibliotheken plötzlich die Synchronisation. Also sah ich mir mal im Webinterface des Clients die Einstellungen an und siehe da: die Servereinstellungen waren bei den betroffenen Verbindungen so gesetzt, dass die DynDNS Adresse und nicht mehr die lokale IP adressiert wird. Um den Client wieder zum Synchronisieren zu bewegen, reichte es an dieser Stelle aus, die Serveradresse entsprechend zu ändern. Dies wurde nach dem Austausch des Routers hinfällig.
Schließlich installierte ich den Client bei meinem Vater und versuchte, die für ihn freigegebenen Bibliotheken herunterzuladen, was jedoch scheiterte. Der Client steckte in einer Downloadschleife fest.
Wieder daheim startete ich "TCPView" von SysInternals, um mal zu sehen, welche Ports der Clients adressiert und stieß dabei auf meinen Fehler. Den, bei der Installation von Seafile, von mir festfelegten Port hatte ich beim Port Forwarding im Router nicht bedacht. Kaum hatte ich dies nachgeholt wurde auch schon die von mir abgelegte Testdatei erfolgreich auf seinem Rechner synchronisiert.
Dies funktionierte jedoch nur einige wenige Male und dann nicht mehr. Der Client verblieb bei der Synchronisation bei 0% und auch bei mir daheim trat dieses Problem auf einmal auf. Der Neustart des Clients half hier nichts. Erst ein Neustart des Seafile-Servers, gefolgt von einem Client-Neustart ließ die Synchronisation wieder sauber durchlaufen.


Page 1 of 1, totaling 2 entries