Configuración del sistema¶

Este documento describe los pasos básicos para configurar Odoo en producción o en un servidor con acceso a Internet. Sigue instalación, y generalmente no es necesario para sistemas de desarrollo que no están expuestos en Internet.

Advertencia

Si está configurando un servidor público, asegúrese de consultar nuestras recomendaciones de `seguridad.

filtro db¶

Odoo es un sistema multiinquilino: un único sistema Odoo puede ejecutar y servir varias instancias de bases de datos. También es altamente personalizable, con personalizaciones (a partir de los módulos que se cargan) dependiendo de la «base de datos actual».

Esto no es un problema cuando se trabaja con el backend (cliente web) como usuario de la empresa que ha iniciado sesión: la base de datos se puede seleccionar al iniciar sesión y las personalizaciones se pueden cargar después.

Sin embargo, es un problema para los usuarios que no han iniciado sesión (portal, sitio web) y que no están vinculados a una base de datos: Odoo necesita saber qué base de datos debe usarse para cargar la página del sitio web o realizar la operación. Si no se utiliza multi-inquilino, eso no es un problema, solo hay una base de datos para usar, pero si hay varias bases de datos accesibles, Odoo necesita una regla para saber cuál debe usar.

Ese es uno de los propósitos de db-filter: especifica cómo se debe seleccionar la base de datos en función del nombre de host (dominio) que se solicita. El valor es una expresión regular, que posiblemente incluya el nombre de host inyectado dinámicamente (%h) o el primer subdominio (%d) a través del cual se accede al sistema.

Para servidores que alojan varias bases de datos en producción, especialmente si se utiliza sitio web, debe configurarse dbfilter; de lo contrario, varias funciones no funcionarán correctamente.

Ejemplos de configuración¶

Mostrar solo bases de datos con nombres que comiencen con “miempresa”

[options]
dbfilter = ^mycompany.*$

Mostrar sólo las bases de datos que coincidan con el primer subdominio después de www: por ejemplo, la base de datos «miempresa» se mostrará si la solicitud entrante se envió a www.miempresa.com o miempresa.co.uk ``, pero no para ``www2.mycompany.com o helpdesk.mycompany.com.

[options]
dbfilter = ^%d$

Nota

Configurar un filtro de base de datos adecuado es una parte importante para proteger su implementación. Una vez que esté funcionando correctamente y solo coincida con una única base de datos por nombre de host, se recomienda bloquear el acceso a las pantallas del administrador de bases de datos y usar el parámetro de inicio --no-database-list para evitar que se incluyan sus bases de datos. y bloquear el acceso a las pantallas de gestión de la base de datos. Véase también seguridad.

PostgreSQL¶

De forma predeterminada, PostgreSQL solo permite conexiones a través de sockets UNIX y conexiones de bucle invertido (desde «localhost», la misma máquina en la que está instalado el servidor PostgreSQL).

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

Acepte únicamente conexiones loopback y use un túnel SSH entre la máquina en la que se ejecuta Odoo y aquella en la que se ejecuta PostgreSQL, luego configure Odoo para conectarse a su extremo del túnel
Acepte conexiones a la máquina en la que está instalado Odoo, posiblemente a través de SSL (consulte Configuración de conexión PostgreSQL para obtener más detalles), luego configure Odoo para conectarse a través de la red.

Ejemplo de configuración¶

Permitir conexión TCP en localhost
Permitir conexión TCP desde la red 192.168.1.x

en /etc/postgresql/<SU VERSIÓN POSTGRESQL>/main/pg_hba.conf establece:

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

en /etc/postgresql/<SU VERSIÓN POSTGRESQL>/main/postgresql.conf establezca:

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

Configurando Odoo¶

De fábrica, Odoo se conecta a un postgres local a través de un socket UNIX a través del puerto 5432. Esto se puede anular utilizando la base de datos cuando su implementación de Postgres no es local y/o no utiliza los valores predeterminados de instalación.

Los instaladores empaquetados crearán automáticamente un nuevo usuario (odoo) y lo configurarán como usuario de la base de datos.

Las pantallas de administración de bases de datos están protegidas por la configuración admin_passwd. Esta configuración solo se puede establecer mediante archivos de configuración y simplemente se verifica antes de realizar modificaciones en la base de datos. Debe establecerse en un valor generado aleatoriamente para garantizar que terceros no puedan utilizar esta interfaz.
Todas las operaciones de la base de datos utilizan la base de datos, incluida la pantalla de administración de la base de datos. Para que la pantalla de administración de la base de datos funcione es necesario que el usuario de PostgreSQL tenga el derecho createdb.
Los usuarios siempre pueden eliminar las bases de datos de su propiedad. Para que la pantalla de administración de la base de datos no funcione completamente, el usuario de PostgreSQL debe crearse con no-createdb y la base de datos debe ser propiedad de un usuario de PostgreSQL diferente.

Advertencia
el usuario de PostgreSQL no debe ser superusuario

Ejemplo de configuración¶

conectarse a un servidor PostgreSQL en 192.168.1.2
puerto 5432
usando una cuenta de usuario “odoo”,
con “pwd” como contraseña
filtrar solo bases de datos con un nombre que comienza con “miempresa”

[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 imponer una conexión SSL entre Odoo y PostgreSQL. en Odoo, db_sslmode controla la seguridad SSL de la conexión con un valor elegido entre “deshabilitar”, “permitir”, “preferir”, “requerir”, “verificar-ca” o “verificar-completo”

Documento PostgreSQL

Servidor incorporado¶

Odoo incluye servidores HTTP integrados, que utilizan multiproceso o multiprocesamiento.

Para uso en producción, se recomienda utilizar el servidor multiprocesamiento ya que aumenta la estabilidad, hace un uso algo mejor de los recursos informáticos y puede monitorearse y restringirse mejor.

Multiprocessing is enabled by configuring :option: a non-zero number of worker processes odoo-bin –workers, the number of workers should be based on the number of cores in the machine (possibly with some room for cron workers depending on how much cron work is predicted)
Los límites de trabajadores se pueden configurar según la configuración del hardware para evitar el agotamiento de los recursos.

Advertencia

El modo multiprocesamiento actualmente no está disponible en Windows.

Cálculo del número de trabajadores¶

Regla general: (#CPU * 2) + 1
Los trabajadores cron necesitan CPU
1 trabajador ~= 6 usuarios simultáneos

cálculo del tamaño de la memoria¶

Consideramos que el 20% de las solicitudes son solicitudes pesadas, mientras que el 80% son más simples.
Un trabajador pesado, cuando todos los campos calculados están bien diseñados, las solicitudes SQL están bien diseñadas,… se estima que consume alrededor de 1 GB de RAM.
Se estima que un trabajador más liviano, en el mismo escenario, consumirá alrededor de 150 MB de RAM.

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

Chat en vivo¶

En el multiprocesamiento, un trabajador de LiveChat dedicado se inicia automáticamente y escucha en odoo-bin –gevent-port pero el cliente no se conecta a él.

En su lugar, debe tener un proxy que redirija las solicitudes cuya URL comience con /websocket/ al puerto gevent. Otra solicitud debe enviarse mediante proxy al odoo-bin –http-port.

Para lograr tal cosa, necesitarás implementar un proxy inverso frente a Odoo, como nginx o apache. Al hacerlo, necesitará reenviar algunos encabezados http más a Odoo y activar proxy_mode en la configuración de Odoo para que Odoo lea esos encabezados.

Ejemplo de configuración¶

Servidor con 4 CPU, 8 subprocesos
60 usuarios simultáneos
60 usuarios / 6 = 10 <- número teórico de trabajadores necesarios
(4 * 2) + 1 = 9 <- número máximo teórico de trabajadores
Usaremos 8 trabajadores + 1 para cron. También usaremos un sistema de monitoreo para medir la carga de la CPU y verificar si está entre 7 y 7,5.
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3Go RAM para Odoo

[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¶

Ya sea que se acceda a través de un sitio web/cliente web o servicio web, Odoo transmite información de autenticación en texto sin cifrar. Esto significa que una implementación segura de Odoo debe usar HTTPS3. La terminación SSL se puede implementar mediante prácticamente cualquier proxy de terminación SSL, pero requiere la siguiente configuración:

Habilite el modo proxy de Odoo. Esto sólo debe habilitarse cuando Odoo está detrás de un proxy inverso
Configure el ejemplo de terminación de Nginx del proxy de terminación SSL.
Configure el proxy en sí. Ejemplo de proxy Nginx.
Su proxy de terminación SSL también debería redirigir automáticamente las conexiones no seguras al puerto seguro.

Ejemplo de configuración¶

Redirigir solicitudes http a https
Solicitudes de proxy para odoo

proxy_mode = True

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

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

# 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;

  # 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 websocket requests to odoo gevent port
  location /websocket {
    proxy_pass http://odoochat;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    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;
  }

  # Redirect requests to odoo backend server
  location / {
    # 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;
    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 aplicación WSGI¶

También es posible montar Odoo como una aplicación WSGI estándar. Odoo proporciona la base para un script de inicio WSGI como odoo-wsgi.example.py. Ese script debe personalizarse (posiblemente después de copiarlo del directorio de instalación) para establecer correctamente la configuración directamente en odoo.tools.config en lugar de a través de la línea de comandos o un archivo de configuración.

Sin embargo, el servidor WSGI solo expondrá el punto final HTTP principal para el cliente web, el sitio web y la API del servicio web. Debido a que Odoo ya no controla la creación de trabajadores, no puede configurar trabajadores cron o livechat.

Trabajadores cron¶

Para ejecutar trabajos cron para una implementación de Odoo como se requiere una aplicación WSGI

Un Odoo clásico (ejecutado a través de odoo-bin)
Conectado a la base de datos en la que se deben ejecutar trabajos cron a través de odoo-bin
El cual no debe estar expuesto a la red. Para garantizar que los ejecutores cron no sean accesibles a través de la red, es posible desactivar completamente el servidor HTTP integrado con odoo-bin –no-http` o estableciendo http_enable = False en el archivo de configuración.

Chat en vivo¶

El segundo subsistema problemático para las implementaciones de WSGI es LiveChat: mientras que la mayoría de las conexiones HTTP son relativamente cortas y liberan rápidamente su proceso de trabajo para la siguiente solicitud, LiveChat requiere una conexión de larga duración para cada cliente para poder implementar notificaciones casi en tiempo real. .

Esto está en conflicto con el modelo de trabajador basado en procesos, ya que paralizará los procesos de trabajo e impedirá que nuevos usuarios accedan al sistema. Sin embargo, esas conexiones de larga duración hacen muy poco y en su mayoría permanecen estacionadas esperando notificaciones.

Las soluciones para soportar livechat/motificaciones en una aplicación WSGI son:

Implemente una versión con subprocesos de Odoo (en lugar de una versión preforking basada en procesos) y redirija solo las solicitudes a URL que comiencen con /websocket/ a ese Odoo, este es el más simple y la URL de websocket puede duplicarse como instancia cron. .
Implemente un Odoo con eventos a través de odoo-gevent y solicitudes de proxy que comiencen con /websocket/ en el puerto gevent.

Servir archivos estáticos y adjuntos¶

Para comodidad del desarrollo, Odoo sirve directamente todos los archivos estáticos y adjuntos en sus módulos. Puede que esto no sea ideal cuando se trata de rendimiento, y los archivos estáticos generalmente deberían ser servidos por un servidor HTTP estático.

Sirviendo archivos estáticos¶

Los archivos estáticos de Odoo se encuentran en la carpeta static/ de cada módulo, por lo que los archivos estáticos se pueden servir interceptando todas las solicitudes a /MODULE/static/FILE y buscando el módulo correcto. (y archivo) en las distintas rutas de complementos.

Example

Digamos que Odoo se ha instalado a través de los paquetes de Debian para Community y Enterprise y –addons-path <odoo-bin –addons-path>` es '/usr/lib/python3/dist-packages/ odoo/complementos'.

Usando la configuración NGINX (https) anterior, se debe agregar el siguiente bloque de ubicación para servir archivos estáticos a través de NGINX.

location @odoo {
    # copy-paste the content of the / location block
}

# Serve static files right away
location ~ ^/[^/]+/static/.+$ {
    root /usr/lib/python3/dist-packages/odoo/addons;
    try_files $uri @odoo;
    expires 24h;
}

Example

Say Odoo has been installed via the source. The two git repositories for Community and Enterprise have been cloned in /opt/odoo/community and /opt/odoo/enterprise respectively and '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

Usando la configuración NGINX (https) anterior, se debe agregar el siguiente bloque de ubicación para servir archivos estáticos a través de NGINX.

location @odoo {
    # copy-paste the content of the / location block
}

# Serve static files right away
location ~ ^/[^/]+/static/.+$ {
    root /opt/odoo;
    try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;
    expires 24h;
}

Advertencia

La configuración real de NGINX que necesita depende en gran medida de su propia instalación. Los dos fragmentos anteriores solo resaltan dos configuraciones posibles y no pueden usarse tal como están.

Servir archivos adjuntos¶

Los archivos adjuntos son archivos almacenados en el almacén de archivos cuyo acceso está regulado por Odoo. No se puede acceder a ellos directamente a través de un servidor web estático, ya que acceder a ellos requiere múltiples búsquedas en la base de datos para determinar dónde están almacenados los archivos y si el usuario actual puede acceder a ellos o no.

Nevertheless, once the file has been located and the access rights verified by Odoo, it is a good idea to serve the file using the static web server instead of Odoo. For Odoo to delegate serving files to the static web server, the X-Sendfile (apache) or X-Accel (nginx) extensions must be enabled and configured on the static web server. Once it is set up, start Odoo with the CLI flag (this unique flag is used for both X-Sendfile and X-Accel).

Nota

La extensión X-Sendfile para Apache (y servidores web compatibles) no requiere ninguna configuración adicional.
La extensión X-Accel para NGINX requiere la siguiente configuración adicional:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
In case you don’t know what is the path to your filestore, start Odoo with the option and navigate to the /web/filestore URL directly via Odoo (don’t navigate to the URL via NGINX). This logs a warnings, the message contains the configuration you need.

Seguridad¶

Para empezar, tenga en cuenta que proteger un sistema de información es un proceso continuo, no una operación única. En cualquier momento, usted estará tan seguro como el eslabón más débil de su entorno.

Por lo tanto, no tome esta sección como la lista definitiva de medidas que evitarán todos los problemas de seguridad. Sólo pretende ser un resumen de las primeras cosas importantes que debe asegurarse de incluir en su plan de acción de seguridad. El resto vendrá de mejores prácticas de seguridad para tu sistema operativo y distribución, mejores prácticas en cuanto a usuarios, contraseñas y gestión de control de acceso, etc.

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

Establezca siempre una contraseña segura de administrador de superadministrador y restrinja el acceso a las páginas de administración de la base de datos tan pronto como se configure el sistema. Consulte Seguridad del administrador de bases de datos.
Elija inicios de sesión únicos y contraseñas seguras para todas las cuentas de administrador en todas las bases de datos. No utilice “admin” como inicio de sesión. No utilice esos inicios de sesión para operaciones diarias, solo para controlar/administrar la instalación. Nunca utilice contraseñas predeterminadas como admin/admin, ni siquiera para bases de datos de prueba/preparación.
No instale datos de demostración en servidores con acceso a Internet. Las bases de datos con datos de demostración contienen nombres de usuario y contraseñas predeterminados que pueden usarse para ingresar a sus sistemas y causar problemas importantes, incluso en sistemas de prueba/desarrollo.
Use appropriate database filters to restrict the visibility of your databases according to the hostname. See filtro db.You may also use to provide your own (comma-separated) list of available databases to filter from, instead of letting the system fetch them all from the database backend.
Once your db_name and db_filter are configured and only match a single database per hostname, you should set list_db configuration option to False, to prevent listing databases entirely, and to block access to the database management screens (this is also exposed as the command-line option)
Make sure the PostgreSQL user is not a super-user, and that your databases are owned by a different user. For example they could be owned by the postgres super-user if you are using a dedicated non-privileged db_user. See also Configurando Odoo.
Mantenga las instalaciones actualizadas instalando periódicamente las últimas versiones, ya sea a través de GitHub o descargando la última versión desde https://www.odoo.com/page/download o http://nightly.odoo.com
Configure su servidor en modo multiproceso con límites adecuados que coincidan con su uso típico (memoria/CPU/tiempos de espera). Véase también Servidor incorporado.
Run Odoo behind a web server providing HTTPS termination with a valid SSL certificate, in order to prevent eavesdropping on cleartext communications. SSL certificates are cheap, and many free options exist. Configure the web proxy to limit the size of requests, set appropriate timeouts, and then enable the option. See also HTTPS.
Si necesita permitir el acceso SSH remoto a sus servidores, asegúrese de establecer una contraseña segura para todas las cuentas, no solo para «root». Se recomienda encarecidamente deshabilitar por completo la autenticación basada en contraseña y permitir solo la autenticación con clave pública. También considere restringir el acceso a través de una VPN, permitiendo solo direcciones IP confiables en el firewall y/o ejecutando un sistema de detección de fuerza bruta como fail2ban o equivalente.
Considere instalar una limitación de velocidad adecuada en su proxy o firewall para evitar ataques de fuerza bruta y ataques de denegación de servicio. Ver también Bloquear ataques de fuerza bruta para medidas específicas.

Muchos proveedores de red brindan mitigación automática para ataques de denegación de servicio distribuido (DDOS), pero este suele ser un servicio opcional, por lo que debe consultar con ellos.
Siempre que sea posible, aloje sus instancias de demostración/prueba/ensayo de cara al público en máquinas diferentes a las de producción. Y aplique las mismas precauciones de seguridad que para la producción.
Si su servidor Odoo público tiene acceso a recursos o servicios confidenciales de la red interna (por ejemplo, a través de una VLAN privada), implemente reglas de firewall adecuadas para proteger esos recursos internos. Esto garantizará que el servidor Odoo no pueda usarse accidentalmente (o como resultado de acciones de usuarios maliciosos) para acceder o interrumpir esos recursos internos. Normalmente, esto se puede hacer aplicando una regla DENEGAR predeterminada de salida en el firewall y luego autorizando solo explícitamente el acceso a los recursos internos a los que el servidor Odoo necesita acceder. El control de acceso al tráfico IP de Systemd también puede ser útil para implementar el control de acceso a la red por proceso.
Si su servidor Odoo público está detrás de un firewall de aplicaciones web, un equilibrador de carga, un servicio de protección DDoS transparente (como CloudFlare) o un dispositivo similar a nivel de red, es posible que desee evitar el acceso directo al sistema Odoo. Generalmente es difícil mantener en secreto las direcciones IP de los terminales de sus servidores Odoo. Por ejemplo, pueden aparecer en los registros del servidor web al consultar sistemas públicos o en los encabezados de los correos electrónicos publicados desde Odoo. En tal situación, es posible que desee configurar su firewall para que los puntos finales no sean accesibles públicamente excepto desde las direcciones IP específicas de su WAF, equilibrador de carga o servicio proxy. Los proveedores de servicios como CloudFlare suelen mantener una lista pública de sus rangos de direcciones IP para este fin.
Si aloja a varios clientes, aísle los datos y archivos de los clientes entre sí utilizando contenedores o técnicas de «cárcel» apropiadas.
Configure copias de seguridad diarias de sus bases de datos y datos del almacén de archivos, y cópielas en un servidor de archivo remoto al que no se pueda acceder desde el servidor.

Bloquear ataques de fuerza bruta¶

Para implementaciones orientadas a Internet, los ataques de fuerza bruta a las contraseñas de los usuarios son muy comunes y esta amenaza no debe descuidarse en el caso de los servidores Odoo. Odoo emite una entrada de registro cada vez que se realiza un intento de inicio de sesión e informa el resultado: éxito o fracaso, junto con el inicio de sesión de destino y la IP de origen.

Las entradas del registro tendrán la siguiente forma.

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

Acceso 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 pueden analizarse fácilmente mediante un sistema de prevención de intrusiones como «fail2ban».

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

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

Esto podría usarse con una definición de cárcel para bloquear la IP atacante en HTTP(S).

Esto es lo que podría verse al bloquear la IP durante 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 administrador de bases de datos¶

Configurando Odoo mencionó admin_passwd de pasada.

Esta configuración se utiliza en todas las pantallas de administración de bases de datos (para crear, eliminar, volcar o restaurar bases de datos).

Si las pantallas de administración no deben ser accesibles en absoluto, debe establecer la opción de configuración list_db en False, para bloquear el acceso a todas las pantallas de administración y selección de bases de datos.

Advertencia

¡Se recomienda encarecidamente desactivar el Administrador de bases de datos para cualquier sistema con acceso a Internet! Está pensado como una herramienta de desarrollo/demostración para facilitar la creación y gestión rápida de bases de datos. No está diseñado para su uso en producción e incluso puede exponer características peligrosas a los atacantes. Tampoco está diseñado para manejar bases de datos grandes y puede generar límites de memoria.

En los sistemas de producción, las operaciones de gestión de bases de datos siempre deben ser realizadas por el administrador del sistema, incluido el aprovisionamiento de nuevas bases de datos y copias de seguridad automatizadas.

Asegúrese de configurar un parámetro db_name apropiado (y opcionalmente, también db_filter) para que el sistema pueda determinar la base de datos de destino para cada solicitud; de lo contrario, los usuarios serán bloqueados ya que no podrán elegir. la propia base de datos.

Si solo se debe acceder a las pantallas de administración desde un conjunto seleccionado de máquinas, use las funciones del servidor proxy para bloquear el acceso a todas las rutas que comiencen con /web/database excepto (tal vez) /web/database/selector que muestra la pantalla de selección de base de datos.

Si se debe dejar accesible la pantalla de administración de la base de datos, se debe cambiar la configuración admin_passwd de su valor predeterminado admin: esta contraseña se verifica antes de permitir operaciones de alteración de la base de datos.

Debe almacenarse de forma segura y debe generarse aleatoriamente, p.

$ 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 principales navegadores de escritorio y móviles disponibles en el mercado, siempre que sean compatibles con sus editores.

Estos son los navegadores compatibles:

Google Chrome
Mozilla Firefox
Borde de Microsoft
Safari de Apple

Advertencia

Asegúrese de que su navegador esté actualizado y aún sea compatible con su editor antes de presentar un informe de error.

Nota

Desde Odoo 13.0, se admite ES6. Por lo tanto, se elimina el soporte de IE.

1: tener múltiples instalaciones de Odoo usando la misma base de datos PostgreSQL, o proporcionar más recursos informáticos a ambos software.
2: Técnicamente, una herramienta como socat se puede usar para proxy de sockets UNIX a través de redes, pero eso es principalmente para software que solo se puede usar en sockets UNIX.
3: o ser accesible sólo a través de una red interna de conmutación de paquetes, pero eso requiere conmutadores seguros, protecciones contra la «suplantación de identidad ARP» y excluye el uso de WiFi. Incluso en redes seguras de conmutación de paquetes, se recomienda la implementación a través de HTTPS, y los posibles costos se reducen ya que los certificados «autofirmados» son más fáciles de implementar en un entorno controlado que a través de Internet.