Hlavní navigace

LinuxAlt 2012, sobota: Firefox, kalendáře a DNS

5. 11. 2012
Doba čtení: 12 minut

Sdílet

Jak už se stalo tradicí, první víkend v listopadu se konal brněnský LinuxAlt. Dvoudenní přednášková akce byla jako obvykle nabitá zajímavými přednáškami především (ale nejen) o Linuxu. Hovořilo se o kalendářových řešeních, organizaci Mozilla a jejich plánech týkajících se také Firefoxu a na řadu přišel i DNS.

Pavel Tůma a Michal Altmann: Kalendáře a plánování času pro Linux

První letošní přednáška se věnovala situaci v oblasti kalendářových služeb v Linuxu. Pavel Tůma se nejprve zmínil o tom, proč jsou či nejsou kalendářové služby pro některé uživatele zajímavé. Malé a střední firmy do 100 zaměstnanců nemají zájem o integrovaná řešení pro kalendářové služby a spolupráci. Až 64 % malých firem o tom vůbec neuvažuje. U firem nad sto lidí je to asi 37 %, přesto je to poměrně hodně, řekl na začátku Tůma o studii zkoumající situaci ve firmách. Citovaná studie uváděla i důvody, které firmy k nezájmu vedou. Hlavním důvodem je, že si myslí, že takové aplikace nepotřebují a jsou pro ně zbytečně drahé.

Každé podobné řešení má dvě strany: klienta a server. Z klientských řešení byly zmíněny asi nejběžnější aplikace Evolution a Thunderbird. Každá z těch aplikací umí zobrazit kalendář, jeho události a umí přistoupit k nějakému vzdálenému úložišti. Rozdíl je hlavně v uživatelském rozhraní a podporovaných úložištích.

Pavel Tůma se podíval nejprve na Evolution, který kritizoval zejména kvůli nedotaženému rozhraní. Vadil mu duplicitní pohled na měsíční kalendář a velký prostor zabraný úkoly, přestože je na ně v rozhraní tlačítko pro přepnutí pohledu. Největší nevýhodou Evolution je, že u událostí rozlišuje mezi událostmi typu appointment a meeting. Rozdíl je, že do meetingu můžete zvát další lidi. To ale musíte vybrat hned na začátku při zakládání události, jakmile se rozhodnete později, už máte smůlu. Velkým problémem Evolution je také sdílení kalendářů. Tím trpí většina aplikací, obvykle je problém sdílet kalendář s někým jiným.

Konkurenční Thunderbird má velmi podobné rozložení obrazovky, které podle Tůmy trpí stejnými problémy. Opět ve výchozím zobrazení vidíme vedle kalendáře i úkoly a zbytečný náhled na měsíc. Thunderbird neumí vkládat přílohy, k události je možné vložit jen URL. Zvláštní je také velmi jemné nastavení času. Rozlišení po pěti minutách je už trochu zbytečné. Nepřehledné je také rozhraní pro pozvánky, které podle Tůmy obsahuje příliš mnoho tlačítek.

Pokud uživatelé nechtějí používat desktopovou aplikaci, mohou sáhnout po webovém kalendáři. Nejprve byl popsán kalendářový plugin pro Roundcube, který je zatím v ne příliš dobrém stavu. Hlavním pozitivem je, že ten plugin vůbec existuje a nějak funguje. Horší je, že toho zatím příliš neumí. Jeho hlavním problémem je nedostatečná integrace se zbytkem Roundcube. Když vám třeba přijde pozvánka, nemůžete ji do kalendáře přidat.

Dalším webovým kalendářem je Zimbra, u které ale Tůma kritizoval příliš komplikované ovládání. Největším problémem je, že uživatelské rozhraní je přeplácané, vývojáři se toho na obrazovku snažili dostat moc. Vidět je to zejména při přijetí pozvánky, která je obložená řadou různých toolbarů a například i náhledem na zbytek kalendáře. Náhled na kalendář při editaci pozvánky je třeba dobrý nápad, protože hned vidíte kontext daného termínu. Ovšem to provedení už ideální není, řekl Tůma.

Poslední popisovanou webovou aplikací byl kalendář na Google. Rozhraní Google je celkem standardní, problém je ale v práci s více kalendáři. Pokud používáte více kalendářů, nejsou všechny přiřazeny interně jednomu uživateli, ale generují se pro ně další identity. Pokud se někdo cizí podívá na vaši dostupnost, uvidí informace jen z hlavního kalendáře, nikdy se mu neobjeví, jestli něco nemáte v některém dalším. Google kalendář má ale nejlepší webové rozhraní a má také integraci prakticky v každé kalendářové aplikaci, uznal Tůma.

Pro komunikaci klienta se serverem se dnes stále používá stařičký standard CalDav, který podle Tůmy také není příliš dobře řešený. Aby vám to fungovalo, potřebujete na serveru HTTP, pak také WebDav, access controll, pak samotný CalDav a nakonec ještě scheduling, aby bylo možné kalendáře sdílet, vysvětlil. Každá aplikace navíc tyto součásti implementuje po svém. Většina serverů například umí využít LDAP, ale kromě jednoho do něj ukládají jen přihlašovací údaje uživatelů a neumí z něj číst data.

U všech řešení ale nastává problém ve chvíli, kdy chcete pozvat na schůzku lidi, kteří nejsou z vaší firmy. Můžete zvednout telefon a zavolat jim, nebo jim poslat mail, či využít nějakou webovou službu, kde událost založíte. Podle průzkumu takové plánování ve firmě probíhá patnáctkrát až osmdesátkrát za měsíc a každého zaměstnance. Spočítejte si, kolik času strávíte takovým plánováním. A to neuvažujeme situaci, kdy vám den před schůzkou někdo z pozvaných zavolá, že potřebuje změnu.

Tento problém řeší nový projekt 3e, který Pavel Tůma a Michal Altmann vyvíjejí. Hlavní výhodou je, že v pohledu dostupností vidíte informace nejen od uživatelů z vlastní firmy, ale i z kalendářů Google a dalších řešení. To přináší podle Pavla Tůmy především méně vyrušování a telefonátů s dotazy o dostupnosti. Snažili jsme se také o co největší automatizovanost, aby uživatel pokud možno nic nekonfiguroval. Kalendářový systém 3e zjišťuje sám všechny informace a podle domény v e-mailové adrese se připojí správným způsobem na správné služby.

K dispozici bude podle autorů už brzy, serverová část bude nejprve k dispozici pro Fedoru, Red Hat, Ubuntu a Debian. Klientská část bude dostupná pro klienty Thunderbird a Evolution. Samozřejmě jde o multiplatformní řešení, klient nemusí běžet jen na Linuxu. K dispozici bude také mobilní klient pro Android, ovšem jen pro verzi 4.0 a vyšší. Bohužel v nižších verzích nejsou kalendáře dostupné pro aplikace třetích stran, zakončil Pavel Tůma.

Pavel Franc: Mozilla v roce 2012

Pavel Franc se na začátku své přednášky věnoval organizaci Mozilla a jejím zajímavým projektům. Zmíněny byly vývojářské nástroje, ale i uživatelské projekty, mezi které patří OpenPhoto projekt, který má být alternativou ke sdílení fotek třeba na Facebooku. Fotky hostujete někde u sebe a OpenPhoto vám nad nimi sám dělá galerii.

Poté se přednáška už věnovala tomu uživatelsky nejzajímavějšímu – prohlížeči Firefox, který Mozilla považuje za svou centrální platformu. Platforma Firefox je nejdůležitějším projektem Mozilly. Patří do něj desktopový prohlížeč, mobilní prohlížeč a Firefox OS. Ostatní projekty jsou více v pozadí a závisí na komunitě, vysvětlil Franc.

Letos jsme se ve Firefoxu dočkali výrazné úspory paměti díky projektu MemShrink. Vývojáři honí každý bajt a daří se jim to neuvěřitelně. Dalším zajímavým projektem je Snappy, který řeší čekání prohlížeče na operační systém. Prohlížeč si často řekne třeba o soubor se záložkami, na který musí počkat. To způsobí zamrznutí prohlížeče na dobu, než dostane odpověď. Projekt proto zavádí se asynchronní chování, kde podobné čekání nebude mít na zbytek prohlížeče žádný vliv.

Během letošního roku jsme se také dočkali nového javascriptového engine IonMonkey, který opět přinesl hladší běh celého prohlížeče. Došlo také na nový garbage collector. Důležité je, aby uklízení paměti nezpůsobilo sekundový zásek, což se dříve stávalo. Teď se paměť uklízí průběžně, vysvětlil Franc.

Vývojáři také pracují na jádře Gecko a snaží se do něj zavádět nové věci a zároveň dohání i konkurenci, která už je zavedla o něco dříve. Ve vývojové verzi například zmizely prefixy z některých vlastností CSS3, jako animace, transitions, gradients a podobně. Už je to podle specifikace, řekl Franc. Dále se vývojáři snaží zavádět i poslední novinky z HTML5, jako využití kolečka myši či zachycení kurzoru, které se hodí třeba ve hrách.

Pro webové vývojáře je užitečná nová lišta vývojáře, která má přinést alternativu k populárnímu Firebugu. Cílem je nekopírovat Firebug, ale udělat to znovu a pokud možno lépe. Ve Firefoxu je nově také příkazová řádka, která jednoduše zpřístupňuje pokročilejší funkce. Skoro vše, co si vymyslíte, je možné přes ni ovládat. Zajímavý je například i vzdálený debugger a konzola. Pokud vyvíjíte weby pro mobily, můžete ho dálkově ladit, aniž byste museli nepohodlně ovládat debugger na malém displeji. Na počítači i mobilu v takové situaci běží Firefox a oba prohlížeče spolu komunikují.

Úplně nejžhavější a zároveň nejdiskutovanější novinkou je podpora standardu WebRTC. Nasazení této technologie má velmi širokou podporu od společností jako Google, Mozilla, Opera, Cisco a dalších. Dříve WebRTC podporoval i Microsoft, ale teď je s ním komunikace velmi složitá. Pavel Franc dodal, že poté, co si Microsoft koupil společnost Skype, přístup k této potenciálně konkurenční technologii ochladl. Je vyloženě cítit, jak chce Microsoft dělat věci po svém a zajistit si integraci se Skype.

WebRTC umožňuje pomocí DOM API pracovat s video či audio vstupy, tedy s daty z mikrofonu a kamery. Přímo v JavaScriptu se můžete zavěsit na příchozí stream, ten pak modifikovat nebo někam dále odeslat, vysvětlil Franc. Je možné také propojit dva prohlížeče pomocí podvlastnosti DataChannel. Z hlediska vývojáře je to jednoduché. Stačí požádat server, ze kterého jste načetli konkrétní stránku, aby vás spojila s jiným uživatelem. Ten spojení potvrdí a je hotovo.

WebRTC už implementuje Mozilla ve Firefoxu a Google v Chrome. Bohužel oba implementují podle různých verzí specifikace, povzdechl si Franc. Mezi Firefoxem a Chrome si tedy zatím nezavoláme, ale ve Firefoxu už by to mělo fungovat. Tedy v případě, že nenarazíte na špatný build, který třeba spadne. Zatím je to opravdu velmi čerstvé. Rozšíření tohoto mladého standardu by mohlo přinést mnoho audiovizuálních novinek i třeba videotelefonii přímo po webu. Pokud se tohle rozšíří, máme se ještě na co těšit.

To byl pohled na desktop, ale na mobilních prohlížečích se toho děje také hodně. Pokud jste vloni na podzim zkoušeli Firefox, asi jste došli k tomu, že je to pomalé a nepoužitelné. Proto došlo ke kompletnímu přepsání rozhraní do Javy, samostatný proces se stará o vykreslování a druhý proces pak pomocí jádra Gecko renderuje stránky. Firefox pro Android přidal i další dnes standardní funkce jako synchronizaci, doplňky či našeptávač. Nově se chystá podpora pro procesory ARMv6, video kodek H.264 a oblíbený anonymní režim. Bohužel se zjistilo, že ne na všech mobilech s ARMv6 to funguje, přestože by mělo. Proto bude podpora k dispozici jen pro konkrétní vyjmenované telefony, varoval Franc.

Asi nejzásadnější novinkou z dílny organizace Mozilla je Firefox OS, který byl představen na jaře 2012. Oficiální uvedení telefonu se chystá na jaro 2013 v Brazílii. Brazilský trh je podle Pavla France prakticky nepolíbený chytrými telefony. Lidé tam nemají na to, aby si koupili iPhone nebo Samsung Galaxy. Právě na takové trhy Telefónica jako partner míří. Jelikož Telefónica působí i v Česku, je podle France jistá šance, že se telefon s Firefox OS objeví i u nás.

Z hlediska architektury jde o velmi ořezaný operační systém Android, nad kterým běží renderovací jádro Gecko. Aby bylo vykreslování rychlé, dělá se pomocí OpenGL ES. Přestože půjde o low endové telefony s nízkými parametry, neměli by to uživatelé nijak pocítit. Protože většina věcí, které jsou ve standardním Androidu, byla odstraněna, mělo by být ovládání velmi rychlé. Aplikace budou se systémem komunikovat pomocí WEBAPI, kde už jsou připravené standardy pro volání, vibrace, SMS, kontakty, ovládání WiFi sítí, komunikaci s budíkem a podobně. Už je implementováno mnoho funkcí a další se připravují, navnadil nás na závěr Pavel Franc a my se na Firefox OS těšíme.

Ondřej Caletka: DNS pro začátečníky

Ondřej Caletka se ve své přednášce zaměřil na začátečníky, kteří ještě nemají s konfigurací DNS žádné zkušenosti. DNS je letitý protokol, první RFC vyšlo už v roce 1982, řekl na začátku a dodal, že jde o internetovou archeologii. Před DNS se používal jeden velký soubor hosts.txt, který obsahoval všechny servery na internetu. Poté se ale síť rozrostla natolik, že nebylo možné, aby jediný správce udržoval celý jmenný prostor. Dnes už si ani neumíme představit, že by něco takového bylo možné. Proto byl vymyšlen nový decentralizovaný systém správy domén.

DNS je distribuován a je navržen tak, aby byl co nejrobustnější a nejspolehlivější. Naopak není potřeba, aby byly odpovědi od všech serverů vždy konzistentní a aby byly umožněny rychlé změny, vysvětlil Caletka. Důležité je, aby bylo možné správu rozdistribuovat mezi různé organizace, které si spravují každá svou malou část. Říká se, že DNS je jediná databáze, do které dobrovolně přispívají Spojené státy i Severní Korea.

Dále se přednáška věnovala detailům samotného protokolu DNS. Ten komunikuje na portu 53 po UDP i TCP. Řada lidí se domnívá, že pro DNS stačí UDP a nepovolují proto na firewallu TCP. Pak to nefunguje dobře, upozornil Caletka. Standardně se komunikuje pomocí UDP, ale pokud je odpověď větší, pošle se o tom informace a začne se navazovat TCP spojení. Celý protokol je binární, a to právě proto, že je velmi starý. Před třiceti lety nebyl výkon počítačů dostatečný na to, aby bylo možné parsovat složité textové odpovědi.Každý server obsahuje a podává nezávislé informace, které drží dohromady pomocí delegací. Nadřazená zóna obsahuje záznam s adresou serveru se zónou nižší úrovně. Nadřazený server vám tedy vždy jen řekne, že informaci o adrese nemá a poradí vám, kde ji máte hledat. Problém nastává, když odpověď leží uvnitř zóny, na kterou se ptáte. K tomu byl vymyšlen GLUE záznam, se kterým se dozvíte i IP adresu patřičného stroje, vysvětlil Caletka.

Informace potřebné pro sestavení DNS odpovědi leží na takzvaných autoritativních serverech. Ty musí být vždy minimálně dva, aby bylo možné najít odpověď, i když je jeden ze serverů nedostupný. Jeden server je master a další jsou slave. Ty se periodicky dotazují master serveru na změny. Pokud k nějakým došlo, požádají jej o podrobnosti. K synchronizaci pak může dojít velmi rychle.

Jako autoritativní servery mohou sloužit různé démony. Nejběžnějším je BIND. To je takový veterán a je považován za naprostý standard. Konkurencí je nizozemský server NSD, český Knot DNS, zbrusu nový YADIFA nebo populární PowerDNS. Ten dokáže pracovat nejen s klasickými zónovými soubory, ale dokáže informace číst i z databáze, což se hodí při integraci s jinými systémy.

Ondřej Caletka pak hovořil o detailech zápisu zónových souborů. Věnoval se i některým aktuálním problémům. Jeden souvisí například s cloudy. Pokud chcete například svou doménu namířit na Google, použijete CNAME na ghs.google.com. Tam je další CNAME na konkrétní server a na další dotaz teprve dostanete A záznam. Potíž nastává, pokud chceme zapsat záznam bez www. Máme problém, protože v apexu zóny nemůže být CNAME záznam, který není podle standardů možné kombinovat s jinými záznamy. Řešení zapsat tam přímo IP adresu je také špatné, protože tím svážeme doménu s konkrétním serverem, který může časem přestat fungovat. Google tento problém řeší pomocí jiné sady IP adres, které jsou zřejmě anycastované a je jim tak zajištěna vysoká dostupnost.

CS24 tip temata

Dále už se přednáška věnovala rekurzivním serverům, které používají uživatelé pro své dotazy. Tam nabídka není už tak pestrá, ale je z čeho vybírat. Stále je tu BIND a PowerDNS a kromě toho třeba i Unbound. Není dobrý nápad kombinovat rekurzivní a autoritativní server. Vyvolává to různé skryté problémy, které se navíc velmi špatně odhalují. Stejně tak by rekurzivní server neměl sloužit pro celý internet. Můžete se tak nevědomky účastnit DDoS útoků na internetu.

Na konci přednášky se Ondřej Caletka věnoval právě DDoS útokům s pomocí DNS. Každý může snadno odeslat UDP datagram s libovolnou zdrojovou adresou. Správci sítí by to měli filtrovat, ale není možné k tomu donutit všechny. Díky tomu je možné zeptat se veřejného DNS serveru a nechat odpověď odeslat na libovolný server v internetu. Protože je odpověď vždy větší než dotaz, můžete efektivně svou oběť zahltit. Tento útok se nazývá DNS amplification a v poslední době se o něm hodně hovoří, protože je také útočníky často využíván.

Autor článku

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.