Closed confile closed 9 years ago
I can access my seafile folder using a web browser on the raspberry but not using the client.
Yeah and the link above describes necessary steps to enable http(s) sync (client sync).
without e.g. following (nginx, for other server see the manual)
location /seafhttp {
rewrite ^/seafhttp(.*)$ $1 break;
proxy_pass http://127.0.0.1:8082;
client_max_body_size 0;
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
}
@shoeper I have this configuration. As I said it worked until I make the latest seafile client update. Now I still work with a seafile client if I use http instead of https. But with https it is still always in connecting server...
mode.
Here is my nginx config (source: http://draptik.github.io/blog/2014/04/21/installing-seafile-on-raspberry-pi/):
server {
listen 8001; # <--------------------------------------- NGINX PORT
ssl on; # <-------------------------------------------- SSL
ssl_certificate /etc/nginx/ssl/seahub.crt; # <--------- SSL
ssl_certificate_key /etc/nginx/ssl/seahub.key; # <----- SSL
server_name myserver.no-ip.biz.tld; # <----------------- CHANGE THIS
error_page 497 https://$host:$server_port$request_uri;
location / {
fastcgi_pass 127.0.0.1:8000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param HTTPS on;
fastcgi_param HTTP_SCHEME https;
access_log /var/log/nginx/seahub.access.log;
error_log /var/log/nginx/seahub.error.log;
}
location /seafhttp {
rewrite ^/seafhttp(.*)$ $1 break;
proxy_pass http://127.0.0.1:8082;
client_max_body_size 0;
}
location /media {
root /home/seafile/seafile/seafile-server-latest/seahub; # <-- change: 2014-07-11
# include /etc/nginx/mime.types; # <--- UNCOMMENT THIS IF CSS FILES AREN'T LOADED
}
}
``
Here is my ``seahub_settings.py``:
SECRET_KEY = "-some key" HTTP_SERVER_ROOT = 'https://myserver.no-ip.biz:8001/seafhttp'
On seafile client I use the server address:
https://myserver.no-ip.biz:8001
I appreciate your help. Really I have no idea what to do now.
I think the certificate is your problem. Have you enabled not to check the certificate in your options?
Furthermore
HTTP_SERVER_ROOT = 'https://myserver.no-ip.biz:8001/seafhttp'
should be
HTTP_SERVER_ROOT = 'https://myserver.no-ip.biz:8001/'
Maybe even without trailing slash.
In addittion adding
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
to your /seafhttp nginx block could help in some cases where the server responds slow (because of high load or an action that need much time, but that is not the cause of the client is not being able to connect at all.
What do you mean by:
Have you enabled not to check the certificate in your options?
How do I enable this?
I made the other edits you suggested but still don't work.
In your client settings. Right click on the seafile icon -> settings -> advanced settings
What should I change?
Ah I guess you mean the third one.
@shoeper Thanks a lot it is working! :-)
@confile Great!
Another tip: If want more security (prevent man in the middle attacks), you need your own domain. Use a cname record to your dyndns domain and get a free certificate at e.g. start ssl.
Great thank you. I have my own domain the problem is that the seafile server works from home and internet is disconnected every 24h. So I need dynamic dns. Or do you see any other way of doing this?
Yeah, as I've described above: Use a cname record your dns record of your own domain. E.g.
dnydns: xyz.dyn-dns.example.com. IN A 8.8.8.8 (your ip address)
your domain: seafile.confile.com. IN CNAME xyz.dyn-dns.example.com.
Now change your seafile config(s) to link to the new domain name and access it via seafile.confile.com. With a trusted ssl certificate you should now be able to disabled to option "do not check server certificate". Hope this was easier to understand.
Make also sure to generate the csr (certificate sign request) and private key on your own machine and to use strong options. 4096 bit is fine and at least sha256 as checksum (sha1 will be displayed as insecure in some browser and seahub will use the same certificate). Furthermore you should enable strong ciphers, the hsts header and pfs (maybe some additional options).
@shoeper I am not sure if you get me right. My IP address changes every 24h. Does your solution works for that as wenn?
Yeah I got you right and yes that solution should work in this case. I assume your german. Me, too.
Also du hast deine dyndns domain, die lässt du wie sie ist. Jetzt erstellst du bei deiner eigenen Domain eine Subdomain und legst eine CNAME Record (ein CNAME Record ist wie ein Alias, heißt einfach: Gucke bei Domain X welche IP diese Adresse hat, Domain X ist deine DynDns Adresse die eine niedrige TTL (time-to-live) und eine API über die dein Router die IP Aktualisieren kann hat.) an, der auf deine dyn dns Domain verweist. Anschließend stellst du deine Seafile und Webserver config auf deine richtige Domain um und richtest entsprechende Zertifikate inklusive Kette (certificate chain) ein.
Probiers einfach aus. Du kannst ja auch kurz testweise einen cname record einrichten, dann in deinem webserver konfigurieren, dass wenn port 80 und die richtige domain verwendet wird hallo angezeigt wird. Dann (vorausgesetzt der CNAME eintrag ist bereits im DNS Server aktiv) die Seite im Browser aufrufen und du solltest den Text sehen. Anschließend im Router ne neue IP anfordern und die Seite mit Strg+F5 neu laden (wenns nicht geht nach 30s oder 1min nochmal versuchen, dann sollte es gehen). Funktioniert der beschriebene Fall kannst du dir sicher sein, dass das Ganze auch mit Seafile funktioniert und die configs entsprechend anpassen.
See also http://serverfault.com/a/123670 if you don't believe what I've told you.
@shoeper Yes I am German. Danke vielmals. Ich werde es ausprobieren und dir Feedback geben.
@shoeper Was genau meinst du mit "Zertifikate inklusive Kette"?
Dein Betriebssystem und oder Browser hat einen Zertifikatespeicher. In diesem sind die Wurzelzertifikate (root ca (certificate authorities)) gespeichert, denen dein System vertraut. Viele Unternehmen die Zertifikate ausstellen erstellen zum Signieren ein oder mehrere Unterzertifikate, mit denen sie die Zertifikate der Kunden signieren. Diese Unterzertifikate sind oft nicht im Zertifikatespeicher enthalten. Damit der Client (Browser, Seafile, was auch immer) das Zertifikat akzeptiert liefert man in diesem Fall die Zertifikatskette (certificate chain) mit aus. Dann kann der Client prüfen, ok das Zertifikat wurde von Unterzetifikat X und das wiederum von Unterztertifikat y und das vom Wurzelzertifikat z signiert. Ist das Wurzelzertifikat im Zertifikatespeicher wird das Zertifikat als sicher gekennzeichnet.
Diese Verfahren wird u.a. von StartSSL genutzt und wie man ein StartSSL Zertifikat richtig konfiguriert (ist nicht viel Arbeit) findest du hier: https://www.startssl.com/?app=20, bzw für nginx und StartSSL hier: https://www.startssl.com/?app=42
@shoeper Hast du zufällig eine Anleitung, wie ich das auf dem RaspberryPi machen muss?
Was denn? Das Zertifikat oder allgemein irgendwas?
Im Prinzip gibt es nicht wie man es bei dem Raspberry Pi macht sondern wie man es mit Debian/Ubuntu/CentOS/RedHat/anderer Distro kombiniert mit nginx/apache2/anderer Webserver macht.
Das Zertifikat?
Wenn du nginx nutzt sollte zweiter link von oben weiterhelfen.
Privaten Schlüssel erzeugen: openssl genrsa -out privatekey.pem 4096
(Rechte für den Schlüssel so weit wie möglich einschränken).
CSR (Certificate Sign Request) erzeugen: openssl req -new -key privatekey.pem -out your.domain.csr -sha512
, wenn ich das richtig habe bei allen Fragen einfach Enter drücken weil StartSSL sowieso alles verwirft. Dann bei StartSSL die Schritte durchgehen, sagen dass du einen privaten Schlüssel hast und deine Unterschriftsanfrage (CSR) hochladen. Am Ende sollten Sie dir dein unterschriebenes Zertifikat zum Download anbieten.
Der Rest müsste dann eigentlich oben beschrieben sein.
@shoeper tut mir leid für die späte Rückmeldung ich war im Urlaub. Versuche nun gerade deine Beschreibung umzusetzen. Gebe dir Rückmeldung ob es geklappt hat. Warum ist das denn besser als die DYNDNS zu verwenden?
Du verwendest ja dann weiterhin dyndns. Du wirst nur kein Zertifikat die kostenlosen dyndns domains bekommen, weil du keine mails an hostmaster@deinedyndnsadresse.tld empfangen kannst.
Kann man ein trusted Zertifikat denn auch kostenlos bekommen oder reicht es wenn ich mir einfach wieder eins erzeuge?
Kostenlos gibts das z.B. bei StartSSL oder demnächst auch bei Mozilla "Let's Encrypt".
Vorteil ist du musst das Zertifikat nicht auf jedem Gerät importieren.
Okay habe ein Level 1 Zertifikat bei StartSSL erstellt. Das funktioniert super außer dass ich in meiner NGINX config:
ssl_certificate /etc/nginx/conf/ssl.crt;
statt
ssl_certificate /etc/nginx/conf/ssl-unified.crt;
verwenden muss. Wenn ich ssl-unified.crt
nutze bekomme ich den folgenden Fehler:
sudo /etc/init.d/nginx restart
Restarting nginx: nginx: [emerg] SSL_CTX_use_certificate_chain_file("/etc/nginx/ssl/ssl-michaelgorski-org-unified.crt") failed (SSL: error:0906D066:PEM routines:PEM_read_bio:bad end line error:140DC009:SSL routines:SSL_CTX_use_certificate_chain_file:PEM lib)
nginx: configuration file /etc/nginx/nginx.conf test failed
Hast du eine Idee woran das liegt? Es muss irgendein Problem mit dem unified certificate geben.
Siehe z.B. http://www.ur-ban.com/2010/12/09/nginx-ssl-pem_read_biobad-end-line/
Also nimms mir nicht böse, aber wer einen Server betreiben möchte muss sich auch ein wenig damit beschäftigen und auch mal kurz Google o.a. bemühen. Sehr viele Probleme sind trivial und können mit einer kurzen Recherche gelöst werden. Wenn man dann nichts findet, kann man immer noch nachfragen ;)
Entschuldige bitte für die vielen doofen Fragen. Ich bin froh wenn mein Server läuft und ich nicht viel daran machen muss :-)
Dein Tipp hat geholfen. Jetzt läuft's. Ich danke dir nochmals sehr für deine Hilfe.
Eine Frage hätte ich noch. Ich habe jetzt ja ein gültiges SSL Zertifikat. Mit dem Desktop client kann ich auch problemlos arbeiten. Allerdings kann ich in der iOS App Version: 1.9.9 keine Bilder hochladen. Die Zielbibliothek ist nicht verschlüsselt. Übertragen geht allerdings über https. Wenn ich über meinen Desktop client Bilder in die Bibliothek hoch lade, dann kommen die auch auf dem Telefon an nur eben vom Telefon aus wird nichts gesendet. Hast du da auch ne Idee?
Da kann ich dir leider nicht weiterhelfen, weil ich keine Apple Geräte habe und mich mit diesen auch nicht auskenne.
@shoeper Ich hatte doch kein problem mit der Seafile App mein Problem ist, dass ich zwar mit dem Desktop Client super up und downloads machen kann, nicht aber wenn ich mich über das Webinterface einlogge. Da kann ich weder Dateien hochladen noch runter laden.
Ich poste hier mal meine NGINX uns seafile config vielleicht hast du ja noch ne Idee. Ich bin sicher das ist nur ne Kleinigkeit:
NGINX config:
server {
listen 8001; # <--------------------------------------- NGINX PORT
ssl on; # <-------------------------------------------- SSL
ssl_certificate /etc/nginx/ssl/ssl-confile-org-unified.crt; # <--------- SSL
ssl_certificate_key /etc/nginx/ssl/ssl-confile-org.key; # <----- SSL
server_name home.myserver.de; # <----------------- CHANGE THIS
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
server_tokens off;
error_page 497 https://$host:$server_port$request_uri;
location / {
fastcgi_pass 127.0.0.1:8000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param HTTPS on;
fastcgi_param HTTP_SCHEME https;
access_log /var/log/nginx/seahub.access.log;
error_log /var/log/nginx/seahub.error.log;
}
location /seafhttp {
rewrite ^/seafhttp(.*)$ $1 break;
proxy_pass http://127.0.0.1:8082;
client_max_body_size 0;
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
}
location /media {
root /home/seafile/seafile/seafile-server-latest/seahub;
}
}
ccnet.conf:
[General]
USER_NAME = home
ID = 123123213123123123263e99092610b5222bc7c0d77ac8
NAME = home
SERVICE_URL = https://myserver:8001
[Network]
PORT = 10001
[Client]
PORT = 13418
seahub_settings.py:
SECRET_KEY = "123456789123456789"
HTTP_SERVER_ROOT = 'https://myserver:8001'
Du musst FILE_SERVER_ROOT anstelle von HTTP_SERVER_ROOT setzen, siehe auch nginx mit ssl unter manual.seafile.com
Und wofür brauche ich HTTP_SERVER_ROOT?
@shoeper abe FILE_SERVER_ROOT anstelle von HTTP_SERVER_ROOT gesetzt und seafile und seahub in fast-cgi mode neu gestartet. Wenn ich über das Webinterface einen Uplaod machen will kommt:
Du hast dir auch die von mir erwaehnte Seite nicht angeguckt. Siehe http://manual.seafile.com/deploy/https_with_nginx.html
Doch habe ich aber eine Stelle habe ich wohl übersehen. seafhttp
fehlte.
Vielen Dank für deine Hilfe.
Bitte.
Using Seafile Client 4.2.4. and Seafile Server 4.2.2 on Rasperypi I get the following when trying to sync a library:
System runs perfect with an earlier version. The "connecting server..." does not change anymore.