abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 17:00 | Bezpečnostní upozornění

Nedávno byla vydána nová verze 9.4.6 nástroje pro řízení a správu IT zařízení a služeb GLPI (Wikipedie). Opraveno bylo několik bezpečnostních chyb. Například také SQL injection CVE-2020-11032 aneb email z ';-- Have I Been Pwned? dokáže smazat celý ticket systém.

Ladislav Hagara | Komentářů: 0
včera 13:00 | Zajímavý článek

MojeFedora.cz informuje, že Firefox 77 pro Fedoru přináší akceleraci videa. Firefox 77 pro Fedoru obsahuje patche, které konečně přináší podporu pro VA-API, tedy hardwarovou akceleraci videa. Podpora pro VA-API momentálně funguje pouze na Waylandu.

Ladislav Hagara | Komentářů: 4
včera 12:00 | Pozvánky

Sdružení CESNET dnes opět po roce pořádá jednodenní seminář věnovaný internetovému protokolu IPv6. Tentokrát on-line a s názvem Svět bez IPv4. K dispozici jsou také prezentace a záznamy přednášek z loňského roku.

Ladislav Hagara | Komentářů: 0
včera 08:00 | Nová verze

Byla vydána nová stabilní verze 2.83 svobodného 3D softwaru Blender. Přehled novinek v oznámení o vydání a na YouTube. Jedná se o první verzi Blenderu s prodlouženou dvouletou podporou (LTS).

Ladislav Hagara | Komentářů: 4
včera 07:00 | Zajímavý článek

Jim Salter v recenzi pro Ars Technica srovnává novou generaci notebooků Dell XPS 13 s MS Windows 10 a Ubuntu (model „Developer Edition“). V obou případech naráží na problémy s výchozími ovladači: Wi-Fi Killer na Windows, chybná detekce ovladačů (audio čipu a Wi-Fi) od Dellu v Ubuntu.

Fluttershy, yay! | Komentářů: 12
3.6. 16:22 | Nová verze

Byla vydána verze 2.2 svobodné federalizované platformy pro sledování a sdílení videí, alternativy YouTube s podporou P2P, PeerTube (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení. Přispět lze na vývoj verze 3. V plánu je například podpora živého přenosu (live streaming). Za vývojem PeerTube stojí nezisková organizace Framasoft snažící se mimo jiné nahradit svými svobodnými Frama službami služby společnosti Google (De-google-ify Internet). Bohužel ale musí některé své služby omezovat.

Ladislav Hagara | Komentářů: 8
3.6. 07:00 | Komunita

Lenovo oznámilo, že bude certifikovat všechny své pracovní stanice řady ThinkStation a ThinkPad P pro Linux, konkrétně pro linuxové distribuce Red Hat Enterprise Linux a Ubuntu LTS. Doteď byly certifikovány pouze konkrétní modely.

Ladislav Hagara | Komentářů: 13
3.6. 00:44 | Nová verze

Oficiálně byl vydán Devuan Beowulf 3.0.0. Přehled novinek v poznámkách k vydání. Kódové jméno Beowulf je podle planetky s katalogovým číslem 38086. Příští verze 4.0.0 bude Chimaera. Devuan (Wikipedie) je fork Debianu bez systemd.

Ladislav Hagara | Komentářů: 0
3.6. 00:11 | Nová verze

Byla vydána verze 20.04 linuxové distribuce Greenie (Wikipedie). Nově s desktopovým prostředím KDE.

Ladislav Hagara | Komentářů: 5
2.6. 19:11 | Nová verze

Byla vydána nová verze 4.7 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 9.5. Thunderbird na verzi 68.8.0. Opraveno bylo několik bezpečnostních chyb.

Ladislav Hagara | Komentářů: 0
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (36%)
 (18%)
 (6%)
 (13%)
 (10%)
 (6%)
 (15%)
 (22%)
Celkem 72 hlasů
 Komentářů: 2, poslední včera 19:05
Rozcestník

Jaderné noviny – 14. 7. 2011: Jak vyřešit nepořádek v logu jádra

26. 7. 2011 | Jirka Bourek | Jaderné noviny | 3247×

Aktuální verze jádra: 3.0-rc7. Citáty týdne: Andrew Morton, Linus Torvalds. Jak se to jádro bude jmenovat?. Problémy se strukturovanými logy.

Obsah

Aktuální verze jádra: 3.0-rc7

link

Současné vývojové jádro je 3.0-rc7 vydané 11. července. Myslím, že jsem říkal, že -rc6 by mohlo být poslední. Lhal jsem. Věci byly poměrně klidné, ale je tu dost nových záležitostí, takže jsem chtěl vydat další -rc; stále také máme nějaké problémy se změnami RCU, které působí potíže, když k RCU událostem dojde před kompletní inicializací plánovače. Takže -rc7 je venku. Všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: stabilní aktualizace 2.6.32.43 a 2.6.33.16 vyšly 13. července; 8. července vyšlo 2.6.39.3. Všechna jádra obsahují obvyklý seznam oprav – v případě 2.6.39.3 je jich poměrně hodně.

Citáty týdne: Andrew Morton, Linus Torvalds

link

Changelog nám zapomněl sdělit, jaké jsou dopady této chyby viditelné pro uživatele. To od něj bylo opravdu špatné. Ošklivý changelog. Nedostaneš kostičku.

-- Andrew Morton

Právníci: vypadají jako rozumní a chytří lidé, když na ně koukáte jako na jednotlivce. A stejně se pokusí dohadovat se, jestli si pamatujete specifické datum příspěvku do newsgroup, který jste napsali. Co na tom, že ten příspěvek u sebe má jasně napsané datum a je odpovědí na jiné příspěvky (a je na něj odpovídáno jinými příspěvky), které také mají datum.

-- Linus Torvalds

Jak se to jádro bude jmenovat?

link

Když Linus na konci května oznámil jádro 3.0-rc1, stále se identifikovalo jako „3.0.0“. Očekávalo se, že mnoho skriptů předpokládá, že třetí číslo existuje a Linus je nechtěl rozbít hned zezačátku. I tak ale doufal, že poslední „.0“ zmizí:

Máme před sebou obvyklých 6-7 týdnů zápasu, než ho vydáme a než se skripty pročistí, takže finální verze by měla být jenom „3.0“. Tým pro stabilní jádra může třetí číslo použít pro své verze.

Rychle vpřed k 3.0-rc7 a jádro se pořád identifikuje jako 3.0.0. I když jednoznačné informace chybí, zdá se, že je stále mnoho programů a skriptů, které bez posledního čísla přestanou fungovat. V jistém smyslu se schéma s třemi čísly ve verzi stalo během let součástí jaderného ABI. Dalo by se dohadovat, že všechno, co přestane fungovat, bylo napsáno hloupě, ale i tak je cílem vyhnout se rozbíjení programů v uživatelském prostoru. Takže i když není žádná jednoznačná odpověď, zdá se, že vydání z hlavní řady budou ještě nějakou dobu mít tři čísla. Bylo by nicméně velice překvapivé, kdyby první stabilní aktualizace měla jiné číslo než 3.0.1.

Je zde nicméně další otázka: co s programy, které se nedokáží vyrovnat s jiným číslem verze než „2.6.x“? Takové zjevně existují. Prohlásit, že verze jádra budou navždy začínat „2.6“ jde za hranice i té největší snahy dodržet binární kompatibilitu; na něco takového nedojde. Aby zjednodušil život lidem, kteří takové programy mají, implementoval Andi Kleen nový režim [personality], který předstírá, že ke změně na 3.0 nikdy nedošlo. Pokud je program spuštěn v tomto režimu, bude si myslet, že verze jádra je 2.6.40; 3.1 bude vypadat jako 2.6.41 atd.

Andi říká: Vím, že je to poněkud ošklivé, ale lepší workaround jsem nevymyslel a kompatibilita pro existující programy je důležitá. V době psaní tohoto článku se daný patch nicméně ještě nedostal do hlavní řady.

Problémy se strukturovanými logy

link

napsal Jonathan Corbet, 12. července 2011

Debata o konceptu jmen disků přívětivých pro uživatele byla tento týden znovu rozdmýchána, když Nao Nishijima zaslal novou verzi patche pro trvalá jména zařízení. Neshody o této vlastnosti trvají; je ale možné bude začleněna i tak. Jádrem diskuze nicméně byl koncept, který jde ještě dál za přidání uživatelem specifikovaných jmen ke specifickým zařízením; je to větší problém, jak dostat z jádra strukturovaná data.

Po všech těch letech je hlavním mechanismem, jak jádro předává informace do uživatelského prostoru, primitivní funkce printk(). Není třeba říkat, že je to užitečná a flexibilní cesta, jak dostat zprávy mimo jádro, ale neklade žádné požadavky na strukturu těchto zpráv. To vše vede k různým výstupům jako (z drivers/net/de620.c):

printk(KERN_WARNING „%s: Thanks, I feel much better now!\n“, dev->name);

nebo slavné zprávy z drivers/char/lp.c:

printk(KERN_INFO „lp%d on fire\n“, minor);

Nelze vinit správce systémů z toho, že nemají tušení, jak na takové zprávy mají reagovat.

Došlo ke změnám, které měly vynutit nějakou strukturu výstupu printk(), počínaje přidáním značky identifikující závažnost každé zprávy. I tak ale není těžké najít volání printk() bez identifikace závažnosti; skutečné vynucení jejich používání se ukázalo jako příliš těžké. Nějakou strukturu přidává dev_printk() (a varianty jako dev_err()), ale používání těchto funkcí rozhodně není všeobecné.

Chybějící struktura znamená, že zprávy nejsou příliš konzistentní; každé dva síťové ovladače téměř určitě vypíšou jinou věc popisující stejnou situaci. Jaderné zprávy se také mohou postupem času změnit; zprávy vypisované pomocí printk() se normálně nepovažují za součást jaderného ABI i přes fakt, že jejich změny mohou rozbít skripty, které se ze systémových logů pokouší vytáhnout užitečné informace. Není překvapivé, že téměř před rokem Andrew Morton řekl:

Celý přístup jádra k zasílání zpráv je poměrně nahodilý a neschopný a smutný. Objevilo se několik návrhů, jak ho zlepšit a racionálně rozdělit věci do kategorií tak, aby to bylo pro obsluhu užitečnější, ale zdá se, že se nikdy nic nedostane do hlavní řady.

Různí lidé se situaci na některých místech pokoušeli vylepšit; uživatelsky přívětivá jména disků, která se snaží zařízením přiřadit konzistentní jména, jsou jeden takový pokus. Patch netoops od Google je další; pomáhá Googlu zjistit, které stroje padají bez toho, aby jejich správci museli přehrabovat logy. Tyto změny ale mají daleko k obecnému frameworku pro strukturovaná data od jádra.

Během let došlo k několika pokusům takový framework vytvořit; ani jednomu se nepodařilo do jádra dostat. Není těžké přijít na věrohodné zdůvodnění tohoto selhání. Množství práce, kterou to vyžaduje, je obrovské, obzvláště pokud někdo chce dodat strukturu do větší části zajímavých sdělení od jádra. Vývojáři mají printk() rádi; těžko je okouzlí jiné rozhraní, které k použití vyžaduje práci navíc, jeho výstup je (z principu) méně flexibilní a navíc může existovat společně se stávajícím logováním pomocí printk(). Vymyslet strukturovaný formát, který splní požadavky všech – a který nebude v následujících letech nutné doplnit formátem „verze 2“ – je výzvou samo o sobě.

Také je potřeba říci, že jaderní vývojáři jako celek vidí jenom malou hodnotu ve strukturovaných logovacích informacích. Nepomůže jim to ladit jejich jádra. Fakt, že mnoho uživatelů by takovou vlastnost chtělo, není pro vývojovou komunitu nerelevantní, ale zkušenosti ukazují, že o co vývojáři nemají zájem, je mnohem těžší začlenit – obzvláště když taková změna bude mít široký záběr a bude rušivá.

Pokud tento problém má někdy být vyřešen, zdá se, že je potřeba najít dvě věci: mechanismus, který bude vypadat, že by mohl fungovat, a motivaci pro jaderné vývojáře ho přijmout. Motivaci lze pravděpodobně najít v kombinaci (1) jejich výplatní pásky, protože zákazníci tuto vlastnost stále vyžadují, a (2) vyhlídky na neustávající proud ad hoc patchů, které budou přidávat strukturu do různých koutů jádra bez řešení skutečného problému. To ale stále ponechává otevřený problém, jak najít fungující řešení.

Autor tohoto článku nad touto záležitostí trochu přemýšlel a uvědomil si, že jádro již má hezký mechanismus, jak do uživatelského prostoru předávat strukturovaná data. Téměř na každém současném systému je adresář /dev spravován démonem udev; udev funguje tak, že od jádra přijímá vysoce strukturované zprávy, které popisují příchody a odchody zařízení, změny jejich konfigurace, požadavky na nahrání firmwaru a další. Je to zavedený protokol, který umožňuje sofistikované reakce na události v jádře. Udev a s ním spojený mechanismus „uevent“ si prošel porodními bolestmi, ale kód je nyní stabilní, funkční a používá se téměř univerzálně. Je možná načase, aby převzal další povinnosti.

Uevent rozhraní funguje, protože formát zpráv je jak strukturovaný, tak flexibilní; lze ho rozšířit, když je to potřeba. Generování událostí je téměř zcela zajišťováno automaticky v centrálním kódu pro ovladače; většina autorů ovladačů nemusí udělat vůbec nic, aby se události vygenerovaly a dokonce ani nemusí vědět, že pod kapotou tento mechanismus pracuje. Autoři ovladačů nemusí vytvářet své události; a museli by se hodně snažit, kdyby chtěli v jejich generování zabránit.

Logování jiných typů událostí bude pravděpodobně vyžadovat explicitní podporu v relevantním jaderném kódu; tato část vyžaduje zamyšlení. Vytvořit uevent ručně je poměrně náročná činnost; relevantní kód vypadá nějak takto:

retval = add_uevent_var(env, „ACTION=%s“, action_string);
if (retval)
        goto exit;
retval = add_uevent_var(env, „DEVPATH=%s“, devpath);
if (retval)
        goto exit;
retval = add_uevent_var(env, „SUBSYSTEM=%s“, subsystem);
if (retval)
        goto exit;

Je zjevné, že jakýkoliv pokus vložit takový kód na každé místo, odkud se něco loguje, nedojde nijak daleko. Co je potřeba, je rozumná sada pomocných funkcí. Tyto funkce, aby byly co nejužitečnější, by pravděpodobně byly poměrně těsně spojeny se subsystémy pod sebou. Ovladače pro úložná zařízení by měly funkce pro hlášení chybných bloků, změn zařízení, změn vícecestné konektivity. Síťové ovladače by potřebovaly hlásit události jako ztrátu nosné, nadměrný počet chyb při počítání kontrolních součtů či duplicitní MAC adresy. Veškerý jaderný kód by mohl benefitovat z pomocných funkcí logujících selhání alokace nebo nesplnění nějakých předpokladů [failed assertions]. V každém případě by pomocná funkce standardizovala formát hlášené informace a zároveň umožnila přidat dodatečné informace specifické pro místo, odkud se volá.

Přidání nové sady logujících funkcí by nutně vyžadovalo změny ovladačů tak, aby se dané funkce začaly používat. Zabralo by tedy čas dosáhnout něčeho, co by se alespoň trochu blížilo všeobecnému pokrytí, a ke 100% pokrytí by nedošlo nikdy. Na druhou stranu nemáme ani 100% pokrytí značkami KERN_* označujícími závažnost hlášení. Pokud toto rozhraní bude užitečné, lze si představit, že kódové cesty, které zajímají zákazníky podnikových distribucí, budou pokryty relativně rychle.

Na druhou stranu tento nápad má pravděpodobně několik aspektů, které jsou naprosto chybné; problém se strukturovaným logováním zůstane pravděpodobně nevyřešen ještě nějakou dobu. Avšak nezmizí; naopak, potřeba rozpoznat a automaticky reagovat na události systému jenom vzroste. Jednoho dne někdo přijde s řešením, které bude fungovat a které bude možné přijmout s minimálními potížemi; do té doby máme jenom printk().

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

26.7.2011 07:14 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše dmesg
26.7.2011 23:11 vlastagf | skóre: 11
Rozbalit Rozbalit vše Re: dmesg
Ted nechci flamovat, ale obcas se uprimne divim, ze ten moloch porad funguje. Popravde doufam, ze brzy prijde neco lepsiho nez linux.
Bedňa avatar 27.7.2011 09:05 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: dmesg
Málo čítaš diskusie jadrákov, sú na svoju prácu a svojich kolegov kritické až negatívne odjakživa. Keby týto ľudia vyrábali Ferrari a prečítal si čo o ňom píšu tvorcovia, tak by si ho vživote nekúpil :)
KERNEL ULTRAS video channel >>>
ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.