Configuración del sistema¶

Este documento describe los pasos para configurar Odoo en producción o en un servidor interno. Sigue la instalación y no es realmente necesario para un desarrollo que no está expuesto a internet.

Advertencia

Si está configurando un servidor público, asegúrese de revisar sus recomendaciones de seguridad.

dbfilter¶

Odoo es un sistema de tenencia múltiple: es posible que un solo sistema de Odoo ejecute y sirva varias instancias de la base de datos. También puede tener varias personalizaciones (desde cómo se cargan los módulos) dependiendo la base de datos actual.

Esto no es un problema al trabajar en el backend (cliente web) como un usuario de la empresa que inició sesión: la base de datos se puede seleccionar al iniciar sesión y las personalizaciones se cargan después.

Sin embargo, esto sí es un problema para usuarios que no iniciaron sesión (portal, sitio web) y no están ligados a la base de datos: Odoo necesita saber qué base de datos se deberían usar para cargar la página de sitio web o realizar la operación. Si la tenencia múltiple no se usa, no será un problema, ya que solo hay una base de datos para usar, pero si hay varias bases de datos a las que se pueden acceder, Odoo necesita una regla para saber cuál debe de usuar.

Ese es uno de los propósitos de --db-filter: especifica cuál es la base de datos que se debe seleccionar dependiendo en el nombre de host (dominio) que se solicita. El valor es una expresión regular, posiblemente incluyendo el nombre de host con inyección dinámica (%h) o el primer subdominio (%d) mediante el cual se accede al sistema.

Para servidores que alojan varias bases de datos en producción, especialmente si se usa sitio web, el dbfilter debe estar configurado, de lo contrario un número de funciones no trabajarán correctamente.

Ejemplos de configuración¶

Mostrar solo las bases de datos con nombres que empiecen con “miempresa”

en el archivo de configuración configure:

[options]
dbfilter = ^mycompany.*$

Mostrar solo las bases de datos que coinciden con el primer subdominio después de www: por ejemplo, la base de datos «miempresa» se enseñará si la solicitud entreante se envió a www.miempresa.com o a miempresa.co.uk, pero no para www2.miempresa.com o serviciodeasistencia.miempresa.com.

en el archivo de configuración configure:

[options]
dbfilter = ^%d$

Nota

Configurar un --db-filtro es una parte importante para asegurar el despliegue. Una vez que funcione correctamente y solo se vincule una base de datos por nombre de host, es muy recomendable bloquear el acceso de las pantallas de gerencia a la base de datos, use el parámetro de inicio --no-database-list para evitar listar sus bases de datos y para bloquear el acceso a las pantallas de gerencia de la base de datos. También vea security.

PostgreSQL¶

Por defecto, PostgreSQL solo permite la conexión con UNIX mediante sockets y loopback (desde «localhost», la misma máquina en la que está instalada el servidor PostgreSQL).

El socket de UNIX está bien si quiere que Odoo y PostgreSQL se ejecuten en la misma máquina y es lo predeterminado cuando no se brinda un alojamiento, pero si quiere que Odoo y PostgreSQL se ejecuten en diferentes máquinas 1 necesitará escuchar las interfaces de la red 2, ya sea:

Solo acepte conexiones loopback y use un SSH tunel entre la máquina en la que Odoo se ejecutra y la máquina en la que PostgreSQL se ejecuta, después configure Odoo para conectarse para su lado del tunel.
Aceptar conexiones a la máquina en la que Odoo está instalado, posiblemente en ssl (vea ajustes de conexión con PostgreSQL para más detalles), después configure Odoo para conectarlo con la red.

Ejemplo de configuración¶

Permitir la conexión tcp en alojamiento local
Permitir la conexión tcp desde la red 192.168.1.x

in /etc/postgresql/9.5/main/pg_hba.conf set:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

in /etc/postgresql/9.5/main/postgresql.conf set:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Configurando Odoo¶

Odoo es un software que de inmediato se puede conectar a postgres locales con un socket UNIX mediante el puerto 5432. Esto se puede anular con las opciones de la base de datos cuando su implementación no es local o no usa la configuración predeterminada de la instalación.

La Instalación en un paquete creará un nuevo usuario (odoo) de manera automática y lo configurará como el usuario de la base de datos.

La configuración de admin_passwd protege las pantallas de gestión de la base de datos. Esta configuración solo se puede usar con los archivos de configuración y simplemente se revisa antes de realizar alteraciones a la base de datos. Debe estar configurado a un valor generado de manera aleatoria para asegurar que terceros no pueden usar esta interfaz.
Todas las operaciones de la base de datos usan las opciones de base de datos, incluyendo la pantalla de gestión de las bases de datos. Para que la pantalla de gestión funcione, el usuario de PostgreSQL necesita tener el derecho createdb.
Los usuarios siempre pueden abandonar las bases de datos que les pertenecen. Para que la pantalla de gestión de la base de datos deje de ser funcional, el usuario de PostgreSQL necesita crearse con no-createdb y otro usuario PostgreSQL debe ser el dueño de la base de datos.

Advertencia
el usuario PostgreSQL no puede* ser un superusuario.

Ejemplo de configuración¶

conéctese a un servidor PostgreSQL en 192.168.1.2
puerto 5432
use una cuenta de usuario «odoo»,
con «pwd» como contraseña
filtre solo la base de datos con nombres que empiecen en «miempresa»

en el archivo de configuración configure:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

SSL entre Odoo y PostgreSQL¶

Desde Odoo 11.0 puede aplicar la conexión entre Odoo y PostgreSQL. En Odoo, db_sslmode controla la seguridad ssl de la conexión con un valor que puede ser «desabilitar», «permitir», «preferir», «requerir», «verificar-ca», o «verificar-completo»

PostgreSQL Doc

Servidor built-in¶

Odoo incluye servidores internos HTTP, cron y live-chat; y usa multihilos o multiprocesos.

The multi-threaded server is a simpler server primarily used for development, demonstrations, and its compatibility with various operating systems (including Windows). A new thread is spawned for every new HTTP request, even for long-running requests such as long polling. Extra daemonic cron threads are spawned too. Due to a Python limitation (GIL), it doesn’t make the best use of the hardware.

El servidor multihilos es el que se usa como predeterminado, también para los contenedores docker. Se selecciona no marcando la opción --workers o estableciéndola en 0.

El servidor multiprocesos es un servidor avanzado que se usa para producción. No esta sujeto a la misma limitación Python (GIL) en cuanto al uso de recursos, y por lo tanto, aprovecha mucho mejor el hardware. Al momento de iniciar un nuevo servidor, se crea una piscina de trabajadores (pool of workers). Se genera otro worker HTTP por evento en un puerto alternativo, así como otros cron workers adicionales. Un proceso reaper configurable monitorea el uso y puede detener/reiniciar workers.

El servidor multiprocesos es opcional. Lo puede seleccionar estableciendo la opción --workers en non-null integer.

Nota

El servidor multiprocesos no está disponible para Windows porque está personalizado para servidores de Linux.

Cálculo del número de workers¶

Regla general : (#CPU * 2) + 1
Los workers del cron necesitan CPU
1 worker ~= 6 usuarios concurrentes

cálculo del tamaño de la memoria¶

Consideramos que el 20% de las solicitudes son serias, mientras que el 80% son más simples.
Se estima que un trabajador pesado consume alrededor de 1GB de RAM una vez que todos los campos computados y las peticiones SQL estén bien diseñadas, etc.
Se estima que un trabajador ligero en el mismo escenario consume alrededor de 150MB de RAM

RAM necesario = #trabajador * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Chat en vivo¶

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

Ejemplo de configuración¶

Servidor con 4 CPU, 8 Thread
60 usuarios concurrentes
60 users / 6 = 10 <- theorical number of worker needed
(4 * 2) + 1 = 9 <- theorical maximal number of worker
Usaremos 8 workers + 1 para el cron. También usaremos un sistema de monitoreo para medir la carga del cpu y revisar que sea entre 7 y 7.5.
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3Go RAM para Odoo

en el archivo de configuración:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS¶

No importa si el acceso es mediante sitio web/cliente web o servicio web, Odoo transmite información de autenticación en cleartext. Esto significa que una implementación de Odoo segura debe usar HTTPS3. La terminación SSL se puede implementar con cualquier proxy de terminación SSL, pero requiere la siguiente configuración:

Activar el modo proxy de Odoo. Esto solo debería estar activado cuando Odoo esté detrás de un proxy reverso.
Configurar la terminación SSL del proxy (ejemplo de terminación Nginx)
Configurar el proxy en sí (ejemplo Nginx del proxy)
Su terminación proxy SSL también debería de redirigir conexiones no seguras automáticamente para asegurar el puerto

Ejemplo de configuración¶

Redirigir solicitudes http a https
Solicitudes proxy a odoo

en el archivo de configuración configure:

proxy_mode = True

en /etc/nginx/sites-enabled/odoo.conf configure:

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}

# http -> https
server {
  listen 80;
  server_name odoo.mycompany.com;
  rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443 ssl;
  server_name odoo.mycompany.com;
  proxy_read_timeout 720s;
  proxy_connect_timeout 720s;
  proxy_send_timeout 720s;

  # Add Headers for odoo proxy mode
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Real-IP $remote_addr;

  # SSL parameters
  ssl_certificate /etc/ssl/nginx/server.crt;
  ssl_certificate_key /etc/ssl/nginx/server.key;
  ssl_session_timeout 30m;
  ssl_protocols TLSv1.2;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;

  # log
  access_log /var/log/nginx/odoo.access.log;
  error_log /var/log/nginx/odoo.error.log;

  # Redirect longpoll requests to odoo longpolling port
  location /longpolling {
    proxy_pass http://odoochat;
  }

  # Redirect requests to odoo backend server
  location / {
    proxy_redirect off;
    proxy_pass http://odoo;
  }

  # common gzip
  gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
  gzip on;
}

Odoo como una aplicación WSGI¶

También es posible montar Odoo como una aplicación WSGI estándar. Odoo proporciona la base para un script de lanzamiento WSGI como odoo-wsgi.example.py. El script debe personalizarse (posiblemente después de copiarlo desde el directorio de configuración) para realizar la configuración correctamente en odoo.tools.config y no en la línea de comando o archivo de configuración.

Sin embargo, el servidor WSGI solo mostrará el extremo HTTP principal para el cliente web, sitio web y servicio web API. Como Odoo ya no controla la creación de workers, ya no puede configurar el cron o los workers del chat en vivo.

Workers de cron¶

Se requiere que inicie unos de los servidores incluidos en Odoo junto al servidor WSGI para procesar trabajos cron. Ese servidor debe estar configurado para procesar solamente crons y no solicitudes HTTPS. Para ello debe establecer la opción --no-http o ajustar la configuración del archivo como http_enable = False.

En sistemas parecidos a Linux, se le recomienda utilizar el servidor multiprocesos en lugar del multihilos para beneficiarse del mejor uso de hardware e incrementar la estabilidad usando las opciones cli --workers=-1 y --max-cron-threads=n.

Chat en vivo¶

Using a gevent-compatible WSGI server is required for the correct operation of the live chat feature. That server should be able to handle many simultaneous long-lived HTTP requests but doesn’t need a lot of processing power. All requests whose path starts with /longpolling should be directed to that server. A regular (thread/process-based) WSGI server should be used for all other requests.

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

Serving Static Files¶

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

Odoo static files live in each module’s static/ folder, so static files can be served by intercepting all requests to /MODULE/static/FILE, and looking up the right module (and file) in the various addons paths.

Seguridad¶

Para empezar, tome en cuenta que asegurar un sistema de información es un proceso continuo, no una operación de una sola vez. En cualquier momento, su entorno solo será tan seguro como el vínculo más débil.

No crea que esta sección es la única lista de medidas para prevenir todos los problemas de seguridad. Esta lista solo es un resumen de las cosas más importantes que debe incluir en su plan de acción de seguridad. Lo demás vendrá de las mejores prácticas de seguridad para su sistema operativo y distribución. Las mejores prácticas en cuanto a usuarios, contraseñas y la gestión del control de acceso, etc.

Al desplegar un servidor con acceso a internet, asegúrese de considerar los siguientes temas relacionados a la seguridad:

Siempre configure una contraseña de administrador del super-admin que sea fuerte y restrinja el acceso a la gestión de la página web tan pronto como se configure el sistema. Vea Seguridad del gestor de la base de datos.
Elija inicios de sesión únicos y contraseñas fuertes para todas las cuentas de administrador en todas las bases de datos. No use «admin» como inicio de sesión. No use los mismos inicios de sesión para operaciones del día a día, solo para controlar o gestionar la instalación. Nunca use contraseñas automáticas, como admin/admin, ni si quiera para bases de dato de prueba o de secuenciamiento.
No instale los datos demo en servidores con acceso a internet. Las bases de datos con información de demo tienen inicios de sesión predeterminados y contraseñas que se podrían usar para ingresar a sus sistemas y puede ser un gran problema, incluso en sistemas de desarrollo o secuenciamiento.
Use filtros apropiados para la base de datos ( --db-filter) para restringir la visibilidad de sus bases de datos según al nombre de host. Vea dbfilter. También puede usar -d para obtener su propia lista (separada por comas) de bases de datos que puede filtrar, en lugar de dejar que el sistema obtenga todo desde el backend de la base de datos.
Una vez que su db_name y db_filter están configurados y solo emparejan las bases de datos por nombre de host. Debe poner la opción de configuración a Falso, para prevenir que se enlisten las bases de datos por completo y para bloquear el acceso a la pantalla de gestión de la base de datos (esto también se muestra como --no-database-list en la opción de la línea de comando).
Asegúrese de que el usuario de PostgreSQL (--db_user) no sea un super usuario y que sus bases de datos le pertenezcan a un usuario diferente. Por ejemplo, puede que los super usuarios de postgres sean los dueños si usa un db_user especializado y no privilegiado. También vea Configurando Odoo.
Instale las versiones más recientes para que las instalaciones siempre estén actualizadas, ya sea por medio de GitHub, o descargando la versión más reciente de https://www.odoo.com/page/download o http://nightly.odoo.com
Configure su servidor en un modo multiproceso con límites adecuados que sean igual a su uso habitual (memoria/CPU/tiempos de espera). También vea Servidor built-in.
Ejecute Odoo con un servicio web que proporcione una terminación HTTPS con un certificado SSL válido para evitar intercepción en comunicaciones de cleartext. Los certificados de SSL son baratos y existen muchas opciones gratis. Configure el proxy web para limitar el tamaño de las solicitudes, configure tiempos de espera apropiados y después active la opción de modo proxy. También vea HTTPS.
Si necesita permitir el acceso remoto SSH a sus servidores, asegúrese de configurar una contraseña fuerte para todas las cuentas, no solo root. Le recomendamos deshabilitar por completo la autenticación a base de contraseña y solo permita la autenticación con clave pública. También considere restringir el acceso a través de VPN y solo permita IP de confianza en el firewall, o ejecutar un sistema de detección a fuerza bruta como un fail2ban o equivalente.
Considere instalar un factor de límite de tasa en su proxy o firewall para así evitar ataques de fuerza bruta y negar ataques al servicio. También vea Bloquear ataques de fuerza bruta para medidas específicas.

Muchos proveedores de red brindan migración automática para ataques DDOS (ataque de denegación de servicio, por su sigla en inglés), pero este es un servicio opcional. Le recomendamos que lo consulte con ellos.
Siempre que sea posible, aloje sus instancias de demostración, prueba, o secuenciamiento en máquinas que sean diferentes a las de producción. Aplique las mismas precauciones de seguridad que para producción.
Si su servidor público de Odoo tiene acceso a recursos o servicios sensibles de la red interna (por ejemplo, a través de una VLAN privada), implemente reglas de firewall apropiadas para proteger esos recursos internos. Esto es para asegurar que el servidor de Odoo no se pueda usar accidentalmente (o como resultado de las acciones de un usuario malicioso) para acceder o alterar los recursos internos. Esto se puede hacer usualmente aplicando una regla de denegación automática de salida en el firewall. Una vez que lo haga solo autorice explícitamente el acceso a recursos internos a los que el servidor de Odoo tiene que acceder. El control de acceso al tráfico IP de Systemd también puede servir para implementarse por control de acceso a la red de procesos.
Si su servidor público de Odoo está detrás de un firewall de aplicaciones web, un balanceo de carga, un servicio de protección DDOS transparente (como CloudFlare), o un dispositivo similar a nivel de red, querrá evitar tener acceso directo al sistema de Odoo. Generalmente es difícil mantener el final de las direcciones IP de sus servidores de Odoo secreto. Por ejemplo, pueden aparecer en registros del servidor web al consultar sistemas públicos, o en los encabezados de los correos que Odoo publica. En cada situación, es posible que quiera configurar su firewall para que no se pueda ingresar a las terminales públicamente, excepto por las direcciones IP de su WAF, balanceo de carga, o servicio proxy. Los proveedores de servicios como CloudFlare usualmente mantienen una lista pública de sus rangos de direcciones IP para este propósito.
Si está alojando a varios clientes, aísle datos de clientes y archivos el uno de otro usando contenedores o técnicas de «jail».
Configure respaldos diarios para sus bases de datos y los datos de los archivos guardados, cópielos a un servidor de almacenamiento remoto que no sea accesible desde el servidor en sí.
Le recomendamos que despliegue Odoo en Linux y no en Windows. Pero si decide hacerlo en una plataforma de Windows de todas maneras, debe realizar una minuciosa revisión de seguridad del servidor, proceso que no cubre esta guía.

Bloquear ataques de fuerza bruta¶

Para despliegues en internet, los ataques a fuerza bruta en las contraseñas de los usuarios son muy comunes. Esta amenaza no se pueda pasar por alto para los servidores de Odoo. Odoo registra una entrada cada que se realiza un intento de inicio de sesión y reporta los resultados: éxito o fallo, así como el objetivo de inicio de sesión e IP fuente.

Los registros de entradas tendrán el siguiente formato.

Inicio de sesión fallido:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login failed for db:db_name login:admin from 127.0.0.1

Inicio de sesión exitoso:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login successful for db:db_name login:admin from 127.0.0.1

Estos registros se pueden analizar fácilmente con un sistema de prevención de intrusos como fail2ban.

Por ejemplo, la siguiente definición del filtro fail2ban debe emparejarse con un inicio de sesión fallido:

[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =

Esto se podía usar con una definición de jail para bloquear los ataques IP en HTTP.

Así es como se podría ver por bloquear la IP por 15 minutos cuando se detectan 10 intentos fallidos de inicio de sesión desde la misma IP en 1 minuto:

[odoo-login]
enabled = true
port = http,https
bantime = 900  ; 15 min ban
maxretry = 10  ; if 10 attempts
findtime = 60  ; within 1 min  /!\ Should be adjusted with the TZ offset
logpath = /var/log/odoo.log  ;  set the actual odoo log path here

Seguridad del gestor de la base de datos¶

Configurando Odoo menciona admin_passwd de paso.

Esta configuración se usa en todas las pantallas de gestión de la base de datos (para crear, borrar, descartar o restablecer bases de datos).

Si no se debería acceder a las pantallas de gestión de ninguna manera, debe establecer la opción de configuración list_db a Falso, para bloquear el acceso a todas las pantallas de gestión o selección de bases de datos.

Advertencia

¡Le recomendamos deshabilitar el gestor de la base de datos para un sistema en internet! Está hecha como una herramienta de desarrollo/demo, para facilitar la creación y gestión rápida de las bases de datos. No está diseñada para usarse en producción, además de que puede exponer funciones peligrosas para los atacantes. Tampoco está diseñado para ejecutar bases de datos grandes y puede que active límites de memoria.

En sistemas en producción, las operaciones de gestión en la base de datos siempre las debe realizar el administrador del sistema, incluyendo el suministro de bases de datos nuevas y respaldos automáticos.

Asegúrese de configurar un parámetro db_name apropiado (y también db_filter, opcionalmente) para que el sistema pueda determinar la base de datos objetivo para cada petición, de lo contrario, se bloqueará a los usuarios ya que no se permitirá que ellos mismos elijan la base de datos.

Si solo se puede acceder a las pantallas de gestión desde un grupo de máquinas específicas, use las funciones de proxy del servidor para bloquear el acceso a todas las rutas que empiecen con /web/database, excepto (quizá) /web/database/selector que muestra la pantalla de selección de base de datos.

Si se debe de mantener el acceso a la pantalla de gestión de la base de datos, la configuración de admin_passwd se debe de cambiar de la predeterminada que es admin: esta contraseña se debe de revisar antes de permitir operaciones que alteren la base de datos.

Se debe guardar en un lugar seguro y se debe de generar aleatoriamente, p. ej.

$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

que generará una cadena imprimible pseudoaleatoria de 32 caracteres.

Navegadores compatibles¶

Odoo es compatible con todos los navegadores web principales, siempre y cuando sigan siendo compatibles con sus creadores.

Estos son los navegadores compatibles:

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

Advertencia

Asegúrese de que su navegador esté actualizado y que el creador le siga dando soporte antes de llenar un reporte de bug.

Nota

Desde Odoo 13.0, ES6 es compatible. Por lo tanto, ya no se da asistencia a IE.

1: para que varias instalaciones de Odoo usen la misma base de datos PostgreSQL, o brindar más recursos de cálculo para el software.
2: técnicamente una herramienta como socat puede utilizarse para proxy UNIX sockets a través de redes, pero eso es sobre todo para el software que sólo se puede utilizar a través de UNIX sockets
3: o puede ser accesible solo a través de una red interna de comunicación de paquetes, pero para esto se necesitan paquetes seguros, protección contra suplantación de ARP y excluir el uso de WiFi. Incluso en redes seguras de comunicación de paquetes, se recomienda el despliegue en HTTPS y los costos posibles se reducen, ya que los certificados «autofirmados» son más fáciles de desplegar en un entorno controlado que en Internet.

Edit on GitHub