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

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

有很多不同的解釋?zhuān)浅鲇谖覀兊哪康?，這就是修補(bǔ)程序的含義：將更改應(yīng)用于計(jì)算機(jī)軟件，以解決功能或安全性錯(cuò)誤，提高可用性，可靠性或性能。

痛點(diǎn)

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

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

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

修補(bǔ)完成后，您需要驗(yàn)證成功并確保您的報(bào)告系統(tǒng)已更新為新?tīng)顟B(tài)。

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

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

等一下，我有個(gè)主意！

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

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

它需要做什么？

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

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

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

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

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

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

• 能夠清理軟件包緩存

• 限制安全補(bǔ)丁

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

• 能夠從命令行，控制臺(tái)或通過(guò)API觸發(fā)補(bǔ)丁運(yùn)行

• 控制誰(shuí)可以執(zhí)行補(bǔ)丁程序運(yùn)行

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

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

它是如何做到的？

要開(kāi)始使用該模塊，您只需要在節(jié)點(diǎn)上聲明os_patching模塊即可。它將設(shè)置一個(gè)計(jì)劃任務(wù)來(lái)刷新補(bǔ)丁信息，并允許訪(fǎng)問(wèn)任務(wù)以執(zhí)行補(bǔ)丁。

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

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

事實(shí)分為兩部分：

陳述事實(shí)

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

• 是否有要應(yīng)用的補(bǔ)丁？

• 如果是這樣，多少？

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

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

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

• 補(bǔ)丁被阻止了嗎？

控制事實(shí)

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

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

• 節(jié)點(diǎn)是否已分配給修補(bǔ)窗口？

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

事實(shí)使我們可以訪(fǎng)問(wèn)審核車(chē)隊(duì)和控制補(bǔ)丁運(yùn)行所需的所有信息。

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

結(jié)合這些事實(shí)，可以編寫(xiě)查詢(xún)，例如：

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ù)將修補(bǔ)分配給修補(bǔ)程序窗口“ Week3”，未被阻止且有修補(bǔ)程序等待應(yīng)用的任何節(jié)點(diǎn)。

控制事實(shí)

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

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

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

• security_only：布爾值，啟用后，僅會(huì)更新security_package_updates軟件包和依賴(lài)項(xiàng)

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

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

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

其實(shí)是打補(bǔ)丁

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

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

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

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

• patch_server：實(shí)際上運(yùn)行修補(bǔ)程序

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

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

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

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

要重啟還是不重啟

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

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

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

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

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

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

您還可以使用該事實(shí)os_patching.reboot_override在粒度級(jí)別上自定義行為，例如，將所有節(jié)點(diǎn)設(shè)置為重啟（三個(gè)節(jié)點(diǎn)除外），never因?yàn)槟肋@些節(jié)點(diǎn)將在以后手動(dòng)重啟。

流程圖

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

輸出量

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

條目是：

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

• debug：修補(bǔ)命令的完整輸出

• start_time/end_time：任務(wù)開(kāi)始/停止的時(shí)間

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

• packages_updated：受影響的軟件包

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

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

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

TL; DR

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

• 添加mod 'albatrossflavour-os_patching'，'0.11.0'您Puppetfile和部署控制回購(gòu)

• 對(duì)您希望能夠與os_patching模塊 打補(bǔ)丁的節(jié)點(diǎn)進(jìn)行分類(lèi)

• include os_patching在修補(bǔ)配置文件中

• 使用PE控制臺(tái)

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

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

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

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

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

• 新的事實(shí)（os_patching）將可用

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

• facter -p os_patching

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

• 使用控制臺(tái)查看事實(shí)

• 在以下節(jié)點(diǎn)上執(zhí)行補(bǔ)丁程序運(yùn)行：

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

• 通過(guò)控制臺(tái)運(yùn)行任務(wù)。