haiwen / seafile

High performance file syncing and sharing, with also Markdown WYSIWYG editing, Wiki, file label and other knowledge management features.
http://seafile.com/
Other
12.43k stars 1.55k forks source link

Seafile does not connect to server anymore #1278

Closed confile closed 9 years ago

confile commented 9 years ago

Using Seafile Client 4.2.4. and Seafile Server 4.2.2 on Rasperypi I get the following when trying to sync a library:

seafile

System runs perfect with an earlier version. The "connecting server..." does not change anymore.

shoeper commented 9 years ago

http://manual.seafile.com/deploy/https_with_nginx.html

confile commented 9 years ago

I can access my seafile folder using a web browser on the raspberry but not using the client.

shoeper commented 9 years ago

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;
        }
confile commented 9 years ago

@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. 
shoeper commented 9 years ago

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.

confile commented 9 years ago

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.

shoeper commented 9 years ago

In your client settings. Right click on the seafile icon -> settings -> advanced settings

confile commented 9 years ago

settings

What should I change?

confile commented 9 years ago

Ah I guess you mean the third one.

confile commented 9 years ago

@shoeper Thanks a lot it is working! :-)

shoeper commented 9 years ago

@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.

confile commented 9 years ago

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?

shoeper commented 9 years ago

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).

confile commented 9 years ago

@shoeper I am not sure if you get me right. My IP address changes every 24h. Does your solution works for that as wenn?

shoeper commented 9 years ago

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.

shoeper commented 9 years ago

See also http://serverfault.com/a/123670 if you don't believe what I've told you.

confile commented 9 years ago

@shoeper Yes I am German. Danke vielmals. Ich werde es ausprobieren und dir Feedback geben.

confile commented 9 years ago

@shoeper Was genau meinst du mit "Zertifikate inklusive Kette"?

shoeper commented 9 years ago

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

confile commented 9 years ago

@shoeper Hast du zufällig eine Anleitung, wie ich das auf dem RaspberryPi machen muss?

shoeper commented 9 years ago

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.

confile commented 9 years ago

Das Zertifikat?

shoeper commented 9 years ago

Wenn du nginx nutzt sollte zweiter link von oben weiterhelfen.

shoeper commented 9 years ago

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.

confile commented 9 years ago

@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?

shoeper commented 9 years ago

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.

confile commented 9 years ago

Kann man ein trusted Zertifikat denn auch kostenlos bekommen oder reicht es wenn ich mir einfach wieder eins erzeuge?

shoeper commented 9 years ago

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.

confile commented 9 years ago

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.

shoeper commented 9 years ago

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 ;)

confile commented 9 years ago

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?

shoeper commented 9 years ago

Da kann ich dir leider nicht weiterhelfen, weil ich keine Apple Geräte habe und mich mit diesen auch nicht auskenne.

confile commented 9 years ago

@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'
shoeper commented 9 years ago

Du musst FILE_SERVER_ROOT anstelle von HTTP_SERVER_ROOT setzen, siehe auch nginx mit ssl unter manual.seafile.com

confile commented 9 years ago

Und wofür brauche ich HTTP_SERVER_ROOT?

confile commented 9 years ago

@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:

bibliotheken_-_private_seafile

shoeper commented 9 years ago

Du hast dir auch die von mir erwaehnte Seite nicht angeguckt. Siehe http://manual.seafile.com/deploy/https_with_nginx.html

confile commented 9 years ago

Doch habe ich aber eine Stelle habe ich wohl übersehen. seafhttp fehlte. Vielen Dank für deine Hilfe.

shoeper commented 9 years ago

Bitte.