使用 Systemd 定時器可靠地執行 ownCloud 後台作業
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
即使啟用了即時補丁,SLES 核心更新仍可能顯示「需要重新啟動」。但這並不意味著安裝失敗:即時修補程式僅涵蓋 SUSE 可以安全地為當前運行核心提供的修復程序,而替換核心或無法進行即時修補程式的修復程序仍然需要重新啟動。 SUSE 於 2026 年 10 月 8 日發布的 SLES 16.0 核心即時修補程式指南提供了一種新的安裝方法:kernel_livepatching在標準 SLES 訂閱下安裝相應的修補程式模式。 SLES 15 SP7 使用單獨的即時修補程式擴充功能和相應的lp_sles補丁模式。
使用與您的版本完全匹配的步驟,透過正常的 SUSE 軟體包工作流程套用更新,並使用 驗證活動修補程式klp -v patches。這些步驟假設已註冊的 SLES 主機可以存取其受支援的更新儲存庫。
確定內核版本和運行內核。運行:
cat /etc/os-release
uname -r
uname -m

記錄 SLES 版本、核心版本和架構。即時補丁包與特定的核心版本匹配,因此,適用於不同運行核心的補丁包並不能證明當前核心已打補丁。下列指令使用目前的 SLES 16.0 和 SLES 15 SP7 指令;請勿將特定於版本的模式或啟動路徑複製到其他版本。
在 SLES 16.0 上,安裝隨附的修補程式。 SUSE的最新指南指出,核心即時修補功能包含在標準 SLES 訂閱中。請安裝其補丁程式:
sudo zypper install -t pattern kernel_livepatching

如果您的軟體倉庫中包含適用於已安裝核心的可用即時補丁,軟體包管理器會在安裝過程中選擇該補丁;SUSE 文件中說明核心會在此過程中進行即時修補。 SLES 16.0 的此安裝過程中無需額外的即時修補註冊碼。
在 SLES 15 SP7 上,請先啟動擴充功能。此版本需要有效的 SLES 和 SLES Live Patching 訂閱。列出可用擴充程序,並使用其列印的、與系統架構完全匹配的啟動命令:
sudo SUSEConnect --list-extensions
sudo SUSEConnect -p sle-module-live-patching/15.7/x86_64 -r LIVE_PATCHING_REGISTRATION_CODE


第二條指令是 x86_64 範例。請將其替換為您實際--list-extensions輸出的產品路徑,並提供有效的 Live Patching 註冊碼。然後安裝所需的補丁:
sudo zypper install -t pattern lp_sles

僅啟動並不會安裝修補程式或軟體包;請完成這兩個步驟,然後才能從更新管道獲取即時補丁包。
定期進行系統更新。核心即時修補程式會透過常規更新機制以軟體包的形式推送。如果需要手動執行補丁,請使用與主機其他部分相同的已核准維護工作流程,例如:
sudo zypper refresh
sudo zypper patch

在確認軟體包計劃之前,請務必仔細審查,尤其是在生產系統中。即時補丁包可以在不重啟工作負載的情況下更新正在運行的核心的適用修復程序,但同一更新操作也可能提供一個新的基礎核心包。安裝該核心包仍然可能觸發重啟建議。即時補丁對其目標核心版本具有累積性;它們不能取代常規的核心維護。
檢查是否有已啟動的補丁。更新完成後,請查看補丁詳情:
sudo klp -v patches

SUSE 文件中提供了此命令,用於檢查補丁狀態並查看當前有效補丁所修復的 CVE 或缺陷。請確認列出的補丁與步驟 1 中記錄的正在運行的核心版本相對應。初始或種子有效補丁包可能不包含任何修復;它為該核心版本準備後續補丁。它的存在本身並不意味著已應用特定的安全修復。
排查空狀態或狀態不符的問題。檢查運行中的核心是否存在即時補丁包,以及生命週期資料是否可用:
sudo zypper se --details 'kernel-livepatch-*'
sudo zypper lifecycle

對於生命週期日期,SUSE 表示lifecycle-data-sle-module-live-patching必須安裝該軟體包。如果沒有適用於目前運行核心的補丁包,請確認已啟用正確的即時補丁儲存庫或通道,並且相關修復程式符合即時補丁的條件。如果尚未發布任何符合條件的更新,請勿僅因補丁列表為空而推斷失敗。
安排內核完整更新所需的重啟。 SUSE無法將所有修復轉換為即時修補程式;某些變更需要取代核心資料結構,或無法在執行時間安全地應用。請將常規核心更新保留在您的維護計劃中,並在更新需要時重新啟動。避免透過無限期鎖定核心軟體包來隱藏重啟通知:這樣做會延遲核心完整修復的發布,而不是即時應用這些修復。
對於無需重新啟動的維護窗口,僅當更新包包含與目前運行核心相容的即時補丁包,且您的變更策略允許時,才可執行更新。在主機啟動新核心之前,請將完整的核心包更新視為待處理狀態。
klp -v patches當偵測到核心的有效即時補丁訊息,且預期的修復程式出現在補丁詳情時,檢查即成功uname -r。由於未發生重啟,主機應保持運行核心版本不變。如果更新管理器仍然要求重啟,請檢查是否安裝了新的基礎核心或超出即時修補程式範圍的修復程式;該請求屬於維護需求,無法透過 live-patch status 命令取消。
將按需作業運行替換為 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 在規定的保留期後刪除已刪除的文件,可靠地安排後台作業,並避免執行清除所有使用者回收站的命令。