Odoo Conf

[Rocki Eibl]

Thisdocument describes basic steps to set up Odoo in production or on aninternet-facing server. It follows installation, and isnot generally necessary for a development systems that is not exposed on theinternet.

That is one of the purposes of --db-filter:it specifies how the database should be selected based on the hostname (domain)that is being requested. The value is a regular expression, possiblyincluding the dynamically injected hostname (%h) or the first subdomain(%d) through which the system is being accessed.

Setting a proper --db-filter is an important partof securing your deployment.Once it is correctly working and only matching a single database per hostname, itis strongly recommended to block access to the database manager screens,and to use the --no-database-list startup parameter to prevent listingyour databases, and to block access to the database management screens.See also security.

UNIX socket is fine if you want Odoo and PostgreSQL to execute on the samemachine, and is the default when no host is provided, but if you want Odoo andPostgreSQL to execute on different machines 1 it willneed to listen to network interfaces 2, either:

Out of the box, Odoo connects to a local postgres over UNIX socket via port5432. This can be overridden using the database options when your Postgres deployment is notlocal and/or does not use the installation defaults.

The database management screens are protected by the admin_passwdsetting. This setting can only be set using configuration files, and issimply checked before performing database alterations. It should be set toa randomly generated value to ensure third parties can not use thisinterface.

Users can always drop databases they own. For the database management screento be completely non-functional, the PostgreSQL user needs to be created withno-createdb and the database must be owned by a different PostgreSQL user.

The multi-processing server is a full-blown server primarily used for production. It is notliable to the same Python limitation (GIL) on resource usage and hence makes the best use of thehardware. A pool of workers is created upon server startup. New HTTP requests are queued by the OSuntil there are workers ready to process them. An extra event-driven HTTP worker for the live chatis spawned on an alternative port. Extra cron workers are spawned too. A configurable processreaper monitors resource usage and can kill/restart failed workers.

In multi-processing, a dedicated LiveChat worker is automatically started and listens onthe --gevent-port. By default, the HTTP requests will keepaccessing the normal HTTP workers instead of the LiveChat one. You must deploy a proxy in front ofOdoo and redirect incoming requests whose path starts with /websocket/ to the LiveChat worker.You must also start Odoo in --proxy-mode so it uses the realclient headers (such as hostname, scheme, and IP) instead of the proxy ones.

Add the Strict-Transport-Security header to all requests, in order to preventbrowsers from ever sending a plain HTTP request to this domain. You will needto maintain a working HTTPS service with a valid certificate on this domain atall times, otherwise your users will see security alerts or be entirely unableto access it.

It is also possible to mount Odoo as a standard WSGI application. Odooprovides the base for a WSGI launcher script as odoo-wsgi.example.py. Thatscript should be customized (possibly after copying it from the setup directory) to correctly set theconfiguration directly in odoo.tools.config rather than through thecommand-line or a configuration file.

However the WSGI server will only expose the main HTTP endpoint for the webclient, website and webservice API. Because Odoo does not control the creationof workers anymore it can not setup cron or livechat workers

Starting one of the built-in Odoo servers next to the WSGI server is required to process cron jobs.That server must be configured to only process crons and not HTTP requests using the--no-http cli option or the http_enable = False configurationfile setting.

On Linux-like systems, using the multi-processing server over the multi-threading one is recommendedto benefit from better hardware usage and increased stability, i.e., usingthe --workers=-1 and --max-cron-threads=n cli options.

The Odoo cron server can also be used to serve the live chat requests. Just dropthe --no-http cli option from the cron server and make sure requestswhose path starts with /websocket/ are directed to this server, either onthe --http-port (multi-threading server) or onthe --gevent-port (multi-processing server).

For development convenience, Odoo directly serves all static files and attachments in its modules.This may not be ideal when it comes to performances, and static files should generally be served bya static HTTP server.

Attachments are files stored in the filestore which access is regulated by Odoo. They cannot bedirectly accessed via a static web server as accessing them requires multiple lookups in thedatabase to determine where the files are stored and whether the current user can access them ornot.

Nevertheless, once the file has been located and the access rights verified by Odoo, it is a goodidea to serve the file using the static web server instead of Odoo. For Odoo to delegate servingfiles to the static web server, the X-Sendfile (apache) orX-Accel (nginx) extensionsmust be enabled and configured on the static web server. Once it is set up, start Odoo with the--x-sendfile CLI flag (this unique flag is used for bothX-Sendfile and X-Accel).

Do not install demo data on internet-facing servers. Databases with demo data containdefault logins and passwords that can be used to get into your systems and cause significanttrouble, even on staging/dev systems.

Use appropriate database filters ( --db-filter)to restrict the visibility of your databases according to the hostname.See dbfilter.You may also use -d to provide your own (comma-separated)list of available databases to filter from, instead of letting the system fetchthem all from the database backend.

Once your db_name and dbfilter are configured and only match a single databaseper hostname, you should set list_db configuration option to False, to preventlisting databases entirely, and to block access to the database management screens(this is also exposed as the --no-database-listcommand-line option)

Make sure the PostgreSQL user (--db_user) is not a super-user,and that your databases are owned by a different user. For example they could be owned bythe postgres super-user if you are using a dedicated non-privileged db_user.See also Configuring Odoo.

Run Odoo behind a web server providing HTTPS termination with a valid SSL certificate,in order to prevent eavesdropping on cleartext communications. SSL certificates arecheap, and many free options exist.Configure the web proxy to limit the size of requests, set appropriate timeouts,and then enable the proxy mode option.See also HTTPS.

If you need to allow remote SSH access to your servers, make sure to set a strong passwordfor all accounts, not just root. It is strongly recommended to entirely disablepassword-based authentication, and only allow public key authentication. Also considerrestricting access via a VPN, allowing only trusted IPs in the firewall, and/orrunning a brute-force detection system such as fail2ban or equivalent.

If your public-facing Odoo server has access to sensitive internal network resourcesor services (e.g. via a private VLAN), implement appropriate firewall rules toprotect those internal resources. This will ensure that the Odoo server cannotbe used accidentally (or as a result of malicious user actions) to access or disruptthose internal resources.Typically this can be done by applying an outbound default DENY rule on the firewall,then only explicitly authorizing access to internal resources that the Odoo serverneeds to access.Systemd IP traffic access controlmay also be useful to implement per-process network access control.

If your public-facing Odoo server is behind a Web Application Firewall, a load-balancer,a transparent DDoS protection service (like CloudFlare) or a similar network-leveldevice, you may wish to avoid direct access to the Odoo system. It is generallydifficult to keep the endpoint IP addresses of your Odoo servers secret. For examplethey can appear in web server logs when querying public systems, or in the headersof emails posted from Odoo.In such a situation you may want to configure your firewall so that the endpointsare not accessible publicly except from the specific IP addresses of your WAF,load-balancer or proxy service. Service providers like CloudFlare usually maintaina public list of their IP address ranges for this purpose.

Deploying Odoo on Linux is strongly recommended over Windows. Should you choose neverthelessto deploy on a Windows platform, a thorough security hardening review of the server should beconducted and is outside of the scope of this guide.

For internet-facing deployments, brute force attacks on user passwords are very common, and thisthreat should not be neglected for Odoo servers. Odoo emits a log entry whenever a login attemptis performed, and reports the result: success or failure, along with the target login and source IP.

It is strongly recommended to disable the Database Manager for any internet-facingsystem! It is meant as a development/demo tool, to make it easy to quickly createand manage databases. It is not designed for use in production, and may even exposedangerous features to attackers. It is also not designed to handle large databases,and may trigger memory limits.

There may be instances where the master password is misplaced, or compromised, and needs to bereset. The following process is for system administrators of an Odoo on-premise database detailinghow to manually reset and re-encrypt the master password.

When creating a new on-premise database, a random master password is generated. Odoo recommendsusing this password to secure the database. This password is implemented by default, so there is asecure master password for any Odoo on-premise deployment.

3a8082e126