Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: M Z 16. 01. 2026, 10:28:54
-
Mel, bych jeden spis obecny dotaz a doufam ze z toho nebude dalsi hadka ;D.
Za posledni rok mozna uz dele se frekvence aktualizaci kernelu zvysila na cca jedenkrat tydne. Delate poctive aktualizace kernelu a restarty OS, nebo jako ja pravidelne aktualizujete, ale restarty jsou jen vyjimecne?
Podle monitoringu bude prumerny uptime serveru hodne pres sto dni. Nemuzu a ani nejsem ochotny kazdy tyden restartovat vice jak stovku serveru. Na nekterych probihaji nekolik dnu a nekdy i tydnu dlouhe vypocty a par aplikaci ma zavislost na trech i vice serverech, takze automaticke restarty by byly dost problematicke.
-
Existují cesty, jak záplatovat jádro za běhu..
Jako jedna z těch nejméne náročných a v mém prostředí otestovaných variant se mi jeví:
https://ksplice.oracle.com/try/desktop
Pokud máš Ubuntu, můžeš to vyzkoušet i free.
-
Mel, bych jeden spis obecny dotaz a doufam ze z toho nebude dalsi hadka ;D.
Za posledni rok mozna uz dele se frekvence aktualizaci kernelu zvysila na cca jedenkrat tydne. Delate poctive aktualizace kernelu a restarty OS, nebo jako ja pravidelne aktualizujete, ale restarty jsou jen vyjimecne?
Podle monitoringu bude prumerny uptime serveru hodne pres sto dni. Nemuzu a ani nejsem ochotny kazdy tyden restartovat vice jak stovku serveru. Na nekterych probihaji nekolik dnu a nekdy i tydnu dlouhe vypocty a par aplikaci ma zavislost na trech i vice serverech, takze automaticke restarty by byly dost problematicke.
A co resis? Aktualizace a jejich cetnost jsou soucasti firemni IT politiky a to je vec, kterou se mas ridit. Pokud takovy plan nemas, tak se obrat na vedeni, jak mas postupovat.
-
Tak ono se to netýká jen jádra. Když zaktualizuješ aplikace, tak bez jejich restartu ti stejně běží na staré verzi.
Jak říká czechsys, je to věc interní politiky a ta se stanovuje podle toho co na serveru běží, kdo a odkud k němu přistupuje a jaká jsou bezpečnostní rizika. Ruku na srdce, pokud nám OS/aplikace běží a dělá co má, tak ji aktualizujeme v 90% případů jen kvůli "bezpečnosti", protože co funguje, na to se sahá jen když je to nutné. :o
-
Existují cesty, jak záplatovat jádro za běhu..
Jako jedna z těch nejméne náročných a v mém prostředí otestovaných variant se mi jeví:
https://ksplice.oracle.com/try/desktop
Pokud máš Ubuntu, můžeš to vyzkoušet i free.
netusim co mas, pro Debian https://packages.debian.org/trixie/kpatch, resp. https://github.com/dynup/kpatch
v povidani https://tuxcare.com/blog/linux-kernel-security-patching/ je zmineno, ze ksplice vyzaduje Oracle Linux Premier Support subscription
-
Za posledni rok mozna uz dele se frekvence aktualizaci kernelu zvysila na cca jedenkrat tydne. Delate poctive aktualizace kernelu a restarty OS, nebo jako ja pravidelne aktualizujete, ale restarty jsou jen vyjimecne?
Odhadl bych, že v Debianu je kernel spíš tak jednou za měsíc? Resp. brzy po vydání nového stablu chodí hodně aktualizací pořád, ale pak se to už uklidní (i když je to samozřejmě stále verze s podporou). Každopádně ne, nerestartuju, doufám, že většina oprav jsou věci v obskurních modulech vyžadující typ přístupu či konfiguraci kterou člověk běžně nemá. Když by se objevil nějaký akutní průšvih postihující běžné konfigurace, tak se o tom dočtu na Rootu a rebootnu…
-
nahodou jsem narazil na video k tematu a ty tooly na konci se zdaj byt uzitecny pro posouzeni (+talky gregkh jsou vzdycky dobry :) )
https://m.youtube.com/watch?v=dhu8HSOzxd8
https://github.com/gregkh/presentation-cve-is-dead
-
Zda se ze pouze _Jenda pochopil na co jsem se ptal :P. Zkouset ksplice na databazovem serveru nebo na gpfs clusteru s nekolika PB filesystemem vazne nebudu. A firemni IT politika je aktualizovat ASAP, o restartech se tam nic nerika.
To uz je tady na foru takovy folklor, neodpovidat na dotaz, ale davat nevyzadane rady.
_Jendo dekujeme.
-
...
Hele zcela obecne plati, ze funkcnost ma vzdy prednost. Sazmorejme ze to koliduje s "bezpecnosti" (ty uvozovky proto, ze 99% der se tyce mozna promile instanci a i tech jen nekdy).
Takze bys mel nejakym zpusobem scanovat co ty aktualizace obsahujou a podle toho se na ne vykaslat. Jestli to budes nebo nebudes instalovat zavisi i na tom jak ten stroj je pripojenej na sit atd atd atd.
Celkem bezne se provozujou systemy, ktery se neaktualizujou vubec.
-
Mel, bych jeden spis obecny dotaz a doufam ze z toho nebude dalsi hadka ;D.
Ale my se hádat chceme, z toho má Root nejvíc shlédnutí reklam! ;D
Za posledni rok mozna uz dele se frekvence aktualizaci kernelu zvysila na cca jedenkrat tydne. Delate poctive aktualizace kernelu a restarty OS, nebo jako ja pravidelne aktualizujete, ale restarty jsou jen vyjimecne?
Nevím úplně, jak často se u nás na jakých serverech aktualizuje jádro, ale jako rule-of-thumb bych řekl "často a rychle". Virtualizace, cloud, kontejnery, kubernety, high availability, a taková klíčová slova na jedné straně, korporátní se-security-se-nediskutuje a certifikace na straně druhé. 8)
Ve výsledku buď ta dlouhoběžící operace pokračuje bez zastavení a jen se přenáší mezi nody, které se někde dole restartují, aniž bys to reálně potřeboval vědět (databáze). Nebo se s touhle úrovní vysoké dostupnosti nechceš otravovat a pak máme aplikace dělané tak, že prostě nepouští měsíc trvající nepřerušitelný výpočet, protože třeba víš, že se ti každou noc celá farma otočí (a při problému i přes den), a pokud ti to něco rozbije, tak jsi to blbě navrhnul.
Což je ostatně dobrá úvaha obecně: Co když zrovna umře železo, přiletí blbá částice z vesmíru a shodí systém (jako nedávno ten Airbus...)? Ale možná prostě nemáte tolik serverů, aby tohle bylo potřeba řešit (počet serverů * pravděpodobnost * náklady)?
-
...Co když zrovna umře železo, přiletí blbá částice z vesmíru a shodí systém (jako nedávno ten Airbus...)? Ale možná prostě nemáte tolik serverů, aby tohle bylo potřeba řešit (počet serverů * pravděpodobnost * náklady)?
Taky ti do serveru muze natyct voda, vyhoret budova, prijit tsunami ... jenze to vsechno se nedeje 5x denne. Abys moh neco prenaset mezi vice nody, tak to tak musi byt od pocatku sveta navrzeno, a pro spousty uloh to tak vubec udelat nelze. V neposledni rade je taky rec o financich.
-
...
nedávno ten Airbus...)? Ale možná prostě nemáte tolik serverů, aby tohle bylo potřeba řešit (počet serverů * pravděpodobnost * náklady)?
Ono je dobré spíš než pravděpodobnost výskytu události vyhodnocovat rizika ze selhání plynoucí a jejich dopady.
Ono je hrozně hezké, když událost vedoucí k nefunkčnosti nastane kterýkoli den s pravděpodobností 1 ku miliónu, když si v případě povinnosti ji ošetřit a ignorování této povinnosti půjdeš na deset let sednout a dostaneš na dalších 15 let zákaz výkonu činnosti plus flastr pár milionů a budeš mít na krku náhradu škody dalších pár desítek míčů a ještě sankce pod SLA třeba 100 tisíc za každou započatou hodinu nefunkčnosti nad hranici povolené doby na zotavení z poruchy.
To ti pak ta mikroskopická pravděpodobnost bude platná, jak říkají rusáci, "jak zuby v pérdeli".
-
Taky ti do serveru muze natyct voda, vyhoret budova, prijit tsunami ... jenze to vsechno se nedeje 5x denne. Abys moh neco prenaset mezi vice nody, tak to tak musi byt od pocatku sveta navrzeno, a pro spousty uloh to tak vubec udelat nelze. V neposledni rade je taky rec o financich.
Však to píšu - udělat se dá spousta věcí, dal jsem příklady, jak se k potřebě restartů dá přistupovat, když těch serverů jsou stovky, nebo spíš tisíce, a víc. Ale přitom uznávám, že aplikovat takové návrhy dává smysl až od určité kombinace počtu, nákladů, a rizik.
Ono je dobré spíš než pravděpodobnost výskytu události vyhodnocovat rizika ze selhání plynoucí a jejich dopady.
Koukám, že jsem se nevyjádřil nejlépe, protože tohle jsem zahrnul pod "náklady." Náklady na řešení problému když to nastane, i náklady na implementaci. Jen jsem nechtěl mít ilustrační vzorec na dva řádky. Ale jo, no jsme na Rootu a řekl jsem si o to. ;D
-
Nemusíš psát vzorce na půl stránky. A ne, to nejsou náklady; alespoň ne bez dalšího upřesnění. Náklady bez dalšího jsou to, co tě bude stát učinění ochranných opatření pro minimalizaci rizik. A tím jsou myšleny výdaje skutečně vynaložené a skutečně směřující k minimalizaci konkrétních rizik.
To, co se stane, když opatření neučiníš nebo selžou, jsou rizika.
-
Pokud firemní security politika tlačí na aktualizace ASAP, ale byznys ti prostě nedá prostor pro restart, tak je na čase začít řešit Live Patching (třeba kpatch pro Debian/RHEL nebo Canonical Livepatch u Ubuntu). Díky tomu můžeš lepit kritické díry v jádře v podstatě za pochodu. Samozřejmě to úplně neruší potřebu ten server dřív nebo později restartovat se vším všudy, ale aspoň můžeš v klidu nechat dojet ty dlouhé výpočty, aniž bys riskoval bezpečnost. Můžete se také seznámit s tímto (https://rodeoslot-cz.net/), doufám, že vám to bude užitečné.
-
Zda se ze pouze _Jenda pochopil na co jsem se ptal :P. Zkouset ksplice na databazovem serveru nebo na gpfs clusteru s nekolika PB filesystemem vazne nebudu. A firemni IT politika je aktualizovat ASAP, o restartech se tam nic nerika.
To uz je tady na foru takovy folklor, neodpovidat na dotaz, ale davat nevyzadane rady.
_Jendo dekujeme.
Bezne se to i na techto masinach dela pokud ma clovek firmu ktera mu za livepatche ruci. Zatim jsem nezazil vyjma problemu s HW drivery pri livepatchingu jadra nejake zasadnejsi problemy. Dalsi vec je taky pouzivat ten spunt na krku a cist si jestli opravy jsou pro mne relevantni nebo ne. Mit par PB dat neni dnes az tak moc. V nouzi sjet report vulnerabilities/ changelogy AI a vysledek dofiltrovat tim spuntem na krku.
Vzhledem k dulezitosti dat a argumentaci z business strany jiste takova firma plati lidi nebo firmu ktera se tim zabyva. V nekterych odvetvich je toto dokonce povinnost.
Co se tyce funkcionality vs bezpecnosti tak tohle si vetsinou vyjednaji infra a sec manazeri. V zavislosti na politice firmy jeden nebo druhy taha za ten silnejsi provaz.
Pokud jsi jen technicka osoba dotazal bych se nadrizenych. Ty od toho placeny nejsi. Nezivis tak neprepinej.
Jsi-li manazer proberte to s obema stranami na meetingu a definujte si nejaka pravidla pokud uz tato pravidla nemusite splnovat napr. spadanim pod zakony, oborove audity atd. Jsi-li na to sam... je mi te lito.
-
...je na čase začít řešit Live Patching....
Ja bych chtel videt nekoho, kdo bude garantovat (nikoli kecama ale penezma) ze ten system pri tom necrashne.
Specielne v situaci, kdy cim dal castejs v ruznech distrech i po aktualizaich ruznych knihoven vyskakujou hlasky na tema "a ted to bezte restartovat nebo to nebude fungovat".
-
...je na čase začít řešit Live Patching....
Ja bych chtel videt nekoho, kdo bude garantovat (nikoli kecama ale penezma) ze ten system pri tom necrashne.
Specielne v situaci, kdy cim dal castejs v ruznech distrech i po aktualizaich ruznych knihoven vyskakujou hlasky na tema "a ted to bezte restartovat nebo to nebude fungovat".
Ano garance penezma existuje. Musite mit specificke distro, lidi s papiry a premium sluzby. Jinak spis nemit ten system postaveny jako prasopes a spolehat se na to ze ten jeden server _snad_ bude fungovat.
Co se tyce userspace uz se livepatchuji i nektere dulezite systemove knihovny jako glibc nebo crapssl.Pro ostatni veci mate mit reseno v HA - ktere se dela taky kvuli patchingu aby sluzba byla ziva v prubehu upgradu. Co tam mate dal?
-
Tak ono se to netýká jen jádra. Když zaktualizuješ aplikace, tak bez jejich restartu ti stejně běží na staré verzi.
Jak říká czechsys, je to věc interní politiky a ta se stanovuje podle toho co na serveru běží, kdo a odkud k němu přistupuje a jaká jsou bezpečnostní rizika. Ruku na srdce, pokud nám OS/aplikace běží a dělá co má, tak ji aktualizujeme v 90% případů jen kvůli "bezpečnosti", protože co funguje, na to se sahá jen když je to nutné. :o
Proto se to resi nadrazenymi systemy a scenari pro migraci loadu tam a zpatky kvuli updatum. Tyhle scenare bud ma clovek predchroupane vyrobcem a nebo si je musi vyvinout sam. Nad to jeste jde firemni DR kdyby se to hodne podelalo.
Jedna vec je rici ASAP, druha vec je definovat casove podminky pro "ASAP" a akce kdyz se neco podela. Dalsi vec je nastavit takove podminky aby to bylo proveditelne a bez problemu testovatelne.
Vypracovat a odladit tyto scenare vcetne testu muze trvat u slozitych systemu i leta s praci mnoha lidi. A pravidelne se v labu testuji.
Proto lidi za to berou ne uplne male penize. Kdyby tomu tak nebylo tak delam admina za plat o neco malo vyssi nez plat vedouci lidlu.
Bud provozovatelum na businessu zalezi a nebo hazeji SLA do smluv bez realnych sanci je splnit a pak je to casovana bomba.
-
...
Ano garance penezma existuje. ...
Cet si nekdy alespon jednou vzivote nejakou takovou smlouvu? NIKDO na tyhle planete ti takove garance NEDA.
A ver tomu, ze sem to resil, a nikoli jednou. Vzdycky to byla nejdriv hromada kecu, jak zadny vypadky nebudou a kdyz sem chtel aby teda do smlouvy dali, ze v pripade vypadku budou platit smesny stovky tisic za kazdou hodinu (odpovidalo to zhruba ciste mzdovym nakladum), tak ze vzdycky vsichni zacli kroutit, ze to je jako moc, ze by pak museli platit mnohem vic, nez kolik si fakturujou ... a ja jim na to vzdycky rikal, vzdyt ste prave prisahali, ze zadne vypadky nebudou, takze nic nikdy platit nebudete ... takze je to proste sprosta lez. A opakovane jsem mel tu cest takovy dodavatele vykopnout.
Vsechny, 100% vsech tzv "garanci" je postaveno v nejlepsim pripade na tom, ze ti vratej nejakej ten mesicni, v maximalni variante rocni poplatek. Tvoje skody budou ale radove vetsi.
...
Jedna vec je rici ASAP, druha vec je definovat casove podminky pro "ASAP" ...
jak ze se to jmenuje ... jo aha ... CrowdStrike ... "hlavne honem"
Zajimaly by me ty biliony dolaru ktery v ramci "garanci" vyplatily za zpusobeny skody ...
-
...
Ano garance penezma existuje. ...
Cet si nekdy alespon jednou vzivote nejakou takovou smlouvu? NIKDO na tyhle planete ti takove garance NEDA.
A ver tomu, ze sem to resil, a nikoli jednou. Vzdycky to byla nejdriv hromada kecu, jak zadny vypadky nebudou a kdyz sem chtel aby teda do smlouvy dali, ze v pripade vypadku budou platit smesny stovky tisic za kazdou hodinu (odpovidalo to zhruba ciste mzdovym nakladum), tak ze vzdycky vsichni zacli kroutit, ze to je jako moc, ze by pak museli platit mnohem vic, nez kolik si fakturujou ... a ja jim na to vzdycky rikal, vzdyt ste prave prisahali, ze zadne vypadky nebudou, takze nic nikdy platit nebudete ... takze je to proste sprosta lez. A opakovane jsem mel tu cest takovy dodavatele vykopnout.
Vsechny, 100% vsech tzv "garanci" je postaveno v nejlepsim pripade na tom, ze ti vratej nejakej ten mesicni, v maximalni variante rocni poplatek. Tvoje skody budou ale radove vetsi.
...
Jedna vec je rici ASAP, druha vec je definovat casove podminky pro "ASAP" ...
jak ze se to jmenuje ... jo aha ... CrowdStrike ... "hlavne honem"
Zajimaly by me ty biliony dolaru ktery v ramci "garanci" vyplatily za zpusobeny skody ...
Spatne nastaveni odberatelsko/dodavatelskych vztahu. Postupoval jste spravne. Vybral jste jine dodavatele. Jsou dodavatele kteri nezvladnou ani spravne vydefinovat urovne odpovednosti (napr. garance do nejakeho predavaciho rozhrani) natoz absorbovat to pres management prostredku nutnych k zachovani kvality.
Je zajimave ze my mame financni kompenzace za vypadle spoje vcetne zaloh. Nebo kdyz se stane neco zavazneho v datacentru.Nad tyto veci existuje jeste pojisteni nicmene za data si rucime sami. A ty zalozni lokality vc paskovych zaloh si zakaznik zaplati v cene. Pokryje to vyznamnejsi cast skod. Zbytek jde z pojisteni nebo fondu "na prusery".
Katastrofy typu crowdstrike take nekde cekaji az nekdo posle kriticky update. Zatim je to riziko aspon podle manazeru a bezpecaku prijatelne. Ja za to nezodpovidam a taky neberu pul mega mesicne abych za to tu odpovednost mel.
Jinak pokud jsem byl na volne noze musel jsem mit nekolik mega pojistku na odpovednost vuci skodam jinak by mne velke firmy ani nezamestnali. Jednou byl zkutecne nejaky pokus podojit moje pojisteni a jednou jsem ho vyvolal sam umyslne protoze tu skodu jsem skutecne zpusobil (byt slo o drobnou castku do 150 tisic). Tohle pojisteni typicky treba absorbuji IT "pasacke" agentury/bodyshopy.