Az Ubuntu Livepatch immár elérhető az Ubuntu 14.04 LTS-hez is

Ubuntu

Részletek itt.

( mrev | 2017. 06. 06., k – 21:25 )

Az Ubuntu telefon dobása jobban fáj, mint a Livepatch hiánya. Amúgy a futás közbeni kernel csere biztos érdekes szakmailag, sőt bravúros, csak azt nem hiszem, hogy attól nagyobb lesz a biztonság.
--
ulysses.co.hu

Bravúros. Különösen azt nézve, hogy a Windows még a userlandot sem tudja munka közben frissíteni. Így aztán a laptopok újabban nem alkalmasak a mobil munkavégzésre, mert amikor össze kéne pakkolni, és menni, a Windows kiírja, hogy ne kapcsoljam ki a gépet, mert frissít. Nem értem, hogy ezt hogy képzelték.

Nem, elmondom neked, hogy ez mire való. Arra, hogy ha van egy rakás hostod és mind érintett, de csak ütemezve tudod újraindítani őket, akkor a kernel live patching időt ad neked arra, hogy végig tudj menni az összesen anélkül, hogy megtörnék az utolsót, miközben csak az x-ediknél tartasz.

Persze ez nem azoknak szokott hasznos lenni általában, akinek az Ubuntu telefon dobása fáj legjobban az IT-n belül. Kicsit más a célközönség.

--
trey @ gépház

Ha érdekel, hogy ki használ ilyen technológiát, akkor arra azért lehet ám az interneten keresni... Te a technológia létjogosultságát kérdőjelezed meg. Az Ubuntu megoldása relatíve fiatal, nem biztos, hogy ebből kell kiindul.

De ott van az ezen a téren úttörő Ksplice, ami pontosan ugyanezt csinálja.

"250 ezer védett rendszer"

Ugyan friss nincs, de pár éves prezentációból kiderül, hogy pl. a Yahoo! használja.

A Google akkora költségvetésből megoldja erőből ezt, de kisebb cégeknek, kisebb felhőszolgáltatóknak ez ettől még egy hasznos techniológia lehet. Ugye, azt belátod, hogy közéd és a Google közé azért még befér néhány piaci szegmens?

Mivel a futó kernelt nemcsak javítani lehet, hanem gond esetén a javítást rollback-elni is lehet, adott esetben két reboot is megspórolható vele.

Egyébként meg nem egyszer volt példa arra, hogy 0day exploitok kiadását olyan időszakra időzítették, amikor az IT staff nagy része szabadságon van (pl. karácsonyi időszak) és nincs elegendő ember a javítások terítésére. Ilyen helyzetben jól jöhet egy adott probléma gyors javítása reboot nélkül, hiszen gyorsan megvan. A full javítás meg ráér a következő tervezett karbantartási időablakban.

--
trey @ gépház

Nem volt szó megkérdőjelezésről. Arról azonban meg vagyok győződve, hogy egyetlen gép esetén egyáltalán nem frissíteni biztonságosabb, mint reboot nélkül frissíteni. Konzervatív rendszergazdák az igazán fontos szervereiket gyakran egyáltalán nem engedik frissíteni, inkább védik kívülről. Elképzelhetetlennek tartom, hogy egy bank számlavezető rendszerében ilyesmivel próbálkozzanak.

Teljesen igazad van a "célközönség" dologban. Ubuntu telefon tulajdonosként annak célközönsége vagyok. Eleve jellemző rám, hogy lett egy ilyen telefonom. Baromira szeretem, hogy a Linux futtatja programjaimat. Ezzel szemben nem vagyok rendszergazda, tehát nem vagyok a Livepatch célközönsége. Amúgy a Canonical elég hektikusan váltogatja a célközönségét.

--
ulysses.co.hu

Nyilvánvaló, hogy egyetlen gépeddel egy havi több száz / ezer dolláros szolgáltatásnak nem vagy célközönsége. Nem is értem, hogy nálad ez egyáltalán hogy merült fel.

"Amúgy a Canonical elég hektikusan váltogatja a célközönségét."

A Canonical széles területet fed le, vagy próbál lefedni. Próbálkozik a mobillal, a desktoppal és a cloud-dal. Szerintem az utóbbi megy neki a legjobban, azzal keres. A többi pedig tapogatózás, útkeresés, hobbi, vagy a közösségnek visszajuttatás.

Egyébként arányait, beleölt zsét tekintve, szerintem a Canonical telefon üzletága semmivel sem rosszabb próbálkozás, mint a Microsofté. Kb. ugyanott tartanak.

--
trey @ gépház

Hát az az egyetlen az nálam 10-20 gép, miközben a családomról meg néhány munkatársamról van csak szó, amúgy meg programozással foglalkozom. De nem tudnám hirtelen megmondani, hogy hány gépem van. Én magam frissítés párti vagyok, mert az a jó ha nálam szállnak el az új dolgok, nem pedig a felhasználónál.

Hogy mi biztosabb, frissíteni vagy nem frissíteni, azt szerintem így kell eldönteni: Elképzeled, hogy egy tengeralattjárón (űrrakétán, effélén) utazol a családoddal, amit egy Linux vezérel. Ha a Linux leáll, mindannyian meghaltok. A Linux már fut egy éve, amikor jön egy Livepatch. Hogy döntesz, hozzányúlsz a rendszerhez?

Persze teszteled először a patchet. 100 ugyanolyan gépen hibátlanul lefutott. És akkor megint az a kérdés, hogy ezután hozzányúlsz-e ahhoz a Linuxhoz, aminek semmiképp sem szabad leállnia, különben meghaltok.

Namost térjünk át a havi több százezer dolláros szolgáltatás nagyságrendjére. Mekkora lesz a pénzügyi katasztrófa, ha egy ilyen helyen hiba csúszik a tömeges frissítésbe? Becsődöl a cég? Márpedig időnként csúszik.
--
ulysses.co.hu

Kritikus rendszert nem futtatunk egyetlen gép, egyetlen oprendszerén. Sem linuxon, sem windows-on, sem máson.
Kritikus rendszer esetén pont teljesen mindegy, hogy újra kell-e inditani patcheléshez vagy nem, mert a minimum, hogy klaszterben van, és amig az egyik gép patchelődik, újraindul, warmuppol, addig a másik gép(ek) kiszolgálják a kiszolgálandót.

Ha nem kell újrainditani az oprendszert, csak a kérdéses szolgáltatást/daemon-t, akkor mi is van? Pont ugyanaz. Ha kritikus, akkor kell legyen másik gép ami ellátja a feladatot, amig az egyik szerveren patchelődik/újraindul a szolgáltatás.

Nem kritikus rendszeren meg maximum kényelmi kérdés, hogy hányszor és mennyi időre esik ki a szolgáltatás amig a gép, vagy a szolgáltatás amit nyújt újraindul.

„Kritikus rendszer esetén pont teljesen mindegy, hogy újra kell-e inditani patcheléshez vagy nem, mert a minimum, hogy klaszterben van, és amig az egyik gép patchelődik, újraindul, warmuppol, addig a másik gép(ek) kiszolgálják a kiszolgálandót.”

Kapcsolódó link: https://www.hwsw.hu/hirek/48816/amazon-aws-cloud-netflix-fejlesztes-tes…

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ezek nagyon okos dolgok. Ha ezeket felmondjátok a vizsgán, biztosan jó jegyet kaptok. De én egy sokkal egyszerűbb kérdéssel jöttem. Fut egy Linux (mindegy, hogy hogyan, miért, ez most a kiindulás). Ennek a Linuxnak semmiképp sem szabad leállnia. Azt, hogy semmiképp, azt nem úgy értem, hogy a szolgáltató 99.9999999-es rendelkezésre állást garantál, és a mégis bekövetkező leállás után kötbért fizet. Hanem úgy, hogyha leáll a rendszer, akkor felrobban az erőmű. Kapsz egy kernel patchet, amiről azt mondják, hogy javít valami fontos hibát. Ebben a helyzetben próbálkozol-e a patcheléssel. Mivel a Linux nem állhat le, persze elve csak reboot nélküli patch jöhet(ne) szóba.
--
ulysses.co.hu

Mondhatjátok, hogy olyan helyzet nem létezhet, hogy egy Linux le nem állásán múljon egy erőmű felrobbanása. Ez persze csak menekülés a kérdés elől, ráadásul nem is igaz. Egyszerűen belátható, hogy lehet ilyen helyzet. Azt ugye tudjuk, hogy Fukusima felrobbant. Nyilván Fukusimában az elképzelhető legfejlettebb biztonsági módszertanokat alkalmazták, és mégis. Képzeljük el, hogy a mi erőművünk is ezerszeresen be volt biztosítva, ezer hostból álló cluster vezérelte a működését, és nagy szerencse, hogy ilyen óvatosak voltunk, mert a földrengés az ezer elemű clusterből csak 999 gépet vágott tönkre, még maradt egy működő Linux, amíg az fut, nem robban az erőmű. Te vagy az operátor, neked kell megmenteni a világot. Kaptál egy patchet, mit csinálsz?

Tegyük fel, hogy felhőszolgáltató vagy. A rendszereden 10 ezer Ubuntu 14.04 LTS image fut, amiket te üzemeltetsz. Ezek mindegyike különböző ügyfeleké.

Melyiknek kisebb az imapct-je? Rebootolni 10 ezer virtuális gépet (előtte kiértesíteni az ügyfelet a kiesésről stb.) vagy megfelelő tesztelés után kiteríteni a live update-et, amitől az ügyfél szolgáltatása nem áll meg, az SLA nem sérül vagy nő meg stb.

--
trey @ gépház

"Persze teszteled először a patchet. 100 ugyanolyan gépen hibátlanul lefutott. És akkor megint az a kérdés, hogy ezután hozzányúlsz-e ahhoz a Linuxhoz, aminek semmiképp sem szabad leállnia, különben meghaltok."

Mi a bánatért ne nyúlnék hozzá? Ugyanonnan jön a live update, ahonnan a kernelcsomag update. Ha nem bízok meg benne, hogy az tesztelt, akkor megette a fene az egészet. Az látszik, hogy te életedben nem használtál ilyet, fogalmad nincs miről beszélsz. Évekig teszteltem a Ksplice-t az elsődleges gépemen, probléma nélkül.

Okoskodhatsz itt, előadhatod, hogy szar elképzelés (mindenféle konkrétumok nélkül), de te kernel belügyekben mennyire vagy otthon? Mi alapján teszel ilyen kijelentéseket?

"aminek semmiképp sem szabad leállnia"

Játszod itt a hülyét, de így nem jutunk előbbre. Ctrl+F időt ad

--
trey @ gépház

CTRL-F high availability
CTRL-F how to operate a mission critical environment

ha csak 1 db linuxos gép maradt életben, és ezen múlik, hogy felrobban-e az erőmű, akkor a következőd csinálod:
1. nem telepítesz patch-et
2. lekapcsolod az erőművet
3. megvárod a bírósági idézést, és számot adsz róla, hogy került egy dobozos OS katasztrófaterv nélkül egy ilyen kritikus rendszerre, és miért veszélyeztetted ezzel több millió ember életét :)

"A Linux már fut egy éve, amikor jön egy Livepatch. Hogy döntesz, hozzányúlsz a rendszerhez?" kimaradt a kepletbol egy szerintem igen fontos dolog. Szoval, hogy jon az a kritikus patch, leteszteled 100 gepen, hogy minden rendben van-e, majd eldontheted, hogy tervezetten halsz-e meg, egy esetleges hibatol, amit a teszt nem hozott elo, vagy tok tervezetlenul adatvesztessel/adatlopassal egybekotve halsz meg mert egy tamado kihasznalta, hogy nem telepitetted a kritikus patchet. Vajon mi kerul tobbe a cegnek, valamennyi kieses (ami ha kritikus rendszerrol van szo van valami HA), vagy az, hogy ellopjak a teljes adatbazist vagy egyeb randasagokat csinalnak?

-
Go konkurencia kezelés gyorstalpaló

Hát persze. Ha nem nagyon fontos hogy ne álljon le a rendszer, akkor lehet ilyesmivel játszani. Ha viszont nem fontos, akkor akár le is lehet állni a frissítéshez, tehát akkor meg felesleges. Legalábbis a leállás/nemleállás szempontjából. Marad a praktikum, amit trey írt, és amit el is ismertem.
--
ulysses.co.hu

Elképzelhetetlennek tartom, hogy egy bank számlavezető rendszerében ilyesmivel próbálkozzanak.

Konzervatív rendszergazdák az igazán fontos szervereiket gyakran egyáltalán nem engedik frissíteni, inkább védik kívülről.

Ez igaz volt úgy 10 éve, azóta a többség azért kijött az IT barlangból. Ha egy banknál ma itt tart az IT, akkor keress inkább másik bankot. ;)

Bankban egyébként már csak azért sem jó ötlet nem frissíteni, mert jönnek az auditok (pl. MNB) félévente, évente, havonta, hol mikor. És ha meglátják, hogy nincs a rendszer rendesen patch-elve, karbantartva, olyan bírságot varrnak a nyakadba, hogy min. egy hétig egyirányba pörögsz. Nem tudom a mostani MNB "díjszabást", de ha jól emlékszem, akkor 50M Ft-ról indul a "móka" és ha jól rémlik akkor 500M a teteje. És bizony az MNB-nél könnyen megszalad az a bizonyos ceruza.
Másrészt, ha nem patch-elsz, akkor sokkal több erőforrást és időt igényel egy-egy rendszer kiváltása, akár újabb verzióra való átállással is. Ez ilyenkor sok idő, és emiatt sok pénz. Sokkal több, mintha folyamatosan követnéd az üzemeltetett rendszerek patch-eit. Amolyan "olló efektus". A bankok pedig egy dolgot nagyon nem szeretnek. Pénzt kiadni, pluszban meg pláne.

Egyébként meg egy számlavezető rendszer egy bank működésének csak egy darabja. A kártyáddal pl. akkor is tudsz pénzt felvenni, fizetni, ha a számlavezető rendszer áll. Rendszere válogatja, de van ahol még mondjuk tranzakciót is tudsz rögzíteni (pl. egy netbankon feladott átutalást), max csak később kerül be a rendszerbe.

bank IT != számlavezető rendszer.

Nem arról volt itt szó elsősorban, hogy jó-e frissíteni, hanem hogy növeli-e a biztonságot, ha _leállás_nélkül_ frissítünk. Nekem az a véleményem, jobb leállással frissíteni. De elismertem, hogy 100 ezer gép frissítése esetén praktikus lehet a menet közbeni frissítés.
--
ulysses.co.hu

( insight | 2017. 06. 07., sze – 09:53 )

Értem, hogy miért kell, de tök vicces, hogy a második teendő :)
- sudo reboot -