Nginx configuration with rewrite dose not shown database list

Dear All,
I set up tryton successfully on vps server.
and if I set the configuration file like this

[database]
uri = postgresql://tryton:tryton@localhost/
path = /opt/tryton/bin/trytond
[web]
root = /opt/tryton/sao
;hostname = http://mydomain.org
listen = 0.0.0.0:8000
num_proxies=1

everything works well

if I change the listen to localhost and I use the reverse proxy, the sao client appear correctly but I’m not able to see the database list. Also if I try to fill up data into login form I get a generic error !!!

This is my nginx configuration:

upstream tryton {
  server 127.0.0.1:8000;
}


server {
  listen 80;
  server_name *.mydomain.org;

# Redirect requests 
  location /tryton/ {
             rewrite ^/tryton/(.*)$ /$1 break;
             proxy_pass http://tryton/;
             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;
             }

I also try to setup the hostname like this:

hostname = http://mydomain.org

but I’m not able to login, and the server log dose not show useful information.

Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET / HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/jquery/dist/jquery.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/moment/min/locales.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/moment/min/moment.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/gettext.js/dist/gettext.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/eonasdan-bootstrap-datetimepicker/build/js/bootstrap-datetimepicker.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/bootstrap/dist/js/bootstrap.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/d3/d3.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/fullcalendar/dist/locale-all.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/mousetrap/mousetrap.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/fullcalendar/dist/fullcalendar.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/c3/c3.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/papaparse/papaparse.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/Sortable/Sortable.js HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/bootstrap/dist/css/bootstrap.min.css HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/bootstrap-rtl-ondemand/dist/css/bootstrap-rtl-ondemand.min.css HTTP/1.0" 304 -
Sat Apr 18 08:37:05 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:05] "GET /bower_components/fullcalendar/dist/fullcalendar.min.css HTTP/1.0" 304 -
Sat Apr 18 08:37:06 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:06] "GET /bower_components/eonasdan-bootstrap-datetimepicker/build/css/bootstrap-datetimepicker.min.css HTTP/1.0" 304 -
Sat Apr 18 08:37:06 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:06] "GET /bower_components/c3/c3.min.css HTTP/1.0" 304 -
Sat Apr 18 08:37:06 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:06] "GET /dist/tryton-sao.min.js HTTP/1.0" 304 -
Sat Apr 18 08:37:06 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:06] "GET /dist/tryton-sao.min.css HTTP/1.0" 304 -
Sat Apr 18 08:37:06 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:06] "GET /custom.js HTTP/1.0" 405 -
Sat Apr 18 08:37:06 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:06] "GET /custom.css HTTP/1.0" 405 -
Sat Apr 18 08:37:06 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:06] "GET /custom.js HTTP/1.0" 405 -
Sat Apr 18 08:37:06 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:06] "GET /custom.css HTTP/1.0" 405 -
Sat Apr 18 08:37:07 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:07] "GET /images/tryton-menu.svg HTTP/1.0" 200 -
Sat Apr 18 08:37:07 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:07] "GET /locale/en_GB.json HTTP/1.0" 405 -
Sat Apr 18 08:37:07 2020] INFO:werkzeug:5.170.192.20 - - [18/Apr/2020 08:37:07] "GET /locale/en.json HTTP/1.0" 405 -

any help will be very appreciated

regards,
Matteo

Why you are redirecting only tryton requests? Is tryton the name of your database?
If you use a diferent database it will not work.

Why you need to rewrite?

We use nginx in front of the docker image (basically to manage multiple hosts on the same server and ssl certificates). We use a single route to redirect all request as seen below:

        location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_pass http://localhost:8000;
        }

Hope this is usefull.

1 Like

Dear Pokoli,
thanks for your quick response.

I have a flask website that use tryton as model object, I wold like to give access to tryton sao interface as website back and to manage it

www.myDomain.org/tryton will give the tryton login.

Regards,
Matteo

That clarifies things a little bit.

I’m not an nginx expert but as far as I understand you don’t need to rewrite the path. Just use two locations and forward each one to the required upstream server. Something like this:

        location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_pass http://flask;
        }

        location /tryton/ {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_pass http://tryton;
        }

See this article for more complete examples or the nginx documentation about proxy_pass.

I already check the nginx documentation.
even with the method you suggest I get the some behaviour as before
the login fails . and not database is selected.
the problem is that in the log of tryton and in the log of the browser i do not have any information !!!

I also try in this way but with no success

location ~ ^/tryton/(.*)$ {
proxy_pass http://192.169.154.102:9999/$1;
}

regards
Matteo

You can use the -v flag (more flags more logging details) to increase trytond logging. Or you can set a custom logging configuration

If no database is listed this means that you are not connecting with the right server. So for me the problem is on the nginx configuration.

This may be the clue to solve the problem. By default tryton will only listen to 127.0.0.1 and not to the lan IP (192.168.154.102).

Did you tried using localhost or 127.0.0.1? (which is the same).

copy paste error in the server is correct because the login page appear

I think it is quite difficult to get Tryton/Sao to work if it is in a subpath. If I am not mistaken, after the login page is served from www.myDomain.org/tryton the subsequent POST requests from Sao go back to www.myDomain.org and not www.myDomain.org/tryton. This is why it works with listen = 0.0.0.0:8000, because in this case trytond is replying directly to the POST requests, instead of via nginx.

Are you sure? Note that nginx will cache all the static files so if your seen the page on time it will be shown correctly when the server is not properly configurad.

You can see in your logs from frist post that it responds with 304 ( which means no modified ) so the server does not send any file and the browser loads the files from it’s cache.

Indeed as far as I know subpath is not really working. But if someone wants to propose a patch to support it, it will be welcomed (even if it is not really a priority).

I’ve tested and I can confirm that it’s not working. I’ve started to write a patch but it is not fully working. I can logging but the menu screen is not properly loading. I need some more time to test it.

I will share my process latter.

I’ve filled Issue 9239: Allow to deploy sao on subpath - Tryton issue tracker which add soport for supbath on sao.

@mboscolo could you please apply it to your setup and test it works correctly?
I’ve also posted on the issue the required nginx configuration to make it work.

2 Likes

Dear @pokoli I check the patch and I’m able to see the database list and login correctly to the sao client.
I also try to create and save entity and it looks to work smoothly.

many thanks for the patch.

regards,
Matteo

Don’t you proxy only the POST requests and use nginx to serve SAO?

No because we use the sao images which already contains sao and are configured to server it’s static content. So we use nginx to proxy the request directly to the container, manage ssl certificates (using letsencrypt).

This allows to receive all updates (python code and sao) by pulling the docker images.

I guess you mean Tryton docker image, don’t you?

So SAO is served from Tryton through uwsgi.

We mount SAO from Tryton docker image in a nginx container to serve SAO from there. We thought that maybe Nginx would be more efficient in this task than uwsgi. Do you think it is worth to serve SAO from nginx instead of uwsgi?

As we have nginx installed on the host (we redirect based on the host to diferent ports environments) we do no think we need an extra container for serving static files. But normally there is no way that works for all.

Hello Mateo,
I’m working on trytond 5.0 version how did you applied this patch? I’m facing exactly the same issue right now with nginx.

Thanks

I test it in 5.4.
I was able to make it work on firefox, but chrome give me the some behaviour

Regards,
Matteo

It will be great if you can explain what errors did you found on the issue.