Názory k článku
Záplatujte jádro za provozu s Ksplice

Prvni co me napadlo po precteni clanku byla bezpecnost.. binarni patche, centralizovane rizene.. ach, ten potencial pro utok. Primo do jadra korporatnich „ovci“ :)

Ne, je to to první, co mne napadlo.

První, co mě napadlo, bylo, že by to vydavatelé distribucí měli co nejrychleji okopírovat :)

Ono hlavne „korporatni ovce“ maji bezpecnostni politiky pro patchovani systemu, takze se do systemu bez rozmyslu neleje kazde jadro, co vyjde ;-)
Ksplice mi prijde jako takovy lepsi kexec, se kterym jsme si hrali, kdyz jsem nahaneli co nejvetsi uptime.

To si pan Krčmář dělá srandu ?
Abych systém zaplácnul nějakou third-party closed-source komerční aplikací, které nevěřím, a nechal jí šahat na nejkritičtější část systému ......

V Článku je uvedeno „Ksplice je plně open-source a je k dispozici pod licencí GNU GPL 2“. Tohle se podle vás nyní označuje closed-source?

„Kde to jsme ? Ve windowsech ?“
No nevím, kde jsou ostatní, ale ty jsi zjevně mimo :-)

V článku chybí podstatná informace, že přes ksplice lze zavádět jen některé změny. Především nelze aktalizovat kód, který očekává jiné datové struktury nebo prostě mění jejich význam.

Nevím, nakolik je nástroj inteligentní, ale obecně problém to je nerozhodnutelný. Takže představa, že běžný správce bude vyzobávat jednotlivé commity, kontrolovat jejich ABI a pak je přes ksplice uváženě nasazovat, je velmi naivní.

Tady má právě smysl zmiňovaná komerční služba. Nicméně ale opakuji, že ne všechny opravy lze takto nasadit a že restartům se rozhodně nevyhnete.

> Především nelze aktalizovat kód, který očekává jiné datové struktury
> nebo prostě mění jejich význam.
Ano, přesně na to myslím vývojáři narazili, když s tím přišli na linux kernel mailing list.
Jinak osobně bych řekl, že pokud si nějaká firma nemůže dovolit jeden restart měsíčně (kolikrát i méně, chyby v jádře většinou nejsou kritického bezpečnostního rázu), pak má pravděpodobně i nějaký HA cluster pro případ selhání hardware jednoho stroje a v takovém případě není velký problém stroje aktualizovat postupně, bez potřeby ksplice.

Opatchovavat okolo tisic servrov uz problem je.
Pisat, ze tolko servrov predsa nikto nema, nemusis. Nebudes mat pravdu. Ani v CR nebudes mat pravdu.

Jistě, ale i tak může být potenciálně větším problémem ksplice, přidává to další (významnou) možnost vzniku kritické chyby. Ne ve smyslu bezpečnosti, ale ve smyslu stability systému.
Jen jsem naznačil, že pokud si někdo nemůže dovolit počkat pár sekund, než se stroj restartuje (pravda, u centos a jiných „server“ distribucí je to kolikrát 2+ minuty), pak má pravděpodobně i dost sofistikované failover řešení, které tyto výpadky během restartů eliminuje.

Casto zalezi na tom co vsetko server robi este pred zavedenim samotneho operacneho systemu. Treba sa trosku pohrat v biose a zvojit rozumny kompromis rychlosti bootovania a nastavenia biosovych kontrol..

Nejdelsi je u me nabeh SAS radice.. nez si to nabootuje ten svuj interni OS tak to trva.. a dela to pri kazdem rebootu, i bez power-cycle.

Pri niektorych radicoch sa da nastavit limit cakania na uzivatelovu reakciu. Ale celkovo aj radice s ktorymi som sa stretol ja relativne dlho „bootuju“.

Někteří ale používají serverové železo a tam je to jiné než na běžném PC – musí se čekat relativně dlouho než proběhnou různé testy inicializují se diskové řadiče a další krámy – a až pak začne nabíhat Linux, což už může být těch pár vteřin, ale předtím to jsou řádově minuty (resp. pod minutu se často nedá dostat). Další věc je, že po naběhnutí linuxového jádra startují démoni – databáze, aplikační servery, aplikace… a to můžou být další minuty, než bude systém plně funkční. Před restartem zase bylo potřeba všechno povypínat a bezpečně uložit – takže to máme výpadek řádově tak 5–10 minut – ne tedy „pár sekund“.
Jinak celkem souhlas – tam, kde je požadavek na vysokou dostupnost, se většinou používají clustery, nebo je ten server dostatečně oddělený od potenciálních útočníků, takže se s aktualizací počká na vhodnou chvíli. Přesto mi ale Ksplice přijde jako zajímavé řešení – možná že za pár let, až opadnou tyhle počáteční strachy, nám záplatování jádra za chodu přijde jako něco naprosto normálního, stejně jako dnes bereme třeba virtualizaci nebo LVM, kde si člověk za chodu pracuje s diskovými oddíly.

Jj, nejkratsi rozumna doba ocekavaneho vypadku pri restartu je 1/2 hodiny. Pokud neni tak nema smysl riskovat restart. Pricemz ocekavam, ze tahle vec muze naprosto s prehledem sejmout lusknutim prstu cely system, takze bych stejne neriskoval nasazovat zaplatu na produkcnim systemu za chodu, kdyz si vypadek nemuzu dovolit.
Presne jak bylo receno, bud mam cluster a pak si muzu patchovat stroje postupne (a muzu na to mit script, takze se tim nemusim zabyvat rucne) nebo mam firewall a dalsi zarizeni a pak me nejaka dira v bezicim system nemuze vytrhnout a restartuju to az bude cas.
Mozna vhodne pro specificke pripady, ale rozhodne nijak zasadne nutne pro kriticka nasazeni. Tam se zajisteni chodu 24/7 resi jinak.

to prave resi komercni ksplice – maji privatni custom patche ktere backportuji beze zmeny struktur takze z toho postupem casu vznika krasny lepenec (a musi drzet vetve pro vsechny LTS distro)

A kdyz tam nemam tu oznamovaci oblast? Cas a datum tam je, ale nic vic. Myslim, ze se mi povedlo tu oblast kousek po instalaci vypnout. Jde neak zapnout?

Resp. vratit tam tu oblast neni problem , ale zadna ikonka se v ni po instalaci nezobrazi, takze nevim jestli tam mam tu spravnou oblast. Vidim nastaveni zvuku, messenger, browser a network.

viz prezentace http://www.scribd.com/doc/4852373/Aix-6 strana 21

cely problem je meniace sa ABI linuxoveho jadra. keby pre nejaky main branch bolo stabilne, nieje problem spravit cez VM instrukcie prebratie systemu novym jadrom.
proste sa zastavi system, jadra si predaju potrebne data (file deskriptory, cache atd) a nove jadro pekne bezi. system stoji par sekund a je to.
bohuzial na linuxe to je nemozne.

Tak treba v RHEL to neni problem, ti se drzi celou dobu jednoho kernelu, do ktereho backportuji opravy …
Ale to nic nemeni na stavu, ze bych se toho bal a radeji server restartoval … je jen malo serveru na svete, ktreby bylo problem restartovat … ja dokonce tvrdim, ze je to mozno udelat i za plneho provozu … kdyz je vypadek par minut, tak je to OK … treba zminene lekarstvi se pocita bezne i s vypadkem 3 dni … a pristroje po tu dobu dale shromazduji data u sebe … nez je zacnou prepisovat …

Jenže i u stabilního vnějšího ABI ( read(struct FileDescriptor *descr)) se mění interní ABI ( struct FileDescriptor {...}), takže to nejde jednoduše předat. Proč myslíte, že tohle Windows ještě neumí?