Jaderné noviny - 16. 4. 2008

5. 6. 2008 | Jirka Bourek | Jaderné noviny | 3551×

Aktuální verze jádra: 2.6.25-rc9. Citáty týdne: Al Viro, Andrew Morton, Arjan van de Ven. Atheros přijal vývojáře ath5k. TOMOYO Linux a bezpečnost založená na pathname. e1000 vs. e1000e. OMFS a hodnota obskurních souborových systémů. Dělení půlením rozděluje uživatele a vývojáře.

Obsah

• Aktuální verze jádra: 2.6.25-rc9
• Citáty týdne: Al Viro, Andrew Morton, Arjan van de Ven
• Atheros přijal vývojáře ath5k
• TOMOYO Linux a bezpečnost založená na pathname
• e1000 vs. e1000e
• OMFS a hodnota obskurních souborových systémů
• Dělení půlením rozděluje uživatele a vývojáře

Aktuální verze jádra: 2.6.25-rc9

Aktuální vývojové jádro je 2.6.25-rc9, vydané 11. dubna. Stabilní verze 2.6.25 je na spadnutí a pravděpodobně bude venku už v době, kdy budete tohle číst; Jonathan Corbet podezřívá Linuse, že s vydáním jádra jen čeká, dokud nevyjde LWN.

Současná verze -mm stromu je 2.6.25-rc8-mm2. Nedávné změny v -mm zahrnují novou infrastrukturu suspend a hibernace, další dlouhou sérii IDE patchů, nějakou práci na bezdrátovém USB a podporu pro značky v jádře pro proprietární moduly.

Citáty týdne: Al Viro, Andrew Morton, Arjan van de Ven

Potřebujeme v l-k vyšší odstup signál-šum. Potřebujeme, aby se lidi dívali do subsystémových stromů, když rostou a smrdí, když jsou objeveny špatné věci - když nic jiného, i oznámení problémů designu do l-k pomůže. Potřebujeme, aby správci stromů pochopili, že revize - včetně těch, které nepocházejí z komunity - jsou nutné (potřeba testovat je většinou chápána lépe - doufám).

-- Al Viro (přečtěte si to celé).

To všechno zní dobře a očekávám, že nesouhlasit bude málokdo. Nicméně, pokud se to má provést, neudělá se to samo automaticky. Budeme se k tomu muset donutit a způsob, jak to provést, jsou změny v procesu. Ty změny, které jsou haněny názvem "byrokracie".

Kroky, které je potřeba udělat, jsou:

a) shodnout se, že máme problém
b) shodnout se, že je potřeba ho řešit
c) identifikovat každodenní postupy, které ho pomohou řešit (jak jsi to udělal ty)
d) identifikovat procesní změny, které nás přinutí použít tyto postupy
e) implementovat tyto procesní změny

Hluboce jsem selhal při snaze dostat nás za krok a).

-- Andrew Morton

Za sebe nesouhlasím s tím, že máme problém.

-- Arjan van de Ven

Atheros přijal vývojáře ath5k

Když jaderní vývojáři mluví o problematických výrobcích hardwaru, Atheros se často objevuje na čelním místě jejich seznamu. Proto je oznámení, které poslal Luis Rodriguez, vývojář reverzním inženýrstvím vyvinutého ovladače ath5k, zajímavé: Píšu, abych vás informoval, že jsem se rozhodl přijmout u Atherosu práci na plný úvazek jako softwarový inženýr, abych jim pomohl v jejich cíli podporovat každé Atheros zařízení v upstreamu v Linuxu. Co z toho vzejde, to se uvidí, ale pokud to opravdu signalizuje změnu nálad v Atherosu, je to velmi vítaný vývoj.

Celý článek na LWN.

TOMOYO Linux a bezpečnost založená na pathname

Zamířit po cestě, když je vidět, jaký nepříjemný osud postihl ty, kdo šli před vámi, vyžaduje určitý druh odvahy. Proto by se dalo očekávat, že osud AppArmoru odradí ostatní od následování podobné cesty. Vývojáři TOMOYO Linuxu se ale nedají jen tak odradit. Přestože mají bezpečnostní subsystém, které s AppArmorem sdílí mnoho rysů, tito vývojáři se snaží prosadit se a protlačit svůj kód do hlavní řady jádra.

Vzpomeňme, že AppArmor je bezpečnostní modul pro Linux, který pro rozhodnutí o bezpečnosti používá jména s cestou [pathname]. Takže je zcela představitelné, že na jeden soubor se mohou aplikovat dvě různá bezpečnostní pravidla, pokud je k tomuto souboru přistupováno pokaždé pod jiným jménem. Díky tomuto přístupu je AppArmor spravovatelný jednodušeji než SELinux, ale během revizního procesu to AppArmoru z několika důvodů způsobilo velké problémy:

• Objevil se silný odpor proti přidávání jakýchkoliv nových bezpečnostních modulů, takže na povrch vyplavaly návrhy odstranit LSM framework úplně.
• Někteří bezpečnostní vývojáři považují na cestách založený mechanismus za nebezpečný od základu. Konkrétně vývojáři SELinuxu byli velmi silně proti bezpečnosti založené na cestách. Podle těchto vývojářů by se bezpečnostní politika měla aplikovat přímo na objekty (nebo na popisky [label] připojené přímo k objektům), a ne na jména s objekty spojená.
• Současné háčky [hooks] bezpečnostních modulů v Linuxu nebyly navrženy s ohledem na bezpečnostní řešení založená na cestách, takže nízkoúrovňovým háčkům souborových operací neposkytují dostatečné informace. Proto AppArmor musel rekonstruovat cesty uvnitř vlastních bezpečnostních háčků. Dalo by se říci, že metoda zvolená pro tuto rekonstrukci nebyla všeobecně obdivována.

Jestliže vývojáři TOMOYO Linuxu myslí začlenění svého kódu do hlavní řady vážně, budou muset na tyto námitky reagovat.

Jak se tak stává, první dvě překážky v podstatě zmizely. Neodbytnost Caseyho Schauflera nakonec vyústila v začlenění bezpečnostního modulu SMACK do 2.6.25; kromě SELinuxu je to jediný bezpečnostní modul, který se dostal do jádra. Nyní, když SMACK vyšlapal cestičku, řeči o odstranění LSM frameworku (které Linus každopádně jednoznačně vetoval) přestaly a další bezpečnostní moduly by měly mít začlenění jednodušší.

Linus také prohlásil, že na cestách založené bezpečnostní moduly jsou pro začlenění jádra zcela akceptovatelné. Takže i když jsou někteří vývojáři k tomuto přístupu velmi skeptičtí, jejich skepticismus sám o sobě nemůže být použit jako důvod držet tyto moduly mimo. Přístupy založené na cestách se zdají být pro mnoho aplikací "dostatečně bezpečné" a využití tohoto přístupu má některé výhody.

Všechno výše uvedené bude sporné, pokud vývojáři TOMOYO Linuxu nebudou schopni implementovat řízení přístupu založené na cestách takovým způsobem, který by prošel prohlídkou. Nedávný TOMOYO Linux patch použil jiný přístup k tomuto problému: vzhledem k tomu, že LSM háčky neposkytují potřebné informace, vývojáři přidali novou sadu háčků mimo LSM, kterou TOMOYO Linux používá. A když už byli v tom, přidali nové háčky do všech prosazovacích míst [enforcement points]. Přinejmenším lze prohlásit, že to nebylo populární rozhodnutí. Nápadem, který stál za LSM, bylo mít jednu sadu háčků pro všechny bezpečnostní moduly; pokud teď každý modul přidá vlastní sadu háčků, tento účel bude k ničemu a jádro se změní na velký zmatek bezpečnostních háčků. Duplikace LSM frameworku není cesta, kterou by se bezpečnostní modul mohl dostat do jádra.

Vývojáři TOMOYO Linuxu budou muset na cestách založené zabezpečení implementovat jiným způsobem. Nejvíce se nabízí modifikace existujících háčků, aby poskytovaly potřebné informace (pointer na strukturu vfsmount). Problém je v tom, že v místě, kde jsou volány LSM háčky, není tato struktura k dispozici; používá se jenom na vyšších úrovních v kódu virtuálního souborového systému. Takže buď bude potřeba změnit některé vnitřní funkce VFS (aby se jim dal předat ukazatel na vfsmount), nebo bude potřeba umístit novou sadu háčků na takovou úroveň, kde je tento ukazatel k dispozici. Zdá se, že v nové verzi patche bude použit druhý přístup - přidání nových háčků do kódu jmenných prostorů [namespace code].

Jak se budou vývojáři TOMOYO Linuxu propracovávat tímto problémem, pravděpodobně budou pečlivě pozorováni (poněkud zmenšenou) skupinou okolo AppArmor. Zdá se, že vzniká obnovený zájem AppArmor začlenit, takže o něm pravděpodobně v blízké budoucnosti uslyšíme. To bude ještě pravděpodobnější, pokud TOMOYO Linux bude schopen vyřešit problém s cestami způsobem, který přežije revize a dostane se do jádra.

e1000 vs. e1000e

Ingo Molnára nedávno potrápil problém, který by nějakým způsobem po 2.6.26 mohl postihnout větší počet uživatelů Linuxu. Linux má v současnosti dva ovladače pro síťové karty e1000 od Intelu; jeden je nazýván "e1000", druhý "e1000e". Ten první je starší a podporuje všechny staré e1000 karty pro PCI. Dalo by se říci, že je relativně málo vývojářů, kteří by byli ochotni se postavit za kvalitu kódu tohoto ovladače, ale funguje a má mnoho uživatelů.

Ovladač e1000e podporuje karty pro PCI expres. Je novější a nahlíží se na něj tak, že je lépe napsaný a lépe udržovaný. Záměrem je, aby byl všechen nový hardware a obzvlášť všechen hardware pro PCI expres podporován tímto ovladačem. Problém je v tom, že do staršího ovladače e1000 bylo přidáno několik PCI expres čipových sad předtím, než byla tato politika ustanovena - a protože nový ovladače tyto čipové sady podporuje také, máme dva ovladače (se dvěma zcela odlišnými kusy kódu), které podporují stejný hardware. Správci e1000 by chtěli tuto duplikaci ukončit a uložit ovladač e1000 do režimu stabilní údržby.

Za tím účelem bylo začátkem tohoto měsíce oznámeno, že od 2.6.26 budou PCI ID odpovídající PCI expres zařízením odstraněna z ovladače e1000 a uživatelé takto postiženého hardware budou muset použít e1000e. Vývojáři e1000 původně zkusili tento krok podniknout už v 2.6.25, ale udělali při tom zásadní faux pas: rozbili Linusův stroj a tahle změna byla odstraněna dřív, než vyšlo 2.6.25-rc1. Místo toho máme nyní oznámení, že změna přijde v dalším cyklu (kdy se předpokládá, že problémy ovladače e1000e budou odstraněny) a že byly přidány nějaké konfigurační triky, takže ovladač e1000 nebude obsluhovat PCI expres zařízení, jestliže byl přeložen ovladač e1000e.

Ingův problém spočívá v tom, že zabudoval ovladač e1000 do jádra, ale e1000e přeložený jako modul se nezavedl. Tahle kombinace vede k tomu, že síťová karta nefunguje vůbec, protože zabudovaný ovladač ji neobslouží. Ingo, který byl poněkud rozladěn tím, že strávil hodinu hledáním problému, prohlásil, že je to regrese a musí být opravena. Správci ovladače e1000 tomu oponovali, ale Linus, který se také spálil, souhlasí. Takže přestože přechod pravděpodobně bude pokračovat tak, jak bylo plánováno, 2.6.25 bude nejspíš obsahovat změnu v konfiguraci určenou k tomu, aby ostatní nespadli do podobné pasti.

OMFS a hodnota obskurních souborových systémů

Autor článku nikdy nefušoval do vývoje souborových systémů, nicméně má podezření, že v životě každého nového vývojáře souborových systémů je jeden moment, kdy zadrží dech: když se mu v poštovní schránce objeví hodnocení od Christopha Hellwiga. Jeho revize, i když ne vždy to bývá hezké čtení, obvykle uhodí hřebík na hlavičku co se týče implementace souborových systémů - a problémy v nových souborových systémech jsou běžné. Christophovo potvrzovací razítko je při přijímání nového souborového systému skoro požadováno, takže pokud se počáteční verze souborového systému setká s hodnocením, které říká "vypadá to dobře", dá se předpokládat, že cesta do hlavní řady bude vcelku přímočará.

Příběh o OMFS nicméně ukazuje, že tento předpoklad neplatí vždy. Hodnotitelé byli schopni najít jenom malinké detaily k opravě, ale přesto existuje opozice proti jeho začlenění, obzvláště od Andrewa Mortona. Námitkou je, že tento souborový systém - k nalezení v zařízeních, jako je hudební přehrávač Rio Karma a stroje ReplayTV - má malou uživatelskou základnu. Vývojář OMFS Bob Copeland ve své první zprávě tvrdil, že ho v daném čase používá méně než dvacet lidí. Nová zařízení s tímto souborovým systémem se nevyrábí, takže šance, že by se uživatelská základna významně rozšířila, jsou malé.

Andrewova námitka spočívá v tom, že přidání dalšího kódu vytváří nové břemeno údržby pro jaderné vývojáře. Kdykoliv se rozhraní VFS změní, všechny souborové systémy musí být opraveny, aby s tímto novým API fungovaly. Kvůli tomu přidání souborového systému přináší náklady, které, jak říká, by měly být převáženy ziskem, který nový systém přináší. V případě obskurního souborového systému s malou a (pravděpodobně) zmenšující se uživatelskou základnou, říká Andrew, není jasné, jestli jsou zisky dostatečné. Pokládá otázku:

Jen pro zamyšlení: měli bychom začlenit malý a dobře napsaný ovladač, který má nula uživatelů?

Andrew by raději viděl, kdyby se OMFS změnil v souborový systém v uživatelském prostoru a používal FUSE. Chris Mason má taktéž obavy:

I když se zdá, že OMFS dobře využívá obecná rozhraní, stále nám pro každou změnu vzniká břemeno testování. Někdo ho musí vyzkoušet, hlásit problémy a nechat je opravit. Vzhledem k tomu, že nikdo z lidí, kteří dělají změny, pravděpodobně nebude mít OMFS kde otestovat, všechna tato zátěž padne na Boba, jeho uživatele a každého, kdo se pokusí ten modul zkompilovat (Andrew).

Ti, kteří OMFS podporují, poznamenávají, že kód je napsán dobře a může sloužit jako příklad pro další autory souborových systémů. Také říkají, že kód s malou uživatelskou základnou je začleňován často - že v některých oblastech vývojáři řekli, že chtějí veškerý kód bez ohledu na to, kolik lidí ho používá. Provozovat OMFS přes FUSE by pro uživatele znamenalo obtížnější nastavení a také by to bylo méně efektivní. Christoph říká:

Přesunutí jednoduchého na blocích založeného souborového systému by znamenalo, že bude komplikovanější, méně efektivní kvůli dodatečnému přepínání kontextu a obtížněji použitelný, protože budou potřeba dodatečné uživatelské balíky a nastavení fuse.

Psaní na blocích založených souborových systémů jsme v jádře zjednodušili proto, aby bylo snadné přidávat podporu pro souborové systémy jako je tenhle.

V tomhle případě to vypadá, že Andrew ustoupí a nechá příští verzi OMFS patchů vstoupit do -mm. Odtud, pokud vše půjde dobře, by mohl skočit do hlavní řady možná už v 2.6.27. Nicméně Andrewovi se tenhle výsledek zjevně nelíbí a je dost možné, že v budoucnosti opět položí otázku: je "dobře napsané" opravdu dostatečné, aby to ospravedlnilo začleňování nových souborových systémů do jádra?

Dělení půlením rozděluje uživatele a vývojáře

V posledních několika letech jsme viděli obnovený tlak jaderné komunity na vyhýbání se regresím. Když se o patchi zjistí, že rozbil něco, co fungovalo, musí být začleněna oprava, nebo bude patch z jádra odstraněn. To je jednoduchá a logická myšlenka, ale má jeden malý problém: když jaderná série obsahuje přes 12000 sad změn (jako například 2.6.25), jak se dá najít patch, který obsahuje problém? Občas je to zjevné, ale u jiných problémů jsou doslova tisícovky patchů, které by mohly být zdrojem regrese. Přehrabování se ve všech těchto patchích při hledání chyby může být jako hledat jehlu v kupce sena.

Jeden z mnoha hezkých nástrojů, které nabízí systém správy zdrojového kódu git, je "dělení půlením" [bisect]. Tato vlastnost umožňuje uživateli provést binární hledání v rámci rozsahu patchů, až je nalezen ten, který obsahuje chybu. Jediné, co je potřeba udělat, je specifikovat nejnovější jádro, o kterém víme, že funguje (řekněme 2.6.24) a nejstarší jádro, které nefunguje (například 2.6.25-rc9), a bisect vytvoří verzi jádra na půl cesty mezi těmito dvěma. Nalezení tohoto středního bodu není jednoduché, protože v gitu není proud patchů přímočarý, ale je to ten druh úkolu, kvůli kterým máme počítače. Jakmile je vygenerováno jádro ve zvoleném středním bodě, osoba hledající chybu ho může přeložit a otestovat a pak říct gitu, jestli se v něm chyba projevuje. Pak je vygenerováno jádro v novém středním bodě a proces pokračuje. Pomocí dělení půlením může být problematický patch nalezen po maximálně tuctu cyklů kompilace-boot-test.

Bisect není perfektní nástroj. Nejsou-li zasílatelé patchů opatrní, bisect může vygenerovat rozbité jádro, když rozdělí sérii patchů. Patch, který způsobuje, že se chyba projeví, nemusí být ten, který ji tam zavedl. V nejhorším případě může vývojář začlenit dlouhou sérii patchů zakončenou jednou krátkou změnou, která povolí předtím přidaný kód. V takovém případě bisect najde ten závěrečný patch, což bude téměř neužitečné. Jestliže osoba, která hlásí chybu, používá jádro od distributora, může být obtížné dostat toto jádro ve formě, kterou lze přizpůsobit pro proces dělení půlením. Dělení půlením může vyžadovat neakceptovatelný downtime na jediném (produkčním) systému, který je chybou postižen. A samozřejmě proces vygenerování, překladu, bootování a testování tuctu jader není něco, co by se stihlo během přestávky na kafe. Vyžaduje to určité odhodlání na straně testera a docela dost času.

Všechny body uvedené výše naznačují, že požadovat dělení půlením od uživatele, který hlásí chybu, by mělo být až to poslední, k čemu by se vývojáři měli uchýlit. V tomto kontextu se hodí podívat se na příběh nedávného hlášení o chybě, který naznačuje, že minimálně někteří pozorovatelé si myslí, že vývojáři jádra na tomto nástroji závisí poněkud více, než je zdrávo. 9. dubna Mark Lord ohlásil regresi v síťovém stacku; po několika tipech síťoví vývojáři navrhli, aby byl na problém použit bisect.

Mark odpověděl, že nemá čas na to, aby procházel kompletním dělením půlením a že by mnohem raději dostal seznam commitů, které by mohly být na vině. Tento seznam ale nepřišel; ani jeden vývojář neměl tušení, kde by problém mohl být. A jak se ukázalo, vývojář, který chybu zavedl, žije v časovém pásmu, které způsobilo, že diskuzi nesledoval. Mark odpověděl silnými slovy:

Před lety Linus tvrdil, že je proti debuggeru v jádře hlavně proto, že preferuje, abychom o problémech přemýšleli místo toho, abychom hledali a opravovali symptomy. Tahle 100% závislost na git-bisect je ještě horší. Kvůli ní lidé do kódu rozhazují regrese nalevo a napravo, protože ví, že všechno testování mohou přehodit na ty chudáky, jejichž stroje přestanou fungovat.

Andrew Morton se také obává, že vývojáři se k dělení půlením uchylují příliš rychle místo toho, aby pracovali s uživateli tak, jak se to dělalo dřív. Buď to, nebo vývojáři hlášení od začátku ignorují.

Jiní vývojáři na to samozřejmě zareagovali. Jaderní vývojáři často nejsou v situaci, aby mohli hlášenou chybu reprodukovat; může záviset na specifikách uživatelova hardwaru nebo zátěži. Proto závisejí na tom, že uživatel zkouší opravy a informuje je, jestli změna problém opravila. Tady je pohled Davida Millera na to, jak to dříve fungovalo:

Ve skutečnosti se to Andrewovo takzvané "tam a zpátky s ohlašovatelem chyby" skládalo z žádání uživatele, aby vyzkoušel tenhle nebo tamten patch, z nichž většina odebírala podezřívané změny. Což, jaké překvapení, znamená, že jsme strávili spoustu času ručním dělením půlením.

Tohle jsme teď schopni zautomatizovat a na tom není nic špatného.

Další reakce, kterou bylo slyšet, byla, že situace je teď v mnohém odlišná - je mnohem více uživatelů, mnohem více kódu a mnohem víc problémů, které je potřeba řešit. Starý "tam a zpátky" režim byl lépe přizpůsoben malým komunitám vývojářů a uživatelů; v současném světě musí být věci dělány jinak. Opět David Miller:

Co lidé nechápou, je, že tohle je situace, ve které platí "princip koncového uzlu". Když máme omezený zdroj (zde vývojáře), nenaložíme jim na záda většinu zátěže. Místo toho věci naložíme na ten zdroj, kterého máme spoustu, na koncové uzly (zde uživatele), aby se situace škálovala.

Existuje další aspekt problému, o kterém se mluví méně často: vývojáři musí stanovit priority hlášení o chybě a rozhodnout se, na kterém pracovat. Na rozdíl od jiných projektů jádro nemá nikoho, kdo by rozhodoval o proritách chyb, takže bez přítomnosti naštvaného platícího zákazníka se většina vývojářů rozhoduje sama o tom, který problém se pokusí vyřešit. Nemělo by být překvapující, že problémy s nejúplnějšími informacemi jsou ty, na které někdo zareaguje nejdřív.

Hlášení o chybě, jež obsahuje dělení půlením, které ukazuje na specifický commit, je hlášení o chybě s velmi dobrými informacemi - většinou je snadné ho vyřešit. Jako příklad můžeme opět použít hlášení od Marka Lorda; ten si nakonec udělal čas (zjevně pět hodin) na dělení půlením a ohlášení výsledku; chyba byla nalezena a opravena téměř okamžitě poté - přestože zodpovědný vývojář stále spal na druhé straně planety.

Ještě méně se mluví o tom, že dost problémů se vyskytuje jen v jednom exempláři. Někde na světě je jeden uživatel, který kvůli vysoce neobvyklé kombinaci hardwaru a softwaru zažívá problém, jenž nepostihuje (téměř) nikoho jiného. Okrajový hardware, patche s původem mimo strom a přetaktování problém jenom zhoršují. Shrnutí kernel oopsů Arjana van de Vena je v tomto ohledu ilustrativní; statistika jader 2.6.25-rc ukazuje, že půl tuctu problémů patří k více než polovině hlášení, zatímco drtivá většina oopsů se objevuje jenom jednou.

Jaderní vývojáři se naučili, že tenhle druh problémů zmizí sám od sebe; postižený uživatel najde způsob, jak problém obejít (nebo to vzdá) a nikdo jiný si nestěžuje. Dalo by se argumentovat, že snaha nalézt takový problém nepředstavuje dobré využití času jaderného vývojáře. Obtížné je zjistit, která hlášení patří do této skupiny. Jedním z jednoduchých způsobů je počkat, až hlášení od dalších uživatelů problém potvrdí - nebo až dostatečně odhodlaný uživatel provede dělení půlením a poskytne ID commitu. V tomto ohledu dělení půlením funguje jako mechanismus určování priorit, který od uživatelů vyžaduje, aby udělali nějakou práci, která ukáže, že problém je skutečný.

Takže vývojáři mají dost důvodů požadovat dělení půlením od uživatelů. Můžeme se tedy obávat, že mnoho uživatelů přestane hlásit chyby. Pokud jediná odezva, kterou budou očekávat, bude požadavek na dělení půlením (kterému nemusí být schopni vyhovět), nemusí mít důvod vůbec chyby hlásit. Méně hlášení o chybě není cesta směrem k lepším vydáním jádra. Takže i když je užitečný, bisect bude muset zůstat nástrojem, ke kterému se ve většině případů uchylujeme nakonec. Dobrá zpráva je, že se zdá, že komunita vývojářů to chápe; dělení půlením zůstává jenom jedním z mnoha nástrojů, které máme pro izolování a řešení problémů.

Ne tak dobrá zpráva, jak podotkli Al Viro a James Morris, je to, že skutečný problém spočívá v revizích kódu, protože by se především nemělo tolik chyb dělat. To není věc, kterou by bylo možné vyřešit pomocí dělení půlením.

       

Komentáře

[Filip Jirsák]

V části TOMOYO Linux: pravděpodobně budou pečlivě pozorování –> pozorováni.

[Luboš Doležel (Doli)]

Opraveno, díky.

[geebranz]

Users and developers

cryotherapychattanoogatn.com