Ondřej Caletka: netiketa v e-mailové komunikaci
Netiketa je soubor pravidel slušného chování na internetu, kodifikována byla v roce 1995 v RFC 1855. Závazná pravidla ovšem neexistují, ale existuje obecný názor o tom, co je to slušné chování. Většina věcí v této přednášce vychází z názorů, které jsou základem slušného chování na síti. Můžete se ale chovat jinak, internet je pořád ještě docela svobodný.
Základní myšlenky říkají, že internet je veřejný prostor a vy nejste středobodem vesmíru. Jsou tu i jiní lidé a měli byste na ně brát ohled a nebýt sobečtí.
Zbytek přednášky se pak zabýval konkrétně netiketou v e-mailové komunikaci, kterou používáme prakticky všichni, ale většina lidí při tom dělá řadu chyb.
Problém začíná už při volbě předmětu zprávy, který by měl shrnovat obsah zprávy a neměl by být prázdný ani příliš obecný. Existuje řada lidí, kteří dostávají víc e-mailů, než stíhají číst. Správně zvolený předmět je jediný způsob, jak na první pohled zjistit, co je obsahem zprávy.
Je tedy potřeba se nad názvem zamyslet, podobně jako v původním Twitteru, kdy jste se museli snažit myšlenku vložit do 140 znaků.
Pak přichází obsah zprávy, který vychází z klasických dopisů, takže by měl začínat oslovením a končit podpisem. E-mail by měl být zdvořilý, snadno čitelný a stručný. Protože píšeme e-mail v češtině, měl by být rozhodně s diakritikou. Chápu, že pro programátory je nepříjemné přepínat klávesnici. Pokud si programátoři píší mezi sebou krátkou zprávu, asi to není potřeba řešit. Pokud ale píše dlouhý referát mnoha lidem, je to velmi neslušné, protože se text bez diakritiky výrazně hůře čte a může dojít k omylu.
Zpráva by měla být také zalomená na 72 znaků na řádek, měla by využívat tradiční zvýrazňovací značky a neměla by obsahovat výkřiky a velké množství smajlíků. Myslel jsem si, že většina lidí slyšela o základech typografie, jak se píší čárky ve větách a tak dále. Zjistil jsem ale, že to tak není. Měli byste vědět, že se za čárkou píše mezera, a podobně.
Stále platí, že slušný e-mail je napsán v prostém textu a případně zároveň v HTML. Stále jsou lidé, kteří čtou poštu v terminálu a je pak problém dostat text, pokud máte k dispozici jen HTML.
I v případě HTML je potřeba být střídmý a nepoužívat příliš obrázků, vyhnout se blikání nebo podtržení.
Problematické jsou také přílohy, které umožňují posílat jakékoliv soubory. Rozhodně by se nemělo posílat více než několik málo megabajtů, protože kvůli překódování do Base64 je přenos binárních souborů velmi neefektivní.
Pro přenos souborů by se měla používat spíše některá specializovaná služba a uživatel by pak měl obdržet jen odkaz ke stažení.
Před samotným odesíláním musíme ještě rozhodnout, kam vyplníme adresu příjemce. Máme možnost použít hlavičku To, Cc, Bcc nebo Reply-To. Jsou lidé, kteří dostávají mnoho různých e-mailů, takže čtou jen to, co je určeno přímo jim. Pokud jsou jen v kopii, není pro ně pošta tolik důležitá a nemusejí se jí věnovat.
Bcc je skrytá kopie, která se hodí pro jednoduché hromadné e-maily. Pokud chcete poslat zprávu více různým lidem, používejte Bcc, abyste nevyzrazovali všem kontakty dalších lidí.
Reply-To se pak používá, pokud si přejete obdržet odpověď na jinou adresu. Pak už zbývá jen zprávu odeslat.
Pokud jsme sami e-mail dostali, musíme na něj odpovědět. To je ještě složitější než vytvořit nový e-mail.
Můžeme například různým způsobem citovat předchozí konverzaci. Měli bychom to dělat, protože se předpokládá, že mezi výměnou jednotlivých zpráv může uplynout dlouhá doba. Sluší se tedy připomenout, o čem jsme se bavili dříve.
Většina e-mailových služeb a klientů dnes používají takzvaný top-posting: citaci vloží dolů a nad ní uživatel odpovídá. Vypadá to dobře, protože odpověď je hned vidět a pod ní je pak iluze historie. Na druhou stranu pokud už má e-mail pět odpovědí, musíte velmi složitě hledat kontext.
Opak toho je pak bottom-posting: na začátku e-mailu odcitujete původní text a pod ni odpovíte. Problém je, že čtenář původní text zná, protože ho sám napsal. Musí tedy odrolovat dolů, aby si přečetl vaši odpověď. Takto rozhodně ne.
Ideální je inline odpověď. Odcituje se jen relevantní část e-mailu, pod ni vložíme odpověď. Většinou se to nepoužívá, protože lidé nevědí, že jejich klasické používání e-mailu nedává smysl.
Rozhodně je správně, když v odpovědi odstraníte nadbytečný text z citace. Je ale neslušné vytrhávat z kontextu a zneužívat výběrové citace k tomu, abyste citovali něco, co pisatel nechtěl říct.
Zprávy jsou dnes často řazeny do vláken, k čemuž pomáhají neviditelné hlavičky. Message-ID, In-Reply-To a References. Tím se mohou stroje dozvědět, jak konverzace navazuje a umí ji zobrazit.
Chybou je, když uživatel místo vytvoření nové zprávy najde nějaký starý e-mail, vymaže text i předmět a vyplní vše znovu. Vypadá to, že je to stejné, ale není. Klient totiž do zprávy vyplní hlavičky, jako by byla odpovědí.
V tu chvíli dojde k takzvané krádeži vlákna, kdy se dovnitř vlákna začne míchat jiné téma. Stává se to velmi často v e-mailových konferencích.
Podobně dochází k rozbití vlákna, pokud uživatel vytváří odpověď ručně a ne pomocí tlačítka Odpovědět – pak se návaznost na vlákna samozřejmě ztratí a zpráva ze struktury vypadne.
Samostatnou kapitolou jsou pak e-mailové konference, kde nějaký automat spravuje seznam příjemců, detekuje nedoručitelné adresy, vyrábí archivy a souhrny. Stačí pak zprávu poslat do konference a ta pak přijde všem příjemcům najednou. Dávejte si pozor při mačkání tlačítko Odpovědět. Obvykle totiž existuje i tlačítko Odpovědět do konference. V prvním případě odpovídáte jen pisateli původní zprávy.
Každá konference má také svého správce (owner), který se o ni stará. Rozhodně byste neměli do konference psát, že si přejete odhlásit. Odběratelé konference vás odhlásit nemohou, jen je obtěžujete nesmyslným požadavkem.
Odhlásit se můžete buď přímo v e-mailovém klientu nebo ve webovém rozhraní, na které obvykle vede odkaz v patičce. Pokud všechno selže, ozvěte se správci konference. Jen ten vás může odhlásit.
Všechna tato pravidla jsou jen slušné chování, ale bez něj bychom daleko nedošlo. Nejdřív čtěte, pak až pište. Dodržujte také posting style konkrétní konference.
Podobná pravidla platí v určité míře i pro jiné platformy.
Milan Beneš: ČVUT SÚZ reinstall – rok a půl poté
Přednáška se týkala převzetí správy sítě ČVUT SÚZ (Správa účelových zařízení), což je servisní organizace starající se ubytování a stravování studentů a zaměstnanců. V červnu 2016 vznikl nový ICT tým, původně bylo vše odsourcováno do externí firmy. Po změně vedení bylo rozhodnuto, že je potřeba zefektivnit mnoho věcí včetně IT.
Síť je rozvinuta na mnoha lokalitách po celé Praze, původně bylo vše organizováno jako jeden L2 segment. Potřebovali jsme vše zjednodušit, redukovat počty routerů s NAT a zavést správcovskou VLAN.
Zároveň byly zlikvidovány morálně i technicky zastaralé síťové prvky. Chtěli jsme, aby ty nové měly podporu automatizace a prostředí bylo co nejvíce homogenní.
Nakonec ve výběrovém řízení uspěla společnost Juniper.
Veškerá konfigurace se provádí pomocí Ansible, je možné snadno dokumentovat, porovnávat nebo se vracet k předchozím stavům. Role od Juniperu jsou velmi dobře udělané a všechny prvky je možné ovládat velmi deterministicky.
V plánu je síť dále učesat, rozdělit ji do různých L2 domén a ty propojit pomocí L3. Bude to především bezpečnější.
Na začátku byla k dispozici celá škála různých serverů, drtivá většina z nich už bez jakékoliv podpory. Zálohovalo se na NAS od Synology, což podle mě do produkce nepatří.
Virtualizovalo se na Hyper-V a dimenzováno to bylo tak špatně, že kvůli novému virtuálu bylo nutné kupovat další licenci. V první řadě bylo nutné se zbavit Windows, začali jsme stavět od nuly a postupně přenášeli věci na Linux.
Poté nastala realizace sdíleného storage postaveného nad Gluster nad ZFS. Začínali jsme s BSD, ale projevil se tam nedostatečný výkon Glusteru, takže teď běžíme na Gentoo. Vše má samozřejmě štábní kulturu a používáme Ansible.
Nyní má síť dvě serverovny: v areálu Strahov a na Masarykově koleji.
Kromě toho byl aktualizován také telefonní systém, původně nebyla k dispozici ani jednotná telefonní síť. Velmi oblíbené u nás bylo například faxování. Z bloku na blok.
Na základě ekonomické rozvahy bylo rozhodnuto o přechodu na VoIP s telefony od Yealink a bránou Yeastar. Aktuálně máme zapojeno 220 a terminálů a měsíčně nám toto řešení šetří na hlasových službách 55 tisíc korun.
V současné době se pracuje na novém webu, je potřeba rekonstruovat fyzickou vrstvu sítě, připravit nový kamerový systém a pořídit novou Wi-Fi síť postavenou na kontrolerovou strukturou. Potřebujeme se také zbavit dalších Windows a dokončit například i nasazení IPv6.
David Bečvařík: Virtuály a kontejnery
V posledních letech se hodně mluví o Dockeru, což spustilo zájem o kontejnery jako takové. Kontejnery nejsou nové, ale teprve Docker znamenal velký hype a všichni se o ně začaly zajímat.
Jenže Docker nemusí běžet jenom v kontejneru, ale i v plné virtualizaci.
Existují dva druhy hypervizorů: první je založen na běžném operačním systému, ve kterém teprve běží hypervizor a pod ním další operační systémy. To má nevýhodu v tom, že musíte provozovat plnohodnotný operační systém, ve kterém teprve spouštíte třeba QEMU.
Druhý typ hypervizoru běží přímo na hardware a nevyžaduje hostitelský operační systém. To se nám na Linuxu příliš neuchytilo, protože to má problémy například s výkonem.
Aby si operační systém uvnitř virtuálního prostředí myslel, že běží na vlastním hardware, je potřeba mu emulovat spoustu věcí. Je potřeba mít různé sběrnice, časovače a spoustu hardware. Když útočíte zevnitř virtuálu na hypervizor, ve skutečnosti bojujete s QEMU, ne s linuxovým jádrem a KVM.
QEMU je podle Bečvaříka problém, protože má hodně bezpečnostních děr a je moc složité. Rozhodně neplatí, že kontejnery jsou méně bezpečné než plná virtualizace.
Problémy složité virtualizace hardware je možné vyřešit pomocí paravirtualizace. Nemusíte pak emulovat spoustu funkcí skutečné hardwarové karty, ale vytvoříte výrazně jednodušší rozhraní. Jádro virtualizovaného systému musí ale paravirtualizovaný hardware podporovat.
Pokud jádro paravirtualizaci neumí, nabídne mu hypervizor klasický plnohodnotný hardware, ale takový stav má výrazně vyšší výkonnostní dopad.
Uživatelé se dnes čím dál více zajímají o kontejnery, což podle Bečvaříka není nic magického. Vlastně neemulujeme žádný hardware, ale pomocí funkcí jádra oddělujeme procesy s namespaces.
Dále se používají takzvané Cgroups, což je funkce jádra umožňující omezovat prostředky jednotlivým procesům. Musíte ale dávat pozor u některých aplikací, které s omezením nepočítají a nastavují své chování podle parametrů skutečného stroje.
Další komponentou je SELinux, který umožňuje kontejner lépe izolovat od zbytku systému. Je tak možné například zakazovat jednotlivé syscally, aby si například proces v kontejneru nemohl mountovat další disky. Uživatelské namespaces vám umožňují vytvořit v systému tabulku přemapování skutečných uživatelů na ty virtuální.
To pak umožňuje vytvářet neprivilegované kontejnery, k čemuž nepotřebujete mít práva roota, ale stačí vám běžný uživatel.
Přednáška pak pokračovala demonstrací jednotlivých vlastností jádra, které při správném použití a poskládání umožní vytvořit uzavřený, oddělený a bezpečný kontejner.
Jan Baier: WireGuard
Mezi typická VPN řešení patří: OpenVPN, Tinc VPN, IPSec. Každá z nich má svou mouchy, další technologie jsou příliš neznámé. Zajímavým projektem je WireGuard, který se snaží o velmi jednoduchou implementaci. Nevýhodou je, že se na tom stále pracuje a ještě to není hotové.
Základním principem je, že se autoři snaží WireGuard dělat co nejjednodušší a udržovat ho minimalistický.
Z uživatelského hlediska stačí zapnout nové síťové rozhraní, přidat mu nastavení specifické pro WireGuard a funguje to. Konfiguraci je možné vložit i do souboru nebo je možné použít i integraci se systemd.
WireGuard potřebuje znát IP adresu rozhraní, pár klíčů, veřejnou adresu protistrany a povolené IP adresy protistrany. Pokud přijde paket, kontroluje se, zda má IP adresu některé z povolených sítí. Pokud ano, přijme se a aplikuje se na něj routování.
To je vlastně vše, víc toho WireGuard ani nemá umět. To ovšem stačí, je možné pomocí toho například zajistit i vysokou dostupnost. WireGuard je z pohledu uživatele bezestavový, takže stačí použít keepalived a nechat komunikovat s klienty jen jeden server.
Na serverové straně je pak možné zařídit plnou mřížku a klient má jednu danou IP adresu, za kterou se pro něj schovává celá VPN síť.
Základní výhodou celého WireGuardu je jednoduchost. Provozuji sítě nad OpenVPN i IPSec, nefunguje to nikdy úplně dobře a spolehlivě. Tady jste úplně odstíněni od složitých věcí jako výměna klíčů a můžete se spolehnout na to, že to autoři udělali dobře.
Autoři tvrdí, že jejich cílem není uspokojit akademiky, ale praktické uživatele. Nehledí tedy na čistotu oddělení síťových vrstev a podobně. Je to nástroj pro praktické administrátory, kteří potřebují rychle a jednoduše použít VPN.
ČLÁNKY DO MAILU