You can switch completely to WSGI on Seafile. No need to run it via fastcgi.
Example configuration for SeafDAV at https://manual.seafile.com/extension/webdav.html still uses fastcgi. How should this configuration be altered to switch to WSGI?
I have the following config which works fine.
location /seafdav {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto https;
proxy_http_version 1.1;
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
proxy_send_timeout 36000s;
send_timeout 36000s;
client_max_body_size 0;
proxy_request_buffering off;
access_log /var/log/nginx/seafdav.access.log;
error_log /var/log/nginx/seafdav.error.log;
}
And of course you need to switch off the fastCGI mode for seadav in the config file.
1 Like
Does not work for me. When I try to acces via webdav, I get a bad gateway error.
I took your template, switched the Port to 3000 and deleted the proxy_request_buffering line. Then I switched fastcgi off in config file. Of course I restarted seafile and nginx.
This is what seafdav.error.log says:
2018/02/05 10:21:15 [error] 16729#0: *38 connect() failed (111: Connection refused) while connecting to upstream, client: 88.130.xxx.xxx, server: meindyndnsname.org, request: "PROPFIND /seafdav HTTP/1.1", upstream: "http://127.0.0.1:3000/seafdav", host: "meindyndnsname.org"
Any idea what’s going wrong?
Port changed in seadav config?
Nginx version?
You put the nginx config block within the seafile block, just replaced the old seadav block right?
Please run netstat -tulpn on your server and post results here.
I just replaced the seafdav block in the config file posted this morning. In my sefdav.conf port is set to 3000 and fastcgi set to no. Nginx version is 1.6.2 arm.
This is the resulot of netstat -tulpn:
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 16878/nginx
tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN 2785/xrdp
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 2710/smbd
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 17002/python2.7
tcp 0 0 0.0.0.0:12001 0.0.0.0:* LISTEN 16965/seaf-server
tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 1518/minidlnad
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 2437/mysqld
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 2710/smbd
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 1973/memcached
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 16878/nginx
tcp 0 0 0.0.0.0:10001 0.0.0.0:* LISTEN 16962/ccnet-server
tcp 0 0 0.0.0.0:81 0.0.0.0:* LISTEN 16878/nginx
tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 16965/seaf-server
tcp 0 0 127.0.0.1:3350 0.0.0.0:* LISTEN 2790/xrdp-sesman
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2583/sshd
tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 16964/python2.7
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 19764/1
tcp6 0 0 :::445 :::* LISTEN 2710/smbd
tcp6 0 0 :::139 :::* LISTEN 2710/smbd
tcp6 0 0 :::8080 :::* LISTEN 2908/java
tcp6 0 0 :::22 :::* LISTEN 2583/sshd
tcp6 0 0 ::1:6010 :::* LISTEN 19764/1
udp 0 0 0.0.0.0:1900 0.0.0.0:* 1518/minidlnad
udp 0 0 127.0.0.1:11211 0.0.0.0:* 1973/memcached
udp 0 0 0.0.0.0:68 0.0.0.0:* 1585/dhclient
udp 0 0 0.0.0.0:2650 0.0.0.0:* 1585/dhclient
udp 0 0 192.168.178.42:54900 0.0.0.0:* 1518/minidlnad
udp 0 0 192.168.178.42:123 0.0.0.0:* 2525/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 2525/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 2525/ntpd
udp 0 0 192.168.178.255:137 0.0.0.0:* 1803/nmbd
udp 0 0 192.168.178.42:137 0.0.0.0:* 1803/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 1803/nmbd
udp 0 0 192.168.178.255:138 0.0.0.0:* 1803/nmbd
udp 0 0 192.168.178.42:138 0.0.0.0:* 1803/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 1803/nmbd
udp6 0 0 2003:e5:5bcb:ea00:4:123 :::* 2525/ntpd
udp6 0 0 fe80::44:2ff:fe81:d:123 :::* 2525/ntpd
udp6 0 0 ::1:123 :::* 2525/ntpd
udp6 0 0 :::123 :::* 2525/ntpd
udp6 0 0 :::17563 :::* 1585/dhclient
Das ist ja alles sehr interessant. Nur sind wir hier nicht eigentlich im deutschsprachigen Teil des Forums also warum schreiben wir hier in englisch?
@Tjelfe
Danke für die Serverkonfig.
Meine sieht recht ähnlich aus.
Ich habe es nun auch hinbekommen Seafile in das Subdirectory umzukonfigurieren und OnlyOffice funktioniert auch.
Es hatte sich bei mir ein Tippfehler eingeschlichen.
Leider funktioniert nun Wordpress nicht mehr.
Sehe ich das beider Konfiguration richtig, dass du das root Verzeichnis deiner Domain gar nicht verwendest.
Ist das nicht für eine Wordpressseite ungünstig?
Wordpress nutze ich nur für eigene Spielereien und nicht einen öffentlichen Blog. Daher ist das Unterverzeichnis kein Problem.
Macht der Gewohnheit.
1 Like
Sieht soweit ja eigentlich okay aus. Hast du deine IPTables ggf. komplett dicht gemacht dass er solche Verbindungen auch verbietet?
Probiere bitte mal mit nmap -p 3000 ob der Dienst sauber antwortet.
Sieht für mich ok aus:
sudo nmap 127.0.0.1 -p 3000
Starting Nmap 6.47 ( http://nmap.org ) at 2018-02-06 13:42 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00032s latency).
PORT STATE SERVICE
3000/tcp open ppp
Nmap done: 1 IP address (1 host up) scanned in 0.77 seconds
Wenn ich seafdav wieder auf fastcgi umgestelle, klappt der Webdav-Zugriff problemlos.
Ich hatte noch im Hinterkopf, gelesen zu haben dass seafdav weiter über fastcgi läuft. Habe nun den Beitrag gefunden: https://forum.seafile.com/t/seafile-server-6-2-0-beta-is-ready-for-testing/3941/7 Da hattest Du selbst nachgefragt, aber wohl keine Antwort bekommen. Ich denke, ich behalte einfach meine laufende Konfiguration bei.
Vielen Dank für Deine Hilfe!
Ich habe es jetzt gerade extra noch einmal getestet. Ich habe es definitiv ohne fastCGI laufen.
Kannst du deine Nginx Version mal bitte auf die neuste Version update?
https://launchpad.net/~nginx/+archive/ubuntu/stable
Von extern greifst du dann via https://my.seafile.domain/seafdav darauf zu korrekt?
Make sure to not pass the fast cgi option on start.
Werde ich mal testen, klappt aber gerade nicht:
W: Fehlschlag beim Holen von http://ppa.launchpad.net/nginx/stable/ubuntu/dists/jessie/main/binary-armhf/Packages 404 Not Found
Ich hoffe, dass da nur vorübergehend was fehlt - versuche es später noch einmal.
Via WebDAV greife genau so zu, wie Du geschrieben hast. Der Zugriff auf das Seafile Webinterface klappt ja auch problemlos ohne fastcgi. Grundsätzlich läuft es ja, so dass ich keinen wirklich dringenden Handlungsbedarf habe.
@shoeper: Klar, seahub starte ich ohne den fastcgi Zusatz. Klappt auch alles problemlos - auch der WebDAV Zugriff. Meine nginx Konfiguration steht ja weiter oben im Thread. Ist halt nur komisch, dass der WebDAV Zugriff nicht ohne fastcgi klappt.
Für WebDAV gibt es ne eigene Konfigurationsdatei.
seafdav.conf
Ich dachte dass ihm das klar sei, anscheinend nicht. \o/
Doch ist klar. Sorry, hatte @shoeper falsch verstanden. 
Meine laufende seafdav.conf sieht so aus:
[WEBDAV]
enabled = true
port = 3000
fastcgi = true
share_name = /seafdav
host = localhost
Für den Test der nginx Konfiguration von @DerDanilo hatte ich fastcgi auf false gesetzt und sowohl nginx als auch seafile neu gestartet.
Leute, lasst es erst mal gut sein. Ich habe inzwischen beschlossen, mir einen neuen Homeserver auf Intel NUC Basis aufzubauen. Wenn es dann bei der seafile Installation Probleme gibt, komme ich gern noch mal auf euch zurück.
Vielen Dank für die Hilfe bis hierhin.
2 Likes
here is mine:
root@hiperborea /home/seafile/conf # cat seafdav.conf
[WEBDAV]
enabled = true
port = 8080
fastcgi = false
share_name = /seafdav
You have to double check that no empty spaces after true, 8080, false, etc