使用 Systemd 定時器可靠地執行 ownCloud 後台作業
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
範例場景:假設一位管理員正在準備一台名為 web01 的虛擬 SLES 15 伺服器,用於託管一個小型公共網站。目標是在允許 TCP 連接埠 80 上的入站 HTTP 請求的同時,保持現有的 SSH 管理路徑可用。這只是一個範例,並非測試報告,也不代表每個 SLES 15 安裝都具有相同的介面名稱或服務。
在 SLES 15 中,firewalldfirewalld 是預設的防火牆框架,並由firewall-cmd其控制。首先,確定活動區域並驗證遠端存取權限;然後,在永久配置中將所需的最小服務新增至該區域並重新載入。 SUSE 的《SLES 15 SP7 安全加固指南》詳細記錄了這種基於區域的模型以及運行時規則和永久規則之間的差異。這些步驟假設 firewalld 已安裝並正在運作;較舊的升級系統可能需要單獨的遷移檢查。
透過伺服器控制台或管理會話進行連接,以便在網路存取中斷時可以恢復。如果您透過 SSH 連接,請在進行防火牆變更時保持該會話開啟。確認 firewalld 正在運行,並查看哪個區域擁有該介面:
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
第一個命令應該會報告結果running。 `active-zones` 指令會列出已指派介面或來源位址的區域;它可能顯示多個區域。在虛構的 web01 範例中,假設它報告了 `<interface>`public和 `<interface> ens192`。在後續命令中,請使用附加到傳入網路介面的區域。不要假設介面名為 `<interface>` eth0,也不要public因為 `<interface>` 是常見的預設值就假設它是活動的。

如果服務未運行,請在啟動前檢查其狀態:sudo systemctl status firewalld。在標準的 SLES 15 安裝中,firewalld 預設已安裝並啟用,但鏡像設定檔、升級或本機原則可能有所不同。如果 firewalld 已安裝但已停止,請僅在確認其目前原則能夠保留您所需的存取權限後才啟動並啟用它:sudo systemctl enable --now firewalld。在遠端管理的主機上,在啟動目前規則未知的防火牆之前,請確認控制台存取權限和 SSH 權限。
firewalld 服務是包含連接埠和協定的命名集合。打開它之前,請檢查本地定義:
sudo firewall-cmd --info-service=http
sudo firewall-cmd --zone=public --list-all
在 SLES 系統中,預先定義http服務對應於 TCP 連接埠 80。區域清單可讓您檢查目前允許的服務和連接埠。請將 `<zone_name>` 替換public為您找到的活動區域。如果您使用 SSH 管理伺服器,請確保ssh在繼續操作之前,該區域已允許 SSH 服務。 SLES 的安裝行為和現有策略可能有所不同,因此請務必檢查,不要僅憑假設。如果已安裝的 SSH 守護程序監聽非標準端口,則通用ssh服務條目可能不匹配;請先確認守護程序的實際監聽端口和現有防火牆策略。

Firewalld 維護獨立的運作時配置和永久配置。普通命令僅更改活動的運行時規則;--permanent寫入已儲存的配置,但不會立即啟動該更改。對於 web01,請將 HTTP 服務新增至擁有其公共介面的區域:
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --reload
明確使用--zone規則,可以避免規則被錯誤地應用到預設區域。重新載入會將永久規則套用到執行時間。未儲存的執行時間變更會在重新載入期間被丟棄,因此請在執行前檢查並保留任何您需要的臨時規則。若要在將服務永久化之前對其進行測試,您可以先執行sudo firewall-cmd --zone=public --add-service=http不帶--permanent永久規則的服務;如果測試成功,再新增永久規則並重新載入。運行時測試會在重新載入或防火牆重新啟動後遺失。

如果您需要的是單一連接埠而不是預先定義的服務,請同時指定連接埠和協議,例如:`example.com/ --add-port=8080/tcp...
檢查正在運行和已儲存的配置:
sudo firewall-cmd --zone=public --list-services
sudo firewall-cmd --permanent --zone=public --list-services
sudo firewall-cmd --check-config
輸出結果應同時包含http在兩個服務清單中,且設定檢查應順利完成,不報告任何錯誤。此外,還應驗證應用程式是否正在本機監聽(例如使用 ` sudo ss -lntpdocker ps` 命令),並從目標網路上的用戶端測試該網站。防火牆清單僅確認規則,而非端對端可達性:DNS、雲端防火牆、路由以及 Web 伺服器本身仍可能封鎖或拒絕請求。

如果不再需要 HTTP,請移除已儲存的規則並重新載入:sudo firewall-cmd --permanent --zone=public --remove-service=http,然後執行sudo firewall-cmd --reload。之後重新檢查運行時列表和永久列表。避免為了解決單一存取問題而清除所有規則或切換到受信任區域;這些更廣泛的變更可能會暴露不相關的服務。
有關特定版本的指導,請參閱SUSE SLES 15 SP7 安全加固指南。有關不同 firewalld 版本下的命令行為,請參閱上游firewall-cmd 文件和運行時配置與永久配置參考。可用選項可能會因特定 SLES 服務包中提供的 firewalld 版本而異,因此firewall-cmd --help如果某個命令不可用,請確認本機說明。
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
透過 Apache、Nginx 或反向代理程式追蹤 WebDAV 請求,然後使用經過驗證的 PROPFIND 測試確認 ownCloud 同步功能正常。
透過設定其規範 URL 並從伺服器本身檢查 DNS、HTTPS 和反向代理路由,修復 Nextcloud 缺少出站位址警告的問題。
透過本機 Unix 套接字配置 APCu 和 Redis,以實現 Nextcloud 快取和檔案鎖定,並提供目前和舊版 Nextcloud 的步驟。
檢查 Nextcloud 的 cron 模式,修復其 systemd 服務和計時器,並驗證後台作業在啟動後以及每隔五分鐘運行一次。
啟用可靠的 Nextcloud 檔案鎖定,選擇適當的 Redis 或 Valkey 後端,並驗證警告是否清除,同時避免並發檔案變更的風險。
使用最新更新、HTTPS 和 HSTS、精確的反向代理信任以及針對公共伺服器的檢查,修復 Nextcloud 掃描中常見的錯誤。
為需要加密的儲存配置 Nextcloud SSE,保護加密金鑰,並在加密現有文件之前測量傳輸和 CPU 影響。
將 Nextcloud 的檔案搜尋連接到 Elasticsearch,索引文件內容,並選擇適合您的伺服器和安全需求的設定。
配置 Nextcloud 在規定的保留期後刪除已刪除的文件,可靠地安排後台作業,並避免執行清除所有使用者回收站的命令。