修補可能需要大量的人工和時間，需要大量的協(xié)調(diào)和過程。在本文中，擔任25年以上UNIX系統(tǒng)管理員的Tony Green，為您提供了一些最佳技巧，以消除對Linux和Windows系統(tǒng)進行修補的煩惱。

在擔任系統(tǒng)管理員的所有這些年中（我已經(jīng)成為UNIX系統(tǒng)管理員已有25年以上），修補程序始終是每個人生存的禍根。修補需要手動進行。集中信息幾乎不存在。它需要進行大量的協(xié)調(diào)才能安排停機時間，并且在不同的操作系統(tǒng)，發(fā)行版甚至發(fā)行版之間，流程存在巨大差異。

有很多不同的解釋，但是出于我們的目的，這就是修補程序的含義：將更改應用于計算機軟件，以解決功能或安全性錯誤，提高可用性，可靠性或性能。

痛點

眾所周知，未修補的漏洞是一個巨大的問題，使組織面臨巨大風險。即使您知道一個漏洞，要跟蹤受影響的服務器也需要手動工作，專用工具，自定義工具開發(fā)或上述各項的組合。

列出受影響的服務器后，如何實際應用更新？IT團隊對流程進行集中控制是一種常見的方法，這種方法可以很好地起作用，但是，在某些方面，這還不夠。選擇補丁窗口，防止服務器被補丁，并控制是否應應用所有補丁或僅應用安全補丁。

自助服務選項可以解決其中一些問題，但可以解決其他問題。想到培訓，訪問控制和標準執(zhí)行。

修補完成后，您需要驗證成功并確保您的報告系統(tǒng)已更新為新狀態(tài)。

確保所有利益相關者都可以訪問服務器的補丁程序狀態(tài)，并確保數(shù)據(jù)及時準確。

如果存在這種風險，為什么還那么困難呢？

等一下，我有個主意！

作為Puppet用戶，我已經(jīng)有一個可以集中數(shù)據(jù)的位置，一種使數(shù)據(jù)保持準確的方法，一個RBAC系統(tǒng)以及觸發(fā)節(jié)點上臨時工作的能力。不僅如此，我所需的大多數(shù)內(nèi)容已經(jīng)由API和Web控制臺驅(qū)動并通過其報告。那么，我還等什么呢？

我立即開始從事最終成為os_patching模塊的工作。該模塊在Linux（RedHat，Debian和Suse）上具有全部功能，并且從V0.11.0開始增加了對Windows的支持。正在積極開發(fā)對其他操作系統(tǒng)類型的支持。

它需要做什么？

• 通過自定義事實將服務器上的補丁程序狀態(tài)報告回PuppetDB

• 顯示哪些更新與安全性相關（如果可能）

• 允許將服務器分配給“補丁程序窗口”，以進行簡單的調(diào)度

• 允許為服務器設置停電時間，以防止任何修補活動

• 能夠控制是否執(zhí)行修補后重新引導

• 在定義的一組服務器上啟用“補丁運行”的執(zhí)行，包括：

• 能夠清理軟件包緩存

• 限制安全補丁

• 為OS軟件包命令的參數(shù)提供替代

• 能夠從命令行，控制臺或通過API觸發(fā)補丁運行

• 控制誰可以執(zhí)行補丁程序運行

• 將規(guī)范的修補狀態(tài)數(shù)據(jù)存儲在節(jié)點上

最后一項是最重要的一項。無論發(fā)生什么事情，我都想確保節(jié)點上的事實是修補信息的真相之源，而其他一切都是從那里得到的。

它是如何做到的？

要開始使用該模塊，您只需要在節(jié)點上聲明os_patching模塊即可。它將設置一個計劃任務來刷新補丁信息，并允許訪問任務以執(zhí)行補丁。

自定義事實是整個模塊的基礎，因此確保我們擁有一個良好的結構和管理系統(tǒng)是關鍵。

自定義事實從緩存的值中提取其值，其中一些是由計劃的腳本/任務生成的，而另一些是由os_patching類生成的。我們將這些值緩存為每次運行Facter時都有數(shù)百個節(jié)點命中apt / yum服務器會導致一些非常大的問題。默認情況下，計劃的腳本每小時刷新一次緩存數(shù)據(jù)，但是可以通過分類覆蓋它。

事實分為兩部分：

陳述事實

這些事實表明了節(jié)點的狀態(tài)。

• 是否有要應用的補??？

• 如果是這樣，多少？

• 它們與安全相關嗎？

• 是否需要重啟節(jié)點？

• 是否需要重新啟動應用程序？

• 補丁被阻止了嗎？

控制事實

這些事實控制著修補的執(zhí)行。

• 我們是否定義了遮光窗口？

• 節(jié)點是否已分配給修補窗口？

• 該節(jié)點是否應覆蓋重新啟動參數(shù)？

事實使我們可以訪問審核車隊和控制補丁運行所需的所有信息。

可以將節(jié)點分配給apatch_window進行分組（例如“ Group 1”，“ Week 4”）?？梢詾橹袛鄡鼋Y或無法修補的節(jié)點定義中斷窗口。

結合這些事實，可以編寫查詢，例如：

puppet task run os_patching::patch_server --query='nodes[certname] { facts.os_patching.patch_window = "Week3" and facts.os_patching.package_update_count > 0 and facts.os_patching.blocked = false }'

此任務將修補分配給修補程序窗口“ Week3”，未被阻止且有修補程序等待應用的任何節(jié)點。

控制事實

如果需要，您還可以配置許多其他設置：

• patch_window：一個字符串描述符，用于“標記”一組計算機，即Week3或Group2

• blackout_windows：日期時間開始/結束日期的哈希值，在此期間阻止更新

• security_only：布爾值，啟用后，僅會更新security_package_updates軟件包和依賴項

• reboot_override：boolean，覆蓋任務的重啟標志（默認值：false）

• dpkg_options/yum_options：分別是dpkg或yum的附加標志/選項的字符串

您可以在hiera中進行設置。例如，我的全局配置在接下來的幾年中會出現(xiàn)一些中斷窗口：

其實是打補丁

由于我將要使用任務，因此我不必擔心如何實現(xiàn)RBAC或如何觸發(fā)補丁程序運行。

我設置了3個任務：

• clean_cache：清除節(jié)點上的程序包緩存（例如，yum clean all）

• refresh_fact：強制重新生成修補緩存數(shù)據(jù)

• patch_server：實際上運行修補程序

patch_server現(xiàn)在，我們將更詳細地介紹這個任務。

觸發(fā)后，任務將首先檢查事實的值os_patching.blocked。如果將其設置為true，則由于無法繼續(xù)修補的原因而導致任務退出。這通常意味著節(jié)點位于中斷窗口內(nèi)。

如果有要應用的補丁程序，則該任務會在超時值（默認為3600秒）下啟動OS補丁程序命令。它等待完成，然后拉回作業(yè)信息以進行報告。

然后刷新事實并將其推送到puppetserver（puppet fact upload），然后我們進入Reboot Town。

要重啟還是不重啟

請記住，修補節(jié)點沒有任何好處，除非您重新啟動使用受影響軟件包的進程。這可以像重新啟動應用程序一樣簡單，也可以像完全重新啟動一樣具有侵入性。那么我們?nèi)绾慰刂颇兀?/span>

您可以使用reboot參數(shù)來控制任務將執(zhí)行的重新啟動操作。它接受以下值：

• always：無論任務執(zhí)行過程中發(fā)生了什么，都請重新啟動節(jié)點。這將總是觸發(fā)重啟

• never：無論任務執(zhí)行過程中發(fā)生了什么，都不要重新引導節(jié)點。這絕不會觸發(fā)重啟

• patched：如果應用了任何補丁，則觸發(fā)重啟

• smart：使用操作系統(tǒng)工具（needs-restarting在redhat上，/var/run/reboot_required在debian上）確定修補后是否需要重新啟動。這只會觸發(fā)重啟內(nèi)核/核心庫的更新。

您還可以使用該事實os_patching.reboot_override在粒度級別上自定義行為，例如，將所有節(jié)點設置為重啟（三個節(jié)點除外），never因為您知道這些節(jié)點將在以后手動重啟。

流程圖

這有點復雜，在流程圖中可能會更容易。

輸出量

以下是任務輸出的示例，可從命令行，通過控制臺或通過API看到。

條目是：

• pinned_packages：任何在操作系統(tǒng)層鎖定/固定的軟件包版本

• debug：修補命令的完整輸出

• start_time/end_time：任務開始/停止的時間

• reboot：使用的重新啟動參數(shù)

• packages_updated：受影響的軟件包

• security：使用的安全性參數(shù)

• job_id：yum作業(yè)ID（僅在RedHat系列節(jié)點上填充）

• message：狀態(tài)信息

TL; DR

上面有很多信息，但是您可能只想開始使用該os_patching模塊，所以這里是步驟。

• 添加mod 'albatrossflavour-os_patching'，'0.11.0'您Puppetfile和部署控制回購

• 對您希望能夠與os_patching模塊 打補丁的節(jié)點進行分類

• include os_patching在修補配置文件中

• 使用PE控制臺

• 在這些節(jié)點上運行puppet并期望進行以下更改：

• 該文件/usr/local/bin/os_patching_fact_generation.sh將被安裝（c:programdataos_patchingos_patching_fact_generation.ps1在Windows上）

• 將設置Cron作業(yè)以每小時（使用fqdn_rand）并在重新啟動時運行腳本

• 目錄/var/cache/os_patching將被創(chuàng)建

• /usr/local/bin/os_patching_fact_generation.sh 將運行并將文件填充到 /var/cache/os_patching

• 新的事實（os_patching）將可用

• os_patching在分類的節(jié)點上查看事實的內(nèi)容：

• facter -p os_patching

• puppet-task run facter_task fact=os_patching --nodes centos.example.com

• 使用控制臺查看事實

• 在以下節(jié)點上執(zhí)行補丁程序運行：

• puppet task run os_patching::patch_server --query='nodes[certname] { facts.os_patching.package_update_count > 0 and facts.os_patching.blocked = false }'

• 通過控制臺運行任務。