我刚刚在工作中遇到了一次大规模的电子邮件服务中断。在事件发生期间，我们的一些 Postfix 给出了一些错误，涉及：
Fatal: connect #n to subsystem private/rewrite: Connection refused.
因为这是一个大事件，所以同时尝试了很多方法，所以我不确定接下来要做的事情是否能解决这个问题，我正在寻求意见。
在这些连接被拒绝之后，他们又回到了我们拥有的其他 Postfix 服务器上，有人记得类似的问题，而且它与证书有关。所以他们运行update-ca-certificate --fresh并重新启动了 Postfix，它就好了……
同时路由器/防火墙重新启动...
因此，我们试图弄清楚是否真的需要更新 ca 证书......
如果您要长时间运行服务器，是否需要update-ca-certificate在 X 时间后运行此程序来更新证书？
答案1
事后发现有帮助的机会非常渺茫。通常，update-ca-certs只需要在 CA 文件更改后运行。当它们由操作系统的包管理（在本例中为 apt）更新时，它会自动完成。当您在那里添加或更改文件时，您需要手动运行它。它不需要每隔一段时间运行一次。
答案2
您可以创建这样的脚本
#!/bin/bash
/usr/sbin/update-ca-certificates
然后将其存储在某处/path/to/update_ca_certs.sh
赋予其执行权限
chmod +x /path/to/update_ca_certs.sh
然后创建一个 cronjob
crontab -e
例如每天凌晨 2 点
0 2 * * * /path/to/update_ca_certs.sh
答案3
我能想到的唯一能从已修复的问题中找出答案的方法是检查 /var/logs/<some_logs>，你可能会很幸运，仍然有相关信息可用。对于 <some_logs>，我想到的是 mail.log、mail.info 和 syslog
在 /var/logs 中，可以尝试类似
sudo grep -r postfix | grep refused
搜索所有 /var/log/* 及其子目录，或者
sudo grep postfix mail.log mail.info syslog | grep refused
针对这些特定文件。可能需要尝试
例如，日志可能包含有关导致 postfix 无法连接的详细信息。如果您真的很幸运，就会有一些关于哪个进程允许 postfix 重新建立连接的信息，如果您知道修复的大致时间，这些信息将更容易找到
如果日志自发布以来已经轮换并被压缩，请使用 zgrep 代替 grep，并将适当的数字附加到文件名