• Запуск сервера
  • Параметры для работы базы данных
  • Встроенный HTTP-сервер
  • Ведение логов
  • Расширенные настройки
• Scaffolding
• Файл конфигурации

Оригинал на GitHub

Запуск сервера

-d <database>, --database <database>

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

-i <modules>, --init <modules>

Список модулей, разделенных через запятую, для установки перед запуском сервера (требуется параметр -d).

-u <modules>, --update <modules>

Список модулей, подлежащих обновлению до запуска сервера (требуется параметр -d).

--addons-path <directories>

Список каталогов, разделенных запятыми, в которых хранятся модули. Эти каталоги сканируются для поиска в них модулей.

--workers <count>

Если count не равно 0 (по умолчанию), то включается многопроцессорная обработка и устанавливается указанное количество HTTP обработчиков (которые обрабатывают HTTP и RPC-запросы).

Примечание

Режим многопроцессорности доступен только в Unix-системах

Ряд параметров позволяет ограничивать и перезапускать обработчики:

--limit-request <limit>

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

По умолчанию - 8196.

--limit-memory-soft <limit>

Максимально допустимая виртуальная память на одного обработчика. Если предел превышен, обработчик будет убит и перезапущен в конце текущего запроса.

По умолчанию 640 Мб.

--limit-memory-hard <limit>

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

По умолчанию - 768 Мб.

--limit-time-cpu <limit>

Предотвращает использование обработчиком больше, чем <limit> секунд процессорного времени для каждого запроса. Если предел превышен, обработчик будет убит.

По умолчанию 60.

--limit-time-real <limit>

Препятствует тому, чтобы обработчик работал с запросом дольше <limit> секунд. Если предел превышен, обработчик будет убит.

Отличается от --limit-time-cpu тем, что это предел "wall time", включая, например, SQL-запросы.

По умолчанию 120.

--max-cron-threads <count>

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

Касаемо многопроцессорного режима, это количество идет в дополнение к процессам HTTP обработчиков.

-c <config>, --config <config>

Предоставляет альтернативный файл конфигурации

-s, --save

Сохраняет конфигурацию сервера в текущий файл конфигурации ($HOME/.openerp_serverrc по умолчанию, чтобы поменять это значение используйте параметр -c)

--proxy-mode

Позволяет использовать заголовки X-Forwarded-* через поддержку прокси Werkzeug (Werkzeug's proxy support.)

Предупреждение

Режим прокси не должен быть включен , если используется внешний обратный прокси-сервер (например nginx)

--test-enable

Запускает тесты после установки модулей

--debug

Когда возникает непредвиденная ошибка (не предупреждение или ошибка доступа), автоматически запускается pdb перед записью и возвратом ошибки

Параметры для работы базы данных

-r <user>, --db_user <user>

Имя пользователя базы данных, используемое для подключения к PostgreSQL.

-w <password>, --db_password <password>

Пароль пользователя базы данных, если используется password authentication.

--db_host <hostname>

Адрес сервера базы данных

• localhost в Windows

• UNIX сокет для других систем

--db_port <port>

Порт, который прослушивает база данных, по умолчанию 5432

--db-filter <filter>

Скрывает базы данных, имена которые не соответствуют <filter>. Фильтр является "регулярным выражением", с дополнениями, которые:

• %h заменяется на полное имя хоста, к которому сделан запрос. (при запросе на www.site.ru - отобразиться только база данных с именем "www.site.ru")

• %d заменяется на имя первого субдомена, к которому сделан запрос, за исключением www (домен odoo.com и www.odoo.com оба соответствуют базе данных odoo) (Например при обращении к subdomain.site.ru будет показана база с именем subdomain)

--db-template <template>

При создании новых баз данных на экране управления базами данных указанная база будет использована в качестве шаблона (template database). По умолчанию используется шаблон template1.

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

--no-xmlrpc

Не запускать обработчиков HTTP или long-polling запросов (при этом остается возможным запустить обработчики в cron)

Предупреждение

Не действует, если используется параметр --test-enable ,так как для тестов требуется доступный HTTP-сервер

--xmlrpc-interface <interface>

TCP/IP-адрес, который слушает HTTP-сервер, по умолчанию равен 0.0.0.0 (все адреса)

--xmlrpc-port <port>

Порт, который слушает HTTP-сервер, по умолчанию равен 8069.

--longpolling-port <port>

TCP-порт для long-polling соединений в многопроцессорном или gevent-режиме, по умолчанию 8072. Не используется в режиме по умолчанию.

Ведение логов

По умолчанию Odoo отображает все логи level info, за исключением логов бизнес-процессов (только warning), и вывод потока логов отправляется в stdout. Доступны различные опции для перенаправления потока логов в другие места и для настройки объема выходных данных логов.

--logfile <file>

отправляет поток логов в указанный файл, а не в stdout. В Unix-системах файл может управляться внешними программами управления логов и автоматически будет вновь открыт при замене

--logrotate

включает ротацию логов ежедневно, хранит логи за последние 30 дней. Частота ротации и количество резервных копий не настраивается.

--syslog

отправляет логи в журнал системных событий: syslog на Unix-системах и Event Log на Windows.

Не настраивается

--log-db <dbname>

пишет логи в модели данных ir.logging (таблица ir_logging) текущей базы данных. База данных может иметь имя "current" PostgreSQL, или a PostgreSQL URI для, например, сбора логов в одной базе из нескольких установок Odoo.

--log-handler <handler-spec>

LOGGER:LEVEL, включает LOGGER на указанном уровне LEVEL, например openerp.models:DEBUG включает вывод всех логов уровня DEBUG в моделях данных.

• Двоеточие : обязательно

• Поток логов может быть пропущен при настройки обработчика root (по умолчанию)

• Если уровень не указан, то по умолчанию устанавливается INFO

Данный параметр может быть повторен для настройки нескольких потоков логов, например:

$ odoo.py --log-handler :DEBUG --log-handler werkzeug:CRITICAL --log-handler openerp.fields:WARNING

--log-request

Включить ведение логов уровня DEBUG для запросов RPC, параметр эквивалентен --log-handler=openerp.http.rpc.request:DEBUG

--log-response

Включить ведение логов уровня DEBUG для ответов RPC, эквивалентен параметру --log-handler=openerp.http.rpc.response:DEBUG

--log-web

Включает ведение логов уровня DEBUG для HTTP-запросов и ответов, параметр эквивалентен --log-handler=openerp.http:DEBUG

--log-sql

Включает ведение логов уровня DEBUG для SQL-запросов, эквивалентен --log-handler=openerp.sql_db:DEBUG

--log-level <level>

Ярлык для более простого задания предопределенных уровней определенных потоков логов. "Real " уровни (critical, error, warn, debug) устанавливаются и для openerp, и для werkzeug (кроме debug, который устанавливается только для openerp).

Odoo также предоставляет отладочные псевдоуровни, которые применяются к различным наборам потоков логов:

debug_sql

Устанавливает уровень debug для потока логов SQL

Эквивалентен параметру --log-sql

debug_rpc

Устанавливает уровень debug для openerp и HTTP-запросов

Эквивалентен параметру --log-level debug --log-request

debug_rpc_answer

Устанавливает уровень debug для openerp и HTTP-запросов и ответов

Эквивалентен параметру --log-level debug --log-request --log-response

Примечание

В случае конфликта между --log-level и --log-handler используется последний

Расширенные настройки

--auto-reload

Включить автоматическую перезагрузку файлов python и xml-файлов без перезапуска сервера. Требуется pyinotify.

Scaffolding

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

Scaffolding доступен с помощью параметра командной строки odoo.py scaffold.

-t <template>

каталог шаблона, файлы пропускаются через jinja2, затем копируются в каталог destination (каталог назначения)

name

Имя создаваемого модуля. Может быть "собрано" по определенному вами алгоритму (например: имя каталога модуля, имена моделей данных, ...)

destination

Каталог, в котором создается новый модуль, по умолчанию используется текущий каталог

Файл конфигурации

Большинство параметров командной строки также можно указать через файл конфигурации. В большинстве случаев они используют похожие имена без префикса - и с заменой других - на _. Например --db-template заменяется на db_template.

Некоторые параметры не соответствуют шаблону, описанному выше:

• --db-filter становится dbfilter

• --no-xmlrpc соответствует xmlrpc boolean

• (Все параметры, начинающиеся с --log-, за исключением --log-handler и --log-db) добавляются в содержимое log_handler

• --smtp записывается как smtp_server

• --database записывается как db_name

• --debug записывается как debug_mode (boolean)

• --i18n-import и --i18n-export не доступны в файле конфигурации

По умолчанию файл конфигурации находится в $HOME/.openerp_serverrc. Можно использовать файл конфигурации из другого места с помощью параметра --config. При использовании параметра --save произойдет сохранение текущей конфигурации в этот файл.