Letošní konferenci zahájil opět tradičně hlavní organizátor Petr Hodač. Na letošní LinuxDays bylo přihlášeno celkem 105 přednášek, přijato jich do programu bylo 70. To znamená, že se snažíme pracovat na kvalitě.
Registrovaných bylo přes tisíc návštěvníků, což je zhruba o třetinu méně než obvykle. Jsme rádi, že jste tady, je to nový start po covidové době.
Organizátoři si dávají pozor, aby se akce tématicky příliš nerozmělnila a držela se především technických témat s přesahem do praxe. Většina ostatních technických konferencí postupně někam tématicky odplavala. Buď do komerčních prezentací nebo do obecných společenských témat. My jsme technici a chceme se držet odborných přednášek,
řekl Hodač.
Lukáš Bařinka: Proměnné v shellu
Parametr je entita, která ukládá hodnoty. Proměnná je parametr označený jménem. Proměnná má hodnotu a může mít nějaké atributy, které říkají, co je možné s proměnnou dělat.
Už při zapnutí shellu jsou některé proměnné naplněné a my se na ně můžeme podívat.
Když v shellu použijeme název proměnné a dáme před něj dolar, je název nahrazen hodnotou. Můžeme tedy zavolat například echo a předat mu proměnnou. Samotné echo o ní nic neví, shell mu ji nahradí hodnotou, kterou echo jednoduše vypíše.
Například echo $BASH_VERSION nám vypíše současnou verzi Bashe.
Pokud chceme zjistit další podrobnosti o některé proměnné, můžeme použít vestavěný příkaz declare, který s parametrem -p vypíše hodnoty proměnné včetně atributů. Nevypíše to navíc samostatně, ale rovnou jako příkaz pro vytvoření dané proměnné včetně všech vlastností.
Syntaxe práce s proměnnou je jednoduchá, ale často jsou s ní problémy. Základní syntaxí je název, rovná se a hodnota. Pokud je hodnota prázdná, bude prázdná i hodnota uložená v proměnné.
Shell expanduje hodnoty, které dávají smysl, například vlnovku, substituci příkazů, aritmetickou expanzi a podobně. Pokud máte ale v proměnné více slov a bojíte se rozpadnutí, bát se nemusíte. K tomu nedochází, ale nic se nestane, pokud to pro jistotu dáte do uvozovek.
K vyprázdnění hodnoty stačí naplnit proměnnou prázdnou hodnotou, ale tím proměnná nezmizí. Pokud ji skutečně chcete zrušit, existuje příkaz
Proměnnou můžete také naplnit pomocí příkazu unset.printf s parametrem -v, který zajistí uložení výstupu do proměnné. Můžete také použít příkaz
declare, který umí založit proměnnou rovnou i s atributy.
Pokud potřebujeme použít proměnnou uvnitř textu a potřebujeme jasně stanovit hranice jména proměnné, použijeme složené závorky: ${VAR} . Je dobré se to naučit používat, abyste nemuseli při použití proměnné přemýšlet, jak to udělat správně.
Stejně tak je dobré používat automaticky uvozovky, aby se obsah proměnné nepoužil jako jednotlivá slova: "${VAR}" .
Syntaxe se složenými závorkami nám umožňuje pracovat s proměnnou různými způsoby. Pokud před její jméno přidáme mřížku, dostaneme délku proměnné. Můžeme také při použití neexistující hodnoty přiřadit nějakou výchozí hodnotu. Můžete si také vzít jen nějakou část hodnoty proměnné.
Pokud máme například v proměnné uloženou cestu, můžeme odkázat jen na část adresářů pomocí: ${file:5}. Máme také možnost odříznout například proměnnou pomocí: ${file%.gz}. Lze tu použít i shellovský vzor, takže některé znaky mohou být volitelné.
Pomocí lomítek máme možnost také při výstupu nahrazovat část hodnoty za jinou: ${file/service/srv}. Podobně je možné také změnit velikost písmen pomocí stříšky a čárky. Pro transformaci proměnné pak slouží symbol zavináče, který je následovaný jednopísmenným příkazem. Můžeme si tak například nechat automaticky oescapovat speciální znaky, abychom je pak mohli bezpečně použít.
Proměnné můžeme testovat, pro což existuje vestavěný test [[ ]], který může zjišťovat naplnění, abecední řazení, číselné porovnání nebo můžeme využít shellovský vzor nebo regulární výraz. Aritmetiku pak můžeme používat pomocí dvou kulatých závorek: (( )). V nich nemusíte používat dolar, protože v aritmetice písmenka znamenají proměnné.
Pavel Machek: Vaše oblíbená distribuce v kapse
Pavel Machek řekl, že by si chtěl vybrat libovolný telefon, distribuci, prostředí a aplikace. Pak vše nainstalujeme a používáme. Tam ještě úplně nejsme, ale už se blížíme.
Hlavním důvodem použití Linuxu na telefonu je možnost jeho pohodlného skriptování.
Základem je vybrat správný hardware, což dneska znamená ideálně PinePhone, který stojí okolo čtyř tisíc korun. Tohle je řešení, které bych vám doporučil, má to i kill switche.
Pokud chcete lepší poměr cena a výkon, je lepší sáhnout po zařízeních původně určených pro Android – třeba po OnePlus 6T nebo Motorola Droid 4. Takových zařízení jsou mraky a lidi se nemůžou shodnout, co mají používat.
Klasickým hardwarem je Nokia N900, což je opravdu starý hardware, který se dnes dá sehnat za dvě stovky. Už fungují i hovory, které byly dlouho problém.
Limitující je dnes ale jen 256MB paměť, ve které si nemůžete příliš vyskakovat.
PinePhone je naopak dnes běžně vybavený telefon se čtyřjádrovým procesorem, dvěma či třemi gigabajty paměti a běžnými senzory. Podobným telefonem je Librem 5, který ale obsahuje průmyslový SOC a vydrží na baterii jen asi deset hodin. Na Droid 4 je možné dualbootovat Android a je možné na něm provozovat různé operační systémy.
Dokud jsme používali PC, byl hardware velmi kompatibilní a linuxové jádro zajišťovalo hardwarovou abstrakci. Pak se to nějak zvrtlo a výrobci začali dělat cokoliv, protože přece Linux na tom poběží.
Týká se to různých modemů, grafických karet, kamer, práce s videem nebo jen obyčejného nabíjení. Je peklo s tím pracovat a hardwarová abstrakce pro to neexistuje.
Podporu grafiky zajišťuje tradiční a dlouho vyvíjený projekt X11, postupně přichází Wayland, který ale zatím neumí všechno. Budoucnost je zřejmě ve Waylandu.
Grafických prostředí máme přehršel a války o nejlepší prostředí se přenesly i do mobilního prostředí. Máme tedy Gnome, Plasma mobile, Maemo, SXMO, Phosh a další. Každý má své výhody a nevýhody a konkurence je důležitá. Vyberte si.
Základní věci už fungují, s telefony se dá telefonovat. Nahrávání videa je ale stále ještě problém.
V Linuxu máme standardní řešení zvané libv4l2, která je ale zaměřena na televizní karty. Za tou sedí nějaký profesionál, který vše připravil, nastavil a zaostřil a vy dostáváte kvalitní vstup, který jen ukládáte na disk.
Kamery v telefonech jsou spíše chytré senzory, které se snaží zastoupit celé televizní studio. Je to velké plýtvání křemíkem, protože dnes máme v telefonech několik velmi chytrých kamer.
Řešením mohou být jednoduché hloupé kamery, na které ale svět není příliš připraven. Vše si musíme vyřešit v procesoru, musíme ostřit, vyvažovat bílou a dělat další věci.
Vyvíjí se knihovna libcamera, která tohle všechno postupně implementuje, ale vývojáři se snaží nenaštvat velké výrobce. Proto ty zajímavé věci dělají uzavřené binární součásti.
Konkurenčními řešeními jsou megapixels a millipixels. Samostatnou kapitolou je práce s videem, pro kterou potřebujeme hardwarovou akceleraci. To není maličkost a budou s tím ještě problémy.
Také distribucí existuje celá řada, můžete si vybrat: Mobian, SUSE, Fedora, Meamo Leste, Ubuntu Touch nebo Jolla/Sailfish. Ta je kus open-source a část zase ne, je to komerční řešení. Dává to smysl, pokud chcete Linux tady a teď.
Doporučenou kombinací je PinePhone s Mobianem – telefonuje to a posílá zprávy, Firefox běží včetně přehrávání videa a Gnome je použitelné. Ostatní aplikace tak nějak běží, ale tvůrci by je měli přizpůsobit používání na mobilním displeji.
Telefon má i použitelnou výdrž a je přiměřeně stabilní. Problém je s usínáním telefonu, což sice šetří baterii, ale komplikuje to programování některých aplikací na pozadí.
Mezi nevýhody tohoto řešení je velikost telefonu, relativně nízký výkon procesoru, horší kvalita obrazu z fotoaparátu, problematický konektor USB-C a špatná čitelnost na přímém sluníčku. Citlivost na mobilní signál není příliš velká a GPS je spíše slabší.
Ještě je potřeba odvést hodně práce například s GUI, virtuální klávesnicí, indikací síly signálu a podobně.
Velké díky patří společnosti Purism, která posunula vývoj z amatérských pokusů na novou úroveň. Kupte si od nich něco, abyste je podpořili.
Druhou zajímavou firmou je Pine64, která sice nedělá tolik pro otevřený svět, ale zase dělá použitelnější zařízení.
Pokud chcete pomoci, můžete začít s testováním, dokumentací, překlady a vývojem. Spousta práce je na kernelu, je možné se podílet na vývoji distribucí nebo vyvíjet aplikace. Práce je neomezeně.
Štěpán Bechynský: Návrhové vzory v české kuchyni
Štěpán Bechynský pracuje jako školitel ve společnosti Microsoft, ale zajímá ho vaření a nakonec se vyučil kuchařem. Já jsem programátor a česká kuchyně má návrhové vzory. Základní návrhový vzor je UHO: univerzální hnědá omáčka.
Přednáška měla velmi netradiční téma, přesto (nebo právě proto) na konferenci velmi zaujala.
Většina jídel, která dnes považujeme za česká, pocházejí z rakouské monarchie. Pokud pojedete třeba do Bavorska, najdete tam úplně stejné jídlo.
Řada jídel k nám také přišla odjinud nebo byla v průběhu let hodně změněna. Svíčková se například původně dělala z telecí sekané.
Guláš pochází z Balkánu, řízek pravděpodobně z Itálie a knedlík z Rakouska. Většina krajových jídel je sezónních a vychází z toho, jaké suroviny byly k dispozici.
Po válce se začalo vše normovat a dělit do pěti tříd. Všude se vařilo podle standardu a všude se vařilo stejně. Tohle je dnes školní jídelna.
Když touhle standardizací projdete, pochopíte tyhle připravené návrhové vzory. Jsou extrémně jednoduché a opakuje se tam dokola pořád to stejné.
Když tedy podle tohoto uvaříte několik jídel, uvaříte pak už cokoliv. Nemusí to být hned od začátku k jídlu, ale uvaříte to.
Gramáže jsou uváděny pro deset osob a jsou rozděleny pro pracující rukama a lidi v kanceláři, kteří nepotřebují tolik kalorií.
Po roce 1989 došlo k výrazným změnám, ale jídlo je stále hlavním způsobem, jak je možné ušetřit. Klasickým českým jídlem ale zůstává flák masa, pořádně zahuštěná omáčka a příloha, do které se krásně nasákne omáčka. Navíc vyrobit třeba knedlík nestojí nic.
Základním receptem je UHO, které známe všichni ze školní jídelny. Tvrdé maso, hustá omáčka a kolínka, ze kterých teče studená voda.
Česká kuchyně zná čtyři druhy omáček: cibulovou, cibulovo-paprikovou, cibulovo-slaninovou a zeleninovou. Z toho se dělá většina jídel, které známe z jídelen.
Poté stačí už jen přidat další ingredience podle toho, co potřebujeme vyrobit: kyselé okurky, vejce, houby a podobně. Výsledek můžeme různě vylepšit třeba máslem, smetanou a podobně.
Petr Stehlík: Zigbee, Thread, Matter a Espressif
Pro bezdrátovou komunikaci s čidly je možné použít celou řadu různých bezdrátových technologií. Wi-Fi byla vytvořena pro trvalé spojení a je tedy náročné na energii. Z mého pohledu není možné použít takové čidlo při provozu na baterii.
Je možné sice zařízení uspávat, ale po probuzení se musí obnovit spojení a to nějakou dobu trvá. Aktuální Wi-Fi 6 už na IoT myslí a má významnou podporu pro low-power. Je ale nutné obměnit veškerý hardware.
Bluetooth je navrženo pro krátkou vzdálenosti a počítalo se s nízkou přenosovou rychlostí. Nehledělo se ani příliš na nízkou spotřebu.
Až verze pět přinesla podporu BLE a postupně se zvyšuje dosah. Pořád je ale dosah krátký, Bluetooth neprojde přes několik panelákových zdí.
Dosah je možné prodloužit pomocí ESPHome Bluetooth Proxy, které dokáže předávat informace dále v síti.
Postupně se začaly objevovat další standardy jako Z-Wave a Zigbee, které mají větší dosah a umožňují sestavit mesh síť. V takové síti komunikuje každý s každým a vytváří se tak stabilní síť, která umožňuje automatickou rekonfiguraci.
To zároveň znamená, že stačí nižší vysílací výkon. Během několika let bylo jasné, že se na trhu prosadí Zigbee – existuje široká nabídka žárovek, teploměrů, čidel a dalších věcí.
V síti je potřeba mít jednu bránu, která propojí zařízení do cloudu výrobce. Každý výrobce to má udělané po svém, posílá data do cloudu a není kompatibilní s nikým jiným.
Proto je možné použít Zigbee2MQTT nebo připojit bránu do Home Assistentu.
Chytří lidé se tedy rozhodli vytvořit další standardy, které zastřeší všechny ostatní: Thread a Matter. Vše je čistě softwarové a není problém propojit různá zařízení.
Vzniká hybridní síť, ve které vše může komunikovat pomocí IPv6. Nemusíme komunikovat přes cloud někde v Číně.
Jakub Onderka: Zabezpečení e-mailové komunikace a jak jsme na tom
Stav zabezpečení e-mailové komunikace není ani po letech příliš dobrý. Asi deset procent komunikace posíláme stále jako korespondenční lístek. Každý si ho může přečíst, každý ho může upravit a poslat dál.
Zhruba osmdesát procent mailů lze připodobnit dopisu, kde je text uvnitř obálky. Abychom se k němu dostali, musíme překonat nějaká bezpečnostní opatření.
Pouze deset procent e-mailů je zabezpečeno tak, jak by to mělo být.
Zabezpečení e-mailové komunikace je mnohem horší než u běžných webových stránek, ke kterým přistupujete. Je to proto, že do SMTP se dostalo něco, čemu říkáme oportunistické šifrování. Před lety nebyl internet tak rozšířený a nezávisel na něm celý svět.
Postupně se ale situace změnila, proto v roce 1999 vzniklo právě oportunistické šifrování pomocí STARTTLS. Jde o způsob, kdy se musí obě strany nejprve dohodnout na tom, že budou šifrovat. Je to proto, aby byla komunikace i zpětně kompatibilní.
Toto šifrování brání i proti Man-in-the-middle (MITM), ale jen pokud útočník pouze pasivně poslouchá. Pokud je aktivní a má možnost do komunikace zasahovat, může si poštu přečíst.
Komunikace vždy začíná v prostém textu a později server oznámí, že umí STARTTLS a pokud s tím klient souhlasí, přejde se na šifrování. Útočník ale může do komunikace zasáhnout a odstranit z úvodní textové komunikace řetězec STARTTLS, což je možné provést velmi snadno. Na základě toho to vypadá, že šifrování není podporována a použije se nešifrovaná komunikace, kterou pak může útočník číst.
Je možné to ale udělat ještě chytřeji, protože protistrany si sice vymění certifikáty, ale neověřují, zda jsou vystaveny pro správný server. Podle platných standardů má akceptovat libovolný certifikát, vůbec na něm nezáleží.
Útočník tak má opět možnost komunikaci narušit a poštu si přečíst.
V roce 2020 proběhl test osmnácti významných institucí, který dopadl katastrofálně. Tři instituce vůbec nepodporovaly šifrovaný přenos pošty, pět institucí mělo povolené i dávno prolomené algoritmy, pět institucí mělo drobné problémy v nastavení a jen čtyři instituce měly vše v pořádku. Před třemi lety nebyl stav ani u takto významných institucí vůbec dobrý. Navíc i správně nastavené šifrování bránilo jen pasivnímu útoku.
Případný útok je pak alespoň detekovatelný z logů, kde je vidět změna poměru šifrované a nešifrované komunikace.
Obecně je ale velmi těžké říct, kolik podobných útoků ve skutečnosti probíhá. Zatímco ransomware pravděpodobně odhalíte, odposlechu si nemusíte všimnout mnoho let. Přišly proto dvě technologie, které se snažily problémy vyřešit: DANE a MTA-STS. Ani jedna z nich ale není široce podporovaná. Aby správně fungovaly, musí je podporovat jak příjemce, tak odesílatel.
Bylo tedy potřeba zvýšit popularitu těchto technologií, aby je provozovatelé různých serverů nasadili. DANE závisí na DNSSEC a vkládá otisky certifikátů do DNS, zatímco novější MTA-STS nevyžaduje DNSSEC a zveřejňuje informace po HTTPS. Je to výrazně složitější cesta a není ani tak bezpečná. Přiklánějí se k ní ale velcí poskytovatelé.
NÚKIB přemýšlel, co se dá udělat pro zlepšení situace. Nemusíme dělat nic, což volí většina států v Evropské unii a nechávají to na poskytovatelích.
Druhou variantou je nařídit alespoň zavedení základních bezpečnostních mechanismů. To ale stejně neřeší problém s aktivním MITM.
Třetí možností bylo nařídit zavedení DANE nebo MTA-STS. Kterou z nich ale zvolit a jak to nařídit? Mohli jsme vydat doporučení, nebo jít cestou nařízení vlády nebo ochranné opatření v podobě vyhlášky.
Nakonec byla v roce 2021 zavedena veřejná vyhláška [PDF], podle které musí organizace zavést následující opatření: STARTTLS, podporu aktuálních algoritmů, důvěryhodný certifikát a zavést DANE.
MTA-STS nebylo zvoleno, protože je komplikovanější, vyžaduje obvykle zásah od několika různých správců a je náchylnější na chyby. Musíte provozovat HTTPS server a nesmí vám na něm vypršel certifikát.
Navíc poštovní server musí mít prostup na HTTPS do internetu, což může znamenat další bezpečnostní slabinu. Přestože MTA-STS přímo nevyžaduje DNSSEC, je možné bez něj šifrování opět obejít odstraněním DNS záznamu v komunikaci. Na rozdíl od DANE není MTA-STS tak široce podporované v serverech, například Postfix pro podporu vyžaduje externí aplikaci.
Česko se tak stalo prvním státem na světě, který vyžaduje DANE zákonným opatřením a má komplexní regulaci zabezpečení e-mailové komunikace. Nizozemsko například vyžaduje DANE pro veřejné instituce, ale zavádění nemůže vymáhat.
Podobně je to v dalších zemích a Evropská komise takové opatření jen doporučuje. Spojené státy zatím váhají nad tím, kterou variantu řešení zvolit.
Po dvou letech je situace výrazně lepší, všechny zkoumané instituce podporují STARTTLS, žádná nemá zastaralé algoritmy a čtrnáct mělo vše nastaveno správně. Deset z osmnácti institucí mělo dokonce zveřejněn TLSA záznam.
NÚKIB průběžně ověřuje plnění opatření, v tuto chvíli má 54 % regulovaných institucí zveřejněný TLSA záznam pro SMTP. Za nedodržení je možné udělit pokutu až jeden milion korun. V současné době spíše upozorňujeme správce na to, co mají špatně.
Radek Zajíc: GNU/Linux na sítích bez IPv4
Dnes máme kolem sebe dva internety: ten starší má zhruba čtyři miliardy IPv4 adres, ten druhý používá hexadecimální zápisy dlouhých adres. Tyhle dva internety používají různé adresy a pokud k nim chcete mít přístup, musíte se ještě trochu snažit.
Podle statistik společnosti Google přistupuje k internetu po IPv6 zhruba 45 % uživatelů, v některých zemích je to i přes sedmdesát procent.
Původní plány na IPv6 počítaly s tím, že v sítích budou vedle sebe dostupné oba protokoly. Tomuto řešení se říká dual-stack a zařízení si může vybrat, který protokol k dané komunikaci použije.
Pokud přistupujete ke službě, která IPv6 podporuje, a vy sami máte patřičnou konektivitu, automaticky ji použijete. Pokud máte jen IPv4, tak si vybrat nemůžete a musíte použít jen starší protokol.
V síti není možné řídit, kterým protokolem proběhne komunikace.
V dual-stacku je tedy nutné provozovat oba protokoly v celé síti, musejí ho podporovat všechny prvky a zvyšuje to riziko chyby. Zároveň to neodstraňuje nevýhody IPv4, jako je zejména nedostatek adres nebo kolize adres v různých sítích.
Typicky se to stává při použití VPN nebo při snaze propojit dříve oddělené sítě, třeba po fúzi dvou firem.
To motivuje provozovatele sítě k přechodu do režimu IPv6-only, kde vůbec IPv4 používat nebudeme. Zjednodušíme tím síť, zlevníme provoz a zajistíme si přístup do IPv4 skrze brány. Odstraní to nějaké další problémy, jako potřeba konfigurovat služby pro IPv4 i IPv6 zvlášť. Některé aplikace se třeba mohou rozhodnout na localhostu poslouchat jen na 127.0.0.1 a ne na IPv6, kde se používá jiná adresa.
Síť pouze s protokolem IPv6 můžeme provozovat tak, že přístup do IPv4 zajistíme jako službu překladu s pomocí DNS64 a NAT64. Novinkou jsou sítě IPv6-mostly, kde síť klientovi říká, že pokud nemusí, může si IPv4 odkonfigurovat a nepoužívat ji.
Posledním krokem pak je skutečná IPv6 only, kdy nemáme vůbec přístup do IPv4 a můžeme přistupovat jen ke zdrojům s IPv6.
Při použití NAT64 a DNS64 se na adresy v IPv6 přistupuje přímo, ale při potřeba komunikace se světem IPv4 se přepisují adresy v DNS tak, že se generují nové adresy v prostoru IPv6. Pro klienta to pak vypadá tak, že celý svět podporuje IPv6. Provoz se pak na hraně sítě překládá do skutečné IPv4 a odpovědi zpět.
V Linuxu je pro NAT64 možné použít nástroj Jool, DNS64 nám dokáží zajistit resolver Unbound nebo Knot Rersolver. Existuje i veřejný NAT64, který poskytuje jeden dobrovolník. Pokud věříte, že vaše data budou v bezpečí, můžete si ji vyzkoušet.
Najdete ji na nat64.net.
Některé aplikace mohou vyžadovat ale přímé připojení k IPv4 adrese, což v síti pouze s IPv6 není možné. Proto je možné na koncovou stanici nainstalovat CLAT, který vytvoří další síťové rozhraní s IPv4 adresou, které data překládá mezi protokoly do IPv6 a odešle do místní sítě. Na hranici jsou zase přeloženy do světa IPv4 a pošle je do internetu.
V Linuxu je CLAT implementován v nástroji Tayga, který v některých distribucích (Fedora a openSUSE) najdete v balíčku clatd.
Při použití sítě pouze s IPv6 je možné narazit na různé problémy, například se nenačítají obrázky na webu Fedory, není možné použít GitHub, nefunguje přístup k repozitáři Snapů v Ubuntu a rozbije se například také určování polohy uživatele. Normálně vám Ubuntu nabídne českou časovou zónu, klávesnici a rozhraní. Na IPv6-only síti se mi nainstalovalo Ubuntu napůl v němčině a angličtině.
Dual-stack je plně funkční, ale neměl by tu zůstat navždy, protože nás nezbaví IPv4. IPv6-only zcela bez IPv4 je také funkční, ale spíš jen pro izolovaná prostředí. NAT64 je obecně jediný přijímaný NAT ve světě IPv6 a řeší přístup k většině zdrojů bez IPv6.
CLAT a TNAT64 jsou dobré mechanismy pro podporu starších aplikací.
Nejběžnější distribuce Linuxu jsou dobře použitelné v prostředí NAT64 a DNS64. S IPv6-only to tak slavné není.
Stejně tak IPv6-mostly je zatím v Linuxu zatím hudba budoucnosti.
(Autorem fotografií je Petr Krčmář.)
