Jaký byl InstallFest 2017? Velký a přitom pořád osobní

Mnoho posledních let se InstallFest konal ve strahovském školicím centru, což je vlastně bývalá prádelna. Malá komunitní akce pro pár desítek lidí měla své kouzlo, ale prostory přestaly postupně vyhovovat a organizátoři se rozhodli udělat radikální změnu. Devátý obnovený InstallFest se po dvanácti letech vrátil na Karlovo náměstí. Musíme poděkovat panu děkanovi FEL ČVUT za to, že nám poskytl prostory a personál budovy zadarmo. Sehnat zadarmo na celý víkend přednáškové sály není vůbec jednoduché, řekl v úvodním povídání Petr Hodač, šéf celé akce. Prostory jsou to opravdu nádherné a InstallFest se za ně nemusel stydět. Někteří návštěvníci si jen stěžovali na velké množství schodů.

Přímo v půlce schodiště bylo možné si koupit Club-Mate nebo nakoupit zboží od LinuxMarket. V neděli se tu navíc konala PGP Key Signing Party, při které si účastníci vyměnili informace o svých veřejných klíčích a vzájemně si podepsali důvěru. Zájem mě překvapil, zúčastnilo se několik desítek zájemců.

Přednášky probíhaly ve třech sálech, k tomu se přidaly dvě místnosti s workshopy. Jako obvykle vše streamoval a nahrával tým AVC SH. Zároveň bylo v předsálí možné si prohlédnout stánky a popovídat si s lidmi u nich: Bastlíři SH ukazovali roboty a spoustu elektroniky, 3D tiskaři tu měli tiskárny, admini tu měli rack se servery a k vidění byl třeba i Vim stánek se skutečným sériovým terminálem. Pro návštěvníky byl otevřen bufet, zdarma se točila malinovka od Active24 a vpsFree.cz připravovalo espresso a cappuccino. Černého voňavého nápoje se mimochodem vypilo přes 850 kelímků.

Konference se zúčastnilo přes 400 návštěvníků, takže byla několikanásobně větší než předchozí ročníky. Přesto mám pocit, že to hlavní nezmizelo: komorní atmosféra, vlídní návštěvníci, spousta chytrých hlav a hlavně zajímavých lidí. Protože mám pořád pocit, že na takových akcích jde především o setkání s lidmi bez rozdílu věku nebo vzdělání. Mluvil jsem s pekařem, restaurátorkou obrazů i doktory nejrůznějších věd. InstallFest se přemístil a vyrostl, ale pořád zůstal akcí, kde je linuxákovi dobře.

Lukáš Bařinka: Jak si přizpůsobit bash

Na začátku přednášky dostal oblíbený přednášející tričko s nápisem „Bařinka!“ a byl založen oficiální fan klub Lukáše Bařinky. Tričko je trochu malé, ale děkuji za něj. Rozhodl jsem se udělat přednášku trochu jinak, aby tam bylo méně WTF okamžiků. Ale jeden eval jsem si tam nechal, začal Lukáš svou přednášku. Bash má celou řadu možností přizpůsobení. Můžete toho udělat hodně, ale pořád to bude ten samý ‚blbý Bash‘.

Bash je možné přizpůsobit pomocí konfiguračních souborů, příkazů shell, proměnných, aliasů nebo funkcí. V dokumentaci je napsáno, že funkce jsou lepší než aliasy. Ukážeme si, jak to je a jak aliasy nahradit pomocí funkcí. Dále je možné upravit klávesové zkratky nebo vytvořit nový zabudovaný příkaz. Tím se šetří systémové prostředky.

Bash při svém spuštění načítá různé soubory podle toho, jestli je spuštěn jako login shell nebo ne. Uživatele to dokáže velmi zmást, ale je to dáno historickým vývojem. V původním Bourne shellu se načítal soubor profile a všechny další instance už pak byly jen subshelly a ty přebíraly nastavení od svých rodičů. Když pak ale přišly modernější shelly, bylo potřeba zajistit, aby se načítala i konfigurace potomků. Vznikly pak konfigurační soubory jako ~/.kshrc. Proto se z login shellu předává proměnná ENV, podle jejíhož obsahu si pak další shell načte svou konfiguraci. To má výhodu v tom, že funguje vždy a je možné použít různé login shelly i různé další shelly a vše funguje.

Bash ale přišel později než Korn shell a bylo potřeba se s tím vyrovnat po svém. Ono to tam funguje stejně, jen přibyly nějaké další soubory. Bash si nejprve načítá .bash_profile, pokud neexistuje, použije se profile. Je tedy možné převzít konfiguraci z Korn shellu nebo si oddělit nastavení pro Bash. Existují ale i další soubory jako /etc/bash.bashrc nebo ~/.bashrc a samostatný /etc/bash_completion pro načítání nastavení pro doplňování.

Proměnné prostředí by tedy mělo být nastaveno v souboru profile, aliasy a další uživatelská nastavení mají být v .bashrc. Tak, aby vše fungovalo i v login shellech. Když se hlásíte přes SSH, možná rozdíl ani nepoznáte, protože se nastavení převezme z login shellu. Pokud ale budete pracovat lokálně, může se vám stát, že když si napíšete aliasy do profile, někdy je tam mít budete a někdy ne. Je možné Bash zavolat s parametrem -l, který ho donutí pracovat tak, jako by byl spuštěn jako login shell.

Dalším zajímavém souborem je ~/.bash_logout , který se spouští při ukončení shellu. Je v něm možné například hlídat, jak hluboko je ukončovaný shell zanořený a pokud je poslední (nad ním už žádný není), je možné smazat obrazovku. Dá se to omezit třeba jen pro roota, aby na obrazovce nezůstaly žádné citlivé informace.

Dále se přednáška věnovala jednotlivým nastavením Bashe, které dovolují například exportovat globální proměnné, zastavit běh více příkazů při selhání jednoho z nich, vypnutí expanze speciálních znaků a podobně.

Miroslav Marcišin: ZoKB z pohledu implementátora

Miroslav Marcišin z T-Mobile přednášel o praktické implementaci povinností ze zákona o kybernetické bezpečnosti. Zákon definuje kritickou informační infrastrukturu, což jsou elektrárny, vodárny a podobné organizace. Druhou skupinou jsou významné informační systémy, za které se může prohlásit kdokoliv. Co všechno je pak potřeba monitorovat? Jednoduše všechno. Servery, síťové prvky, disková pole, aplikace i netflow. Podle Marcišina se sbírají data ze všech síťových vrstev od L2 až po L7.

Zařízení pro takový monitoring je velmi málo. Marcišin zmínil HP ArcSight, IBM QRADAR a FlowMon. Záleží na tom, jaký máte rozpočet a jestli chcete použít vlastní řešení nebo nasadit hotovou službu. V prvním případě je potřeba zdroj dat, pak je potřeba řídicí stroj a datové úložiště. Zákon nám říká, že musíme ukládat data za posledních devět měsíců, některé firmy skladují data i za jedenáct let. To znamená starat se o obrovské úložiště. My ukládáme 7 TB dat měsíčně.

U dat ze syslogů by stačilo sbírat informace označené jako debug, ale ve skutečnosti je záznam přepnutý na info. Sbírá se úplně všechno, kdo kam přistupuje, co se kam kopíruje, jak vznikají zálohy a podobně. Systém se musí nějakou dobu učit, ale pak dosahuje velmi vysoké přesnosti. Na konec víme, co uživatel udělá, pár vteřin před tím, než to doopravdy udělá.

Sbíraná data se musí složitě korelovat mezi sebou. Například se někde přehřeje procesor, to se koreluje s provozem na síti, v databázi uživatelů se vyhledá zodpovědný účet a podobně. Je to velmi složitý proces. Dále je třeba zajistit lidi, kteří se o zařízení starají, dohled a zajistit redundanci zařízení. Ideální je mít offline zálohu pro rychlé přepnutí, protože veškeré incidenty je potřeba hlásit do 15 minut na NBÚ.

Takový systém si pořizují především organizace, které pod zákon spadají. Jsou ale i další a hlavním důvodem podle Marcišina není to, že by chtěly mít pořádek na vlastní síti. Nejrozšířenějším důvodem je snaha šmírovat zaměstnance. Bohužel, je to smutné, ale je to tak.

Michal Kubeček: Co se děje v linuxovém síťování

Michal Kubeček ze SUSE Labs začal svou přednášku tím, jak vlastně probíhá zpracování paketu v linuxovém jádře. Většina dnes používaných protokolů pochází z minulého tisíciletí. Nabízí se otázka, co je na tom ještě za vývoj, když třeba IPv4 má více než třicet let a bylo dost času na to to udělat pořádně. Ve skutečnosti ale byly specifikace postupně doplňovány a upravovány. Sítě jsou čím dál rychlejší a čím dál komplikovanější.

Při zpracování paketů nás zajímají jen hlavičky, které zabírají jen jeho velmi malou část. Pokud bychom procházeli celý paket, trvalo by nám to strašně dlouho. Proto se tomu snažíme vyhnout a zpracováváme jen několik desítek bajtů. Při odesílání se postupuje směrem dolů a hlavičky se přidávají, při přijmu se postupuje nahoru a hlavičky se postupně procházejí.

Při zpracování se používají datové struktury:sk_buff obsahuje metadata paketů, včetně těch, která nejsou součástí samotného paketu. Historicky se pak pro uložení obsahu celého paketu používal lineární buffer, což fungovalo do té doby, dokud byly pakety malé. Dnes obsahuje jen relativně malou část paketu, zejména hlavičky. Zbytek je v části nazývané shared info. Může jít o binární list bloků nebo o pole bloků (page fragments). V některých situací pakety klonujeme, pokud jej potřebujeme zpracovat více způsoby. Museli bychom kopírovat velké množství dat, což by bylo velice neefektivní. Proto se tato struktura sdílí.

Při odesílání dat předává proces jádru aplikační data, která se předají transportní vrstvě, pak síťové vrstvě, následně linkové vrstvě a ovladači síťového zařízení. Ve skutečnosti může být takových ovladačů i víc, ale na konci se data předají zařízení, které pomocí přerušení signalizuje odeslání paketu. Každá z vrstev může paket nějakým způsobem modifikovat, typicky přidat vlastní hlavičky. Při odesílání většinou nebývá problém, protože tam si sami regulujeme, jak bude celý proces probíhat.

Při přijetí paketu je vyvolání přerušení, IRQ handler provede minimální potřebné kroky a paket uloží do fronty. U hardwarového přerušení musíme být opatrní, protože kdybychom toho udělali moc, prakticky bychom systém udusili. Pak je vytvořena zmíněná metadatová struktura sk_buff, která má okolo 200 až 250 bytů, a všechny další struktury. V tu chvíli se ještě data nekopírují, síťová karta typicky data uloží někam do paměti, kde je možné k nim přistoupit.

Data si pak převezme síťová vrstva, která rozhodne, jestli je paket určen pro nás nebo je třeba jej přeposlat. Pokud je určen pro místní počítač, projde přes transportní vrstvu a je uložen do fronty v kontextu procesu, kde je možné si vyzvednout data. Pak jsou teprve data zkopírována do uživatelského prostoru. To je velmi pomalá operace, proto si ji necháváme až na konec.

U dnešních vysokých rychlostí je na zpracování každého paketu velmi málo času. Zatímco u 100mbit Ethernetu se zpracovává 8100 paketů za sekundu a je k dispozici 120 µs, u gigabitu je potřeba to stihnout za 12 µs. To je spousta času, za tu dobu se toho stihne udělat hodně. Moderní sítě ale mají vyšší rychlosti jako 10, 40 nebo dokonce 100 gigabitů. Rychlost 10 gigabitů ještě na rychlém procesoru zvládnete, i když je na to už velmi málo času.

Čím dál častěji se ale používají ještě vyšší rychlosti 40 a 100 Gbps. Tam je nutné zpracovat až 8,1 milionů paketů a na zpracování každého z nich už čas nezbývá. Můžeme si sice pomoci s jumboframes, takže je pak potřeba zpracovávat méně paketů, ale pokud chceme zpracovávat takové rychlosti, musíme být rychlejší. V praxi je navíc síťování složitější, protože do všeho vstupují VLAN, VXLAN, zpracování v bridge nebo zapojení do virtuálních síťových karet.

Pro zvýšení efektivity je potřeba nasadit NAPI, které umožňuje přijímat více paketů najednou. Dnes je jádro chytřejší a nepoužívá přerušení pro každý paket zvlášť, ale moderní ovladače se snaží zpracovat více paketů najednou, pokud ještě nějaké čekají ve frontě. Ještě o kousek dále jde technika busy looping, která kontroluje přítomnost paketů ve frontě i ve chvíli, kdy tam žádné nejsou. Není to ve výchozím stavu zapnuté, protože to sice snižuje latenci, ale zvyšuje zátěž procesoru.

Další možností je GSO/GRO, kdy se většinu doby zpracování pracuje s výrazně většími pakety. Během většiny cesty mají pakety desítky kilobajtů a až těsně před odesláním se rozdělí na menší části. Většina stacku stejně pracuje jen s metadaty a nezáleží na délce paketů. Čím méně paketů tedy použijeme, tím méně výkonu potřebujeme. Takto zvětšené pakety neopouštějí systém, ale používají se pro efektivní zpracování uvnitř stacku.

Moderní karty také umí multiqueue, kdy síťová karta používá více front a umožňuje tak použít pro zpracování více procesorových jader. Důležitou věcí je také checksum offloading, protože při počítání kontrolních součtů je nutné pracovat s celým paketem. Tady je krajně nežádoucí, aby to dělal pomalý software. Potřebujeme tedy, aby to vypočítala nebo ověřovala karta. Většina rozumných karet dnes podporuje offloading nad IPv4 a často i nad IPv6, ale do hry vstupují ještě i tunelovací protokoly. Karta nesmí být chytrá a rozhodovat sama o tom, co bude zpracovávat. Ideální je generický offloading, kdy sami určíte, co chcete počítat. To bohužel umí jen velmi málo karet a pak musí karta podporovat konkrétní tunelovací mechanismus, který používáte. Podle Kubečka se tu střetává technický a marketingový svět. Když má karta generický offloading, není možné u nového modelu říct, že umí nový tunelovací protokol než ten starší.

Často by kvůli zvýšení efektivity bylo výhodné, kdyby se přepínání paketů neprovádělo v síťovém stacku, ale mimo něj na switchovacím zařízení. Taková zařízení skutečně existují, typicky managovatelné 40 nebo 100gbit switche. Dříve pro něj existovala proprietární rozhraní, dnes máme univerzální Switchdev. Pomocí ovladače je tak možné komunikovat se switchem a spravovat jej na dálku. V poslední době se pracuje i na tom, aby bylo možné takto používat routery. Není to ale jednoduché, protože možnosti těch zařízení jsou odlišné od toho, co zvládne software. Vývojáři se ale mohou soustředit na správu zařízení, která se pak postarají o samotné zpracování toku.

Petr Stehlík: Představení Orange Pi

Raspberry Pi oslavilo nedávno páté narozeniny a je vlastně etalonem pro všechny kopie a následovníky. Pokusy o malé počítače tu byly už před ním, ale až RPi nastavil rozměry platební karty a hlavně stanovil nízkou cenu. Zároveň má velmi silnou komunitu, perfektní podporu software i hardware, velký ekosystém a podrobnou dokumentaci. Zajímavé je také to, že je to počítač vyvíjený a vyráběný kompletně v Evropě. Vždycky s novým modelem vyrábí část i v Číně, aby se uspokojila poptávka.

Velmi rychle vznikla celá řada klonů, většina z nich s ovocným názvem: Banana Pi, Orange Pi, ale také Odroid, NanoPi, Pine64 a mnoho dalších. Přednáška se dále věnovala konkrétně Orange Pi. Dnes už je to celá rodina malých počítačů a hlavní prodejní kanál je na AliExpressu. Návrh a výroba probíhá ve společnosti Shenzen Xunlong Shofware CO a jde o open hardware se svobodným software. Je to vlastně více otevřené než Raspberry Pi, které schválně zdržuje uvolňování návrhů.

Podle Petra Stehlíka má Orange Pi lepší parametry a lepší poměr cena/výkon než Raspberry Pi. Jinak by to asi nemělo smysl vůbec vyrábět. Srdcem je procesor AllWinner H3, což je jádro ARM Cortex A7 a Mali GPU. Řada lidi se nad použitým procesorem ušklíbá, protože s AllWinnerem byly v minulosti velmi špatné zkušenosti. Mně ale všechno funguje, včetně 2D a 3D akcelerace.

Parametrově je Orange také na výši: má 2 GB RAM, 8 GB eMMC paměti, zvládá 4K UHD rozlišení, má integrovaný HEVC dekodér, rychlý gigabitový Ethernet, konektor na externí Wi-Fi anténu a poctivý napájecí konektor. Raspberry se stále drží microUSB, ale pro bezproblémové napájení doporučuje 2,5A zdroj, což je mimo specifikaci konektoru. Na desce je také spousta dalších prvků, které na RPi nenajdeme: mikrofon, infraport, SATA port, tlačítka, LED, sériový port a další.

Čtěte: seriál Orange Pi Plus: vybavený čínský počítač

Výrobce jako operační systém podporuje Linux a Android, dobrovolníci staví obrazy disků s dalšími systémy. Všechny jsou postavené na starém jádře 3.4, protože to je jediné, pro který AllWinner udělal patche, aby všechno fungovalo. Nejlepším zdrojem software je podle Stehlíka projekt Armbian, který nabízí podporu pro celou řadu zařízení. Mají vlastní opatchovanou verzi jádra a dokonce podporují nejnovější jádro s patchi, které míří do mainline jádra.

Uživatelé většinou na začátku stojí nad problémem, který model Orange Pi si vybrat. Vše je složité zejména proto, že pojmenování je velmi matoucí a jednotlivé modely se jmenují podobně. Petr Stehlík používá Orange Pi Plus, Orange Pi One a Orange Pi Zero. Zero je maličký, stojí okolo sedmi dolarů a pořád má všechny vlastnosti velké verze. Zároveň umí třeba pasivní PoE a je možné ho rozšířit za necelé dva dolary o rozšiřující desku.

Začít s Orange Pi je snadné, je potřeba si objednat desku a zdroj, zapsat image na kartu a spustit. Je to jednoduché, skvělé a velice levné. Paradoxně je to dostupnější než Raspberry Pi Zero, který i s poštovným stojí 17 dolarů. Tohle stojí 13 dolarů a je to výkonnější.

Jiří Eischmann: Flatpak: desktopové aplikace v kontejnerech

Flatpak jsou desktopové aplikace v kontejnerech. Kontejnery jsou v poslední době čím dál populárnější a desktopu se to také nevyhýbá. Tradiční způsob distribuce software se spoléhají na repozitáře, které nijak neoddělují aplikace a operační systém. Lidé by chtěli mít rozdílné vývojové cykly operačního systému a aplikace samotné, což s dynamickým linkováním není možné.

Další problém balíčkovacích systémů plyne z principu instalace do systému, kdy musíte důvěřovat tvůrci balíčku. Dáváte mu rootovský přístup a on má možnost při instalaci udělat cokoliv. Řešením je minimalizovat privilegia nutná k instalaci a omezit množinu operací, kterou je možné během instalace udělat. Už byly případy, kdy tvůrce balíčků udělal chybu a nová verze třeba smazala uživatelům data. (příklad) Proto jsou balíčky v distribucích testovány a jejich správci jsou prověřováni, ale takový postup neškáluje.

Flatpak umožňuje vytvořit jeden instalační soubor, který pak funguje na všech distribucích. Aby se aplikace dostala k uživatelům, není potřeba projít složitou cestou přidávání balíčků do různých distribucí. U aplikací instalovaných z internetu není možné vždy věřit autorovi, proto Flatpak aplikace odděluje a dává jím pokud možno co nejmenší přístup do zbytku systému.

Projekt vznikl v hlavě Alexe Larssona, který už v roce 2007 začal experimentovat s aplikací, kterou nazval glick. Skutečný vývoj ale začal v roce 2014 pod názvem Xdg-app a v červenci 2016 pak výsledek vyšel pod oficiálním názvem 2016. On pochází ze Švédska a tam IKEA balí nábytek do plochých krabic, čímž způsobila revoluci. Alex chce způsobit revoluci v balení aplikací, proto svůj projekt přejmenoval na Flatpak.

Flatpak využívá řadu technologií dostupných v linuxovém jádře: cgroups, namespces, bind mounts a seccomp. Dále se používá Bubblewrap, který původně vznikl přímo pro Flatpak a umožňuje běh kontejneru pod neprivilegovaným účtem. Na vytváření repozitáře aplikací a aktualizace se používá OSTree. Pro sestavování katalogu aplikací je použit AppStream a nově se používá také OCI format pro standardizaci kontejnerů. Flatpak by měl být v budoucnu schopen distribuovat obrazy v tomto standardizovaném formátu, ve kterém třeba budete distribuovat také obrazy pro Docker.

Aplikace se distribuují v samostatném kontejneru, jehož součástí můžou být také všechny závislosti. Abyste nemuseli do každého kontejneru balit úplně všechno, používají se takzvaný runtimy, které jsou sdílené a nabízejí nějaké základní knihovny a nástroje. Řeší to například problémy s bezpečností knihoven, takže když je pak potřeba například záplatovat OpenSSL, udělá se to na jednom místě. Pokud třeba máte dvacet aplikací vyžadujících GTK, můžete ho mít v systému jen jednou. Má to také dopad na spotřebu paměti a místa na disku.

Celý kontejner je pak zcela izolovaný a komunikovat by měl jen pomocí „portálu“, což je definované rozhraní pro komunikaci se systémem nebo dalšími aplikaci. Definované runtimy (prostředí pro běh aplikací) se připojují do /usr, aplikační bundle je pak v samostatném adresáři /app. Portály nabízejí kontrolovaný přístup aplikací k prostředkům mimo sandbox – soubory, tisk, otevírání URI, snímky obrazovky, upozornění, stav sítě, proxy a zařízení. Každý portál je řešený trošku jinak, třeba GTK přesměruje požadavek mimo kontejner a aplikace dostane přístup jen k jednomu uživatelem vybraného souboru. Aplikace si pak myslí, že má přístup všude, ale není to tak.

Dříve bylo potřeba všechny kroky při instalaci aplikace udělat ručně – přidat si klíče, přidat repozitář, poté nainstalovat a ručně spustit aplikaci. Dnes jsou k dispozici soubory pro různé akce: .flatpakrepo přidá repozitář, .flatpakref přidá repozitář a nainstaluje aplikaci, soubor .flatpak obsahuje celou aplikaci a všechny instrukce k její instalaci. Integraci do grafických aplikací je pak možné zajistit pomocí knihovny libflatpak.

Ve formátu Flatpak jsou k dispozici různé aplikace, například: 32 aplikací z GNOME, 19 z KDE, LibreOffice, různé edice Firefoxu, mpv, Spotify, Pitivi, GIMP, Darktable, Blender, Scribus, Skype, Telegram a mnoho dalších. Z hlediska distribucí je Flatpak ve Fedoře od 23, Debian v testingu (Jessie backports), Ubuntu 16.10, Arch Linu, openSUSE Tumbleweed, Gentoo přes neoficiální overlay, Mageia Cauldron a SolusOS.

V budoucnosti vznikne centralizovaný repozitář, který bude řešit infrastrukturu pro sestavování a šíření repozitáře. Lidé okolo Flatpaku pracují na něčem s pracovním názvem FlatHub, na kterém bude možné vytvářet osobní repozitáře s Flatpaky. Zároveň by měl vzniknout jakýsi katalog aplikací FlatStore, který ale nebude otevřený všem, ale bude do něj moci přispívat jen pověřený autor aplikace. Nechceme, aby se nám tam objevovaly stovky neaktualizovaných balíčků různých aplikací. Red Hat také plánuje automatické generování flatpaků z balíčků ve Fedoře. Získáte tak automatizovaně tisíce aplikací z už existujících balíčků.

Flatpak má ale i své nevýhody, mezi které patří například větší náročnost na diskový prostor. Zatímco balíčky LibreOffice ve Fedoře mají do 100 MB, runtime ve Flatpaku má 150 MB a samotný kancelářský balík dalších 150 MB. Runtime může být samozřejmě sdílen, takže se to špatně měří a generalizuje, nicméně tam určitě zvýšená náročnost je. Další nevýhodou je duplikace nutnosti oprav bezpečnostních problémů. To sice řeší sdílené runtime, ale ne všude. Pokud jsou knihovny bundlované s aplikacemi, je potřeba opravu aplikovat ve všech postižených flatpacích. Dále může být problém ve sdílení nastavení se zbytkem systému. Typicky jsme narazili třeba na vzhled či písmo. Grafické téma může být kompatibilní jen s knihovnou v systému, ale aplikace používá jinou verzi, která téma zobrazí rozbité. Zatím není sdílení témat podporováno a uspokojivé řešení zatím neexistuje. Flatpak také nemá žádný mechanismus pro instalaci rozšíření k aplikacím. Například pro GIMP je možné doinstalovat řadu modulů, ve Flatpaku se spoléhá na to, že to nějak vyřeší tvůrce aplikace.

David Karban: Serverless – neřešte servery kde nemusíte

Při klasické instalaci nového serveru je potřeba nasadit nový počítač nebo virtuál, nainstalovat aplikace a servery, monitorovat server, zálohovat ho a podobně. Celkově je ho hodně práce, server musíte hlídat a když se na něm něco rozbije, musíte to opravovat.

Se Serverless zákazník vytvoří sadu funkcí pro API, každá funkce dělá jednu věc. Říká se tomu nanoservice a hlavní výhodou je, že každá malá část se dá škálovat. Nevýhodou je, že je to trochu nepřehledné. Takové funkce jsou pak uloženy v kontejnerech, které se spouští jen v případě potřeby. Udělají svou práci, zruší se a proces je možné opakovat. Takže ty servery tam někde jsou, ale nestaráte se o ně. Správu vám zajistí někdo jiný.

Výhodou rozdělení aplikace je také možnost lepšího škálování a v cloudu je pak možné platit jen za používání funkcí. Běh platíte jen ve chvíli, kdy funkce běží. Pokud používáte klasický virtuální server, platíte za něj, ať v něm něco běží nebo ne. Většina běžných webových služeb má výrazně vyšší zátěž během dne, ale provoz stejného serveru platíme i v noci.

Jednotlivé funkce jsou bezestavové a spouští se jen na tu chvíli, kdy mají plnit svou úlohu. Když třeba uživatel přijde na astro web a chce vidět výseč oblohy, spustí se pro něj funkce, která načte data z databáze a vrátí mu třeba obrázek. Pokud přijde najednou deset uživatelů, spustí se proces desetkrát. Funkce jsou uzavřeny v kontejneru a každá z nich může být bez problémů napsaná ve zcela jiném programovacím jazyce.

Nejvhodnější použití je v aplikacích, které jsou závislé na vnějších akcích. V případě mailového serveru je například takovou událostí příchozí mail, který je potřeba zkontrolovat antispamem. Na webu je takto možné třeba postavit galerii, která bude spouštět funkci zpracování nově nahraného obrázku. Výhodou je, že za takový přístup zaplatíte výrazně méně. Zatímco za klasickou virtuální infrastrukturu můžete platit třeba tisíc dolarů měsíčně, za milion spuštění malých funkcí zaplatíte třeba osm dolarů. Platíte centy za jednotlivá volání.

Naopak se Serverless nehodí na nic, co vyžaduje výkon dlouhodobě. Když potřebujete počítat a využijete pro to osm jader po mnoho hodin, pak se vám tento přístup vůbec nevyplatí. Stejně tak pokud jsou funkce složité a vyžadují mnoho kroků nebo zpracovávají mnoho dat. Problémem takového distribuovaného přístupu je také problematické ladění chyb v kódu rozděleného do stovek malých funkcí.

Částečným řešením problémů komplexních aplikací jsou frameworky. Mezi takové frameworky patří Chalice, Apex, Zappa, Sparta nebo Serverless. Aplikace pak můžete spouštět u různých poskytovatelů: AWS Lambda, GCE Cloud functions, Azure functions, IBM OpenWhisk, Iron.io a další. Jako první s tím přišel Amazon a dnes je možné ze všech jeho 50 služeb zavolat svou mikro funkci v Lambdě. To umožňuje si doprogramovat cokoliv, co vám chybí.

AWS Lambda je založena na Amazon Linux AMI a podporuje jazyky Node.js, Java, Python, C# nebo je možné spouštět vlastní binárky. Je tam možné tedy možné spustit prakticky cokoliv, ale musíte nahrát vlastní binárky. Dnes je možné volat funkce přímo z JavaScriptu, takže uživatel přijde na statickou aplikaci uloženou na S3 a data do ní stáhne pomocí mikro funkcí Lambdě.

Ondřej Caletka: Analýza otrávené DNS cache

E-mail je stále využívaná služba, přestože je starší než web. Velkým problémem stále zůstává spam. Jedním ze způsobů boje se spamem jsou takzvané real-time black listy. Ty vyhodnocují, kdo kam posílá spam a zaznamenávají IP adresy serverů, které rozesílají spam. Pokud rozhodne, že některá adresa rozesílá spam, přidá si ji do databáze. Velmi snadno se může stát, že dojde k falešně pozitivnímu nálezu a pokud nepřijímáte podle blacklistu, máte velký problém.

Zkoumání na základě blacklistu je ale velmi levné, protože není potřeba žádný výkon a složité rozhodování, stačí se podívat do databáze. My na CESNETu používáme osm různých blaclistů a podle odpovědí dáváme mailům záporné body. Pokud je jich hodně, mail odmítneme. Pokud je jich velmi málo, poštu rovnou pustíme. Když si server není jist, podrobuje mail podrobnějšímu zkoumání.

Dotazuje se pomocí DNS a převrácenou adresou doplněnou příponou blacklistu. Je to podobné jako reverzní záznamy. Blacklist pak odpoví buď záznamem 127.0.0.1 nebo nedá odpověď žádnou. Takto se jednoduše na malý dotaz dozvíte, zda je adresa v databázi blacklistu.

V úterý 1. listopadu 2016 začal Nagios tvrdit, že se IP adresy CESNETu objevily na blacklistu UCEprotect. Ruční kontrola ale neukázala žádný problém. Ukázalo se, že za problémem stála otrávená DNS cache. Zmíněný Nagios používal vlastní resolver Unbound, do jehož záznamů se dostal falešný záznam. Hlavní DNS fungovaly správně, ale třeba kolega pozoroval doma na VDSL od T-Mobile totéž. Šlo tedy o větší problém. Otázkou tedy bylo, zda jde o cílený útok a jak mu pro příště zabránit.

Jako první byl použit systém RIPE Atlas, který má na celém světě 9000 sond a umožňuje zadat měření základních věcí: ping, traceroute, DNS dotazy a podobně. Můžete takto jít do spousty sítí a zeptat se, jak situace vypadá z jejich strany. Byl proto spuštěn test na všech českých a slovenských sondách a 500 sondách na zbytku světa. Celkem přišlo 758 odpovědí a 14 sítí vykazovalo otrávená data. Šlo tedy o nějaký globální problém a bylo potřeba hledat odpověď na autoritativních serverech.

Reálně tedy připadal v úvahu únos autoritativních serverů domény blacklistu. Mohlo dojít k únosu IP adres, mohl být unesen master server nebo mohla být unesena delegace. Ondřej Caletka provedl další analýzu pomocí RIPE Stats a zjistil, že autoritativní servery mají diverzitní rozmístění a jejich únos je proto nepravděpodobný. Zároveň kolektory BGP nezaznamenaly žádné změny v ohlašování daných IP adres a pro synchronizaci se nejspíše nepoužívají zónové přenosy. Zóny se přenáší rsyncem, takže všechny jsou master. Nemohlo tedy dojít k ovlivnění přenosu. Zbývala poslední možnost – někdo změnil delegaci v nadřazené zóně.

Skutečně se to potvrdilo, doménu uceprotect.net naposledy pozměnil někdo den před tím, než CESNET objevil problém. Na žádné službě sledující stav DNS jsem ale nenašel žádný důkaz o úpravě – údaje před touto změnou a po ní byly stejné. Proč tedy došlo k úpravě zóny, když se v ní nic neměnilo? Nezbývalo než kontaktovat správce blacklistu, který odpověděl, že někdo skutečně otrávil DNS servery pro různé domény a oni museli na server vložit znovu skutečné údaje.

Čtěte: Za výpadek známého blacklistu mohla unesená doména

Nejpravděpodobnějším vysvětlením je hacknutí registrátora, kterým je v tomto případě PSI-USA, jejichž web ale nevypadá jako web registrátora. Pokud chcete vidět, jak vypadal web v roce 96, podívejte se tam. Nejspíš se někomu podařilo hacknout servery této společnosti a změnil delegaci některých domén. Servery, na které byly domény delegovány, stále ještě existují a obsahují asi 1000 domén. Některé domény jsou na ně stále delegovány, takže správci si toho nevšimli.

Proti takové změně je možné se bránit pomocí DNSSEC, což by v tomto případě pravděpodobně nepomohlo. Proti injektování obsahu do zóny při přenosu zase pomáhá TSIG, který podepisuje přenos zónových souborů pomocí sdíleného tajemství. Český registr také umožňuje zamykání na úrovni registru, takže od registrátora není možné do takto zamčené zóny zasahovat. Dále je dobré mít v rekurzivním serveru nastavený limit na maximální hodnotu TTL, aby při vrácení delegace na původní hodnotu nezůstaly v keších podvržené údaje příliš dlouho.