系统配置¶
本文档介绍在正式运行数据库或面向互联网的服务器上安装 Odoo 的基本步骤。它遵循 安装,对于不面向互联网的开发系统一般不需要。
警告
如果您正在设置公共服务器,请务必查看我们的:ref:`安全 <security>`建议!
数据库过滤器¶
Odoo是一个多租户系统:单一Odoo系统可以运行并启用若干数据库实例。Odoo也是高度可定制的,定制(如模块加载)依赖“当前数据库”。
以登录公司用户身份使用后端(Web 客户端)时,这不是问题:登录时可以选择数据库,然后加载自定义项。
但是,对于未绑定到数据库的非登录用户(门户,网站)来说,这是一个问题:Odoo需要知道应该使用哪个数据库来加载网站页面或执行操作。如果不使用多租户,这不是问题,只有一个数据库可以使用,但是如果有多个数据库可访问,Odoo需要一个规则来知道它应该使用哪一个。
这是 :option:--db-filter
的目的之一 <odoo-bin –db-filter>:它指定应如何根据所请求的主机名(域)选择数据库。该值是一个“正则表达式”_,可能包括动态注入的主机名(“%h”)或访问系统的第一个子域(%d“”)。</odoo-bin>
对于在生产环境中托管多个数据库的服务器,尤其是在使用“网站”的情况下,必须设置 dbfilter**,否则许多功能将无法正常工作。
配置示例¶
仅显示名称以“mycompany”开头的数据库
在:ref:`配置文件<reference/cmdline/config_file>`中设置:
[options]
dbfilter = ^mycompany.*$
仅显示与“www”之后的第一个子域匹配的数据库:例如,如果传入的请求发送到“www.mycompany.com”或“mycompany.co.uk”,则不会显示“www2.mycompany.com”或“helpdesk.mycompany.com”的数据库“ mycompany”。
在:ref:`配置文件<reference/cmdline/config_file>`中设置:
[options]
dbfilter = ^%d$
注解
设置适当的 --db-filter
是保护部署安全的重要部分。一旦它正常工作并且每个主机名只匹配一个数据库,强烈建议阻止对数据库管理器屏幕的访问,并使用“–no-database-list”启动参数来阻止列出数据库,并阻止对数据库管理屏幕的访问。另请参见‘安全’_。
PostgreSQL¶
默认情况下,PostgreSQL只允许通过UNIX套接字和环回连接进行连接(来自“localhost”,PostgreSQL服务器安装在同一台机器上)。
如果您希望Odoo和PostgreSQL在同一台机器上执行,UNIX套接字是可以的,并且在没有提供主机时是默认值,但是如果您希望Odoo和PostgreSQL在不同的机器[#different-machines]_上执行,它将需要“监听网络接口”_[#remote-socket]_,或者:
只接受环回连接,并在运行Odoo的计算机和运行PostgreSQL的计算机之间“使用SSH隧道”_,然后将Odoo配置为连接到其隧道的末端
接受与安装Odoo的计算机的连接,可能通过ssl(有关详细信息,请参阅“PostgreSQL连接设置”_),然后将Odoo配置为通过网络连接
配置示例¶
允许在本地主机上进行 tcp 连接
允许来自 192.168.1.x 网络的 tcp 连接
在 /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf
set中:
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 192.168.1.0/24 md5
在``/etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf`` set中:
listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80
配置 Odoo¶
开箱即用,Odoo通过UNIX套接字通过端口5432连接到本地postgres。当您的 Postgres 部署不是本地部署和/或不使用安装默认值时,可以使用 数据库选项 来覆盖它。
doc:软件包安装程序<packages>
会自动创建一个新用户 (odoo
),并将其设置为数据库用户。
数据库管理屏幕受“admin_passwd”设置保护。此设置只能使用配置文件进行设置,并且在执行数据库更改之前只需进行检查即可。应将其设置为随机生成的值,以确保第三方无法使用此接口。
所有数据库操作都使用 数据库选项,包括数据库管理屏幕。要使数据库管理屏幕正常工作,需要 PostgreSQL 用户具有“createdb”权限。
用户始终可以删除他们拥有的数据库。为了使数据库管理屏幕完全不起作用,需要使用“no-createdb”创建PostgreSQL用户,并且数据库必须由其他PostgreSQL用户拥有。
警告
PostgreSQL用户*必须不*是超级用户,例如:root或Adiministrator
配置示例¶
连接到 192.168.1.2 上的 PostgreSQL 服务器
端口 5432
使用“odoo”用户帐户,
使用“pwd”作为密码
仅筛选名称以“mycompany”开头的数据库名
在:ref:`配置文件<reference/cmdline/config_file>`中设置:
[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$
在 Odoo 和 PostgreSQL 之间使用 SSL¶
从Odoo 11.0开始,您可以在Odoo和PostgreSQL之间强制实施ssl连接。在Odoo中,db_sslmode通过从“禁用”,“允许”,“首选”,“要求”,“验证-ca”或“验证完全”中选择的值来控制连接的ssl安全性
内置服务器¶
Odoo 包括内置 HTTP、cron 和实时聊天服务器,应用多线程或多进程模式任选其一。
**多线程**服务器是一种更简单的服务器,主要用于开发和演示,并兼容各种操作系统(包括 Windows)。每个新的 HTTP 请求都会产生一个新的线程,即使是 websocket 等长期连接也不例外。此外,还会生成额外的守护进程定时线程。由于Python的限制(全局解释器锁),它不能充分利用硬件资源。
多线程服务器是默认服务器,也适用于 docker 容器。不使用 --workers
选项或将其设置为 0
,就可以选择多线程服务器。
**多处理**服务器是主要用于生产的完整服务器。它不受 Python 资源使用限制(GIL)约束,因此能充分利用硬件。服务器启动时会创建一个工作进程池。新的 HTTP 请求会被操作系统排队,直到有可用的工作进程来处理它们。为了处理实时聊天功能,还会在另一个端口上生成一个额外的基于事件驱动的 HTTP 工作进程。同时还会生成额外的定时任务工作进程。一个可配置的进程管理器会监控资源使用情况,并可以终止/重启失败的工作进程。
多进程服务器是可选的。可通过将 --workers
选项设置为非空整数来选择。
注解
由于多进程服务器为 Linux 服务器高度定制,因此 Windows 无法使用。
工人数计算¶
经验法则 : (#CPU * 2) + 1
Cron workers 需要 CPU
1 个工作线程 ~= 6 个并发用户
内存大小计算¶
我们认为 20% of 请求是繁重的请求,而 80% a是更简单的请求
一个繁重的工作,当所有计算字段都设计得很好,SQL请求设计得很好,…估计消耗约1GB的内存
在相同的情况下,较轻的工作线程估计会消耗大约150MB的RAM。
所需 RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )
在线聊天¶
在多进程模式下,会自动启动一个专用 LiveChat Worker,并通过 --gevent-port
监听。默认情况下,HTTP 请求将继续访问普通 HTTP 工作进程,而不是 LiveChat 工作进程。您必须在 Odoo 前部署一个代理,并将路径以 /websocket/
开头的传入请求重定向到 LiveChat 工作进程。您还必须在 --proxy-mode
下启动 Odoo,这样它就会使用真正的客户端头信息(如主机名、协议和 IP 地址)而不是代理头信息。
配置示例¶
具有 4 个 CPU、8 个线程的服务器
60 个并发用户
60 个用户 / 6 = 10 < - 理论上的线程数量
(4 * 2) + 1 = 9 <- 理论的最大线程数
我们将应用 8 线程 + 1 计划任务。我们还将使用监视系统来测量CPU负载,并检查它是否在7和7.5之间。
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3Go RAM 用于 Odoo
在:ref:配置文件 <reference/cmdline/config_file>
中:
[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都会以明文形式传输身份验证信息。这意味着Odoo的安全部署必须使用HTTPS3。SSL 终止可以通过几乎任何 SSL 终止代理实现,但需要以下设置:
启用 Odoo 的 :option:’代理模式(proxy mode) <odoo-bin –proxy-mode>’。仅当 Odoo 位于反向代理后面时,才应启用此功能
设置 SSL termination proxy (Nginx termination example)
设置代理本身 (Nginx proxying example)
您的 SSL 终止代理还应自动将不安全的连接重定向到安全端口
配置示例¶
将 http 请求重定向到 https
对 odoo 的代理请求
在:ref:`配置文件<reference/cmdline/config_file>`中设置:
proxy_mode = True
在 /etc/nginx/sites-enabled/odoo.conf
set中:
#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 $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;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
proxy_cookie_flags session_id samesite=lax secure; # requires nginx 1.19.8
}
# Redirect requests to odoo backend server
location / {
# 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;
proxy_redirect off;
proxy_pass http://odoo;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
proxy_cookie_flags session_id samesite=lax secure; # requires nginx 1.19.8
}
# common gzip
gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
gzip on;
}
HTTPS 加固¶
在所有请求中添加 “Strict-Transport-Security “标头,以防止浏览器向该域发送纯 HTTP 请求。您需要在该域上始终使用有效证书维护正常运行的 HTTPS 服务,否则您的用户将看到安全警报或完全无法访问该域。
在 NGINX 中使用以下命令行,在一年内强制每个访客使用 HTTPS 连接:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
可以为 session_id
cookie 定义其他配置。可添加`安全`标志以确保不会通过 HTTP 传输,并添加`SameSite=Lax`以防止验证`CSRF`_。
# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;
Odoo 作为 WSGI 应用程序¶
也可以将Odoo作为标准WSGI_应用。Odoo为WSGI启动器脚本提供了“odoo-wsgi.example.py”的基础。应该自定义该脚本(可能是在从安装目录复制它之后)以直接在:mod:`odoo.tools.config`中正确设置配置,而不是通过命令行或配置文件。
但是,WSGI 服务器将仅公开 Web 客户端、网站和 Web 服务 API 的主 HTTP 终结点。因为Odoo不再控制工人的创建,所以它无法设置cron或livechat工人
Cron Workers¶
要处理 cron 作业,必须在 WSGI 服务器旁边启动一个内置 Odoo 服务器。必须使用 --no-http
cli 选项或 “http_enable = False” 配置文件设置,将该服务器配置为只处理 cron 而不处理 HTTP 请求。
在类 Linux 系统上,建议使用多进程服务器而不是多线程服务器,这样可以更好地利用硬件并提高稳定性,即使用 --workers=-1
和 --max-cron-threads=n
cli 选项。
在线聊天¶
要正确运行即时聊天功能,必须使用与 gevent 兼容的 WSGI 服务器。该服务器应能同时处理多个长连接,但不需要很强的处理能力。所有路径以 /websocket/
开头的请求都应指向该服务器。所有其他请求都应使用普通的(基于线程/进程的)WSGI 服务器。
Odoo cron 服务器也可用于处理即时聊天请求。只需从 cron 服务器中删除 --no-http
cli 选项,并确保路径以 /websocket/
开头的请求会被定向到该服务器,或者在 --http-port
上(多线程服务器),或者在 --gevent-port
上(多处理服务器)。
提供静态文件和附件¶
为了便于开发,Odoo 直接提供其模块中的所有静态文件和附件。在性能方面,这可能并不理想,静态文件通常由静态 HTTP 服务器提供。
提供静态文件¶
Odoo 静态文件位于每个模块的 static/
文件夹中,因此可通过拦截对 /MODULE/static/FILE
的所有请求,并在各种附加组件路径中查找正确的模块(和文件)来提供静态文件。
建议在网络服务器发送的所有图像上设置``Content-Security-Policy: default-src ‘none’``标头。严格来说,这并非必要,因为用户无法在模块的 static/
文件夹中修改/注入内容,而且现有图像是最终的(它们不会自行获取新资源)。不过,这是一个很好的做法。
使用上述 NGINX (https) 配置,应添加以下 map
和 location
块,以便通过 NGINX 提供静态文件。
map $sent_http_content_type $content_type_csp {
default "";
~image/ "default-src 'none'";
}
server {
# the rest of the configuration
location @odoo {
# copy-paste the content of the / location block
}
# Serve static files right away
location ~ ^/[^/]+/static/.+$ {
# root and try_files both depend on your addons paths
root ...;
try_files ... @odoo;
expires 24h;
add_header Content-Security-Policy $content_type_csp;
}
}
实际的 root
和 try_files
指令取决于安装,特别是 --addons-path
。
Example
假设 Odoo 已通过**debian 软件包**安装为社区版和企业版,且 --addons-path <odoo-bin --addons-path>`
为``’/usr/lib/python3/dist-packages/odoo/addons’``。
root
和 try_files
应该为:
root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;
假设 Odoo 已通过 sources 安装,社区版和企业版的 git 仓库分别克隆在 /opt/odoo/community
和 /opt/odoo/enterprise
中,并且 --addons-path
是 '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'
。
root
和 try_files
应该为:
root /opt/odoo;
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;
提供附件¶
附件是存储在文件库中的文件,其访问受 Odoo 监管。它们不能通过静态网络服务器直接访问,因为访问它们需要在数据库中进行多次查找,以确定文件存储在哪里,以及当前用户是否可以访问它们。
不过,一旦找到文件并由 Odoo 验证了访问权限,最好使用静态网络服务器而不是 Odoo 来提供文件。要让 Odoo 委托静态网络服务器发送文件,必须在静态网络服务器上启用并配置 X-Sendfile (apache) 或 X-Accel (nginx)扩展。设置完成后,使用 --x-sendfile
CLI 标志启动 Odoo(X-Sendfile 和 X-Accel 均使用此唯一标志)。
注解
apache(以及兼容的网络服务器)的 X-Sendfile 扩展不需要任何辅助配置。
NGINX 的 X-Accel 扩展**的确**需要以下额外配置:
location /web/filestore { internal; alias /path/to/odoo/data-dir/filestore; }
如果您不知道文件库的路径,请使用
--x-sendfile
选项启动 Odoo,并通过 Odoo 直接导航到/web/filestore
URL(不要通过 NGINX 导航到 URL)。这将记录警告,信息中包含您需要的配置。
安全¶
首先,请记住,保护信息系统是一个连续的过程,而不是一次性操作。在任何时候,您都只能像环境中最薄弱的环节一样安全。
因此,请不要将此部分视为防止所有安全问题的最终措施列表。它仅作为安全行动计划中应确保包含的第一个重要事项的摘要。其余的将来自操作系统和发行版的最佳安全实践,用户,密码和访问控制管理等方面的最佳实践。
部署面向互联网的服务器时,请务必考虑以下与安全相关的主题:
始终设置强超级管理员密码,并在系统设置后立即限制对数据库管理页面的访问。请参阅:数据库管理器安全性。
为所有数据库上的所有管理员帐户选择唯一登录名和强密码。不要使用“admin”作为登录名。不要将这些登录名用于日常操作,仅用于控制/管理安装。*从不*使用任何默认密码,如管理员/管理员,即使对于测试/临时数据库也是如此。
不要 **要 **面向互联网的服务器上安装演示数据。包含演示数据的数据库包含默认登录名和密码,可用于进入系统并造成重大麻烦,即使在暂存/开发系统上也是如此。
使用适当的数据库筛选器 (
--db-filter
) 根据主机名限制数据库的可见性。请参阅:数据库过滤器。您还可以使用-d
来提供您自己的(逗号分隔的)可用数据库列表,以便从中进行筛选,而不是让系统从数据库后端获取所有数据库。一旦配置了“db_name”和“db_filter”,并且每个主机名只匹配一个数据库,则应将“list_db”配置选项设置为“False”,以防止完全列出数据库,并阻止对数据库管理屏幕的访问(这也显示为 :option:`–no-database-list <odoo-bin –no-database-list>`命令行选项)
确保 PostgreSQL 用户 (
--db_user
) 不是超级用户,并且您的数据库由其他用户拥有。例如,如果您使用的是专用的非特权“db_user”,则可以由“postgres”超级用户拥有。另请参阅 :odoo。通过 GitHub 定期安装最新版本,或者从 https://www.odoo.com/page/download 或 http://nightly.odoo.com 下载最新版本,从而保持安装更新
在多进程模式下配置服务器,并具有与典型使用(内存/CPU/超时)匹配的适当限制。另请参阅:内建服务器。
在提供HTTPS终止的Web服务器后面运行Odoo,并提供有效的SSL证书,以防止窃听明文通信。SSL证书很便宜,并且存在许多免费选项。将 Web 代理配置为限制请求的大小,设置适当的超时,然后启用
proxy mode
选项。另请参阅:Https 代理。如果需要允许对服务器进行远程 SSH 访问,请确保为 all 帐户设置强密码,而不仅仅是“root”。强烈建议完全禁用基于密码的身份验证,并且仅允许公钥身份验证。还要考虑限制通过VPN的访问,仅允许防火墙中的受信任IP,和/或运行暴力检测系统,如“fail2ban”或等效系统。
请考虑在代理或防火墙上安装适当的速率限制,以防止暴力攻击和拒绝服务攻击。另请参阅:ref:`login_brute_force`了解具体措施。
许多网络提供商为分布式拒绝服务攻击 (DDOS) 提供自动缓解措施,但这通常是一项可选服务,因此您应该咨询他们。
只要有可能,就将面向公众的演示/测试/过渡实例托管在与生产计算机不同的计算机上。并应用与生产相同的安全预防措施。
如果您面向公众的 Odoo 服务器可以访问敏感的内部网络资源或服务(例如,通过专用 VLAN),请实施适当的防火墙规则来保护这些内部资源。这将确保 Odoo 服务器不会被意外使用(或由于恶意用户操作)来访问或破坏这些内部资源。通常,这可以通过在防火墙上应用出站默认的DENY规则来完成,然后仅显式授权访问Odoo服务器需要访问的内部资源。“systemd IP 流量访问控制<http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html>”_ 对于实现每个进程的网络访问控制也可能很有用。
如果您的面向公众的Odoo服务器位于Web应用程序防火墙,负载平衡器,透明DDoS保护服务(如CloudFlare)或类似的网络级设备后面,您可能希望避免直接访问Odoo系统。通常很难对Odoo服务器的端点IP地址保密。例如,当查询公共系统时,它们可以出现在Web服务器日志中,或者出现在从Odoo发布的电子邮件的标题中。在这种情况下,您可能需要配置防火墙,以便除了从 WAF、负载均衡器或代理服务的特定 IP 地址访问终结点外,无法公开访问终结点。为此,像CloudFlare这样的服务提供商通常会维护其IP地址范围的公共列表。
如果您托管多个客户,请使用容器或适当的“jail”技术将客户数据和文件彼此隔离。
设置数据库和文件存储数据的每日备份,并将它们复制到无法从服务器本身访问的远程存档服务器。
强烈建议在 Linux 平台上部署 Odoo,而不是 Windows 平台。如果您还是选择在 Windows 平台上部署,则应对服务器进行彻底的安全加固审查,这不在本指南的讨论范围之内。
阻止暴力破解攻击¶
对于面向互联网的部署,对用户密码的暴力攻击非常普遍,对于Odoo服务器来说,这种威胁不容忽视。每当执行登录尝试时,Odoo都会发出日志条目,并报告结果:成功或失败,以及目标登录和源IP。
日志条目将具有以下形式。
登录失败::
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
登录成功:
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
这些日志可以通过入侵防御系统(如“fail2ban”)轻松分析。
例如,以下 fail2ban 筛选器定义应与失败的登录相匹配:
[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =
这可以与 jail 定义一起使用,以阻止 HTTP(S) 上的攻击 IP。
以下是在 1 分钟内从同一 IP 检测到 10 次登录尝试失败时,阻止 IP 15 分钟的情况:
[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
数据库管理器安全性¶
:ref:setup/deploy/odoo
顺便提到``admin_passwd``
此设置用于所有数据库管理屏幕(用于创建、删除、转储或还原数据库)。
如果管理屏幕根本无法访问,则应将“list_db”配置选项设置为“False”,以阻止访问所有数据库选择和管理屏幕。
警告
强烈建议对任何面向 Internet 的系统禁用数据库管理器!它旨在作为开发/演示工具,以便于快速创建和管理数据库。它不是为在生产中使用而设计的,甚至可能向攻击者暴露危险的功能。它也不是为处理大型数据库而设计的,并且可能会触发内存限制。
在生产系统上,数据库管理操作应始终由系统管理员执行,包括预配新数据库和自动备份。
请务必设置适当的“db_name”参数(也可以选择“db_filter”),以便系统可以确定每个请求的目标数据库,否则用户将被阻止,因为他们将不被允许自己选择数据库。
如果只能从一组选定的计算机访问管理屏幕,请使用代理服务器的功能阻止访问以“/web/database”开头的所有路由,但(可能)“/web/database/selector”除外,它显示数据库选择屏幕。
如果数据库管理屏幕应保持可访问状态,则必须将“admin_passwd”设置从其默认值“admin”更改为“admin”:在允许数据库更改操作之前,将检查此密码。
它应该安全地存储,并且应该随机生成,例如
$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'
这将生成一个32个字符的伪随机可打印字符串。
重置主密码¶
在某些情况下,主密码可能被放错位置或泄露,需要重新设置。以下流程面向 Odoo 内部数据库的系统管理员,详细介绍了如何手动重置和重新加密主密码。
参见
有关更改 Odoo.com 帐户密码的更多信息,请参阅此文档: 修改 Odoo.com 账户密码。
创建新的内部数据库时,会生成一个随机主密码。Odoo 建议使用该密码来保护数据库的安全。默认情况下会使用该密码,因此任何 Odoo 本地安装都有一个安全的主密码。
警告
创建 Odoo 本地安装数据库时,在设置密码以确保数据库安全之前,互联网上的任何人都可以访问安装的数据库。
主密码在 Odoo 配置文件(odoo.conf
或 `odoorc`(隐藏文件))中指定。通过图形用户界面(GUI)修改、创建或删除数据库时,需要使用 Odoo 主密码。
找到配置文件¶
首先,打开 Odoo 配置文件(odoo.conf
或`odoorc`(隐藏文件))。
配置文件位于 c:ProgramFilesOdoo{VERSION}serverodoo.conf
根据 Odoo 在 Linux 机器上的安装方式,配置文件位于两个不同位置之一:
软件包安装:`/etc/odoo.conf
源安装:
~/.odoorc
更改旧密码¶
打开相应文件后,将配置文件中的旧密码修改为临时密码。
找到配置文件后,使用图形用户界面打开文件。只需双击文件即可打开。然后,设备应该有一个默认的 GUI (图形用户界面) 来打开文件。
接下来,将主密码行 admin_passwd = $pbkdf2-sha...
修改为 admin_passwd = newpassword1234
。这个密码可以是任何内容,只要是临时保存的。确保修改 =
后面的所有字符。
Example
该行显示如下 admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m
.
修改后的行显示如下:admin_passwd = newpassword1234
使用下面的 Unix 命令修改主密码行。
通过安全外壳(SSH)协议连接到 Odoo 服务器的终端,然后编辑配置文件。要修改配置文件,请输入以下命令: sudo nano /etc/odoo.conf。
打开配置文件后,将主密码行 admin_passwd = $pbkdf2-sha...
修改为 admin_passwd = newpassword1234
。这个密码可以是任何内容,只要是临时保存的。确保修改 =
后面的所有字符。
Example
该行显示如下 admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m
.
修改后的行显示如下:admin_passwd = newpassword1234
重要
必须将密码更改为其他内容,而不是在行首添加分号 ;
,从而触发新的密码重置。这样可以确保整个密码重置过程中数据库的安全。
重启 Odoo 服务器¶
设置临时密码后,**需要**重启 Odoo 服务器。
要重启 Odoo 服务器,首先在 Windows 搜索 栏中输入 服务
。然后,选择 服务 应用程序,向下滚动到 Odoo 服务。
接下来,右键单击 Odoo,然后选择 开始 或 重启。此操作将手动重启 Odoo 服务器。
重新启动 Odoo 服务器,键入指令:sudo service odoo15 restart
注解
更改 odoo
后面的数字,以适应服务器运行的特定版本。
使用网络界面重新加密密码¶
首先,在浏览器中导航到 /web/database/manager
或 http://server_ip:port/web/database/manager
。
注解
将 server_ip
替换为数据库的 IP 地址。将 port
替换为数据库可访问的端口号。
然后,点击 设置主密码,并在 主密码 字段中输入之前选择的临时密码。在此步骤之后,输入 新主密码。点击 继续 按钮后,新主密码 将被散列(或加密)。
此时,密码已成功重置,新密码的散列版本已出现在配置文件中。
参见
有关 Odoo 数据库安全性的更多信息,请参阅此文档:数据库管理器安全性。
将图像的 WebP 版本用于受支持的浏览器,并且对于不支持 WebP 的浏览器,请优雅地回退 JPEG 和 PNG。¶
Odoo支持市场上所有主要的桌面和移动浏览器,只要它们得到出版商的支持。
以下是支持的浏览器:
谷歌浏览器
火狐浏览器
Microsoft Edge
苹果浏览器
警告
在提交错误报告之前,请确保您的浏览器是最新的,并且仍然受其发布者的支持。
注解
从Odoo 13.0开始,支持ES6。 因此,将删除 IE 支持。