• Запуск сервера
  • database
  • Интернационализация
  • built-in HTTP
  • logging
• Scaffolding
• Файл конфигурации

Оригинал на GitHub

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

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

database used when installing or updating modules.

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

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

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

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

--addons-path <directories>

comma-separated list of directories in which modules are stored. These directories are scanned for modules (nb: when and why?)

--workers <count>

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

Примечание

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

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

--limit-request <limit>

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

Defaults to 8196.

--limit-memory-soft <limit>

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

Defaults to 2048MB.

--limit-memory-hard <limit>

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

Defaults to 2560MB.

--limit-time-cpu <limit>

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

Defaults to 60.

--limit-time-real <limit>

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

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

Defaults to 120.

--max-cron-threads <count>

number of workers dedicated to cron jobs. Defaults to 2. The workers are threads in multi-threading mode and processes in multi-processing mode.

В режиме мультипроцессорной обработки это в дополнение к воркерам обрабатывающим HTTP.

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

provide an alternate configuration file

-s, --save

saves the server configuration to the current configuration file ($HOME/.openerp_serverrc by default, and can be overridden using -c)

--proxy-mode

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

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

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

--test-enable

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

--debug

when an unexpected error is raised (not a warning or an access error), automatically starts pdb before logging and returning the error

database

-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 is replaced by the subdomain the request is made on, with the exception of www (so domain odoo.com and www.odoo.com both match the database odoo)

--db-template <template>

when creating new databases from the database-management screens, use the specified template database. Defaults to template1.

Интернационализация

Используйте эти опции для перевода Odoo на другой язык. См. Раздел i18n руководства пользователя. Опция -d обязательна. Опция -l обязательна в случае импорта

--load-language <languages>

укажите языки (разделенные запятыми) для переводов, которые вы хотите загрузить

-l, --language <language>

указать язык файла перевода. Используйте его с --i18n-export или --i18n-import

--i18n-export <filename>

экспортировать все предложения для перевода в файл CSV, PO-файл или архив TGZ и выйти.

--i18n-import <filename>

импортировать файл CSV или PO с переводами и выйти. Опция -l обязательна.

--i18n-overwrite

перезаписывает существующие термины перевода при обновлении модуля или импорте файла CSV или PO.

--modules

указать модули для экспорта. Использовать в сочетании с --i18n-export

built-in HTTP

--no-xmlrpc

do not start the HTTP or long-polling workers (may still start cron workers)

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

не действует, если используется параметр --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. Не используется в режиме по умолчанию.

logging

By default, Odoo displays all logging of level info except for workflow logging (warning only), and log output is sent to stdout. Various options are available to redirect logging to other destinations and to customize the amount of logging output

--logfile <file>

sends logging output to the specified file instead of stdout. On Unix, the file can be managed by external log rotation programs and will automatically be reopened when replaced

--logrotate

enables log rotation daily, keeping 30 backups. Log rotation frequency and number of backups is not configurable.

--syslog

logs to the system's event logger: syslog on unices and the Event Log on Windows.

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

--log-db <dbname>

logs to the ir.logging model (ir_logging table) of the specified database. The database can be the name of a database in the "current" PostgreSQL, or a PostgreSQL URI for e.g. log aggregation

--log-handler <handler-spec>

LOGGER:LEVEL, enables LOGGER at the provided LEVEL e.g. openerp.models:DEBUG will enable all logging messages at or above DEBUG level in the models.

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

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

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

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

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

--log-request

enable DEBUG logging for RPC requests, equivalent to --log-handler=openerp.http.rpc.request:DEBUG

--log-response

enable DEBUG logging for RPC responses, equivalent to --log-handler=openerp.http.rpc.response:DEBUG

--log-web

enables DEBUG logging of HTTP requests and responses, equivalent to --log-handler=openerp.http:DEBUG

--log-sql

enables DEBUG logging of SQL querying, equivalent to --log-handler=openerp.sql_db:DEBUG

--log-level <level>

Shortcut to more easily set predefined levels on specific loggers. "real" levels (critical, error, warn, debug) are set on the openerp and werkzeug loggers (except for debug which is only set on openerp).

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

debug_sql

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

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

debug_rpc

sets the openerp and HTTP request loggers to debug

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

debug_rpc_answer

sets the openerp and HTTP request and response loggers to debug

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

Примечание

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

Scaffolding

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

Scaffolding is available via the odoo.py scaffold subcommand.

-t <template>

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

name

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

destination

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

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

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

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

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

• --no-xmlrpc corresponds to the xmlrpc boolean

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

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

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

• --debug is stored as debug_mode (a boolean)

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

The default configuration file is $HOME/.openerp_serverrc which can be overridden using --config. Specifying --save will save the current configuration state back to that file.