Jaderné noviny – 17. 3. 2011: Licenční problémy s OpenSSL

28. 3. 2011 | Jirka Bourek | Jaderné noviny | 4253×

Aktuální verze jádra: 2.6.38. Citáty týdne: Linus Torvalds, Steven Rostedt, Hugh Dickins. Demonstrace skupinového plánování. Začleňovací okno 2.6.39, část první. API pro senzory. PostgreSQL, OpenSSL a GPL.

Obsah

• Aktuální verze jádra: 2.6.38
• Citáty týdne: Linus Torvalds, Steven Rostedt, Hugh Dickins
• Demonstrace skupinového plánování
• Začleňovací okno 2.6.39, část první
• API pro senzory
• PostgreSQL, OpenSSL a GPL

Aktuální verze jádra: 2.6.38

Jádro 2.6.38 je venku vydáno bylo 14. března. Když se na něj podíváme zeširoka, tj. na všechny změny od 2.6.37, mým osobním favoritem zůstávají změny ve vyhledávání jmen ve VFS. Způsobily nějaké problémy a Al dal jasně najevo, že chce další pročištění, ale dohromady bych řekl, že byly relativně bezproblémové. Mezi další významné změny v 2.6.38 patří podpora transparentních velkých stránek [transparent hugepages], skupinové plánování podle sezení, mnoho zlepšení Btrfs a další. Jako vždy excelentní stránka na KernelNewbies.org obsahuje všechny detaily.

Stabilní aktualizace: 14. března vyšly aktualizace 2.6.37.4 a 2.6.32.33.

Citáty týdne: Linus Torvalds, Steven Rostedt, Hugh Dickins

Myslím si, že tohle je opravdu zásadní záležitost: každý, kdo z něčeho, z čeho se lze zotavit, udělá tvrdou chybu, je totální pitomec.

-- Linus Torvalds

Zlaté pravidlo č. 12: Když komentáře neodpovídají kódu, pravděpodobně je špatně obojí.

-- Steven Rostedt

Jenže jestli máš pravdu, pak mám obavu, že tento patch bude prvním z toho, co se stane pramínkem, proudem a následně povodní patchů, kterými budou lidé zarovnávat a přeorganizovávat struktury tak, aby nejčastěji využívaná pole byla na začátku řádky v cache a dalo se k nim přistoupit o okamžik rychleji.

Grr a touhle poznámkou tu povodeň ještě přivolávám. Někdo prosím vás diskreditujte Georgeovy argumenty.

-- Hugh Dickins

Demonstrace skupinového plánování

napsal Jonathan Corbet, 16. března 2011

O patchi skupinového plánování podle sezení a jeho zařazení do jádra 2.6.38 se diskutovalo hodně, ale je těžké vidět ho v akci, když neděláte překlad jádra v dvaceti procesech. Nedávno se nicméně autorovi tohoto článku podařilo takovou demonstraci vytvořit díky neočekávaným výsledkům upgrade Rawhide. Způsob, jakým plánovač pracuje, je možné vidět z toho, co v danou chvíli bylo možné zachytit.

Uživatelé Rawhide ví, že za neškodně vypadajícím příkazem yum upgrade se často skrývají překvapení. V tomto případě něco během aktualizace (pravděpodobně spojené s fonty) způsobilo, že se všechny grafické procesy v systému rozhodly, že je čas začít pracovat na něčem náročném. Výsledek je vidět ve výstupu příkazu top:

Heuristika řadící podle sezení většinu procesů vložila do jediné řídící skupiny, takže většinu času soupeřily o čas CPU mezi sebou. Tyto procesy ve chvíli zachycené na obrázku mají k dispozici přibližně 5,3 % z dostupného času CPU. Dva procesy, které v této řídící skupině nebyly, soupeřily o druhé jádro v systému; každý dostal 46 %. Celková zátěž systému byla téměř 22 a desktop vůbec nereagoval. Bylo ale možné se do systému přihlásit po síti a situaci prozkoumat, aniž by byla zátěž nějak znát.

Izolace je jednou z nejhezčích vlastností skupinového plánování; i když se velký počet procesů totálně zblázní, jejich schopnost ničit život ostatním procesům na daném stroji je omezená. To samo o sobě ospravedlňuje náklady na tuto vlastnost.

Začleňovací okno 2.6.39, část první

napsal Jonathan Corbet, 16. března 2011

Linus vydal jádro 2.6.38 14. března a následující den začal začleňovat patche do vývojového cyklu 2.6.39. V době psaní tohoto článku bylo do hlavní řady začleněno něco přes 1000 patchů. Proces začleňování zjevně teprve začal, ale přidáno bylo již několik zajímavých vlastností. Mezi ty viditelné pro uživatele patří:

• Systémová volání pro otevření podle manipulátoru [open by handle] byla začleněna. Konečná podoba API je:

  int name_to_handle_at(int dfd, const char *name, struct file_handle *handle,
                        int *mnt_id, int flag);
  int open_by_handle_at(int dirfd, struct file_handle *handle, int flags);

  Tuto funkcionalitu mají používat souborové servery v uživatelském prostoru, které pomocí manipulátorů mohou efektivněji sledovat soubory.

• Systémové volání open() má nový příznak O_PATH. Cesta k souboru otevřenému s tímto příznakem byla ověřena jádrem a soubor existuje, ale nelze s ním dělat nic moc jiného. Systémová volání, která pracují přímo s popisovačem souboru (např. close() nebo dup()), budou fungovat; popisovače bude také možné předat jinému procesu přes Unix sockety, které používají datagramy SCM_RIGHTS. Důvodem pro existenci popisovačů O_PATH je možnost použít je jako popisovač pro adresáře v různých voláních *at().

• Úlohy v třídě SCHED_IDLE se nyní mohou povýšit na SCHED_BATCH či SCHED_OTHER, pokud jim to umožní jejich „nice“ rlimit.

• Přibylo systémové volání, které umožní nastavit POSIX hodiny:

  int clock_adjtime(clock_id which_clock, struct timex *time);

  Možnosti, jak upravit čas, jsou stejné jako u adjtimex(), ale specifické POSIX hodiny nemusí všechny operace podporovat.

• Byly přidány POSIXové hodiny CLOCK_BOOTTIME

• Nový atribut SMACK64MMAP řídí, kdy mohou být běžícími programy mapovány specifické knihovny.

Mezi změny viditelné pro jaderné vývojáře patří:

• Nový příznak přerušení (IRQF_FORCE_RESUME), který vynutí povolení přerušení během probouzení bez ohledu na to, jestli bylo během uspávání vypnuto.

• Jádro nyní může vynutit běh (téměř) všech obsluh přerušení ve vláknech; tato možnost se řídí parametrem threadirqs na příkazové řádce jádra. Je to užitečné pro ladění, protože když spadne obsluha přerušení ve vlákně, způsobí to pouze oops jádra místo kompletního pádu systému. Obsluhy přerušení, které by nikdy neměly být nuceny běžet ve vláknech, lze označit IRQF_NO_THREAD, ale očekává se, že to bude ojedinělé.

• Ladící infrastruktura pro objekty nyní umožňuje specifikovat funkci pro „nápovědu k ladění“; ta vrací adresu, kterou je možné použít k lepší identifikaci specifického objektu. Detaily vizte v tomto commitu.

• Dlouho zastaralé inicializátory zámků SPIN_LOCK_UNLOCKED a RW_LOCK_UNLOCKED byly odstraněny.

• Subsystém událostí výkonnosti má nový monitorovací režim, ve kterém sleduje pouze procesy patřící do specifické řídící skupiny. K této funkci poskytuje přístup přepínač -G programu perf.

• Do férového plánovače bylo přidáno přímé předání; tato vlastnost by měla vylepšit výkonnost hostů virtualizovaných pomocí KVM.

• Nový mechanismus pro přidávání POSIXových hodin; vizte <linux/posix_clock.h>, kde najdete detaily o rozhraní.

• Architektura x86 získala minimální podporu pro strom zařízení [device tree].

• Vznikla nová globální pracovní fronta system_freezable_wq; od ostatních se liší tím, že je možné ji během uspávání zmrazit.

• Vnitřní subsystémy mohou použít nový mechanismus syscore_ops a zaregistrovat si zpětná volání [callback] pro správu napájení, aniž by bylo nutné vytvářet systémová zařízení, která k ničemu jinému neslouží.

Pokud budou platit obvyklá pravidla, lze konec začleňovacího okna 2.6.39 čekat někdy kolem 29. března a finální vydání 2.6.39 někdy první týden v červnu.

API pro senzory

napsal Jonathan Corbet, 16. března 2011

Senzory prostředí byly kdysi dávno výbavou, kterou bylo možné najít pouze ve specializovaných zařízeních pro řízení průmyslových procesů nebo ve výzkumu. Byly drahé a vyladěné ke specifickému úkolu. Čím dál tím více je ale můžeme najít ve všem možném. Mobilní handsety mají kompasy, akcelerometry a další. Senzory teploty, tlaku atd. jsou také častější a častější. Důsledek pobaví: z jakéhokoliv linuxového stroje se může stát přenosné zařízení pro sběr dat.

Jediný problém je v tom, že jádro ještě nemá zavedené žádné API – ani interní, ani pro uživatelský prostor – pro senzory. Jsou v něm rozhraní pro specifické typy senzorů; Video4Linux2 se například zabývá kamerami a subsystém hwmon zase senzory, které monitorují stav samotného počítače. V těchto oblastech jsou rozhraní zavedena dobře a je možná spolupráce. Pro senzory mimo tyto oblasti nicméně žádná pravidla neplatí. Výsledkem této situace je jako vždy to, že nová zařízení se přidávají bez konzistentních rozhraní, což ztěžuje život vývojářům aplikací.

Tato situace se (opět) projevila s nedávným zasláním ovladače pro senzor tlaku, který byl implementován jako jiné (misc) zařízení. Pro své rozhraní používal vstupní [input] subsystém; Jonathan Cameron, který pracuje na rozhraních pro senzory, upozornil na to, že v této podobě patch přijat nebude. Vstupní zařízení mají přijímat vstup od člověka; vzhledem k tomu, že většina lidí se svým počítačem nekomunikuje pomocí změn atmosférického tlaku prostředí, do této skupiny se senzor tlaku nehodí. Ovladač tedy potřebuje jiný domov. Navržen byl subsystém hwmon, ale senzor tlaku nemonitoruje hardware, takže tam ten ovladač také nebude vítán. A Arndu Bergmannovi se nelíbí používání misc rozhraní:

Obvykle se snažím bránit lidem přidávat nová ad-hoc rozhraní do drivers/misc. Všechno, co má patřit pod drivers/misc, se u mě musí kvalifikovat jako „není možné, aby vznikl další ovladač se stejnou sémantikou“. Jinak to má být součástí jiného subsystému s jasnými pravidly, nebo vloženo do vlastního souborového systému.

Tím zůstává subsystém pro průmyslové I/O [industrial I/O, IIO], kam patří „zařízení, která jsou v určitém smyslu A/D převodníky.“. IIO se snaží standardizovaným způsobem zvládnout široký záběr senzorů s podporou pro události, I/O s velkým průtokem dat a další. V IIO subsystému je poměrně hodně ovladačů; jediný problém je, že to všechno sedí ve stromě staging a seznam „TODO“ položek s tím spojený je poměrně dlouhý. Zařízení, která jsou tam zastoupena, nejsou, co se používání rozhraní týče, úplně konzistentní – a podoba žádaného rozhraní také není nijak jasná.

I tak je ale Jonathanovým cílem takové rozhraní vytvořit:

Podle mě jednoho dne bude vhodný subsystém 'senzory', takže jedním z důležitých bodů je snažit se minimalizovat změny rozhraní na cestě k němu (ať už to bude IIO nebo něco lepšího). Opravit sysfs je jednoduché, pracujme tedy přinejmenším na sdílených rozhraních tam. Hwmon je vyspělé rozhraní a rozumný výchozí bod; odtud jsme získali mnoho podobných rozhraní pro IIO. Trik je v tom přesvědčit lidi, že obecnost je dobrá, a to není nijak jednoduché.

K tomu Jonathan dodal, že rozhraní a podpora pro jednoduchá zařízení (ta, která předávají málo dat a mají sysfs rozhraní ve stylu hwmon) je v poměrně dobrém stavu. Otázka je, jak zajistit zbytek.

Jednou alternativou je definovat v podstatě nové IIO jádro, které by bylo začleněno do hlavní řady. Jednotlivé ovladače by potom byly vylepšeny a přesunuty pod něj, až by to bylo možné. Problém je, že to může trvat dlouho a verze ovladačů z hlavní řady by nemusely z počátku mít v porovnání s černými ovcemi ze stromu staging všechnu funkcionalitu. To by nějaký čas znamenalo víc práce s údržbou obou verzí ovladače.

I tak je to ale přístup, který Arnd doporučil. Přechod do hlavní řady je poslední dobrá šance, jak definovat rozhraní, které bude nutné podporovat několik let. Současné problémy, pokud se s nimi vypořádáme správně, tedy mohou ospravedlnit to, že si v budoucnu zjednodušíme život. Přesvědčit vývojáře na tento nápad přistoupit nicméně nemusí být úplně jednoduché; většina z nich tráví čas jinými věcmi než psaním ovladačů pro Linux a může jim tak chybět snaha přepsat kód kvůli novému rozhraní, když to současné funguje. I tak je to ale téměř jistě nejlepší cesta kupředu. A téměř určitě je správný čas na to, aby s vývojem verze IIO rozhraní pro hlavní řadu pomohli lidé, kteří mají v této oblasti své zájmy.

PostgreSQL, OpenSSL a GPL

napsal Jake Edge, 16. února 2011

OpenSSL licencované pod licencí ve stylu BSD s dodatkem o propagaci, je dlouhodobě zdrojem problémů, protože není příliš jisté, jestli je možné ji zahrnout do kódu licencovaného pod GPL. Většina distribucí je podle všeho spokojena s tím, že lze OpenSSL považovat za „systémovou knihovnu“, takže její používání nevyžaduje licenci kompatibilní s GPL. Free Software Foundation (FSF) a Debian ale s touto interpretací nesouhlasí a záležitost s licencí se tak znovu objevila v mailové konferenci pgsql-hackers (vývoj PostgreSQL).

U programů orientovaných na příkazovou řádku je běžné používání knihovny GNU readline, která umožňuje různé způsoby práce s příkazovou řádkou. Readline je ale licencováno pod GPL (ne pod LGLP) a to znamená, že programy, které ji používají, musí být pod kompatibilní licencí, což PostgreSQL se svojí jakoby-BSD licencí rozhodně splňuje. Licence OpenSSL ale přidává pro uživatele dodatečná omezení a s GPL tedy kompatibilní není. Jestli to je skutečný problém nebo ne v praxi závisí na tom, jak interpretujete GPL a jestli se OpenSSL dá považovat za systémovou knihovnu a platí pro ni výjimka.

Debian se rozhodl pro nekompromisní postoj, který zjevně souhlasí s interpretací FSF, a místo readline začal používat knihovnu Editline (libedit) licencovanou pod BSD. PostgreSQL podporuje libedit jako alternativu k readline, takže přepnutí je jednoduché. Bohužel chyba v libeditu způsobuje, že uživatelé PostgreSQL v Debianu nemohou do psql zadávat vícebytové znaky, když používají Unicode locale.

Pro PostgreSQL je tohle problém typu „kámen a tvrdá skála“. Kód OpenSSL funguje dobře a je poměrně těsně – možná až moc – integrován. Jsou zde nicméně dvě zjevné alternativy – GnuTLS a Network Security Services (NSS) Mozilly. Přechod k jednomu z toho by problém s readline odstranilo, protože jejich licence problematickou část o propagaci nemají.

Snahy o přechod k GnuTLS u PostgreSQL tu byly, což ve svém shrnutí historie problému popsal Greg Smith; patch ale byl příliš rušivý a velký, takže nebyl přijat. K problému zde přispívá to, že psql je příliš těsně spojené s OpenSSL, což Martijn van Oosterhout, který podporu pro GnuTLS vyvinul, popsal následovně:

Před delší dobou jsem věnoval nějaký čas tomu, aby PostgreSQL fungovalo s GnuTLS. Ten kousek, který se zabývá SSL, je triviální – rozhraní GnuTLS dokonce dávalo smysl, kdežto rozhraní OpenSSL je neprůhledné (přinejmenším jsem v něm nikdy neviděl jedinou strukturu). Rozhraní GnuTLS bylo navrženo v moderní době a je to vidět.

Problém je v tom, že se u psql různými způsoby ukazuje to, že používá OpenSSL; to ale dělá způsobem, který je těžké zpětně podporovat (kompatibilně). Tyhle kousky musí podpora GnuTLS vyřešit taky.

Dalším řešením by mohla být změna licence readline nebo OpenSSL, ale to není příliš pravděpodobné. Někdo dává do GPL kódu explicitní výjimku ohledně OpenSSL, ale nedá se příliš očekávat, že by FSF udělalo pro readline totéž – již dlouhou dobu považuje tuto knihovnu za způsob, jak dostat více projektů pod licenci kompatibilní s GPL. A OpenSSL je se svojí licencí buď spokojené, nebo ji nemůže změnit, na což v jednom vlákně upozornil Stephen Frost.

Jestli to dobře chápu, problém zde představuje jeden bývalý vývojář OpenSSL, který nemá zájem (nebo dokonce je proti) změně licence OpenSSL. Většina současných vývojářů OpenSSL nemá se změnou problém (opět – pokud jsem to dobře pochopil.)

Robert Hass doporučil revidovat podporu GnuTLS v PostgreSQL 9.2, ale mezitím tu budou uživatelé Debianu, kteří nemohou snadno používat psql. A netýká se to jenom Debianu, protože Ubuntu převezme verzi PostgreSQL + libedit v příští verzi. To problém dále šíří, což podotkl i Joshua D. Drake, který celé zmiňované vlákno začal: Jakkoliv je Debian populární, populace 'uživatelů' je ve světě Ubuntu a to bude mít závažné důsledky, co se týče pohledu veřejnosti.

Místo GnuTLS by se dalo použít NSS, což by mělo jednu zásadní výhodu: certifikaci Federal Information Processing Standard (FIPS) 140-2. FIPS 140-2 je standard Spojených států pro šifrování a některé firmy a organizace jej vyžadují, když jde o software, který obsahuje šifrování. OpenSSL tento certifikát má, stejně tak NSS, ale GnuTLS ne. Z toho důvodu se mluví o tom, aby PostgreSQL místo GnuTLS podporovalo spíše NSS.

Projekt Fedora se na NSS dívá také, je to součást jejich snahy konsolidovat šifrovací knihovny, které používají. Z mnoha důvodů, mezi které patří certifikace FIPS a některé vlastnosti, které v GnuTLS chybí (hlavně S/MIME), se ve Fedoře rozhodli pro NSS. Můžeme hádat, že licence nekompatibilní s GPL hrála roli v tom, že OpenSSL bylo ze zvažování vyřazeno.

Na jednu stranu Fedora dodává různé nástroje s readline i OpenSSL, mezi ně patří i PostgreSQL. Zdá se, že Fedora (a dost možná právníci Red Hatu) spoléhá na to, že OpenSSL se distribuuje jako systémová knihovna, což technický manager Fedory Tom „spot“ Callaway řekl roku 2008 a zopakoval to roku 2009. Možná také (stejně jako jiní) spoléhají na to, že je téměř nulová pravděpodobnost, že by se FSF někdy vážně pokusilo zastavit distribuci PostgreSQL používající readline.

Pro Debian to ale není dostatečné. Další hlášení chyby obsahovalo delší diskuzi o problému a způsob, jak ho obejít, který objevil Andreas Barth:

Když psql zavoláte

LD_PRELOAD=/lib/libreadline.so.5 psql

všechno funguje jako normálně.

Je to poměrně ošklivý hack a nikomu se moc nelíbí, ale plánuje se přidat LD_PRELOAD do wrapperu psql (pokud bude libreadline k dispozici), který se dodává v balíku postgresql-client-common. Martin Pitt to shrnul takto:

Technicky je to poněkud křehké, protože tu mohou být jemné rozdíly v ABI, které povedou k pádu. Nicméně workaround s preload situaci o tolik vylepšuje, že to bude IMHO lepší než předchozí status quo.

Tato situace se mi opravdu nelíbí a osobně bych se raději vrátil zpět k libreadline, dokud OpenSSL nebo readline nebo PostgreSQL nebude Debianu hrozit žalobou za porušení licence (Troufám si tvrdit, že šance něčeho takového se blíží nule...) Co naděláme...

Tento střet licencí se objevuje s určitou pravidelností a o licenci OpenSSL se ví, že je problematická – přinejmenším pro projekty, které používají GPL kód. Požadavek na propagaci, což je atavismus z prvních dní licence BSD, způsobuje, že je OpenSSL čím dál tím více izolováno. Distribuce a další projekty budou pravděpodobně pokračovat v hledání alternativ – a budou je nalézat. A to i když to bude jenom kvůli omezení nejasností ohledně licencování a s tím spojených otázek vývojářů a uživatelů. Je nešťastné, že jeden nebo dva články v licenci sloužící k nafukování ega způsobí, že se knihovna bude o něco méně používat, ale – jako vždy – si svobodný software najde cestu, jak tyto problémy obejít a fungovat dál.

       

Komentáře

[Gilhad]

Myslím si, že tohle je opravdu zásadní záležitost: každý, kdo z něčeho, z čeho se lze zotavit, udělá tvrdou chybu, je totální pitomec.

-- Linus Torvalds

Myslím si, že tento výrok je třeba interpretovat v určitém kontextu. U jádra fungují některé věci jinak než v uživatelském prostoru.

Mě osobně se u jednoho projektu velice osvědčilo, když většina chyb způsobila zalogování problému a řízený pád programu, který byl následně skriptem znovu spuštěn. Vystoupit a nastoupit se ukázalo mnohem rychlejším a stabilnějším, než se pokoušet balancovat na prstech jedné nohy ve větru nad propastí v 45 stupňovém náklonu - při pokusech o zotavení se program často dostával do oblastí, kdy sice běžel dál, ale v podstatě nefungoval správně, případně nefungoval takřka vůbec.

Na druhou stranu je pravda, že zalogování chyby, řízený pád a znovuspuštění skriptem lze do jisté míry popsat jako "zotavení, nikoli tvrdou chybu" aspoň v přeneseném slova smyslu, protože po troše automagických kejklů ten program jako běží dál a nevyžaduje interakci lidské obsluhy...

[David Watzke]

při pokusech o zotavení se program často dostával do oblastí, kdy sice běžel dál, ale v podstatě nefungoval správně

Takže pokud tomu dobře rozumím, tak jsi místo řešení problému ten problém radši obešel...

[Ladicek]

Ani ne, tenhle postup je úplně běžný, viz supervision tree v Erlang/OTP.

[Heron]

Nikoliv. On ho vyřešil. Nejúčinnějším řešením v jeho případě se ukázal restart služby, tak jej použil. Je to zcela legitimní způsob a používá se. Naopak by bylo velmi hloupé konstruovat nějaké šílené a drahé řešení, jen aby se vyhnul restartu (a tomu, že to někdo stupidně nazve obejitím).

[pribinacik]

Neuvazoval si aj nad tym, ze by si robil nieco ine? Napriklad traktoristu a podobne. Bolo by fajn, keby vymizli takyto "programatori" ako ty.

[Gilhad]

Uvazoval, ale neprislo mi to jako dobry napad. Pokud povazujes za dobre aby vymizli programatori, kteri jsou schopni dat dohromady plne funkcni system ke spokojenosti zakaznika v rozumnem case a pak ho leta udrzovat v chodu bez velkych obtizi, tak je to tvuj boj. Mi zakaznici to ale vidi po zkusenostech s nekterymi firmami dost jinak nez ty.

Pokud mas nejakou konkretni pripominku, tak sem s ni, pokud mas jen obecne kecy, tak zalez.

[Filip Jirsák]

což PostgreSQL se svojí jakoby-BSD licencí rozhodne splňuje

-> rozhodně

konzolidovat šifrovací knihovny

-> konsolidovat

[Martin Kratochvíl]

Začleňovacího okna 2.6.39 čekat někdy kolem 29. března a finální vydání 2.6.39 někdy první týden v červnu.

Březen vs červen?, nemělo by tam být "první týden v dubnu"?

[kip]

Chyba v překladu nebude, originál to má stejně. Spíš se do června budou vychytávat mouchy.

[Xerces]

To jako že by to během 2 týdnů odladili? To asi ne. Většinou to je 14 dní začleňovací okno a pak cca každý týden rc verze, kterých bývá cca 6-8 dle potřeby, takže asi 2 měsíční cyklus. Tak bych to viděl že to mají dobře spočítaný.

[Petr Tomášek]

Hm, muzete mi nekdo vysvetlit, jak souvisi OpenSSl, PostgreSQL a ja nevim co dal s linuxovym jadrem?

[trekker.dk]

Nijak. V čem je problém?