[Troubleshooting] Check Point R82 CPUSE 無法更新修復：解決 "Can not look for updates" 與 Config Lock 異常

作者：
🔥 延伸閱讀 更多維運實戰筆記 :

最近心血來潮，想說趁著授權到期前 把手上的防火牆管理主機 (SMS) 升級到2026最穩定的 Check Point R82。本來以為是一次平淡無奇的韌體更新，結果升級完重開機，那個讓人不想看到的畫面就來了。

滿心期待打開 CPUSE (Software Updates) 想看看有沒有最新的 Hotfix，結果系統送我一個大大的叉叉："Can not look for updates"。

當下心裡真的是一萬個為什麼，網路不是通的嗎？Curl 也是通的啊？為什麼 WebUI 就是死活讀不到？好吧~~只好先使用指令更新到最新版本..

這篇筆記就是紀錄這次「踩坑」的過程，順便把 R82 版本 幾個莫名其妙的改動（例如消失的 web_server 指令）整理一下，希望未來的自己（或者正在看這篇的你）不要再浪費時間在這種鬼打牆的問題上。

Part 1：靈異現象 - 網路通但 Web 報錯

升級完的第一件事，習慣動作就是進 Gaia Portal 檢查更新。結果點開 Software Updates > Available Updates，轉圈轉了老半天，最後跳出這個讓人絕望的錯誤訊息：

🚫 Error:
Can not look for updates. For more information contact support.
Check Point R82 Error 圖 1：熟悉的 Check Point，熟悉的報錯，但這次是連更新都不能檢查

Part 2：自我懷疑 - 到底是誰的問題？

遇到這種狀況，第一直覺通常是：「是不是 DNS 設錯了？」、「是不是 Gateway 沒有放行到 Check Point Update Center 的流量？」。

於是認命地打開 Putty，SSH 進去開始一頓操作。先用 curl_cli 測試一下連線，結果... 居然是通的！

[Expert@CPSMS:0]# curl_cli -vk https://updates.checkpoint.com
* Rebuilt URL to: https://updates.checkpoint.com/
* Connected to updates.checkpoint.com (3.169.121.128) port 443
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* Server certificate: CN=*.checkpoint.com

看到這個 Connected 和 TLSv1.3，我更困惑了。既然底層 Linux 能連上網，憑證也沒問題，那 Gaia Portal 到底在鬧什麼彆扭？

再查一下 Agent 狀態：

[Expert@CPSMS:0]# clish -c "show installer status"
Agent: Enabled
Network connection: connected
Update from cloud: Last updated on Mon Jan 19...

結論： 這根本不是網路問題，而是 CPUSE 本地快取 (Cache) 壞了，或者是 WebUI 跟後端 Agent 吵架了（狀態不同步）。而且 R82 對於 Config Lock (設定鎖) 的判定似乎變得超級嚴格，只要 WebUI 卡住，CLI 也會跟著無法寫入，變成一個死結。

Part 3：解決方案 - 那些消失的指令

既然知道是 Process 卡住或 Cache 壞掉，老司機的直覺告訴我：「重啟治百病」。但就在我準備輸入熟悉的 web_server restart 時，系統冷冷地回了我一句 Command not found。

查了 Release Note 才發現，Check Point 在 R82 版本把 /bin/web_server 移除掉了！ 現在要重啟 Web 介面，得用 WatchDog 的指令才行。這真的是... 改這種習慣動作不需要先講一聲嗎？(崩潰)

⚠️ R82 踩坑重點：
別再試 web_server restart 了。在 R82 中，必須透過 WatchDog (cpwd) 的 tellpm 指令來重啟 Web 服務。

好啦，碎碎念完還是要面對現實。以下是經過實測，能夠徹底修復這個問題的完整步驟（包含處理那個煩人的 Config Lock）：

步驟一：在 Standard Mode (Clish) 搶鎖並停止服務
一定要在互動模式下做，千萬不要用 clish -c 一行一行貼，不然 Session 一結束鎖就沒了，你會發現錯誤無限輪迴。

# 1. 先進入標準模式
[Expert@CPSMS:0]# clish

# 2. 強制取得設定鎖 (這步最重要，不管它顯示什麼 already turned on，搶就對了)
CPSMS> lock database override

# 3. 停止 CPUSE Agent 服務
CPSMS> installer agent stop

# 4. 暫時離開標準模式
CPSMS> exit

步驟二：在 Expert Mode 清除那些壞掉的快取
服務停掉後，我們就可以進去大掃除。把那些暫存檔刪乾淨，強迫 Agent 重新去雲端拉一份新的 Catalog。

# 確認已回到 Expert 模式
[Expert@CPSMS:0]# expert

# 1. 暴力刪除 CPUSE 暫存檔與備份 (不用怕，刪了它會自己重建)
[Expert@CPSMS:0]# rm -rf /var/log/CPda/*

# 2. R82 專用指令：重啟 WebUI 服務 (網頁會短暫斷線約 10-20秒)
[Expert@CPSMS:0]# tellpm process:httpd2 t

步驟三：回到 Standard Mode 叫醒 Agent
掃地掃完了，現在把服務叫起來工作。

# 再次進入標準模式
[Expert@CPSMS:0]# clish

# 啟動 Agent
CPSMS> installer agent start

# 強制檢查更新 (這會觸發重新下載)
CPSMS> installer check-for-updates
CLI Check Success 圖 2：看到這行 "Successful" 的瞬間，眼淚差點流下來

Part 4：驗證修復結果 - 終於變綠燈了

看到 CLI 顯示成功後，帶著忐忑的心情回到瀏覽器。這時候記得按 Ctrl + F5 強制重新整理（這很重要，不然瀏覽器要是讀到舊快取，你可能會以為沒修好而氣死）。

一開始右上角會出現 "Processing candidates" 轉圈圈，這代表它正在重新比對資料庫。再等個幾秒鐘......

Success - Up to date
Success - Processing candidates
Success - R82 Take 40
圖 3：終於！那個令人安心的綠色勾勾回來了，所有 Hotfix 也都正常顯示
📝 筆記總結 (Takeaway)

這次經驗告訴我們，Check Point 升級後如果遇到 WebUI 怪問題，先別急著查網路，通常都是 Cache 在搞鬼。重點整理如下：

  • Lock 機制很龜毛： 遇到權限錯誤，務必在 Clish 模式下執行 lock database override。
  • Web 重啟指令改了： web_server 沒了，請愛用 tellpm process:httpd2 t。
  • Cache 清除大法： 核心修復指令是 rm -rf /var/log/CPda/*，但記得先停 Agent。
  • 操作習慣： 在 Expert/Clish 之間切換建議用 exit，不要用 clish -c 偷懶，不然鎖會搶不到。

希望這篇能幫到同樣被 R82 折磨的苦主們。好了，我要去喝杯咖啡壓壓驚了。

🏷️ 熱門關鍵字 (Tags)
#CheckPoint #R82 #CPUSE #Troubleshooting #Gaia

留言

張貼留言