1. 为什么我把Odoo生产环境从Ubuntu迁到了Rocky Linux1.1 一次升级事故逼出来的选型反思先说个真实经历。前两年我给一家做外贸的公司维护过一套跑在Ubuntu 18.04上的Odoo平时挺稳定结果有一回系统提示可以做LTS升级我没多想就点了升级过程中PostgreSQL从10被强制迁移到12Python环境也被系统包管理器动了手脚结果Odoo服务起不来数据库连接报错客户那边销售单录到一半卡住电话直接打到我手机上。那次折腾了将近一天才恢复教训特别深刻跑企业级应用的服务器稳定性要比“新”重要得多。后来我接了一个新项目客户要求重新搭一套Odoo我毫不犹豫选了Rocky Linux。这不是拍脑袋的决定。Rocky Linux是CentOS停止维护之后最被看好的替代品之一走的是RHEL兼容路线社区维护活跃而且它不搞Ubuntu那种激进升级策略每个大版本的生命周期很长补丁风格偏保守。对ERP这种不能随便宕机的应用来说这种“慢工出细活”的节奏反而最合适。这套部署方案适合谁我总结下来主要是三类场景一是要给中小型制造或贸易企业搭一套内部可用的ERP系统二是个人想系统学习Odoo在生产环境中的完整落地流程三是做Odoo实施服务的团队需要一套可复现的交付模板。后面我会把所有步骤拆开讲包括为什么这么做、参数怎么算、哪些坑我替你踩过了。1.2 Rocky Linux在企业环境里的几个实在优势对比Debian系Rocky Linux在企业部署中的好处非常具体。首先是生命周期。Rocky Linux 9的支持周期到2032年8系列甚至更久这意味着你在一台服务器上部署完后几年内不需要因为系统版本到寿而被迫迁移。ERP数据迁移是大工程能不动就不动这一点对企业IT负责人来说几乎是刚需。其次是生态兼容性。RHEL系是商业软件适配的重灾区各种商业数据库、中间件、安全软件都会优先出RHEL兼容版本。Rocky Linux既然和RHEL二进制兼容那这些闭源组件比如某些财务接口的SDK装起来就很顺利。这一点在给客户做系统集成时特别省事。第三个是软件包管理风格。dnf虽然初看比apt繁琐但模块化机制dnf module让你可以锁定PostgreSQL、Python这类基础软件的版本避免系统升级时被悄悄改变。生产环境最怕的就是“悄悄变化”。1.3 这套方案适合什么样的场景注意我说的是Rocky Linux做生产环境的底座不代表所有Odoo场景都该这么搭。如果只是本地开发、快速试错你直接跑Docker容器或者用Odoo官方的一键安装脚本就够了没必要花时间做这套系统级部署。但如果你遇到下面任意一种情况就该用今天这套方案了企业要求数据完全自主可控不希望依赖第三方云平台的托管数据库。你需要在同一台服务器上对接内部AD/LDAP、做定制化模块开发、安装私有Python依赖。并发用户超过20人需要相对精细地控制worker进程、数据库参数和反向代理行为。客户是制造或流通企业对数据备份、审计日志、权限边界有比较明确的要求。这套方案的核心理念是每个组件都比“默认安装”多迈一步所有服务都由systemd管理所有日志都可回溯所有配置都有注释。下面开始实操。2. 系统初始化静态IP、swap、防火墙一个都不能省2.1 用nmcli配置静态IP别再去改ifcfg-eth0了很多人搜Rocky Linux教程时习惯找“修改/etc/sysconfig/network-scripts/ifcfg-eth0”这种老办法但在Rocky 8/9里NetworkManager接管了网络配置直接改文件不仅麻烦还容易因为格式错误导致网络起不来。正确姿势是用nmcli。先看当前的网络连接名称nmcli connection show假设网卡连接名是ens160执行下面四条命令就能配置静态IPnmcli con mod ens160 ipv4.addresses 192.168.1.100/24 nmcli con mod ens160 ipv4.gateway 192.168.1.1 nmcli con mod ens160 ipv4.dns 8.8.8.8 114.114.114.114 nmcli con mod ens160 ipv4.method manual nmcli con up ens160注意ipv4.method manual这一步最容易忽略。不改成manual重启网卡后系统可能又去DHCP拿地址IP变了Odoo虽然还能用但Nginx、PostgreSQL里如果是用IP做访问控制的就直接瘫痪了。检查一下配置是否生效ip addr show ens160 ping -c 3 gateway还有个小细节如果你的服务器在机房或云平台上云平台控制台里也要绑定相同的私网IP否则重启后云平台可能会把IP抢走。这个我在实际项目中遇到过花了不少时间才定位到是云平台和系统配置冲突。2.2 swap规划4GB内存的服务器硬跑Odoo会怎样Odoo对内存的胃口不小。跑一个15个并发用户的测试环境光PostgreSQL加Odoo主进程空闲状态下就要吃掉2GB左右峰值翻倍很常见。如果服务器只有4GB内存不配置swap早晚会遇到OOM Killer把Odoo进程杀掉。我的建议是8GB以下内存的服务器swap至少分配到物理内存的1.5倍。8GB以上swap可以分到4GB即可主要用于抵御突发峰值。Rocky Linux下创建swapfile的方式fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 /etc/fstab这里有个小坑某些文件系统上fallocate创建的swapfile在swapon时会报“swapon failed: Invalid argument”。遇到这种情况不要慌改用dd方式重建dd if/dev/zero of/swapfile bs1M count4096 chmod 600 /swapfile mkswap /swapfile swapon /swapfile另外建议调整vm.swappiness。对数据库服务器来说不要太早把进程往swap里赶echo vm.swappiness 10 /etc/sysctl.conf sysctl -p2.3 firewalld这样开端口SELinux这样设置Rocky Linux默认开了firewalld和SELinux这两个东西是新手最容易头大的但千万别图省事直接关掉。企业交付时如果安全审计发现SELinux是disabled很不好交代。生产环境只需要对外开放80/443和SSH端口Odoo的8069和8072端口不要暴露到公网只让Nginx本机访问即可firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --permanent --add-servicessh firewall-cmd --reloadSSH端口如果你改成了非默认端口记得把--add-servicessh换成--add-port你的端口/tcp不然防火墙一重载你把自己锁在门外就尴尬了。SELinux方面部署Odoo本身一般不需要额外设置因为Odoo进程是自定义的SELinux默认对它没有特殊限制。要特别注意的反而是Nginx它做反向代理时默认不允许向后端发起网络连接需要放行setsebool -P httpd_can_network_connect 1如果忘了这一步Nginx会频繁报502或超时排查起来非常费劲。2.4 时间同步和主机名这些“小”配置时间同步对ERP系统非常重要订单时间、库存流水时间、日志审计时间都得准确。Rocky默认装了chrony确认它在运行就行systemctl status chronyd timedatectl set-timezone Asia/Shanghai主机名也别忽略PostgreSQL和Odoo日志里会出现主机名如果主机名是随机的localhost排查问题时会增加很多困惑hostnamectl set-hostname odoo-prod-01改完顺便把/etc/hosts里的对应条目加上避免某些服务解析主机名超时。3. PostgreSQLOdoo的数据底座怎么调才不拖后腿3.1 安装和初始化以及pg_hba.conf的认证坑Rocky系列仓库里直接带了PostgreSQL值得留意的是dnf模块流版本。建议锁定在PostgreSQL 13或14Odoo官方支持得很充分。dnf module list postgresql dnf module enable postgresql:13 -y dnf install -y postgresql-server postgresql-contrib初始化数据库后启动postgresql-setup --initdb systemctl enable --now postgresql这中间有个高频坑默认的pg_hba.conf里本地主机连接用的是ident认证方式也就是系统用户名和数据库用户名必须一致否则连接时直接报“no pg_hba.conf entry for host ...”。Odoo是用TCP连数据库的必须改成MD5或SCRAM-SHA-256认证。编辑/var/lib/pgsql/13/data/pg_hba.conf把下面两行host all all 127.0.0.1/32 ident host all all ::1/128 ident改成host all all 127.0.0.1/32 scram-sha-256 host all all ::1/128 scram-sha-256同时确认/var/lib/pgsql/13/data/postgresql.conf里password_encryption设置为scram-sha-256然后重启PostgreSQLsystemctl restart postgresql3.2 建库建用户权限边界一定要划清楚生产环境不建议直接用postgres超级用户跑Odoo规范做法是在PostgreSQL里建专用的Odoo账号和数据库sudo -u postgres psql进入psql后执行CREATE USER odoo WITH PASSWORD your_strong_password; CREATE DATABASE odoo_prod OWNER odoo ENCODING UTF8; GRANT ALL PRIVILEGES ON DATABASE odoo_prod TO odoo; \q有两个容易忽略的点。第一ENCODING UTF8一定要显式指定Odoo的很多多语言功能依赖UTF8不指定可能继承模板库编码导致乱码。第二如果后续你想用pgAdmin远程连这个库做管理会需要给用户增加LOGIN权限但生产环境我一般建议不开PostgreSQL远程端口需要管理时通过SSH隧道连更安全。3.3 生产级参数shared_buffers、effective_cache_size到底设多少很多教程让你照抄一组配置但参数应该跟着服务器内存走。以一台8GB内存、16核CPU的服务器为例我的经验基准是shared_buffers 2GB通常设置为总内存的25%左右。effective_cache_size 6GB表示操作系统和PostgreSQL共享的缓存预算设置为总内存的75%。work_mem 32MB排序和哈希操作的内存上限。注意这是“每个操作”的预算并发高的场景别给太大否则内存直接被打满。maintenance_work_mem 256MB用于VACUUM、CREATE INDEX等维护操作。max_connections 200Odoo的worker进程数一般不会很多但加上其他管理连接200够用。wal_level replicamax_wal_senders 10提前为后续做主从复制留好余地。checkpoint_completion_target 0.9分散检查点的I/O压力。改完配置后重启PostgreSQL然后看实际占用的内存ps aux | grep postgres如果shared_buffers设得过高加上Odoo worker的内存8GB机器很容易吃紧。参数不是越大越好够用就行。3.4 备份要在没出事之前就演练过我见过太多人部署完从来没测过恢复等到数据库挂了才发现backup脚本一直在报错。生产环境必须做两件事定时备份以及定期恢复演练。最简单的逻辑备份命令sudo -u postgres pg_dump -F c -b -f /backup/odoo_prod_$(date %F).dump odoo_prod-F c表示自定义格式-b包含大对象Odoo附件存储会用到大对象这个参数必须加。恢复也很直接sudo -u postgres pg_restore -d odoo_restore /backup/odoo_prod_某天.dump备份老司机都知道数据库备份只是半个备份Odoo上传的文件都存在data_dir的filestore目录里所以完整备份一定把两者打成一个包后面第6节我会给出完整的定时脚本。4. Odoo本体安装源码、RPM、Docker三种路线怎么选4.1 三种安装方式的真实差异网上搜Odoo安装教程你会看到三种主流方式Odoo官方RPM包、Docker Compose、源码运行。直接说我的结论生产环境优先选源码部署。官方RPM包的问题是版本相对滞后而且默认安装路径和文件布局是按他们内部打包逻辑来的你后续想自定义模块、调整Python依赖时就比较别扭。Docker Compose胜在干净一条命令拉起来但问题也明显数据卷、容器日志、网络模式对运维能力要求反而更高数据库容器状态不好排查真要出问题时Docker的故障域比裸机更难界定。源码部署看起来最麻烦但每一步都是自己控制的模块路径清晰、日志明确、性能可调出了问题也最容易定位。当然开发机或测试环境直接Docker最快我不反对。4.2 源码部署完整步骤我推荐的方式先装编译依赖和工具链Odoo的Python依赖里有很多C扩展dnf install -y git python3 python3-devel gcc libxml2-devel libxslt-devel libjpeg-turbo-devel freetype-devel openldap-devel libffi-devel openssl-devel redhat-rpm-config创建专用系统用户不要用root跑Odoouseradd --system --home-dir /opt/odoo --shell /sbin/nologin odoo拉取源码。Odoo 17是当前稳定版也是我推荐生产环境使用的版本mkdir -p /opt/odoo git clone --depth 1 --branch 17.0 https://github.com/odoo/odoo.git /opt/odoo/odoo--depth 1能减少下载量但要注意以后想升级分支时可能需要先git fetch --unshallow才能拉到完整历史。如果想做源码级的定制建议去掉--depth 1。创建Python虚拟环境并安装依赖cd /opt/odoo/odoo python3 -m venv /opt/odoo/venv /opt/odoo/venv/bin/pip install --upgrade pip /opt/odoo/venv/bin/pip install -r requirements.txt如果服务器无法直接上外网建议提前把requirements.txt里的包下载到内网源不然这个步骤会卡很久。创建数据和日志目录并修正权限mkdir -p /var/lib/odoo mkdir -p /var/log/odoo chown -R odoo:odoo /opt/odoo chown -R odoo:odoo /var/lib/odoo chown -R odoo:odoo /var/log/odoo4.3 odoo.conf每个参数我都解释一遍配置文件放在/etc/odoo.conf内容如下我逐段说明[options] addons_path /opt/odoo/odoo/addons,/opt/odoo/addons data_dir /var/lib/odoo admin_passwd 换成超强随机密码 db_host 127.0.0.1 db_port 5432 db_user odoo db_password 和PostgreSQL里建的一致 db_name odoo_prod list_db False proxy_mode True xmlrpc True logfile /var/log/odoo/odoo.log log_level info workers 4 max_cron_threads 2 limit_time_cpu 600 limit_time_real 1200 limit_memory_hard 2684354560 limit_memory_soft 2147483648几个重点参数list_db False关闭数据库列表接口避免攻击者通过页面扫描可用的数据库名。这个在企业安全评估里很容易被扣分建议直接设置。proxy_mode True启用反向代理模式Odoo会读取X-Forwarded-*头生成正确的链接。如果你用Nginx却不开这个用户访问时可能看到端口号或者生成错误的URL。workers不是越大越好。经验公式是workers 2 * CPU核心数 1但还要受内存限制。8GB内存的机器设4个比较稳。limit_memory_hard和limit_memory_soft以字节为单位。2684354560是2.5GB2147483648是2GB。建议根据你服务器的内存和worker数平衡一下。max_cron_threads 2跑定时任务的线程数。别设太大否则多个cron任务同时跑会把CPU瞬间拉满。另外说下addons_path。源码版本里有两个addons目录一个是内置模块另一个是你的自定义模块目录。你可以先创建/opt/odoo/addons空目录以后放定制模块。4.4 systemd管理Odoo服务创建/etc/systemd/system/odoo.service[Unit] DescriptionOdoo ERP Requirespostgresql.service Afternetwork.target postgresql.service [Service] Typesimple Userodoo Groupodoo ExecStart/opt/odoo/venv/bin/python3 /opt/odoo/odoo/odoo-bin -c /etc/odoo.conf Restartalways RestartSec5 KillModemixed [Install] WantedBymulti-user.target启动并验证systemctl daemon-reload systemctl enable --now odoo systemctl status odooKillModemixed这个参数值得提一下它保证停止服务时先发SIGTERM给主进程再发SIGKILL给残留的子进程避免留下僵尸worker。我用默认的control-group模式时偶尔会遇到服务停了但端口还被占用的情况换成mixed后没再犯过。如果你访问http://服务器IP:8069看到数据库管理页面说明服务跑起来了。没有页面的话先看日志tail -f /var/log/odoo/odoo.log大部分启动失败都能在日志里直接看到原因最常见的是数据库密码不对、目录权限不足、Python依赖缺失。4.5 LibreOffice必须装否则报表全是空白这一点特别容易被忽略。Odoo的QWeb报表最终是转成PDF输出的而PDF转换依赖LibreOffice的无头模式headless。不装LibreOffice你导出的销售订单、采购单、报价单都会是空白或者报“QWeb PDF generation failed”。安装方式dnf install -y libreoffice-headless装完建议手动跑一次命令验证库文件完整libreoffice --headless --version如果显示版本号就说明正常。注意如果你之前没有安装字体中文PDF导出可能出现乱码建议顺便装一下中文字体dnf install -y wqy-zenhei-fonts wqy-microhei-fonts对于日文、韩文等文字也需要对应安装字体包。5. Nginx反向代理把长轮询、WebSocket、HTTPS一次性搞定5.1 Nginx安装及SELinux放行安装Nginxdnf install -y nginx systemctl enable --now nginx如果启动失败先排查80端口是否被占用ss -lntp | grep :80SELinux放行之前提过httpd_can_network_connect一定要设置否则Nginx代理到8069会直接Connection refused或者超时。怎么判断是不是SELinux去看这个命令的输出ausearch -m avc -ts recent | grep nginx有输出就说明是SELinux拦截了执行了setsebool -P httpd_can_network_connect 1再验证。5.2 SSL证书与安全头配置我建议你直接用证书管理工具自动申请Lets Encrypt证书也可以把已有的企业证书手动放到/etc/nginx/ssl/下面。手动部署证书的Nginx配置片段如下server { listen 80; server_name erp.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name erp.example.com; ssl_certificate /etc/nginx/ssl/erp.example.com.crt; ssl_certificate_key /etc/nginx/ssl/erp.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always; add_header Referrer-Policy strict-origin-when-cross-origin always; }X-Frame-Options记得设成SAMEORIGIN。Odoo的部分界面比如看板视图里嵌入iframe需要同源加载如果设成DENY会导致某些视图显示不正常。5.3 长轮询/WebSocket专用locationOdoo有一个常驻的聊天/消息推送服务监听在8072端口同时存在WebSocket和长轮询两种情况。如果Nginx配置里没有单独处理这两个路径聊天消息会不实时刷新讨论串收发异常甚至消息丢失。在刚才的443 server块中额外加上location /longpolling/ { proxy_pass http://odoo_chat; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_buffering off; proxy_connect_timeout 7200; proxy_read_timeout 7200; proxy_send_timeout 7200; } location /websocket/ { proxy_pass http://odoo_chat; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 7200; proxy_send_timeout 7200; proxy_buffering off; }对应的upstream定义在http块中upstream odoo_web { server 127.0.0.1:8069; } upstream odoo_chat { server 127.0.0.1:8072; }注意/longpolling/末尾的斜杠别省略。我见过有人漏了斜杠导致路径拼接出错刷新页面时总是404。5.4 代理超时参数别用默认值默认的Nginx代理超时只有60秒如果Odoo在处理一个大数据量报表或者批量导入超过60秒就会直接返回504用户看着页面转圈然后报错。经验是把超时时间拉长proxy_connect_timeout 7200; proxy_read_timeout 7200; proxy_send_timeout 7200;同时还要关闭proxy_buffering。Odoo的聊天消息、进度条通知这类功能依赖实时响应如果开了缓冲数据会在Nginx层堆积前端收到消息延迟明显。改完配置先测试语法nginx -t systemctl reload nginx6. 上线后的运维清单日志、升级、备份恢复6.1 日志分割与磁盘空间监控Odoo默认把日志写到/var/log/odoo/odoo.log不处理的话日志会越来越大直到把磁盘塞满。用logrotate来做是最省事的方案。创建/etc/logrotate.d/odoo/var/log/odoo/*.log { daily rotate 14 compress missingok notifempty copytruncate }其中的copytruncate很关键。如果直接kill -HUP当前进程可能会让Odoo重新加载日志句柄失败甚至日志不写。用copytruncate会把日志复制一份再清空原文件应用完全感知不到比较安全。日志之外的磁盘监控建议用zabbix或者简单的cron脚本检查df -h输出一旦磁盘使用率超过85%就发告警。ERP的filestore目录很容易被附件塞满这个真的发生过很多次。6.2 升级Odoo的完整流程先备份再动手升级Odoo不是简单git pull就完事。社区版每个minor版本之间也要走规范化流程尤其是模块数据库结构有调整的时候。我现在的升级流程是停止Odoo服务systemctl stop odoo完整备份数据库dump filestore打包拉取新代码cd /opt/odoo/odoo git pull origin 17.0更新Python依赖/opt/odoo/venv/bin/pip install -r requirements.txt运行模块升级sudo -u odoo /opt/odoo/venv/bin/python3 /opt/odoo/odoo/odoo-bin -c /etc/odoo.conf -d odoo_prod -u all --stop-after-init启动服务systemctl start odoo验证核心业务登录、录一张测试订单、跑一次报表、看聊天消息是否正常。其中第5步很容易卡很久因为-u all会触发所有已安装模块升级生产库可能在几千张表上做结构变更耗时取决于数据量少则几分钟多则几小时。一定先在前一天的非工作时间安排这个窗口别白天直接升。如果升级后出现模块报错眼睛要盯着两个地方一是/var/log/odoo/odoo.log里的Traceback二是/var/log/odoo/odoo.log里Module xxx loaded是否都出现。有一次我遇到一个自定义模块依赖了旧接口日志里直接报AttributeError这种只能回滚代码再尝试。6.3 数据库filestore的备份还原演练前面第3节说过备份必须包含数据库和filestore两个部分。我现在用的完整备份脚本是这样#!/bin/bash # /usr/local/bin/backup_odoo.sh BACKUP_DIR/backup DB_NAMEodoo_prod DATA_DIR/var/lib/odoo DATE$(date %F_%H-%M) # 1. 数据库自定义格式备份 sudo -u postgres pg_dump -F c -b -f $BACKUP_DIR/${DB_NAME}_${DATE}.dump $DB_NAME # 2. filestore打包 tar czf $BACKUP_DIR/filestore_${DATE}.tar.gz -C /var/lib odoo # 3. 清理7天前的备份 find $BACKUP_DIR -name *.dump -mtime 7 -delete find $BACKUP_DIR -name *.tar.gz -mtime 7 -delete放进crontab0 2 * * * /usr/local/bin/backup_odoo.sh /dev/null 21恢复的完整流程# 1. 创建新数据库 sudo -u postgres createdb -O odoo odoo_restore # 2. 恢复数据 sudo -u postgres pg_restore -d odoo_restore /backup/odoo_prod_某日.dump # 3. 恢复filestore sudo -u odoo tar xzf /backup/filestore_某日.tar.gz -C /var/lib # 4. 在odoo.conf中临时把db_name改成odoo_restore然后启动服务验证别只在文档里写恢复流程建议每季度真刀真枪恢复一次到测试库确认备份文件能跑通。我见过太多公司备份脚本运行了半年结果恢复时报“archive file not found”这类低级问题。7. 生产环境踩过的坑今天一次性复盘7.1 SELinux拦截导致502有一次客户反馈网站打开502我第一反应是Nginx配置问题调了半小时都没解决。后来习惯性地去翻/var/log/audit/audit.log发现一堆denied { name_connect } for pidxxx commnginx记录。原因就是新服务器装了Nginx后没有执行setsebool -P httpd_can_network_connect 1。这个坑的特别之处在于它不是必现的。有时Nginx的某些编译参数或配置会触发SELinux限制有时不会特别迷。所以我的建议是在部署脚本里把setsebool直接写上别等到出了问题再查。7.2 OOM kill内存预算怎么算4GB内存的服务器跑了Odoo加PostgreSQLworker设了8个上线第二天早上客户发现系统很卡查看/var/log/messagesgrep -i killed process /var/log/messages看到Out of memory: Killed process 12345 (odoo)。根本原因是worker数超过内存预算。Odoo每个worker进程大约占用150-250MB内存8个worker加PostgreSQL的2GB shared_buffers4GB机器肯定顶不住。调整方式就是减少workers到2或3同时降低limit_memory_hard。内存这个事一定要按“峰值”来算不要按“空闲”来算。上线前建议用并发脚本做一轮压力测试把20个用户同时操作录单的情况模拟一遍观察内存峰值再定参数。7.3 长轮询不工作聊天消息像断线还有一次客户反馈说系统里两个同事同时编辑一张订单A改了B那边不自动刷新要手动刷新页面才能看到。这就是长轮询没走通的现象。检查链路浏览器请求/longpolling/→ Nginx代理到127.0.0.1:8072→ Odoo的gevent处理。我排查时发现Nginx配置里没有那段location /longpolling/请求直接被代理到8069的Odoo主服务了。补上配置后聊天和实时协作就正常了。另外一个容易踩的坑是proxy_buffering没关。有人按网上的配置加了长轮询location但忘了关缓冲结果消息延迟能达到几十秒甚至更久。这个参数对实时交互类功能至关重要。7.4 升级后模块不兼容的排查思路Odoo每次大版本升级都伴随大量模块接口变化。从16升17那会儿很多第三方模块的JavaScript改写方式完全不同升级后出问题概率很高。我的排查步骤看odoo.log里第一个报错的模块名一般就是问题源头。找到这个插件的清单文件__manifest__.py看声明的依赖版本范围。检查插件目录里是否有旧API调用比如fields.function、api.one这种老写法。如果插件有Git仓库直接看其master分支是否已适配新版Odoo必要时升级插件而不是升级Odoo。还有一个实用技巧升级前先在一台测试机上用生产数据副本跑一遍-u all把报错全部暴露在测试环境里别在生产上直接试错。这个习惯帮我避免了好几次不可逆的数据库变更。回到最初的话题Rocky Linux Odoo这套方案做到现在我最大的体会是ERP部署没有银弹所谓的“企业级”不在用了多少新潮技术而在每个环节都有人想过“如果这里挂了怎么办”。源码部署、专用用户、定时备份、恢复演练、参数调优做起来都不难难的是在第一次部署时就愿意把这些“慢功夫”做足。如果按这篇文章从头到尾操作一遍你得到的不仅是一套能跑的Odoo更是一套知道自己每块零件在哪儿的系统这个踏实感是任何一键脚本都给不了的。