如何安全地清除 Zimbra 稽核日誌以釋放磁碟空間
了解如何識別、歸檔、壓縮和刪除舊的 Zimbra 稽核日誌,何時避免截斷 audit.log,以及如何驗證磁碟空間和日誌記錄是否正確復原。
當 Kopano 在郵件投遞過程中報告「無法連線到儲存伺服器」時,表示投遞代理 (dagent) 無法與指定的 Kopano 伺服器端點建立連線。僅憑此訊息無法確定故障原因是伺服器停止運作、套接字路徑錯誤、存取權限問題或遠端連線問題。請先檢查已設定的端點和伺服器本身;在診斷連線故障時,請勿變更郵件資料或附件儲存位置。
Kopano 管理員文件將 dagent 描述為將郵件從郵件傳輸代理程式 (MTA) 傳遞給 Kopano 使用者的元件。 Kopano Core 8.0 配置參考文件指出,dagentserver_socket指定了與 Kopano 伺服器的連接,並將file:///var/run/kopano/server.sock其記錄為預設值。軟體套件版本、服務管理員和本機設定可能有所不同,因此在應用範例之前,請務必在您的主機上驗證這些值。
確認錯誤是影響所有收件者還是僅影響一條投遞路徑。如果所有入站投遞同時失敗,請檢查伺服器可用性和端點。如果只有透過某個主機或節點路由的訊息失敗,請將該節點的dagent.cfg網路路徑與正常節點進行比較。測試時請保留失敗的訊息或佇列條目;重複重試可能會掩蓋日誌中第一個有效的時間戳記。
在採用 systemd 的系統上,檢查 Kopano 單元和交貨時間附近的伺服器日誌:
systemctl list-units 'kopano*'
systemctl status kopano-server --no-pager
journalctl -u kopano-server -b --no-pager
如果您的軟體包對單元的命名方式不同,請使用顯示的單元名稱list-units。伺服器不活動或反覆重啟表示伺服器端有問題。請查閱其日誌,尋找早期啟動、資料庫、設定或儲存錯誤;重新啟動 dagent 無法修復不可用的 Kopano 伺服器。管理員手冊中記錄了 Kopano 服務管理,但具體的單元名稱取決於軟體包。
讀取目前設定檔(通常為),/etc/kopano/dagent.cfg並找到server_socket以下條目:
grep -nE '^[[:space:]]*server_socket[[:space:]]*=' /etc/kopano/dagent.cfg
對於本機 Unix 套接字,請將設定與正在執行的伺服器實際建立的套接字進行比較。 Kopano Core 文檔中常見的值為:
server_socket = file:///var/run/kopano/server.sock
檢查檔案是否存在且是否為套接字檔案:
ls -l /var/run/kopano/server.sock
test -S /var/run/kopano/server.sock && echo "Socket exists"
如果配置路徑與實際路徑不同,請將server_socket值修正為安裝程式實際使用的端點。如果伺服器配置為使用其他運行時目錄、叢集位址或遠端傳輸,請勿盲目複製預設值。 Kopano 的參考文件也介紹了 HTTPS 傳輸的 SSL 金鑰設定;遠端端點語法和憑證要求應與您已安裝的伺服器設定相符。
是的。即使套接字存在,執行 dagent 的使用者仍然無法存取它。請從相關的服務單元或進程中找到有效的進程用戶,然後檢查套接字及其所有父目錄。例如:
namei -l /var/run/kopano/server.sock
stat -c '%A %U:%G %n' /var/run/kopano/server.sock
將擁有者、群組和目錄遍歷權限與 dagent 的執行時間身分進行比較。 Kopano dagent 設定參考文件指出,其運行身分使用者和群組是可以設定的,文件中記錄的預設值為 Kopano;打包或覆蓋設定可能會變更此設定。如果正在使用 systemd,請在變更所有權之前檢查單元及其任何覆蓋設定:
systemctl cat kopano-dagent
systemctl show kopano-dagent -p User -p Group
僅調整權限以授予目標服務帳戶所需的存取權限。請勿chmod 777在套接字或其目錄上使用權限:這可能會將特權服務端點暴露給無關的本機使用者。運行時目錄可能會在啟動時重新創建,因此請修復創建這些目錄的服務或軟體包配置,而不是依賴臨時的手動權限變更。
在多伺服器或高可用性架構中,請驗證代理是否正在使用其節點可存取的叢集或伺服器位址。 Kopano 高可用性指南指出,服務端點和 Postfix 郵件路由必須在各個節點之間進行協調。請比較server_socket雙方的伺服器監聽器、DNS 或叢集位址、防火牆規則以及任何 TLS 設定。成功連接到一個節點上的本地套接字並不能證明遠端端點可以從另一個節點存取。
使用與 dagent 配置相同的端點和網路路徑測試連接性。對於遠端傳輸,請檢查 Kopano 主機上的監聽器狀態和防火牆策略,然後檢查 dagent 和伺服器日誌,尋找連線拒絕、逾時或 TLS 錯誤。切勿為了快速排查問題而將監聽器廣泛開放給 Internet;應將存取權限限制在受信任的郵件和應用程式主機上。
伺服器啟動且端點和權限設定完成後,使用指定的測試郵箱執行受控測試。 Kopano 管理員手冊中記錄如何使用該節點上的使用者直接呼叫 dagent,然後輸入主題和郵件正文。一個基本的測試模式如下:
kopano-dagent -v -c /etc/kopano/dagent.cfg testuser
Subject: Kopano connection test
This is a controlled delivery test.
[Press Ctrl-D to finish input]
請替換testuser為現有的本機 Kopano 用戶,並依照已安裝版本的命令語法進行操作。此測試會繞過部分 MTA 路由和佇列行為;直接投遞成功驗證了路徑中的一部分有效訊息,但並不能證明 Postfix 或其他 MTA 的郵件路由正確。在重試已排隊的生產郵件之前,請檢查 dagent 輸出、Kopano 日誌和測試郵箱。
僅重新啟動配置已變更的元件,並且務必先儲存已知有效的設定副本。如果您變更了配置dagent.cfg,請在您的安裝將 dagent 作為持久服務運行時重新啟動 dagent 單元。某些安裝會為每次交付啟動 dagent,因此可能沒有長時間運行的 dagent 單元可供重新啟動。如果您變更了server.cfg伺服器監聽器設置,請依照您所在網站針對 Kopano Server 的變更流程進行操作。 dagent 參考文件僅列出了可透過 HUP 重新載入的特定選項;請勿假設每個套接字或執行時間標識的變更都會透過訊號生效。
在關閉事件之前,請確認以下所有事項:
如果直接投遞成功,但透過郵件傳輸代理程式 (MTA) 投遞仍然失敗,請檢查 MTA 的 LMTP 傳輸、套接字路徑和路由,而不是更改 Kopano 郵箱儲存。如果伺服器和終端檢查無誤,但 dagent 仍然報告連線失敗,請收集相符的時間戳記、脫敏後的server_socket值、服務狀態以及相關日誌,並提供給您的軟體包維護人員或 Kopano 管理員。在共享診斷資訊之前,請務必隱藏密碼、私鑰、郵件內容和個人地址。
參考資料:Kopano Core 管理員手冊;Kopano 代理配置參考;Kopano 高可用性指南;Kopano 特殊配置和故障排除。
了解如何識別、歸檔、壓縮和刪除舊的 Zimbra 稽核日誌,何時避免截斷 audit.log,以及如何驗證磁碟空間和日誌記錄是否正確復原。
透過檢查伺服器狀態、伺服器套接字、Unix 套接字權限、遠端監聽器和受控交付測試來排查 Kopano dagent 儲存伺服器連線故障。
透過識別事務鎖、將鎖定儲存遷移到 Redis、檢查叢集並安全地重新測試來修復 ownCloud 檔案鎖定逾時錯誤。
透過檢查記憶體壓力、仔細調整快取、隔離初始同步以及監控工作進程來排查 Matrix Synapse 在 /sync 期間的 OOM 問題。
使用主金鑰模式、APCu、Redis 或 Valkey 鎖定,安全地啟用 Nextcloud 伺服器端加密,並採取可最大限度減少效能影響的穩定推廣措施。
透過檢查成員資格、權限等級、目標使用者等級和 Synapse 伺服器管理員復原選項(例如 make_room_admin)來修復 Matrix M_FORBIDDEN 房間管理員錯誤。
Zimbra 網頁信箱接受您的登入要求,但頁面顯示空白?請將瀏覽器問題與郵箱或代理故障區分開來,檢查正確的日誌,並安全地驗證復原方法。
找到 Jitsi Meet 服務卡在重新啟動狀態的問題,讀取致命日誌,並修復常見的 Docker 問題,例如缺少密碼、掛載錯誤和設定不相容等。
了解 Jitsi Meet 帳戶身份驗證與會議室密碼有何不同,配置傳統的安全性網域方法,並安全地驗證存取控制。
修正 ownCloud 後台作業未執行的問題,方法是切換到 Cron 模式並使用 systemd 定時器調度 occ system:cron,然後驗證計時器和日誌。