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 11:00 | Zajímavý software
Na Good Old Games je v rámci aktuálních zimních slev zdarma k dispozici remasterovaná verze klasické point&click adventury Grim Fandango, a to bez DRM a pro mainstreamové OS včetně GNU/Linuxu. Akce trvá do 14. prosince, 15:00 SEČ.
Fluttershy, yay! | Komentářů: 6
včera 07:22 | Pozvánky

Konference InstallFest 2018 proběhne o víkendu 3. a 4. března 2018 v Praze na Karlově náměstí 13. Spuštěno bylo CFP. Přihlásit přednášku nebo workshop lze do 18. ledna 2018.

Ladislav Hagara | Komentářů: 0
12.12. 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

Ladislav Hagara | Komentářů: 6
12.12. 10:22 | Zajímavý článek

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 13
12.12. 07:22 | Komunita

Od 26. do 29. října proběhla v Bochumi European Coreboot Conference 2017 (ECC'17). Na programu této konference vývojářů a uživatelů corebootu, tj. svobodné náhrady proprietárních BIOSů, byla řada zajímavých přednášek. Jejich videozáznamy jsou postupně uvolňovány na YouTube.

Ladislav Hagara | Komentářů: 0
11.12. 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
11.12. 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 2
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 14
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 4
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 979 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Jaderné noviny – 15. 2. 2011: Plán změn v MD (RAID)

    28. 2. 2011 | Jirka Bourek | Jaderné noviny | 3761×

    Aktuální verze jádra: 2.6.38-rc5. Citáty týdne: Linus Torvalds, Ingo Molnár. Plán změn MD. Řízení propustnosti CFS. Bezpečnostní moduly a ioctl().

    Obsah

    Aktuální verze jádra: 2.6.38-rc5

    link

    Současné vývojové jádro je 2.6.38-rc5 vydané 15. února. Objem patchů klesá (trochu) s tím, jak se jádro stabilizuje, takže není mnoho nových vlastností, ale zato se objevily nějaké důležité opravy chyb. Detaily najdete v kompletním changelogu.

    Stabilní aktualizace: aktualizace 2.6.32.29 (115 patchů), 2.6.36.4 (176 patchů) a 2.6.37.1 (272 patchů!) se v současnosti revidují; lze očekávat, že vyjdou 18. února nebo později.

    Citáty týdne: Linus Torvalds, Ingo Molnár

    link

    Takže nikdy nic neoznačujte jako „zastaralé“ [deprecated]. Jestliže se chcete něčeho zbavit, zbavte se toho a opravte místa, kde se to volalo. Neříkejte „někdo jiný by se toho měl zbavit, protože je to zastaralé.“

    A ano, až se příště objeví tahle diskuze, odstraním tu sra*ku. Je to nemoc. Je to jenom stupidní způsob, jak říct „někdo jiný by tenhle problém měl vyřešit.“ Je to způsob, jak se vymlouvat. Je to svinstvo. Byla chyba s tím vůbec někdy začít.

    -- Linus Torvalds

    Hej, jestliže tohle stačí, aby bylo __deprecated odstraněno, začnu tu diskuzi hned zítra!!

    -- Ingo Molnár

    Plán změn MD

    link

    napsal Jonathan Corbet, 16. února 2011

    Uživatele subsystému MD (více disků [multiple disk] či RAID) v Linuxu by mohl zajímat Plán změn MD, který zaslal správce Neil Brown. Poměrně detailně se tam píše o mnoha věcech, které plánuje pro MD; jeho slovy:

    Co konkrétně chci tímto plánem vyřešit, je explicitní stanovení požadovaného řazení a vzájemných závislostí jednotlivých úkolů. Snad se tím zjednoduší jejich řešení ve správném pořadí a snad to bude znamenat, že vyplýtvám méně času říkáním „to je moc těžké, možná bych si místo toho mohl přečíst nějaké e-maily.“

    Naplánováno je mnoho zlepšení. Log špatných bloků by mohl RAID polím umožnit dál fungovat i s vadnými bloky, aniž by bylo nutné okamžitě vyjmout vadný disk. Je zde varianta „výměny za běhu“, která by umožnila vložit nový disk před vyjmutím starého, takže by pole mohlo dál fungovat se všemi disky i v době, kdy se nový synchronizuje. Sledování oblastí, o kterých se ví, že neobsahují užitečná data, by omezilo náklady na synchronizaci. Mnoho navrhovaných vylepšení funkce „reshape“ (změna pole) má za cíl zvýšit robustnost a flexibilitu a umožnit vzít zpět mnoho operací. Zvažováno je i mnoho dalších funkcí; kompletní seznam najdete v Neilově zprávě.

    Řízení propustnosti CFS

    link

    napsal Jonathan Corbet, 16. února 2011

    Plánovač CFS se snaží co nejlépe rozdělit dostupný čas CPU mezi procesy, které o něj soupeří, tak, aby každý z nich CPU využíval přibližně stejně. Plánovač nicméně nebude trvat na rovnoměrném vytížení, když bude k dispozici volný čas CPU; místo toho, aby CPU bylo nečinné, rozdělí plánovač přebývající čas mezi procesy, které ho dokáží využít. Tento přístup dává smysl; nemá cenu omezovat spustitelné procesy, když CPU nikdo jiný stejně nechce.

    Až na to, že přesně tohle někdy správce systému chce udělat. Omezení maximálního podílu na času CPU, který může proces (nebo skupina procesů) zkonzumovat, může být zapotřebí, když procesy patří zákazníkovi, který si zaplatil jenom za určité množství času CPU, nebo v situacích, kdy je nutné poskytnout striktní izolaci procesů, co se spotřeby zdrojů týče. Plánovač CFS tímto způsobem využívání CPU omezit neumí, ale tuto situaci mohou změnit patche řízení propustnosti CFS, které zaslal Paul Turner.

    Patch přidává do mechanismu řídících skupin CPU dva nové soubory: cpu.cfs_period_us definuje periodu, za kterou se reguluje spotřeba času CPU skupinou procesů, zatímco cpu.cfs_quota_us řídí, kolik času CPU může skupina za tuto periodou spotřebovat. Administrátor tedy může omezit skupině dostupný čas CPU a také nastavit granularitu, s jakou bude tento limit vynucován.

    Paulův patch není jediný, který by měl tento problém řešit; sada patchů tvrdých limitů CFS, jejichž autorem je Bharata B Rao, nabízí téměř stejnou funkcionalitu. Implementace je ale odlišná; tento patch se snaží využít kód omezující propustnost z realtime plánovače a limity vynutit s jeho pomocí. Paul vyjádřil své obavy z toho, jaká bude režie za tento kód a jak dobře bude fungovat v situacích, kde je CPU téměř naplno využito. Jeho obavy pravděpodobně vyhrály – od začátku roku 2010 nebyl patch tvrdých limitů znovu zaslán; zdá se tedy, že do hlavní řady se dostanou patche pro řízení propustnosti.

    Bezpečnostní moduly a ioctl()

    link

    napsal Jonathan Corbet, 16. února 2011

    Systém ioctl() volání má z mnoha důvodů špatnou pověst, většina z nich souvisí s faktem, že každý implementovaný příkaz je ve své podstatě nové systémové volání. Není možné mít nějakou efektivní kontrolu nad tím, co se v ioctl() stane a bez prohrabávání se spoustou starého kódu není u mnoha obskurních ovladačů dokonce ani možné zjistit, co se děje. Není tedy překvapením, že kód, který přidává nové ioctl() příkazy, bývá podrobován pečlivému zkoumání. Nedávno se ukázalo, že z ioctl() bychom měli být nervózní ještě z jednoho důvodu – nespolupracuje dobře s bezpečnostními moduly a SELinux s ním několik posledních let pracoval chybně.

    SELinux funguje tak, že specifické pokusy o přístup porovnává s oprávněními, které má volající proces. Pro systémová volání jako je write() je tento typ přístupu zjevný – proces se pokouší do objektu zapisovat. U ioctl() nejsou věci tak jasné. V minulosti se SELinux pokoušel pracovat s ioctl() voláními tak, že se podívá na specifický přístup a pokusí se zjistit, co se proces ve skutečnosti pokouší udělat. Například příkaz FIBMAP (který načte mapu umístění bloků souboru) bude povolen, pokud má volající proces právo číst atributy souboru.

    Tento přístup má několik problémů počínaje tím, že počet možných ioctl() příkazů je obrovský. I když se nebudeme zabývat obskurními příkazy, které implementuje jediný ovladač, snažit se je vyjmenovat všechny a zjistit, co vlastně dělají, to je cesta k šílenství. A je to horší v tom, že zamýšlené chování daného příkazu ještě nemusí souhlasit s tím, co ve skutečnosti v reakci na daný příkaz udělá specifický ovladač. Jediný způsob, jak zjistit, co udělá ioctl() příkaz, je vypátrat, který ovladač volání vyřizuje a jak. Vytvořit tuto funkcionalitu není úkol pro příčetné; udržovat ji by nebyl úkol pro nikoho, kdo chce příčetný zůstat. Vývojáři bezpečnostního modulu se tedy rozhlíželi po lepším způsobu.

    Že jeden našli, si mysleli, když si někdo uvědomil, že kódy příkazů používané implementacemi ioctl(), nejsou náhodná čísla. Ve skutečnosti jsou to pečlivě složené 32 bitové hodnoty, které zahrnují i 8 bitové pole „typ“ (které přibližně identifikuje ovladač, který příkaz implementuje), číslo příkazu specifické pro ovladač, pár bitů čtení/zápis a pole pro velikost. Použít bity čtení/zápis vypadalo jako skvělý způsob, jak zjistit, jaký přístup ioctl() volání potřebuje, aniž by bylo potřeba příkazu porozumět. Do 2.6.27 tedy byl začleněn patch SELinuxu, který vytrhl kód rozpoznávání příkazů a jednoduše použil bity čtení/zápis v kódu příkazu, podle kterých určil, jestli má být specifické volání povoleno nebo ne.

    Tato změna zůstala více než dva roky, dokud si Eric Paris nevšiml, že ve skutečnosti nedává smysl. Většina volání ioctl() zahrnuje předání datové struktury do nebo z jádra; tato struktura popisuje operaci, která má být provedena, nebo obsahuje data vracená jádrem – nebo obojí. Pole velikost v kódu příkazu udává velikost této struktury a přístupové bity udávají, jak bude k dané struktuře přistupovat jádro. Tyto dvě informace se v základním kódu ioctl() použijí ke zjištění, jestli volající proces má správná přístupová práva k paměti, na kterou míří předaný ukazatel.

    Jak Eric upozornil, tyto bity neříkají nic o tom, co ioctl() volání udělá s objektem identifikovaným popisovačem souboru, který byl předán jádru. Volání předávající data pouze pro čtení může zformátovat disk, zatímco volání se zapisovatelnými daty se může jenom ptát na informace o hardwaru. Použít tedy bity čtení/zápis k určení, jestli volání má nebo nemá pokračovat, s největší pravděpodobností neposkytne žádné dobré výsledky. Když se to řekne takhle, je tento poznatek zjevný, ale tehdy si toho žádný vývojář pracující na bezpečnosti nevšiml.

    Tenhle kód tedy musí zmizet – v době psaní tohoto článku ale v hlavní řadě jádra změněn nebyl. A to má jednoduchý důvod: nikdo neví, co by ho mělo nahradit – jak bylo řečeno výše, jednoduché vyjmenování příkazů a očekávaného chování také není řešením. Je tedy nutné vymyslet něco jiného a není jasné, co to bude.

    Stephen Smalley poukázal na jeden přístup, jehož návrh byl zaslán již roku 2005. Tento patch vyžaduje, aby ovladače (a další kód implementující ioctl()) poskytly zvláštní tabulku spojenou s každým kódem příkazu, ve které by byly uložena práva potřebná k vykonání příkazu. V té době se objevily předvídatelné námitky: změnit každý ovladač v systému by bylo problematické, v implementacích ioctl() je bordel už teď, tabulky by nikdo neudržoval při změnách ovladače atd. Návrh byl tedy opuštěn; jeho návrat pravděpodobně nebude u nikoho populární, ale pravděpodobně není jiná možnost, jak opravdu sledovat, co příkaz ioctl() dělá. Tyto vědomosti má pouze kód, který ho implementuje, takže pokud je chceme využívat jinde, musíme je nějak exportovat.

    Samozřejmě je tu alternativa, kde prohlásíme, že (1) s ioctl() jsou problémy a (2) s bezpečnostními moduly jsou problémy, takže bude možná lepší se prostě vzdát a doufat že ostatní kontroly přístupu a další kontroly, které mohou být zabudovány do samotného ovladače, budou dostatečné. Což je v podstatě řešení, které máme nyní.

           

    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ář

    28.2.2011 07:25 kip | skóre: 8 | blog: kip | Nový Jičín
    Rozbalit Rozbalit vše Re: Jaderné noviny – 15. 2. 2011: Plán změn v MD (RAID)
    Ve čtvrtém odstavci od konce je ips.
    28.2.2011 16:26 Petr Ježek | skóre: 10
    Rozbalit Rozbalit vše Re: Jaderné noviny – 15. 2. 2011: Plán změn v MD (RAID)
    Je to chyba kernelu? Že by překlep změnil informaci v dezinformaci?
    Archlinux for your comps, faster running guaranted!
    28.2.2011 20:37 Laco
    Rozbalit Rozbalit vše Re: Jaderné noviny – 15. 2. 2011: Plán změn v MD (RAID)
    cely linux je deprecated :)
    28.2.2011 22:25 Jiří J. | skóre: 34 | blog: Poutník | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 15. 2. 2011: Plán změn v MD (RAID)

    Osobně bych rád v MD viděl něco jako "syncni i přestože část raidu bude poškozena". Nedávno jsem narazil na případ RAID5, kdy při synchronizaci nového disku (předchozí zkolaboval) při nějakých 95% nahodil jiný disk read error. Pravděpodobně se jednalo jen o celkem malou část a přeskočení by sice způsobilo několikabajtovou ztrátu dat, ale pořád lepší, než současná situace - sync se zastaví a RAID má najednou 2 "failed" disky, takže je víceméně odepsaný.

    Nakonec to vyřešil jen mdadm -C --assume-clean a specifikace disků ve správném pořadí.

    Je mi jasné, že majitel tomu mohl snadno zabránit nákupem disků různých výrobců, pravidelnými měsíčními kontrolami nebo třeba RAIDem 6, ale i MD subsystém tu má co zlepšovat.

    Víra je firma si myslela, že něco je pravdivé. LMAO -- “zlehčovat mého osla”
    1.3.2011 10:46 ZiGi
    Rozbalit Rozbalit vše Re: Jaderné noviny – 15. 2. 2011: Plán změn v MD (RAID)
    Ja by som zase rad videl blokovu cache na SSD, Myslim, ze to by posunulo MD do uplne inej ligy. Predstava, ze by som mohol mat 10TB pole, ktore by bolo aj lacne a aj rychle je neuveritelne lakava.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.