Deploy web client with subpath

I tried it on my local machine and had an issue while the web application sends a POST request. But step by step:

The aim is to have several instances of trytond, each in its own virtualenv enviroment, so you can them call via web browser with

> http://domain.de/instance1

> http://domain.de/instance2

and so on.

So I set up nginx locally with a default setting and one proxy definition for one trytond instance. The trial was done without uwsgi and ssl. Trytond runs in a virtualenv on Port 8000. The nginx config file looks like this:

server {
	listen 80;

	location / {
		root /var/www/html;
	}
	
	location /tryton/ {
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_pass http://localhost:8000/;
	}
}

When calling directly Tryton via
http://localhost:8000
everything works fine.

When calling Tryton via nginx
http://localhost/tryton
only GET requests are working, so the login page of Tryton is shown. When trying to login with the database name Vers6.0skr04 and the user admin (and the correct password) an error occurs.

/var/log/nginx/access.log shows

POST /Vers6.0skr04/ HTTP/1.1" 404 125 "http://localhost/tryton/"

and /var/log/nginx/error.log shows

[error] 5681#5681: *51 "/var/www/html/Vers6.0skr04/index.html" is not found (2: No such file or directory ), client: 127.0.0.1, server: , request: "POST /Vers6.0skr04/ HTTP/1.1", host: "localhost", referrer: "http://localhost/tryton/"

The question is, why the default directory /var/www/html/ is used. Do You @lukio or anybody else have an idea?

Thanks in advance, Michael

This is a deployment schema that it is not yet supported: Allow to deploy sao on subpath (#9239) · Issues · Tryton / Tryton · GitLab

@mstma I am curious, what is your use case? For me, it makes more sense to use sub-domains to distinguish multiple trytond instances (e.g. tryton1.domain.tld, tryton2.domain.tld…), which seems (imho) to be the standard entry-level strategy by SaaS providers (tryton1 = client1, tryton2 = client2), when clients do not have their own domain.

The idea is to do all that on a virtual machine, while not having direct access to the actual server. So you would always have to ask the server administrator for a new subdomain, whenever you launch a new Tryton instance.

Subpaths would be in our own sphere of control.

Cheers,
Wolf

1 Like

While I understand your requirement that I don’t know how difficult is to achieve, I want to note you that most of the server/domain companies are adopting APIs to allow doing different things like creating a new subdomain, creating a new instance in a programmatic way.

The DNS administrator could just add as wildcard entry to the DNS zone, like this:

*.tryton           3600     A     192.0.2.1

Assuming your zone is example.com, customert1.tryton.example.com, and customert2.tryton.example.com would both resolve to 192.0.2.1
Also see Wildcard DNS record - Wikipedia

1 Like