Развертывание (Deploy)

В этом документе описаны основные шаги по настройке Odoo на сервере. Их нужно делать после установки. Они обычно не нужны для окружения разработки, которые не видны в интернете.

dbfilter

Одна система Odoo может запускаться и обслуживать несколько экземпляров базы данных. Каждый из них имеет свои индивидуальные настройки (например установленные модули) в зависимости от базы данных, которая используется в данный момент.

Это не проблема при работе только с бэкэндом (веб-клиентом) в качестве зарегистрированного пользователя компании: при входе в систему можно выбрать базу данных и Odoo запомнит какую именно.

Однако это проблема проявляется для не зарегистрированных пользователей (портала, веб-сайта), которые не привязаны к базе данных: Odoo нужно знать, какая база данных должна использоваться для конкретных операций или для получения данных. Если используется одна база данных, то Odoo работает с ней, но если доступно несколько баз данных, то Odoo нуждается в правиле, чтобы узнать, какую из них нужно использовать.

Для этих целей используется --db-filter: он указывает базу данных по умолчанию для системы Odoo, которая должна быть выбрана на основании хоста (домена), который запрашивается. Значение представляет собой регулярное выражение, включая динамически введенное имя хоста (%h) или поддомен (%d), через который осуществляется обращение к системе Odoo.

Если Odoo содержит несколько баз данных на сервере, особенно если используется website, он должен использовать dbfilter, или некоторые функции не будут работать корректно или вообще не будут использоваться.

Образцы конфигурации

  • Show only databases with names beginning with „mycompany“

в /etc/odoo/odoo.conf установите:

[options]
dbfilter = ^mycompany.*$
  • Показывать только базы данных, соответствующие первому субдомену после www: например, база данных «mycompany» будет отображаться, если входящий запрос был отправлен на www.mycompany.com или mycompany.co.uk, но не для www2.mycompany.com или helpdesk.mycompany.com.

в /etc/odoo/odoo.conf установите:

[options]
dbfilter = ^%d$

PostgreSQL

По умолчанию PostgreSQL разрешает только подключение к UNIX-сокетам и loopback соединениям (из «localhost», той же машине, на которой установлен сервер PostgreSQL).

UNIX-сокет удобен, если вы хотите, чтобы Odoo и PostgreSQL выполнялись на одном компьютере, и по умолчанию не задаются адреса компьютеров, но если вы хотите, чтобы Odoo и PostgreSQL выполнялись на разных машинах 1, то необходимо listen to network interfaces 2, либо:

  • Only accept loopback connections and use an SSH tunnel between the machine on which Odoo runs and the one on which PostgreSQL runs, then configure Odoo to connect to its end of the tunnel
  • Accept connections to the machine on which Odoo is installed, possibly over ssl (see PostgreSQL connection settings for details), then configure Odoo to connect over the network

Пример конфигурации

  • Allow tcp connection on localhost
  • Allow tcp connection from 192.168.1.x network

в /etc/postgresql/9.5/main/pg_hba.conf пропишите:

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

в /etc/postgresql/9.5/main/postgresql.conf пропишите:

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

Настройка Odoo

Из коробки Odoo подключается к локальному postgres через сокет UNIX и порт 5432. Эти параметры можно переопределить, используя параметры базы данных, если Postgres установлен не локально и/или не использует установки по умолчанию.

При установке с использовании инсталяторов автоматически создаст нового пользователя (odoo) и установит его как пользователя базы данных.

  • Экран управления базами данных защищен паролем, который устанавливается настройкой admin_passwd. Этот параметр можно установить только в файле конфигурации, и он используется перед выполнением изменений базы данных. Он должен быть произвольно сгенерированным значением, чтобы гарантировать, что из вне никто не получит доступ к вашим базам данных.
  • All database operations use the database options, including the database management screen. For the database management screen to work requires that the PostgreSQL user have createdb right.

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

Пример конфигурации

  • подключиться к серверу PostgreSQL по адресу 192.168.1.2
  • порт 5432
  • используется учетную запись „odoo“
  • с „pwd“ в качестве пароля
  • фильтрация баз данных с именем, начинающимся на „mycompany“

в /etc/odoo/odoo.conf установите:

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

SSL Between Odoo and PostgreSQL

Since Odoo 11.0, you can enforce ssl connection between Odoo and PostgreSQL. in Odoo the db_sslmode control the ssl security of the connection with value choosed out of „disable“, „allow“, „prefer“, „require“, „verify-ca“ or „verify-full“

PostgreSQL Doc

Встроенный сервер

Odoo включает в себя встроенный HTTP-сервер, который использует многопоточность и многопроцессорность.

Для использования на продакшене рекомендуется использовать многопроцессорность на сервере, поскольку это повышает стабильность, улучшает использование вычислительных ресурсов и может быть лучше контролироваться.

  • Многопроцессорность включается путем настройки ненулевое число рабочих процессов, количество workers должно быть равно количеству ядер процессора (возможно, в некоторых случаях стоит учесть сколько ядер процессора выделено для Cron)
  • Ограничения Worker настраиваются основываясь на конфигурации оборудования, чтобы избежать исчерпания ресурсов

Расчет количества worker

  • Рассчитывается по формуле: (#CPU * 2) + 1
  • Cron Workers используют процессор
  • 1 worker ~ 6 конкурентных пользователей

расчет размера необходимого ОЗУ

  • Мы считаем, что 20% запросов - это тяжелые запросы, а 80% - более простые
  • A heavy worker, when all computed field are well designed, SQL requests are well designed, … is estimated to consume around 1GB of RAM
  • «Более легкий» worker, в том же сценарии, по оценкам, потребляет около 150 МБ ОЗУ

Необходимое кол-во ОЗУ = #worker * ((light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation))

Живой чат

При многопроцессорной работе автоматически запускается выделенный LiveChat worker и слушает порт longpolling, но клиент не подключается к нему.

Вместо этого у вас должны быть перенаправленные прокси-запросы, URL которых начинается с /longpolling/ на порт longpolling. Остальные запросы должен быть проксирован на обычный HTTP порт

To achieve such a thing, you’ll need to deploy a reverse proxy in front of Odoo, like nginx or apache. When doing so, you’ll need to forward some more http Headers to Odoo, and activate the proxy_mode in Odoo configuration to have Odoo read those headers.

Пример конфигурации

  • Сервер с 4 процессорами, 8 потоков
  • 60 одновременных пользователей
  • 60 пользователей / 6 = 10 <- теоретическое число worker
  • (4 * 2) + 1 = 9 <- теоретическое максимальное число worker
  • Мы будем использовать 8 worker + 1 для cron. Мы также будем использовать систему мониторинга для измерения нагрузки процессора и проверим, составляет ли она от 7 до 7.5.
  • RAM = 9 * ((0,8 * 150) + (0,2 * 1024)) ~ 3Gb ОЗУ для Odoo

в /etc/odoo/odoo.conf:

[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

Независимо от того, используете ли вы Odoo как веб-сайт, или как веб-клиент, или как веб-сервис, Для безопасной передачи информацию аутентификации нужно использоваться HTTPS[#switching] _. SSL может быть реализован с помощью любого прокси-сервера, но для этого потребуются следующие настройки:

  • Enable Odoo’s proxy mode. This should only be enabled when Odoo is behind a reverse proxy
  • Set up the SSL termination proxy (Nginx termination example)
  • Set up the proxying itself (Nginx proxying example)
  • Your SSL termination proxy should also automatically redirect non-secure connections to the secure port

Пример конфигурации

  • Redirect http requests to https
  • Proxy requests to odoo

в /etc/odoo/odoo.conf установите:

proxy_mode = True

в /etc/nginx/sites-enabled/odoo.conf:

#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;
 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 on;
 ssl_certificate /etc/ssl/nginx/server.crt;
 ssl_certificate_key /etc/ssl/nginx/server.key;
 ssl_session_timeout 30m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
 ssl_prefer_server_ciphers on;

 # 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 как приложение WSGI

Также возможно установить Odoo в качестве стандартного приложения WSGI. Odoo предоставляет базу для сценария запуска WSGI - odoo-wsgi.py. Этот скрипт должен быть настроен (возможно, после его копирования из каталога установки), чтобы правильно настроить конфигурацию непосредственно в odoo.tools.config, а не через командную строку или файл конфигурации.

Сервер WSGI будет работать для веб-клиента, веб-сайта и API веб-сервиса, но Odoo не будет контролировать создание workers, он не сможет настроить workers cron или livechat workers

Задания Cron

Для выполнения заданий cron при развертывании Odoo в качестве приложения WSGI требуется

  • A classical Odoo (run via odoo-bin)
  • Connected to the database in which cron jobs have to be run (via odoo-bin -d)
  • Which should not be exposed to the network. To ensure cron runners are not network-accessible, it is possible to disable the built-in HTTP server entirely with odoo-bin --no-http or setting http_enable = False in the configuration file

Живой чат

Второй проблемной подсистемой при развертывании Odoo, как приложения WSGI, является LiveChat: где большинство HTTP-соединений относительно короткие и быстро освобождают рабочий процесс для следующего запроса, LiveChat требует долговременного подключения для каждого клиента, чтобы внедрять уведомления в режиме реального времени.

Это противоречит рабочей модели, основанной на процессах, поскольку она свяжет рабочие процессы и предотвращает доступ новых пользователей к системе. Тем не менее, эти долгоживущие соединения делают очень мало и в основном выполняют функцию ожидания уведомлений.

Решения для поддержки живого чата и уведомлений в приложении WSGI:

  • Deploy a threaded version of Odoo (instread of a process-based preforking one) and redirect only requests to URLs starting with /longpolling/ to that Odoo, this is the simplest and the longpolling URL can double up as the cron instance.
  • Deploy an evented Odoo via odoo-gevent and proxy requests starting with /longpolling/ to the longpolling port.

Хранение статических файлов

Для удобства разработки Odoo хранит все статические файлы в своих модулях. Это не идеально с точки зрения производительности. Статические файлы обычно должны обслуживаться HTTP-сервером.

Статические файлы Odoo живут в папке static/ каждого модуля, поэтому статические файлы могут отдаваться веб-сервером путем перехвата всех запросов /MODULE/static/FILE и поиска правильного модуля (и файла) по всем путям хранения аддонов.

Безопасность

Для начала имейте в виду, что обеспечение безопасности информационной системы - это непрерывный процесс, а не одноразовая акцуия. Уровень безопасности будет равен уровню безопасности самого слабого звена в вашей среде.

Поэтому, пожалуйста, не принимайте этот раздел как окончательный список мер, которые предотвратят все проблемы безопасности. Он предназначен только для краткого изложения первых важных вещей, которые вы обязательно должны включить в свой план действий в области безопасности. Остальные будут обеспечены лучшими методами безопасности для вашей операционной системы, лучшими практиками с точки зрения пользователей, паролями и управлением доступом и т.д.

При развертывании публичного сервера, обязательно рассмотрите следующие темы, связанные с безопасностью:

  • Всегда устанавливайте сложный пароль супер-администратора и ограничивайте доступ к страницам управления базой данных сразу же после установки системы. См.:ref:[UNKNOWN NODE title_reference].
  • Выберите уникальные логины и надежные пароли для всех учетных записей администратора во всех базах данных. Не используйте «admin» в качестве логина. Не используйте эти логины для ежедневных операций, только для управления/управления установкой. Никогда не используйте любые пароли по умолчанию, такие как admin/admin, даже для тестовых/промежуточных баз данных.
  • Do not install demo data on internet-facing servers. Databases with demo data contain default logins and passwords that can be used to get into your systems and cause significant trouble, even on staging/dev systems.
  • Используйте соответствующие фильтры баз данных ( --db-filter), чтобы ограничить видимость ваших баз данных в соответствии с именем хоста. См. dbfilter. Вы также можете использовать -d, чтобы предоставить свой собственный (разделенный запятыми) список доступных баз данных для фильтрации.
  • Когда ваш db_filter настроен и соответствует только одной базе данных для каждого имени хоста, вы должны установить опцию list_db в False, чтобы скрыть список баз данных (также это можно сделать параметром командной строки --no-database-list)
  • Убедитесь, что пользователь PostgreSQL (--db_user) не является суперпользователем и что ваши базы данных принадлежат другому пользователю. Например, они могут принадлежать суперпользователю postgres, если вы используете выделенный не-привилегированный db_user. См. также : ref:[UNKNOWN NODE title_reference].
  • Получайте обновления, регулярно устанавливая последние сборки, либо через GitHub, либо загружая последнюю версию с https://www.odoo.com/page/download или http://nightly.odoo.com
  • Настройте свой сервер в многопроцессном режиме с соответствующими лимитами, соответствующими вашему типичному использованию (память/процессор/таймауты). См. Также: ref:[UNKNOWN NODE title_reference].
  • Запустите Odoo за веб-сервером с настроенным HTTPS и действительным сертификатом SSL, чтобы обеспечить шифрование соединений. SSL-сертификаты дешевы, и существует множество бесплатных вариантов. Настройте веб-прокси, чтобы ограничить размер запросов, установить соответствующие тайм-ауты, а затем включить параметр proxy mode. См. Также HTTPS.
  • If you need to allow remote SSH access to your servers, make sure to set a strong password for all accounts, not just [UNKNOWN NODE title_reference]. It is strongly recommended to entirely disable password-based authentication, and only allow public key authentication. Also consider restricting access via a VPN, allowing only trusted IPs in the firewall, and/or running a brute-force detection system such as [UNKNOWN NODE title_reference] or equivalent.

  • Consider installing appropriate rate-limiting on your proxy or firewall, to prevent brute-force attacks and denial of service attacks. See also Blocking Brute Force Attacks for specific measures.

    Many network providers provide automatic mitigation for Distributed Denial of Service attacks (DDOS), but this is often an optional service, so you should consult with them.

  • По мере возможности размещайте свои демонстрационные/тестовые экземпляры с открытым доступом на машинах, отличных от продакшена. И применяйте на них меры безопасности по максимуму.
  • If your public-facing Odoo server has access to sensitive internal network resources or services (e.g. via a private VLAN), implement appropriate firewall rules to protect those internal resources. This will ensure that the Odoo server cannot be used accidentally (or as a result of malicious user actions) to access or disrupt those 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 server needs to access. Systemd IP traffic access control may 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-level device, you may wish to avoid direct access to the Odoo system. It is generally difficult to keep the endpoint IP addresses of your Odoo servers secret. For example they can appear in web server logs when querying public systems, or in the headers of emails posted from Odoo. In such a situation you may want to configure your firewall so that the endpoints are not accessible publicly except from the specific IP addresses of your WAF, load-balancer or proxy service. Service providers like CloudFlare usually maintain a public list of their IP address ranges for this purpose.
  • Если вы размещаете несколько клиентов, изолируйте данные и файлы клиентов друг от друга с помощью контейнеров или соответствующих методов.
  • Делайте ежедневные резервные копии ваших баз данных и файлов хранения данных и копируйте их на удаленный сервер архивации, который недоступен с самого сервера.

Blocking Brute Force Attacks

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

The log entries will have the following form.

Failed login:

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

Successful login:

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

These logs can be easily analyzed by an intrusion prevention system such as [UNKNOWN NODE title_reference].

For example, the following fail2ban filter definition should match a failed login:

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

This could be used with a jail definition to block the attacking IP on HTTP(S).

Here is what it could look like for blocking the IP for 15 minutes when 10 failed login attempts are detected from the same IP within 1 minute:

[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

Безопасность менеджера баз данных

admin_passwd мимоходом упоминается в Настройка Odoo

Этот параметр используется для всех действий над базами данных (для создания, удаления, сброса или восстановления баз данных).

If the management screens must not be accessible at all, you should set list_db configuration option to False, to block access to all the database selection and management screens.

Be sure to setup an appropriate db_name parameter (and optionally, db_filter too) so that the system can determine the target database for each request, otherwise users will be blocked as they won’t be allowed to choose the database themselves.

Если экраны управления не должны быть доступны или должны быть доступны только из выбранного набора компьютеров, используйте функции прокси-сервера для блокировки доступа ко всем адресам, начинающимся с /web/database, за исключением (возможно) /web/database/selector, который отображает экран выбора базы данных.

Если экран управления базой данных должен быть доступен, параметр admin_passwd` должен быть изменен с ``admin по умолчанию: этот пароль проверяется перед тем, как совершить операцию изменения базы данных.

Он должен храниться надежно и должен генерироваться случайным образом, например

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

этот код выведет 32-символьную псевдослучайную строку.

Поддерживаемые браузеры

Odoo is supported by multiple browsers for each of its versions. No distinction is made according to the browser version in order to be up-to-date. Odoo is supported on the current browser version. We support the following browsers:

  • Mozilla Firefox
  • Google Chrome
  • Safari
  • Microsoft Edge
[1] чтобы несколько установок Odoo использовали одну и ту же базу данных PostgreSQL или обеспечивали больше вычислительных ресурсов для обоих программ.
[2] технически такой инструмент, как socat, может использоваться для прокси UNIX-сокетов по сетям, но это в основном для программного обеспечения, которое можно использовать только для UNIX сокетов
[3] или быть доступным только через внутреннюю сеть с коммутацией пакетов, но для этого требуются защищенные коммутаторы, с защитой от [UNKNOWN NODE title_reference] и отключенным Wi-Fi. Даже над защищенными сетями с коммутацией пакетов рекомендуется развертывание по HTTPS, а возможные затраты снижаются, поскольку «самоподписанные» сертификаты легче развертывать в контролируемой среде, чем в Интернете.