Configuración del sistema

Este documento describe los pasos básicos para configurar Odoo en producción o en un servidor de internet, sigue la instalación y por lo general no es necesario para un sistema de desarrollo que no está expuesto a internet.

Advertencia

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

dbfilter

Odoo es un sistema de tenencia múltiple. Es posible que un solo sistema de Odoo ejecute y preste servicios a varias instancias de la base de datos, también puede tener varias personalizaciones (por ejemplo, cómo se cargan los módulos) dependiendo de la base de datos actual.

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

Sin embargo, esto sí es un problema para los usuarios que no iniciaron sesión (portal, sitio web) y no están vinculados a la base de datos. Odoo necesita saber qué base de datos se debería usar para cargar la página de sitio web o realizar la operación. No habrá ningún problema si no usa la tenencia múltiple, pues 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 usar.

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 inyectado dinámicamente (%h) o el primer subdominio (%d)  mediante el cual el 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.*$
  • Para mostrar solo las bases de datos que coinciden con el primer subdominio después de www. Por ejemplo, la base de datos «mycompany» aparecerá si la solicitud entrante se envió a www.mycompany.com o a mycompany.co.uk, pero no para www2.mycompany.com o helpdesk.mycompany.com.

en el archivo de configuración configure:

[options]
dbfilter = ^%d$

Nota

Configurar un --db-filter es una parte importante para asegurar el despliegue. Una vez que funciona de forma correcta y coincida solo con una base de datos por nombre de host, le recomendamos bloquear el acceso a las pantallas de gestión de la base de datos. Use el parámetro de inicio --no-database-list para evitar que sus bases de datos aparezcan en una lista y para bloquear el acceso a las pantallas antes mencionadas. También consulte security.

PostgreSQL

De forma predeterminada, PostgreSQL solo permite conexiones mediante sockets UNIX y bucles de retorno (también conocidas como loopback) que ocurren desde «localhost», en 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

  • Permita la conexión tcp desde la red 192.168.1.x.

En /etc/postgresql/9.5/main/pg_hba.conf configure:

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

En /etc/postgresql/9.5/main/postgresql.conf configure:

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

Configurar Odoo

Odoo se conecta a un servidor PostgreSQL local mediante un socket UNIX a través del puerto 5432 de forma predeterminada. Puede anular esto si usa las opciones de la base de datos cuando el despliegue de PostgreSQL no es local o no usa la configuración de instalación predeterminada.

Los paquetes de instalación crearán un nuevo usuario (odoo) de manera automática y se establecerá como el usuario de la base de datos.

  • Las pantallas de gestión de las 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 solo se revisa antes de realizar alteraciones a la base de datos. Debe estar configurado en un valor generado de forma aleatoria para garantizar que cualquier fuente externa no pueda utilizar esta interfaz.

  • Todas las operaciones de la base de datos usan las opciones de base de datos, entre ellas, la pantalla de gestión de las bases de datos. Para que esta pantalla funcione, el usuario de PostgreSQL necesita tener el permiso 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 debe crearse con no-createdb y otro de los usuarios debe ser propietario de la base de datos.

    Advertencia

    El usuario de PostgreSQL no debe ser un superusuario.

Ejemplo de configuración

  • Conéctese a un servidor PostgreSQL en 192.168.1.2.

  • Puerto 5432.

  • Use la cuenta con el usuario «odoo».

  • Use «pwd» como contraseña.

  • Filtre solo las bases de datos con nombres que empiecen con «mycompany».

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 hacer uso de la conexión SSL entre Odoo y PostgreSQL. En Odoo, db_sslmode controla la seguridad SSL de la conexión con un valor que puede ser “disable”, “allow”, “prefer”, “require”, “verify-ca” o “verify-full”.

Documentación de PostgreSQL

Servidor incorporado

Odoo incluye servidores integrados HTTP, cron y de chat en vivo. Estos usan multiprocesos o multihilos.

El servidor multihilos es un servidor más simple que por lo general se usa para desarrollos y demostraciones, además de que se usa debido a su compatibilidad con varios sistemas operativos (como Windows). Por cada nueva solicitud HTTP se genera un nuevo hilo, incluso para las conexiones persistentes como websocket, también se generan hilos de cron daemonic adicionales. Sin embargo, por su limitación con Python (GIL), no aprovecha muy bien el hardware.

El servidor predeterminado es el multihilos, también en los contenedores de docker. Se selecciona al no elegir 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 de Python (GIL) en cuanto al uso de recursos, así que aprovecha mucho mejor el hardware. Al momento de poner en marcha un servidor se crea un conjunto de workers y el sistema operativo pone en cola las nuevas solicitudes HTTP hasta que haya workers listos para procesarlas. Los eventos del chat en vivo generan otro worker HTTP en un puerto alternativo. También se generan workers cron adicionales. Un proceso reaper configurable monitorea el uso y puede detener o reiniciar workers con errores.

El servidor multiprocesos es opcional. Lo puede seleccionar al establecer la opción --workers como non-null integer.

Nota

El servidor multiprocesos está personalizado para servidores de Linux, así que no está disponible para Windows.

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 worker pesado consume alrededor de 1 GB de RAM una vez que todos los campos calculados y las peticiones SQL están bien diseñadas, etc.

  • Se estima que un worker ligero en el mismo escenario consume alrededor de 150 MB de RAM.

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

Chat en vivo

En multiprocesamiento, se inicia automáticamente un worker específico para el chat en vivo y escucha en --longpolling-port. De manera predeterminada, las solicitudes HTTP podrán seguir accediendo a los workers HTTP regulares en lugar de a los de chat en vivo. Debe desplegar un proxy en Odoo y redirigir las solicitudes entrantes que empiecen con la ruta /longpolling al worker de chat en vivo. También debe establecer Odoo en --proxy-mode para que use los encabezados reales de los clientes (como el nombre del alojamiento, esquema, IP) en lugar de los de proxy.

Ejemplo de configuración

  • Servidor con 4 CPU, 8 hilos.

  • 60 usuarios concurrentes.

  • 60 usuarios / 6 = 10 <- Número teórico de workers necesarios.

  • (4 * 2) + 1 = 9 <- Número teórico máximo de workers.

  • Usaremos 8 workers + 1 para el cron. También usaremos un sistema de monitoreo para medir la carga del CPU y verificar que se encuentre 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 un sitio web, cliente web o servicio web, Odoo transmite información de autenticación mediante texto sin cifrar. Esto significa que un despliegue seguro de Odoo debe usar HTTPS3. La terminación SSL se puede implementar con cualquier proxy de terminación SSL, pero requiere la siguiente configuración:

  • Habilite el modo proxy de Odoo. Solo debería estar habilitado cuando Odoo se encuentre detrás de un proxy inverso.

  • Configure la terminación SSL del proxy (ejemplo de terminación Nginx).

  • Configure el proxy (ejemplo de Nginx del proxy).

  • Su proxy de terminación SSL también debería redirigir conexiones no seguras de forma automática al puerto seguro.

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 $http_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. Debe personalizar el script (luego de copiarlo desde la carpeta de configuración) para realizar la configuración de forma correcta en odoo.tools.config y no en la línea de comandos o el archivo de configuración.

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

Workers de cron

Es necesario que inicie uno de los servidores incluidos en Odoo junto al servidor WSGI para procesar trabajos cron. Ese servidor debe estar configurado para que solo procese crons y no solicitudes HTTPS. Use la opción --no-http en la línea de comandos o ajuste el archivo de configuración con http_enable = False.

En sistemas de tipo Linux es recomendable utilizar el servidor multiprocesos en lugar del multihilos para aprovechar mejor el hardware e incrementar la estabilidad, por ejemplo, use las opciones --workers=-1 y --max-cron-threads=n de la línea de comandos.

Chat en vivo

Se requiere el uso de un servidor WSGI compatible con gevent para que la función de chat en vivo funcione de forma adecuada. Ese servidor debe poder gestionar varias solicitudes HTTP persistentes de manera simultánea pero no necesita mucha potencia de procesamiento. Todas las solicitudes que comienzan con /longpolling se deben redirigir a ese servidor y utilizar un servidor normal WSGI (de hilos o procesos) para el resto de las solicitudes.

El servidor cron de Odoo también es útil para las solicitudes del chat en vivo. Solo debe soltar la opción --no-http de la línea de comandos desde el servidor cron y asegurarse de que las solicitudes que comienzan con /longpolling/ estén dirigidas a este servidor, ya sea en --http-port (servidor multihilos) o en --longpolling-port (servidor multiprocesos).

Servicio de archivos estáticos

Por conveniencia, Odoo sirve directamente todos los archivos estáticos en sus módulos. Esto puede ser ideal cuando se trata de rendimiento y los archivos estáticos generalmente se deberían servir con un servidor HTTP estático.

Los archivos estáticos en la carpeta static/, así que los archivos estáticos se pueden servir al interceptar todas las solicitudes a /MODULE/static/FILE y puede buscar el módulo (y archivo) correcto en todas las rutas agregadas.

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 tome esta sección como 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 también restrinja el acceso a las páginas de gestión de la base de datos tan pronto como configure el sistema. Consulte 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/gestionar la instalación. Nunca use contraseñas automáticas, como admin/admin, incluso 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 es un super usuario y sus bases de datos le pertenecen 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 Configurar Odoo.

  • Mantenga las instalaciones actualizadas e instale con regularidad las versiones más recientes, ya sea a través de GitHub o descárguelas de https://www.odoo.com/page/download o http://nightly.odoo.com.

  • Configure su servidor en un modo multiproceso con los límites adecuados que correspondan a su uso habitual (memoria, CPU y tiempos de espera). Consulte Servidor incorporado.

  • Ejecute Odoo con un servicio web que proporcione una terminación HTTPS con un certificado SSL válido para evitar interceptación en las comunicaciones de texto sin cifrar. Los certificados de SSL son baratos y existen muchas opciones gratuitas. Configure el proxy web para limitar el tamaño de las solicitudes, establezca tiempos de espera apropiados y después active la opción de modo proxy. Consulte 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 para root. Le recomendamos deshabilitar por completo la autenticación por contraseña y solo permita la autenticación con clave pública. También considere restringir el acceso a través de VPN para permitir el acceso solo a las IP de confianza en el firewall o ejecute un sistema de detección de fuerza bruta como fail2ban o algún equivalente.

  • Considere instalar un límite en su proxy o firewall para evitar ataques de fuerza bruta y negar ataques al servicio. También consulte Bloquear ataques de fuerza bruta para obtener más información sobre medidas específicas.

    Muchos proveedores de red ofrecen mitigación automática para ataques de denegación de servicio distribuido (DDoS), pero suele ser un servicio opcional. Le recomendamos que lo consulte con ellos.

  • Siempre que sea posible, aloje sus instancias de demostración, prueba o preproducción en máquinas distintas a las de producción y aplique las mismas precauciones de seguridad que usa para producción.

  • Si su servidor público de Odoo tiene acceso a recursos o servicios confidenciales de la red interna (por ejemplo, a través de una VLAN privada), implemente reglas de firewall apropiadas para proteger esos recursos internos. Esto asegurará que el servidor de Odoo no se pueda usar sin querer (o como resultado de acciones maliciosas de algún usuario) para acceder o alterar los recursos internos. Por lo general, esto se puede hacer con una regla de denegación predeterminada de salida en el firewall, después autorice de forma explícita el acceso solo a los recursos internos que el servidor de Odoo necesita. 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 procesos.

  • Si su servidor público de Odoo está detrás de un firewall de aplicaciones web, un equilibrador de carga, un servicio transparente de protección contra DDoS (como CloudFare) o un dispositivo similar a nivel de red, querrá evitar tener acceso directo al sistema de Odoo. Por lo general es difícil mantener el punto de conexión de las direcciones IP de sus servidores de Odoo en secreto. Por ejemplo, pueden aparecer en registros del servidor web al consultar sistemas públicos o en los encabezados de los correos que envía Odoo. En este caso, es posible que quiera configurar su firewall para que no se pueda ingresar a las terminales de forma pública, excepto por las direcciones IP de su firewall de aplicaciones web, equilibrador de carga o servicio proxy. Los proveedores de servicios como CloudFlare casi siempre 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(S).

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

Configurar 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 genera una cadena imprimible pseudoaleatoria de 32 caracteres.

Restablecer la contraseña maestra

Pueden haber casos en los que la contraseña principal se pierde o ya no es segura y necesita cambiarse. El siguiente proceso es para administradores del sistema de una base de datos de Odoo local y se muestra cómo cambiar y volver a encriptar la contraseña principal de nuevo de forma manual.

Véase

Consulte esta documentación para obtener más información sobre cómo cambiar la contraseña de una cuenta de Odoo.com: Cambiar la contraseña de una cuenta de Odoo.com.

Al crear una base de datos local se generará una contraseña principal aleatoria, la cual Odoo recomienda usar para asegurar la base de datos. Esta contraseña se implementa de forma automática, así que hay una contraseña maestra segura para cada entorno de Odoo local.

Advertencia

Al crear una base de datos de Odoo local cualquiera dentro de internet podrá entrar a la instalación hasta que use la contraseña para asegurar la base de datos.

La contraseña maestra se especifica en el archivo de configuración de Odoo (odoo.conf u odoorc (archivo oculto)). Necesita la contraseña maestra de Odoo para modificar, crear o borrar una base de datos a través de la interfaz gráfica de usuario (GUI, por sus siglas en inglés).

Ubicar el archivo de configuración

Primero abra el archivo de configuración de Odoo (odoo.conf o odoorc (archivo oculto)).

El archivo de configuración está en c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf.

Cambiar la contraseña anterior

Una vez que haya abierto el archivo adecuado, modifique la contraseña nueva en el archivo de configuración a una contraseña temporal.

Después de ubicar el archivo de configuración, ábralo con una (GUI), para esto solo debe hacer doble clic al archivo. El dispositivo debería tener una GUI predeterminada con la cual abrir el archivo.

Después modifique la línea de la contraseña maestra admin_passwd = $pbkdf2-sha… a admin_passwd = newpassword1234, por ejemplo. Elija la contraseña que desee, siempre y cuando la almacene de forma temporal. Asegúrese de modificar todos los caracteres después del =.

Example

La línea aparece de la siguiente forma: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

La línea modificada aparece de la siguiente manera: admin_passwd = newpassword1234

Importante

Es indispensable que cambie la contraseña a otra cosa en lugar de activar un nuevo restablecimiento de contraseña al agregar un punto y coma ; al inicio de la línea. Esto asegurará que la base de datos esté segura durante todo el proceso de restablecimiento de contraseña.

Reiniciar el servidor de Odoo

Después de configurar una contraseña temporal debe reiniciar el servidor de Odoo.

Para reiniciar el servidor de Odoo, primero escriba servicios en la barra de búsqueda de Windows. Después, seleccione la aplicación Servicios y vaya al servicio Odoo.

Haga clic derecho en Odoo y seleccione Iniciar o Reiniciar. Esta acción reiniciará el servidor de Odoo de forma manual.

Usar la interfaz web para volver a encriptar la contraseña

Primero, vaya a /web/database/manager o a http://server_ip:port/web/database/manager desde un navegador.

Nota

Reemplace server_ip con la dirección IP de la base de datos y reemplace port con el número de puerto desde el cual es posible acceder a la base de datos.

Después haga clic en Establecer contraseña maestra y escriba la contraseña temporal seleccionada con anterioridad en el campo Contraseña maestra. Después de este paso, escriba una nueva contraseña maestra. La nueva contraseña maestra se cifrará (o encriptará) después de que haga clic en el botón Continuar.

En este punto ya restableció la contraseña con éxito, así que en el archivo de configuración aparecerá una versión encriptada de la nueva contraseña.

Véase

Consulte la siguiente documentación para obtener más información sobre la seguridad de la base de datos de Odoo: Seguridad del gestor de la base de datos.

Navegadores compatibles

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

Los navegadores compatibles son los siguientes:

  • 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 ser utilizada 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 excluye 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.