系統配置¶

本文介紹在正式運行資料庫或對外向互聯網開放的伺服器上，安裝 Odoo 的基本步驟。安裝過程大致與安裝相若，而不對外向互聯網開放的開發系統，一般不需要進行此安裝。

警告

若要設置公共伺服器，請務必查看我們的安全措施建議！

dbfilter 資料庫篩選器¶

Odoo 系統以多租戶形式運作，單一個 Odoo 系統可以運行及服務數個資料庫安裝個體。Odoo 亦具有高度可自訂空間，而自訂功能（例如加載的模組）需要依賴「目前資料庫」。

透過已登入公司使用者身份使用後端（網絡客戶端）時，這不會是問題，因為登入時可選擇適用的資料庫，然後加載自訂功能。

但是，對於未綁定至資料庫的非登入使用者（門戶、網站）來說，這是一個問題，因為 Odoo 需要知道應該使用哪個資料庫去載入網站頁面或執行操作。若不採用多租戶，這不會是問題，因為只有一個資料庫可以使用；但如果有多個資料庫可以存取，Odoo 便需要一個規則，去決定應該使用哪一個資料庫。

這正是 --db-filter 指令的用途之一：它用作指定應如何根據所請求的主機名（網域）選擇資料庫。該值是一個正規表達式，可能包括動態注入的主機名（%h）或存取系統時經過的第一個子網域（%d）。

對於在正式運行環境中寄存多個資料庫的伺服器，尤其是在使用「網站」的情況下，便必須設置 dbfilter，否則有多項功能將無法正確運作。

配置範例¶

只顯示名稱以「mycompany」起首的資料庫

在配置檔案中，設定：

[options]
dbfilter = ^mycompany.*$

只顯示符合 www 之後第一個子網域的資料庫：例如，如果傳入的請求發送至 www.mycompany.com 或 mycompany.co.uk，會顯示資料庫「mycompany」；但若果是 www2.mycompany.com 或 helpdesk.mycompany.com 便不會顯示。

在配置檔案中，設定：

[options]
dbfilter = ^%d$

備註

設置適當的 --db-filter 是保護安裝個體安全的重要一環。當它正確運作，而每個主機名稱只匹配至一個資料庫後，強烈建議封鎖對資料庫管理工具畫面的存取要求，並使用 --no-database-list 啟動參數去阻止系統列出資料庫，並封鎖對資料庫管理畫面的存取要求。另請參閱：安全。

PostgreSQL¶

預設情況下，PostgreSQL 只允許通過 UNIX 通訊端及環迴連線（來自「localhost」，即與 PostgreSQL 伺服器安裝的機器相同）去進行連線。

若希望 Odoo 及 PostgreSQL 在同一台機器上執行，使用 UNIX 通訊端是沒有問題的，而且它是在沒有提供主機時的預設值。但若想 Odoo 和 PostgreSQL 在不同的機器 1 上執行，將需要監聽網絡介面 2。你可選擇其中一項：

只接受環迴連線，並在運行 Odoo 及 PostgreSQL 的不同機器之間使用 SSH 隧道，然後將 Odoo 配置為連線至該隧道的末端；
接受向安裝 Odoo 的機器傳送的連線，有可能通過 ssl（詳情請參閱 PostgreSQL 連線設定），然後將 Odoo 配置為透過網絡連線。

配置範例¶

允許在 localhost 本地主機上，進行 tcp 連線
允許由 192.168.1.x 網絡提出的 tcp 連線

在 /etc/postgresql/<你的 PostgreSQL 版本>/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/<你的 PostgreSQL 版本>/main/postgresql.conf 內，設定：

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

配置 Odoo¶

Odoo 開箱即用，透過 UNIX 通訊端通過連接埠 5432 連線至本地 postgres。若你的 Postgres 部署不是本地寄存及/或不使用安裝後的預設設定時，可使用資料庫選項去覆蓋它。

套裝化安裝程式會自動建立一個新的用戶（odoo），並將它設為資料庫使用者。

資料庫管理畫面受 admin_passwd 的設定所保護。此設定只可透過配置檔案進行設置，並會在執行資料庫更改前，只作簡單檢查。它應設為隨機生成的數值，以確保第三方無法使用此介面。
所有資料庫操作都使用資料庫選項，包括資料庫管理畫面。要使資料庫管理畫面正常運作，需要 PostgreSQL 使用者具有 createdb 權限。
使用者始終可以刪除他們名下擁有的資料庫。為使資料庫管理畫面完全無法運作，需要使用 no-createdb 建立 PostgreSQL 使用者，而且資料庫必須由其他 PostgreSQL 使用者擁有。

警告
該 PostgreSQL 使用者不可是超級使用者

配置範例¶

連線至 192.168.1.2 上的 PostgreSQL 伺服器
連接埠 5432
使用「odoo」使用者帳戶，
以「pwd」作為密碼
只篩選名稱起首是「mycompany」的資料庫

在配置檔案中，設定：

[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 去控制連線的 ssl 安全性，可選用值為：disable（停用）、allow（允許）、prefer（偏好）、require（必需）、verify-ca（驗證ca）及 verify-full（完整驗證）。

PostgreSQL 使用說明

內置伺服器¶

Odoo 已有內置 HTTP、cron 以及實時聊天伺服器，只會是使用多線程或多進程模式。

多線程 伺服器是較簡單的伺服器，主要用於開發、演示，及利用其兼容各種操作系統（包括 Windows）的特性。每個新的 HTTP 請求都會產生一個新的線程，即使是 websocket 等的長時間連線也不例外。此外，還會生成額外的守護 cron 線程。由於 Python 有限制（GIL 全域直譯器鎖），它不能充份利用硬件的性能。

多線程伺服器是預設的伺服器，也適用於 docker 容器。只要不使用 --workers 選項，或將其設為 0，就可以選擇多線程伺服器。

多處理程序 伺服器是主要用於生產的完整伺服器。它不受 Python 的資源使用限制（GIL）約束，因此能充份利用硬件。伺服器啟動時，會建立一個工作進程池。新的 HTTP 請求會被操作系統排隊，直至有可用的工作進程可以處理它們。為處理實時聊天功能，系統還會在另一個連接埠上，生成一個額外、基於事件驅動的 HTTP 工作進程，同時還會生成額外的定時任務工作進程。一個可配置的進程管理器，會監控資源使用情況，並可以終止/重新啟動失敗的工作進程。

多進程伺服器是要你選擇使用，才會生效。可將 --workers 選項設為非空白整數去選用。

備註

由於多進程伺服器是高度自訂給 Linux 伺服器使用，因此 Windows 無法使用。

計算工作器數目¶

一般估算法則：(中央處理器數目 × 2) + 1
Cron 工作器需要中央處理器
1 個工作器 ~= 6 個同時存取使用者

計算記憶體大小¶

我們認為 20% 的請求是重度請求，而 80% 是較簡單的請求
在所有計算欄位都經過良好設計、SQL 請求都經過良好設計等情況下，重度工作程序估計會消耗約 1GB RAM
在相同情況下,輕度工作程序估計會消耗約 150MB RAM

所需記憶體 = 工作器數目 × ( (輕型工作器比例 × 輕型工作器記憶體估算值) + (重型工作器比例 × 重型工作器記憶體估算值) )

實時聊天¶

在多程序處理中，會自動啟動專用的即時聊天工作程序，並監聽:option:--gevent-port <odoo-bin --gevent-port>。預設情況下，HTTP 請求會繼續存取正常的 HTTP 工作程序，而非即時聊天工作程序。您必須在 Odoo 前面部署代理伺服器，並將路徑以 /websocket/ 開頭的傳入請求重新導向到即時聊天工作程序。您還必須以:option:`–proxy-mode <odoo-bin –proxy-mode>`啟動 Odoo，以便它使用真實的客戶端標頭（例如主機名稱、配置和 IP）而非代理伺服器的標頭。

配置範例¶

伺服器配備 4 個 CPU、8 個執行緒
60 個同時存取使用者
60 個使用者 / 6 = 10 <- 理論上需要的工作程序數量
(4 * 2) + 1 = 9 <- 理論上的最大工作程序數量
我們將使用 8 個工作程序 + 1 個用於 cron。我們還會使用監控系統來測量 CPU 負載，並檢查其是否在 7 到 7.5 之間。
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB 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 的安全部署必須使用 HTTPS[#switching]_。SSL 終止可以透過幾乎任何 SSL 終止代理伺服器實作，但需要以下設定：

啟用 Odoo 的:option:代理模式 <odoo-bin --proxy-mode>。這應該只在 Odoo 位於反向代理伺服器後面時啟用
設定 SSL 終止代理伺服器（Nginx 終止範例）
設定代理本身（Nginx 代理範例）
您的 SSL 終止代理伺服器還應自動將非安全連線重新導向到安全連接埠

配置範例¶

將 http 請求重新導向到 https
代理請求至 Odoo

在配置檔案中，設定：

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;
}
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 定義額外配置。可以加入 Secure 標誌以確保永不透過 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。該腳本應進行自訂(可能在從安裝目錄複製後),以便直接在 odoo.tools.config 中正確設定配置,而不是透過命令列或配置檔案。

然而,WSGI 伺服器僅會公開用於網頁客戶端、網站和網頁服務 API 的主要 HTTP 端點。由於 Odoo 不再控制工作程序的建立,因此無法設定 cron 或線上客服工作程序

Cron 工作程序¶

需要在 WSGI 伺服器旁啟動其中一個內建的 Odoo 伺服器來處理 cron 作業。該伺服器必須配置為僅處理 cron 而不處理 HTTP 請求,使用 --no-http 命令列選項或配置檔案中的 http_enable = False 設定。

在類 Linux 系統上,建議使用多處理程序伺服器而非多執行緒伺服器,以獲得更好的硬體使用率和更高的穩定性,即使用 --workers=-1 和 --max-cron-threads=n 命令列選項。

實時聊天¶

線上客服功能的正確運作需要使用與 gevent 相容的 WSGI 伺服器。該伺服器應能夠處理許多同時進行的長期連線,但不需要大量處理能力。所有路徑以 /websocket/ 開頭的請求都應導向該伺服器。其他所有請求應使用一般的(基於執行緒/處理程序的)WSGI 伺服器。

Odoo cron 伺服器也可用於處理線上客服請求。只需從 cron 伺服器中移除 --no-http 命令列選項,並確保路徑以 /websocket/ 開頭的請求導向此伺服器,無論是在 --http-port <odoo-bin --http-port>`(多執行緒伺服器)還是在 :option:–gevent-port <odoo-bin –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 為 '/usr/lib/python3/dist-packages/odoo/addons'。

root 和 try_files 應為：

root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;

假設 Odoo 是透過**原始碼**安裝的，社群版和企業版 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 <https://tn123.org/mod_xsendfile/>`_(apache) 或 X-Accel (nginx) 擴充功能。設定完成後,使用 :option:–x-sendfile <odoo-bin –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;
    add_header Content-Security-Policy $upstream_http_content_security_policy;
    add_header X-Content-Type-Options nosniff;
}
```
如果您不知道檔案儲存區的路徑，請使用 --x-sendfile 選項啟動 Odoo，並直接透過 Odoo 導覽至 /web/filestore 網址（不要透過 NGINX 導覽至該網址）。這會記錄警告訊息，該訊息包含您需要的配置。

安全¶

首先，請記住，保護資訊系統是一個持續的過程，而不是一次性的操作。在任何時候，您的安全性只能與環境中最薄弱的環節一樣強。

因此，請不要將本節視為可防止所有安全問題的最終措施清單。它僅旨在總結您應確保包含在安全行動計劃中的首要重要事項。其餘的將來自作業系統和發行版的最佳安全實踐、使用者、密碼和存取控制管理方面的最佳實踐等。

部署面向網際網路的伺服器時，請務必考慮以下與安全相關的主題：

務必設定強式的超級管理員密碼，並在系統設定完成後立即限制對資料庫管理頁面的存取。請參閱資料庫管理員安全性。
為所有資料庫上的所有管理員帳戶選擇唯一的登入名稱和強式密碼。不要使用「admin」作為登入名稱。不要將這些登入名稱用於日常操作，僅用於控制/管理安裝。*絕不*使用任何預設密碼（如 admin/admin），即使是測試/預備資料庫也不行。
**不要**在面向網際網路的伺服器上安裝示範資料。含有示範資料的資料庫包含可用於進入您系統並造成重大問題的預設登入名稱和密碼，即使在預備/開發系統上也是如此。
使用適當的資料庫篩選器（--db-filter）根據主機名稱限制資料庫的可見性。請參閱 dbfilter 資料庫篩選器。您也可以使用 -d 提供您自己的可用資料庫清單（以逗號分隔）進行篩選，而不是讓系統從資料庫後端擷取所有資料庫。
一旦您的 db_name 和 dbfilter 配置完成且每個主機名稱僅符合單一資料庫，您應將 list_db 配置選項設為 False，以完全防止列出資料庫，並封鎖對資料庫管理畫面的存取（這也作為 --no-database-list 命令列選項公開）
確保 PostgreSQL 使用者（--db_user）*不是*超級使用者，且您的資料庫由不同的使用者擁有。例如，如果您使用專用的非特權 db_user，它們可以由 postgres 超級使用者擁有。另請參閱配置 Odoo。
定期安裝最新版本以保持安裝的更新狀態，可以透過 GitHub 或從 https://www.odoo.com/page/download 或 http://nightly.odoo.com 下載最新版本
以多處理程序模式配置伺服器，並設定符合典型使用情況的適當限制（記憶體/CPU/逾時）。另請參閱內置伺服器。
在提供 HTTPS 終止且具有有效 SSL 憑證的網頁伺服器後方執行 Odoo，以防止明文通訊遭到竊聽。SSL 憑證價格低廉，且有許多免費選項。配置網頁代理伺服器以限制請求大小、設定適當的逾時，然後啟用 proxy mode 選項。另請參閱 HTTPS。
如果需要允許遠端 SSH 存取伺服器，請確保為**所有**帳戶設定強式密碼，而不僅僅是 root。強烈建議完全停用基於密碼的驗證，僅允許公開金鑰驗證。也請考慮透過 VPN 限制存取、在防火牆中僅允許受信任的 IP，和/或執行暴力破解偵測系統，例如 fail2ban 或同等系統。
考慮在代理伺服器或防火牆上安裝適當的速率限制，以防止暴力破解攻擊和阻斷服務攻擊。另請參閱阻止暴力破解攻擊了解具體措施。

許多網路供應商提供分散式阻斷服務攻擊 (DDOS) 的自動緩解措施，但這通常是選用服務，因此您應諮詢供應商。
盡可能將面向公眾的示範/測試/預備實例託管在與正式環境不同的機器上，並套用與正式環境相同的安全預防措施。
如果面向公眾的 Odoo 伺服器可以存取敏感的內部網路資源或服務（例如透過私有 VLAN），請實作適當的防火牆規則以保護這些內部資源。這將確保 Odoo 伺服器不會意外（或因惡意使用者行為）被用於存取或中斷這些內部資源。通常可以透過在防火牆上套用預設 DENY 的出站規則，然後僅明確授權 Odoo 伺服器需要存取的內部資源來實現。Systemd IP traffic access control 也可能有助於實作每個處理程序的網路存取控制。
如果面向公眾的 Odoo 伺服器位於網頁應用程式防火牆、負載平衡器、透明 DDoS 防護服務（如 CloudFlare）或類似網路層級裝置後方，您可能希望避免直接存取 Odoo 系統。通常很難保持 Odoo 伺服器端點 IP 位址的機密性。例如，它們可能出現在查詢公共系統時的網頁伺服器記錄中，或出現在從 Odoo 發布的電子郵件標頭中。在這種情況下，您可能需要配置防火牆，使端點無法從公開網路存取，除非來自 WAF、負載平衡器或代理服務的特定 IP 位址。CloudFlare 等服務供應商通常會維護其 IP 位址範圍的公開清單以供此用途使用。
如果您託管多個客戶，請使用容器或適當的「隔離」技術將客戶資料和檔案彼此隔離。
設定資料庫和檔案儲存資料的每日備份，並將其複製到無法從伺服器本身存取的遠端封存伺服器。
強烈建議在 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

資料庫管理員安全性¶

配置 Odoo 順帶提及了 admin_passwd。

此設定用於所有資料庫管理畫面（建立、刪除、傾印或還原資料庫）。

如果不應允許存取管理畫面，您應將 list_db 配置選項設為 False，以封鎖對所有資料庫選擇和管理畫面的存取。

警告

強烈建議對任何面向網際網路的系統停用資料庫管理員！它是一個開發/展示工具，旨在輕鬆快速地建立和管理資料庫。它並非設計用於生產環境，甚至可能向攻擊者暴露危險功能。它也不是設計用來處理大型資料庫，可能會觸發記憶體限制。

在生產系統上，資料庫管理操作應始終由系統管理員執行，包括配置新資料庫和自動備份。

請務必設定適當的 db_name 參數（以及選擇性地設定 dbfilter），以便系統可以為每個請求確定目標資料庫，否則使用者將被封鎖，因為他們不被允許自行選擇資料庫。

如果管理畫面只能從選定的機器存取，請使用代理伺服器的功能來封鎖所有以 /web/database 開頭的路由的存取，但（可能）``/web/database/selector`` 除外，該路由顯示資料庫選擇畫面。

如果資料庫管理畫面應保持可存取，則必須將 admin_passwd 設定從其 admin 預設值更改：在允許資料庫變更操作之前會檢查此密碼。

它應該安全儲存，並且應該隨機生成，例如

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

這會生成一個 32 字元的偽隨機可列印字串。

重設主密碼¶

可能會發生主密碼遺失或洩露，需要重設的情況。以下流程適用於 Odoo 離線安裝資料庫的系統管理員，詳細說明如何手動重設和重新加密主密碼。

其他資料

Odoo.com 帳戶

建立新的離線安裝資料庫時，會生成一個隨機主密碼。Odoo 建議使用此密碼來保護資料庫。此密碼預設實施，因此任何 Odoo 離線安裝部署都有安全的主密碼。

警告

建立 Odoo 離線安裝資料庫時，在設定此密碼以保護資料庫之前，網際網路上的任何人都可以存取該安裝。

主密碼在 Odoo 配置檔案中指定（odoo.conf 或 `odoorc`（隱藏檔案））。需要 Odoo 主密碼才能透過圖形使用者介面 (GUI) 修改、建立或刪除資料庫。

找出配置檔案¶

首先，開啟 Odoo 配置檔案（odoo.conf 或 `odoorc`（隱藏檔案））。

配置檔案位於：c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

根據 Odoo 在 Linux 機器上的安裝方式，配置檔案位於以下兩個不同位置之一：

套件安裝：/etc/odoo.conf
原始碼安裝：~/.odoorc

變更舊密碼¶

開啟適當的檔案後，請繼續將配置檔案中的舊密碼修改為臨時密碼。

找到配置檔案後，使用:abbr:圖形使用者介面 (GUI) 開啟它。只需按兩下該檔案即可完成此操作。然後，裝置應具有預設的:abbr:圖形使用者介面 (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 搜尋`列中輸入 `services。然後，選取:guilabel:服務`應用程式，並向下捲動至:guilabel:`Odoo 服務。

接下來，在:guilabel:Odoo 上按一下滑鼠右鍵，然後選取:guilabel:啟動`或:guilabel:`重新啟動。此動作會手動重新啟動 Odoo 伺服器。

透過輸入以下命令重新啟動 Odoo 伺服器：sudo service odoo15 restart

備註

將 odoo 後面的數字改為伺服器正在運行的特定版本。

使用網頁介面重新加密密碼¶

首先，在瀏覽器中導航至 /web/database/manager 或 http://server_ip:port/web/database/manager。

備註

將 server_ip 替換為資料庫的 IP 位址。將 port 替換為可存取資料庫的編號連接埠。

接下來，按一下設定主密碼，然後在主密碼欄位中輸入先前選擇的臨時密碼。完成此步驟後，輸入新主密碼。按一下繼續按鈕後，新主密碼將被雜湊（或加密）。

至此，密碼已成功重設，新密碼的雜湊版本現在會出現在配置檔案中。

其他資料

有關 Odoo 資料庫安全性的更多資訊，請參閱此使用說明：資料庫管理員安全性。

支援的瀏覽器¶

Odoo 支援以下瀏覽器的最新版本。

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

1: 讓多個 Odoo 安裝使用同一個 PostgreSQL 資料庫，或為兩個軟體提供更多運算資源。
2: 從技術上來說，可以使用 socat 之類的工具在網路上代理 UNIX 通訊端，但這主要適用於只能透過 UNIX 通訊端使用的軟體
3: 或僅可透過內部封包交換網路存取，但這需要安全的交換器、防範 ARP 欺騙的保護措施，並且無法使用 WiFi。即使在安全的封包交換網路上，仍建議透過 HTTPS 部署，而且在受控環境中部署「自簽」憑證比在網際網路上部署更容易，因此可能的成本也會降低。

在 GitHub 上編輯