The announcement took longer than usual due to facing some issues during testing wsgi in beta release 6.2.0 and later on testing 2WF authentication, which since 6.2.0 is a new valuable feature not only for the PRO version. Many new thirdpart python modules are shiped with this release. I have tested them and worked like a charm. If you come from 6.1.x, don’t forget to execute the upgrade script.
Don’t forget to stop Seafile Server before the upgrade (i.e: service seafile-server stop or, another example: service seahub stop && service seafile stop)
Don’t forget to change the directory rights of Seafile after unpacking it (i.e: chown -R seafile:nogroup seafile-server-6.2.1 or, another example: sudo chown -R seafile:seafile seafile-server-6.2.1 )
Don’t forget to apply the upgrade script/s according your start release && with the properly user which in normal case should be seafile (i.e change to seafile user: su seafile or, another example: sudo su seafile)
Starting from 6.2, It is recommended to use WSGI mode for communication between Seahub and Nginx/Apache. Two steps are needed if you’d like to switch to WSGI mode:
Step 1. Change the config file of Nginx/Apache.
The configuration of Nginx is as following:
# Seafile root domain configuration
location / {
proxy_pass http://127.0.0.1:8000;
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_read_timeout 1200s;
proxy_http_version 1.1; # if you use http2 or you get errors in nginx like connection refused ... HTTP/1.1
# used for view/edit office file via Office Online Server
client_max_body_size 0;
access_log /var/log/nginx/seahub.access.log;
error_log /var/log/nginx/seahub.error.log;
}
In case you have configured seafile like as non root domain, take the /seafile block.
The /seafhttp block remains untoched, only add proxy_http_version 1.1; inside it.
Great
But 6.2.2 is out , will you build that again or did your build include the fixes?
Btw, i had some problem with login and WSGI mode, from login screen it didnt load next screen, but if calling the url again i’m logged in…
So i tested a bit, cause i thought it could be something with my nginx config…same as in example above.
Now i replaced proxy_set_header Host $host
with proxy_set_header Host $host:8001;
and (not really sure what i did with that, lol) it works…
I know, after compiling 6.2.0 I had to compile again, 6.2.1 and yesterday, I saw that same day, 6.2.2 was released. To build once again were too much, therefore I decided to publish what it was done and working. The changes in 6.2.2 are IMHO not really important. I didn’t realize about them (and others that maybe will arise next week or in the future).
For my it works NGINX and WSGI in the published way, straightforward. It looks like that you communicate over the port 8001 instead of the 8000, likewise is your port 8000 already used by other application.
No, 8001 is the port nginx listening and forwarding it to seafile server on port 8000 as usual. With fastcgi i never had this problem. Login page works with url like https://my_dyndns.de:8001, but then it tries to open next page without port, what ends with network error page. As i said, login works. if i call https://my_dyndns.de:8001 again i’m logged in.
Really funny that my little change in proxy_set_header code did it…
Btw, it works, even if i dont know why (but i’m just copy/paste user on nginx normally…)
normally/default ports that nginx is listening are 80 and 443, isn’t it? If you have configured your nginx to listen in 8001 instead of 80 and 443 is a speciall configuration and therefore the standard ngnix block doesn’t fit your special condition unless you adapt it, like you already have done. Other users with standard configuration should not be affected.
yes, 80+443 are standard ports, but shouldnt nginx forward all to port 8000, even not using standard ports? Btw, now it works (and withs fastcgi never had problems).
In nginx, at the beginning, in server block, we tell in which port nginx should listen (80, 443 but everyone is possible, which is not already in use by the system)
Later on, we define the match criteria in location block, in my case for non root domain is /seafile and what to do. Then, these traffic will pass from 443 (80,etc) to port system 8000(proxy_pass http://127.0.0.1:8000;). On this port is listening our wscgi gunicorn, python or seafile. If you had here proxy_set_header Host $host:8001; it means that you are listening through https://my_dyndns.de:8001 and not over 80 or 443. It means that your 8001 will be forwarded to your 8000 if you had proxy_pass http://127.0.0.1:8000; We can discuss this by PN. Even if it works, I can give you my whole nginx configuration and the output of netstat -tulpen, to compare it. For me is not clear to understand why you use the proxy_set_header Host $host:8001 instead the standard proxy_set_header Host $host
The proxy_set_header Host $host:8001 is what i didnt understand, too, was just a try without knowing what i do, but after that it works. So its a mystery (for me) but ok
@marco, I warmly recommend it if you wanna use 2 Ways Factor Authentication. Check the ChangeLog as well if there are some features you considered is worth to. I have the feeling the browser is running even quicker than early.
In Version 6.1.1 several Upgrades were necessary:
Important Edit (29.07.2017): Please install pyhton-requests module dependence and update Pillow to 4.1.1;
To install python-requests:
apt-get install python-requests
To check Pillow version:
pip list --format=columns | grep -i pillow
upgrade Pillow until last version:
pip install --upgrade Pillow
Some users need to install libjpeg-dev as well:
apt-get install libjpeg-dev
i’m coming from 6.1.0.
Are these steps still necessary?
Yes, I think so since 6.2.X is having basically the same code than 6.1.X. Check the official one ChangeLog.. Try withoutPillow and libjpeg-dev at first, because now, the thumbnail video option needs to be enabled by config file. You can see if it works out the box, if it doesn’t work, you should consider all these steps.
Not really, I was reading about proxy_http_version 1.1 in NGINX manual and was not clear to me. Since in the forum was commented here, I included with the #comment maybe not necessary.
I needed that addition cause the upstream wsgi was partly sending data through http1.0 but due to the http2 setup all connections that got established in 1.0 failed as they’re not junked.
For me proxy_http_version 1.1 forces all connections to be handled correctly.
Compare your nginx logs with and without that option and see if it helps
Please remember:
