Řešení 1:
Na záplatách Ubuntu vs. Windows, RHEL, CentOS, SuSE, debian atd. není nic zvláštního.
Základní stav mysli, ve kterém musíte být při navrhování procedury patche, je předpokládat, že něco bude přestávka.
Některé ze základních pokynů, které používám při navrhování nastavení opravy, jsou:
- Vždy používejte místní systém k interní centralizaci do vaší sítě, odkud jsou opravy instalovány
To může zahrnovat použití služby WSUS nebo zrcadel <your_os_here> do interního stroje pro správu záplat. Nejlépe takový, který se může centrálně dotazovat a informovat vás o stavu záplat nainstalovaných na vašich jednotlivých počítačích.
- Předpřipravte instalace – pokud je to možné – na strojích.
Když je to možné, po vydání záplat je centrální server zkopíruje na jednotlivé stroje. Toto je opravdu jen úspora času, takže nemusíte čekat, až se stáhnou A nainstalují, stačí zahájit instalaci během okna opravy.
- Získejte okno výpadku pro instalaci záplat, možná budete muset restartovat a něco se pravděpodobně porouchá. Ujistěte se, že stakeholdeři těchto systémů vědí, že se nasazují záplaty. Buďte připraveni na volání „toto“ nefunguje.
V souladu s mojí základní teorií, že záplaty porušují věci, ujistěte se, že máte období výpadku, abyste mohli aplikovat záplaty dostatečně dlouho, abyste mohli vyřešit kritické problémy, a případně záplatu vrátit zpět. Nemusíte nutně mít lidi, kteří tam sedí a testují opravy. Osobně se velmi spoléhám na své monitorovací systémy, aby mi daly vědět, že vše funguje na minimální úrovni, se kterou se můžeme dostat. Ale buďte také připraveni na malé otravné problémy, které budou přivolány, až se lidé dostanou do práce. Vždy byste měli mít někoho naplánovaného, aby tam byl připraven odpovědět na telefon – raději ne toho, kdo byl až do 3:00 a opravoval krabice.
- co nejvíce automatizovat
Jako všechno ostatní v IT, scénář, scénář a pak ještě něco navíc. Skriptujte stažení balíčku, spuštění instalace, zrcadlení. V podstatě chcete proměnit okna patchů na hlídání dětí, které tam prostě potřebuje člověka pro případ, že by se něco zlomilo.
- Mějte každý měsíc několik oken
To vám dává možnost neopravovat některé servery, pokud z jakéhokoli důvodu nemohou být opraveny v "stanovenou noc". Pokud je nemůžete udělat 1. noc, požadujte, aby byly 2. noci zdarma. Také vám umožní udržet počet serverů opravených ve stejnou dobu při rozumu.
A co je nejdůležitější, držte krok s opravami! Pokud tak neučiníte, zjistíte, že musíte provádět velmi velká 10-hodinová opravná okna, jen abyste se dostali zpět do bodu, kdy jste dohnáni. Představujeme ještě více bodů, kde se může něco pokazit, a mnohem obtížnější je zjistit, který patch způsobil a který problém.
Další částí tohoto problému je, že držet krok s opravami je „dobrá věc“, ale opravy jsou vydávány téměř denně. Kolik plánovaných výpadků musí člověk udělat, pokud je každý den k dispozici nová bezpečnostní záplata?
Oprava serveru jednou za měsíc nebo jednou za dva měsíce je - IMHO - velmi dosažitelný a přijatelný cíl. Víc než to, budete neustále opravovat servery, mnohem méně a začnete se dostávat do situací, kdy máte stovky oprav, které je třeba aplikovat na server.
Kolik oken potřebujete měsíčně? To záleží na vašem prostředí. Kolik máte serverů? Jaká je požadovaná doba provozu vašich serverů?
Menší prostředí, která jsou 9x5, pravděpodobně vystačí s jedním opravným oknem za měsíc. Velké obchody 24x7 mohou potřebovat dva. Velmi velké 24x7x365 může vyžadovat rolovací okno každý týden, aby byla každý týden opravována jiná sada serverů.
Najděte frekvenci, která vyhovuje vám a vašemu prostředí.
Jedna věc, kterou je třeba mít na paměti, je, že 100% aktuální je nemožné cíl, kterého chcete dosáhnout – nedovolte, aby vám bezpečnostní oddělení říkalo něco jiného. Dělejte to nejlepší, nezůstávejte příliš pozadu.
Řešení 2:
Co dělat:
- Vytvořit zálohu
- Ujistěte se, že se jedná o obnovitelnou zálohu (ačkoli tyto dva body jsou obecné)
- Zkuste během upgradu přesměrovat provoz mimo produkční box.
- Zkuste použít metodu mimopásmového přístupu pro případ, že se vše pokazí, KVM, sériovou konzoli, místní přístup nebo vzdálené ruce.
- Před nasazením aktualizací na více serverů se ujistěte, že vše funguje na jednom serveru.
- Pokud můžete, použijte loutku, abyste zajistili, že čísla verzí budou na více serverech stejná. (Můžete jej také použít k vynucení upgradů)
- Na testovacím serveru porovnejte verze konfiguračních souborů s novými (nainstalovanými aktualizacemi) a ujistěte se, že nic vážně nezlomí. Zdá se mi, že si vzpomínám, že se dpkg ptal před instalací nových verzí, které se liší od aktuálně nainstalovaných.
Čemu se vyhnout:
- Aktualizace uprostřed dne nebo v 9:00 v pondělí ráno nebo v 17:00 v pátek odpoledne! (díky @3influence!)
- Upgrade MySQL na opravdu velkých databázových serverech (restart může trvat dlouho)
- Provádění všech serverů najednou (zejména jader)
- Dělat cokoli, co by mohlo změnit /etc/networks (protože byste mohli ztratit připojení)
- Automatické aktualizace, které mohou provést výše uvedené, aniž byste museli kontrolovat, zda je vše v pořádku.
Řešení 3:
Další bod, který stojí za zmínku:Pokud jste zvyklí na Windows, budete překvapeni, že většina aktualizací Linuxu ne vyžadují odstávku nebo restart. Některé ano, například aktualizace jádra. Ale aktualizace, které vyžadují restart nebo výpadek, jsou obvykle jako takové označeny a lze je zpracovat podle samostatného plánu.
Řešení 4:
Na všech našich počítačích Ubuntu běží verze LTS.
Prostě automaticky instalujeme všechny aktualizace – jistě to není „nejlepší praxe“, ale jsme relativně malý obchod a nemáme testovací/vývojářské/produkční prostředí pro každou jednotlivou službu. Aktualizace LTS jsou obecně poměrně dobře testovány a každopádně minimálně invazivní.
Upgrade na nové vydání je samozřejmě trochu složitější.
Řešení 5:
Aktualizace pro systémy ubuntu LTS řešíme následujícím způsobem:
- Udržujte sadu akceptačních testů, které kontrolují všechny kritické cesty v našem softwaru
- Nainstalujte bezobslužné aktualizace zabezpečení ve 4 hodiny ráno každé ráno a okamžitě spusťte akceptační testy. Pokud něco selže, technikovi je zavoláno a má spoustu času věci opravit nebo vrátit zpět do 9:00. To se zatím stalo pouze dvakrát za pět let – LTS je dobře otestovaný a stabilní.
- Každý týden automaticky znovu nasadíme celou naši infrastrukturu (na digitalocean) pomocí modrých/zelených implementací, které udržují všechny balíčky v jejich nejnovějších verzích. Pokud nové nasazení neprojde při akceptačních testech, nasazení je pozastaveno, dokud technik nedokáže problém odladit.
Dalším logickým krokem pro nás je eliminovat informace o relaci v paměti, abychom mohli jednoduše znovu nasadit infrastrukturu každý den nebo dokonce několikrát za den bez dopadu na zákazníky a eliminovat krok (2).
Tento přístup je nenáročný na údržbu a zcela se vyhýbá oknům údržby.