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

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

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

痛點

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

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

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

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

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

如果存在這種風(fēng)險，為什么還那么困難呢？

等一下，我有個主意！

作為Puppet用戶，我已經(jīng)有一個可以集中數(shù)據(jù)的位置，一種使數(shù)據(jù)保持準(zhǔn)確的方法，一個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)類型的支持。

它需要做什么？

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

• 顯示哪些更新與安全性相關(guān)（如果可能）

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

• 允許為服務(wù)器設(shè)置停電時間，以防止任何修補活動

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

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

• 能夠清理軟件包緩存

• 限制安全補丁

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

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

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

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

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

它是如何做到的？

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

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

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

事實分為兩部分：

陳述事實

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

• 是否有要應(yīng)用的補??？

• 如果是這樣，多少？

• 它們與安全相關(guān)嗎？

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

• 是否需要重新啟動應(yīng)用程序？

• 補丁被阻止了嗎？

控制事實

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

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

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

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

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

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

結(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 }'

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

控制事實

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

• patch_window：一個字符串描述符，用于“標(biāo)記”一組計算機(jī)，即Week3或Group2

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

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

• reboot_override：boolean，覆蓋任務(wù)的重啟標(biāo)志（默認(rèn)值：false）

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

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

其實是打補丁

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

我設(shè)置了3個任務(wù)：

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

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

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

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

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

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

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

要重啟還是不重啟

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

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

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

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

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

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

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

流程圖

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

輸出量

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

條目是：

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

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

• start_time/end_time：任務(wù)開始/停止的時間

• 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é)點進(jìn)行分類

• include os_patching在修補配置文件中

• 使用PE控制臺

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

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

• 將設(shè)置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 }'

• 通過控制臺運行任務(wù)。