Switching from fastCGI to WSGI gives errors

Hello everyone.

I’m having trouble getting WSGI to work after upgrading to Server 7.05…

I switched from fastCGI to WSGI with the instructions in the manual.for nginx Then, I reloaded the nginix config file and started seahub using “seahub.sh.hstart”.

Now, when I connect, to the web server, the server times out with the following error message:

seahub.error.log

02/04 00:22:46 [error] 12598#0: *81 upstream timed out (110: Connection timed out) while reading response header from upstream, client: xx.xxx.xxx.xxx, server: , request: "GET /api2/repos/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:8000", host: "xx.xxx.xxx.xxx"

seahub.access.log

192.168.1.2 - - [04/Feb/2021:00:33:50 -0600] "GET /api2/repos/ HTTP/1.1" 504 182 "-" "Mozilla/5.0"
192.168.1.2 - - [04/Feb/2021:00:38:50 -0600] "GET /api2/repos/ HTTP/1.1" 504 182 "-" "Mozilla/5.0"
192.168.1.2 - - [04/Feb/2021:00:43:50 -0600] "GET /api2/repos/ HTTP/1.1" 504 182 "-" "Mozilla/5.0"

Here is my nginx conf file:

nginx seafile.conf

server {
    listen 80;
    server_name seafile.example.com;

    proxy_set_header X-Forwarded-For $remote_addr;

    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;

         # 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;
    }

# If you are using [FastCGI](http://en.wikipedia.org/wiki/FastCGI),
# which is not recommended, you should use the following config for location `/`.
#
#    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   REMOTE_ADDR         $remote_addr;
#          fastcgi_read_timeout 36000;
#
#         client_max_body_size 0;
#
#         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_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_connect_timeout  36000s;
        proxy_read_timeout  36000s;
        proxy_send_timeout  36000s;

        send_timeout  36000s;
    }
    location /media {
        root /sefaile/seafile-server-latest/seahub;
    }
}

Thank you for any help

What is your server platform/OS?

Do you have an auto-startup script that needs to be updated for WSGI?

Debian 8

My understanding is that the nginx startup script handles this when it loads the nginx config file. Is there another startup script that needs to be modified?

Thanks for your help

The error message suggests that something is calling fastcgi. What is it?

I’m wondering is you set a startup script with systemd or init as described here and here.

Another thing: Are you using memcached?

Thanks.for your response. I’m having difficulty determining what’s calling fastcgi. Here is my netstat output

tcp        0      0 192.168.x.xx:https       192.168.x.xx:49870       ESTABLISHED 12598/nginx: worker
cp        0      0 localhost:54717         localhost:8000          TIME_WAIT   -cd /
tcp        0      0 localhost:8000          localhost:54729         ESTABLISHED 12815/python2.7

No, I’m not using any startup script

I do not think so. There is no memcached config file in /etc

I have now been able to establish an unsecured connection through a web browser.

I also now see entries in error.log and access.log. I don’t understand why these entries are contained in these log files as opposed to the x.seahub.log files. Here are a few lines of output:

error.log

`2021/02/05 23:35:22 [error] 12598#0: *2063 open() "/sefaile/seafile-server-latest/seahub/media/js/base.js" failed (2: No such file or directory), client: 192.168.x.xxx, server: seafile.example.com, request: "GET /media/js/base.js?t=1569203823 HTTP/1.1", host: "192.168.x.xx", referrer: http://192.168.x.xx/accounts/login/?next=/`

Access.log

192.168.1.3 - - [05/Feb/2021:23:35:22 -0600] "GET /media/js/base.js?t=15693823 HTTP/1.1" 404 200 "http://192.168.x.xxx/accounts/login/?next=/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/8.0.80.141 Safari/537.36"

In Seafile memcached is setup in seahub_settings.py. You can read about it here.

There is a typo here, I believe:

I checked this, and It’s not setup in seahub_settings.py

I checked this file, and it is unchanged from the official package downloaded from seafile.com

I’m still stuck and haven’t been able to get WSGi to work. Hoping one of the experts such as @daniel.pan , @Jonathan , @romainc would comment.

Thanks again.

Hello Nate,

I feel flattered but I am not an expert… I am just an ordinary Seafile user tweaking some servers from times to times ! :slightly_smiling_face:

What @mercury was pointing out is that your Seafile base folder is called sefaile instead of seafile which might cause errors if you use standard configuration files for your server.

If you connect a web browser to your server’s IP on port 8000, do Seafile and Seahub work properly ?

Thank you, Romain.

Not sure why I didn’t realize that the typo Mercury was pointing out was in the message–not in the .py file. I just fixed that and it solved one of the problems.

Now, I am able to connect via Seafile Client http via port 8000, but not https. The seafile.error log still produces the entries indicating fastcgi is being called somehow.

Also, I notice that in ccnet.conf, I have the following entry:

SERVICE_URL = https://xxxx.xx.net:8001

Not sure whether this should be changed to port 8000

In case it might be helpful, here is my ccnet.conf file:

SECRET_KEY = "its a secret"
#FILE_SERVER_ROOT = 'https://xxx.xxx.xx/seafhttp'
LOGIN_ATTEMPT_LIMIT = 10
DEBUG = True
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'seahub-db',
        'USER': 'username',
        'PASSWORD': 'password,
        'HOST': '127.0.0.1',
        'PORT': '3306',
        'OPTIONS': {
            'init_command': 'SET storage_engine=INNODB',
        }
    }
}

Thanks again

Nate,
I am glad I could be of some help.
I took a look on my production server and on my test ones for the ccnet conf file.
On my production server I have : SERVICE_URL = https://<fqdn>
On my tests servers, which are not public, I have the following : SERVICE_URL = http://10.44.3.101:8000
From my point of view it should match with the address and protocol you are using.
If you are using a web server (Apache ou Nginx) for HTTPS, you should probably keep “https://xxxx.xx.net” but without the 8001 port.
Seahub lessons to port 8000 and uses HTTP. Which is why you can not connect directly in HTTPS.
As I said, I am not an expert, but you should try to change your configuration accordingly.

This looks like a partial seahub_settings.py configuration, not like ccnet.conf
In the ccnet config database is not set like this at all :slightly_smiling_face:
Here is what it should look like :

[General]
SERVICE_URL = https://<your fqdn>

[Database]
ENGINE = mysql
HOST = 127.0.0.1
PORT = 3306
USER = <dbuser>
PASSWD = <yourdbpassword>
DB = ccnet-db
CONNECTION_CHARSET = utf8

How did you end up with this configuration ?

1 Like

Thanks for catching my dumb error–I posted my seahub_settings.py file by mistake (seem that I’ve been staying up way too late working on this :slight_smile:).

Here is my real ccnet.conf file:

[General]
USER_NAME = seafile
ID = xxxxx
NAME = seafile
SERVICE_URL = https://xxx.net:8001

[Client]
PORT = 13419

[Database]
ENGINE = mysql
HOST = 127.0.0.1
PORT = 3306
USER = >username>
PASSWD = <password>
DB = ccnet-db
CONNECTION_CHARSET = utf8

I removed the port for the SERVICE_URL and restarted seafile and seahub, but still cannot connect via HTTPS.

Does this mean that I should not use HTTPS in my client settings? When I try to connect via HTTP in browser, it connects but the connection shows “unsecured”. Do you know whether an HTTP connection to Seahub is supposed to be changed to HTTPS after the connection is made? I haven’t been able to fully understand that.

From the below log file entry, it appears to at least begin a connection to seahub when I use HTTPS:

seahub.access.log

`<IP Address> - - [13/Feb/2021:12:03:05 -0600] "GET /api2/ping/ HTTP/1.1" 499 0 "-" "Mozilla/5.0"`

Thanks again for your help. I really appreciate it.

Ok, let’s make things clearer regarding HTTP and HTTPS :

  • Seahub listens to HTTP connections on port 8000
  • Your web server daemon handles HTTPS requests and sends them in HTTP to Seahub on port 8000.

Therefore :

  • Continue to use HTTPS for your connections, it is more secured
  • If you try to connect to your internal IP address on port 8000 do it in HTTP

Your ccnet configuration file seems fine.
The only doubt I have got is on the SERVICE_URL = https://xxx.net:8001 line.
I would put SERVICE_URL = https://xxx.net (without the :8001)

By the way, where does this 8001 port comes from ?
Have you got any other file referring to it ?
What have you got in your gunicorn.conf.py file for the bind value ?

I seem to have solved the problem by changing the listen port in the nginx seafile.conf file from 80 to 443. Now, I’m able to connect and login to the seahub web interface via HTTPS, although some of the images are not loading and html format is not correct. I’m going to look into that next.

Thank you again for your help.