Even if it’s nice to have a running system now, please don’t! Not in this configuration because Werkzeug is primarily a development server and security is not it;s thing.
If you want to go ahead this way (keep Werkzeug), add a layer of protection like OpenVPN or WireGuard. Also if possible add geo blocking in the firewall and open only a minimal set of addresses. All to make the attack vector as small as possible.
That said, thanks for ‘testing’ the guide and that it worked for you!
Do you know of any specific attack vectors that affect Tryton? I found a couple vulnerabilities reported for Werkzeug 2.0.2 (a DoS vulnerability and an Action Restriction Bypass vulnerability, which seemed to depend on a malicious application on an adjacent sub-domain), but didn’t see anything for Werkzeug 3.0.1 used in Tryton 6.8.
@edbo Thanks for pointing out the security problems. I read in other posts that the way to use Tryton over the net is through a nginx or apache2 webserver. I do have a apache2 webserver running and would like very much to configure my Tryton server to be used. From what I read in other posts the way to do it could be apache2 reverse proxy setup.
Can anyone help me with that? I am familiar with apache2 and I have already created a ssl certificate with certbot for another website. I do have a registered domain to be used for the Tryton setup. I also am familiar with configuring apache2 virtual hosts.
No, but when I open something to the internet I’m always cautious and try to minimize the attack vector. When you are testing or developing a custom module or something along those lines, I recommend to do it locally.
I’m not familiar with Apache, but searching the internet it seems you can use Apache with Gunicorn. So you can setup the base with Gunicorn and you have to change the NginX configuration into Apache. See https://medium.com/django-deployment/how-to-setup-apache-with-gunicorn-6616986f1702 it’s for Django, but it also should apply for Tryton. Also search for apache reverse proxy etc. Another one https://www.howtogeek.com/devops/how-to-set-up-a-reverse-proxy-with-apache/.
Thanks for the reply.
Between the lines I read that you are using nginx, am I right? If you think that that is a better approach I would follow your advice.
That’s correct, see https://discuss.tryton.org/t/deploying-tryton-with-a-python-virtual-environment and https://discuss.tryton.org/t/install-sao-in-a-production-environment
I thought you read those one as well. They are based on NginX and Gunicorn.
I personally want to use the tools I know and where I’m familiar with. If you are familiar with Apache, go for it. You already have setup a running system which even more plead for keeping Apache. You just have to setup a reverse proxy. You can follow https://discuss.tryton.org/t/deploying-tryton-with-a-python-virtual-environment to get Tryton running with Gunicorn. Then you can read the section how to setup NginX but you have to use your knowledge to convert the idea to Apache. Looking at the links I provided and the examples it shouldn’t be that hard to get it running.
I am currently going through the script again with the purpose of creating a production server.
At the point where the virtual environment is generated, command:
python3 -m venv --system-site-packages
I am getting the error ‘venv: error: the following arguments are required: ENV_DIR’
the command python3 -m venv --system-site-packages
creates a virtual environment in the directory ‘directoryname’. Is it possible that in your protocol is missing or is the error mine?
You are missing the . at the end. The command should be:
python3 -m venv --system-site-packages .
The . means “create the virtual environment here”.
<edit>
I clearified the command a bit in the start post as well. Thanks for going through it.
</edit>
In the second run I am at the point to start the desktop client. In contrast to the first run, this time I followed your script ‘by the book’ i.e. I created a new sytem user and created the venv in /srv/tryloc. The first time I was in the home directory and used the home user.
Now, when trying to start the desktop client I get the error:
Authorization required but no authorization protocol specified
(tryton:234774): Gtk-ERROR **: Can’t create a GtkStyleContext without a display connection.
The desktop client is installed in the virtual environment, in case that’s important.
Well that shouldn’t be a problem, I’m using this as well for development and works perfectly.
testadmin@docsrv:~$ mkdir -p ~/Projects/my_tryton_install
testadmin@docsrv:~$ cd ~/Projects/my_tryton_install
testadmin@docsrv:~$ python3 -m venv --system-site-packages .
For the last command you can also use
testadmin@docsrv:~$ python3 -m venv --system-site-packages ~/Projects/my_tryton_install
On which side do you get this error? On the server side or the client side?
Normally I just download the source code, extract it and run it so no virtual environment for the client. You are missing some parts like calendar view but for the first setup it should be ok. You can also install the desktop client through Flatpak Search for 'tryton' | Flathub
I am getting the error on the client side. The client is installed in the same virtual environment as the server. When starting the client from the activated virtual environment with the command ‘tryton’ I get the error.
In the second run I was following your suggestion to create a new user and using the /srv/trydoc location because ultimately I want to create a production environment. Thus a new user in a separate environment are good in terms of security, I guess.
AHHH, you got me! You cannot run the client as that user because it’s a system user not a regular user. So running the client from the environment as that new user won’t work. You should run the client as your regular user.
The new user is added specific for running Tryton indeed. So when you do other things on the server you don’t disrupt the user but also don’t give it rights by accident to execute other programs you have running.
ok, that’s exactly what I want. I guess the next step will be to make the server available on the internet which you descibe in great detail here 6747. I will try to use your protocol and adapt it to apache2.
I am using Apache2 for hosted PHP apps, and had planned to follow @edbo’s production server NginX/Gunicorn recipe, but if you post your adventure I will eagerly follow to decide if I should instead my existing Apache stack. I expect an NginX/Gunicorn stack to be more efficient in terms of server CPU cycles and memory, but it will also require more learning and maintenance effort.
You may find the “How we used Tryton to build an insurance ERP” presentation at TUB 2016 of interest because it describes in considerable detail the challenges Coopengo surmounted to achieve their desired level of operations (the presentation refers to 1M invoices per month for 1M insurance contracts, and iiuc the video mentions the number of simultaneous users). The presentation is a few years old, but I think the technology is still relevant (spoiler, they use NginX).
You can also use Gunicorn with Apache. So the difference will then between NginX and Apache as reverse proxy. Personally I don’t think there will be a huge difference between them. NginX got popular because it was very easy to configure as reverse proxy.
I haven’t seen the whole video but generating 1M invoices is all backend work, so basically the webserver is sleeping, but Gunicorn or other WSGI server is hard at work. Also there are now worker queue’s which can do work in parallel but the biggest bottleneck is the invoice number sequence which should not have holes. That’s still a sequential process which slows down the whole operation.
Yes, I confirm I’m happy with Apache2.
I created a bash script in /srv/tryloc/ which activates the virtual env and starts the server as trysysuser. When I su to trysysuser and cd to /srv/tryloc, the commands work but in a script the commands don’t work, the . /bin/activate command is executed but the server is not started.
The plan is to start a script as ‘home-user’ which starts the server as trysysuser and then starts the client as ‘home-user’
How can I achieve this?
I’m trying to understand this why you would do that? What you can do is to automatically start the server on booting your PC with a systemd file. Take a look at https://discuss.tryton.org/t/deploying-tryton-with-a-python-virtual-environment to get Gunicorn up-and-running which should be enough.
For development purposes I would recommend to open a terminal and start the server from there, so you can see the errors when they pop up, and start another terminal to run the client or use the prebuild one like Flatpak.
OK, thanks, I see what you mean.
Just in case someone is curious about the outcome of the production level installation with the apache2/gunicorn combination.
In a nutshell: the system is up and running, the tryton server can be accessed through the internet (I tested that with a desktop client, not with the web client).
What I did:
Prerequisite: webserver linked to a domain name with a DNS A record and port 8000 open.
If the gunicorn server is running you can reach your trytond server through the internet at http://<your.domain>