Zapnutý fast roaming pre Wi-Fi, eliminácia rozostrenej farebnej tlače, dlhšie zobrazovanie obrázkov na infopaneloch.
Stalo sa, stane sa
Nefunkčné panely vo vestibule (11. 4. – 16. 5.): V dôsledku snahy o vypínanie infopanelov pri recepcii na noc mohli byť v uvedených časoch nechcene vypnuté i cez deň. Po určitom laborovaní a neúspešných pokusoch s nastavením obrazovky, HDMI (príkaz tvservice používaný Raspberry Pi síce HDMI vypne, ale obrazovka sa neprepne do šetriaceho módu a namiesto toho neustále informuje o absencii zdrojového signálu) či inými možnosťami sme zhodnotili, že najjednoduchšie bude nechať tieto obrazovky permanentne zapnuté.
Ojedinelé problémy s Eduroamom (26. 4. – 4. 5.): 26. 4. došlo o 16:45 k aktualizácii certifikátov pre radius.muni.cz. Voči nemu sa autentizujú Wi-Fi klienti Eduroamu. Táto zmena reťaze certifikátov však spôsobila, že vyše 30 klientov (necelé dve percentá) prestalo byť schopných pripojiť sa k sieti, keďže považovali certifikačnú reťaz za nedôveryhodnú. Zdalo sa, že jediným riešením bude opätovne nakonfigurovať Eduroam na každom klientovi. Univerzitným správcom sa však 4. 5. podarilo vhodnou úpravou certifikačnej reťaze autentizáciu opäť sfunkčniť bez potreby zásahu na klientoch. Dotknutými boli klienti s Androidom využívajúci kontrolu certifikátu radius.muni.cz voči systémovým certifikátom namiesto špecifikovanému certifikátu (ktorý je inštalovaný aplikáciou eduroam CAT).
Infraštruktúra a hardvér
Zapnutý fast roaming pre Wi-Fi od 28. 4.: Jedným z voliteľných rozšírení Wi-Fi je 802.11r Fast Roaming (tiež Fast BSS Transition, viď i Wikipédiu). 802.11r umožňuje výrazne zrýchliť reasociáciu klientov pri roamingu medzi Wi-Fi AP, a to vďaka vynechaniu autentizácie pri prechode na nové AP. To má najväčší potenciál prejaviť sa u Eduroamu, keďže tam je proces autentizácie najzložitejší (využíva sa WPA2-802.1X): pri obyčajnej autentizácii voči Eduroamu dochádza k výmene malých desiatok rámcov, pričom tie putujú až na autentizačný server (ktorý je navyše v prípade hosťa z inej univerzity ešte vzdialenejší/„latentnejší“, než ten univerzitný). V prípade rýchlej reasociácie sa tento proces úplne preskočí a prebehne v rámci jednotiek rámcov. Podľa našich testovacích meraní trvala obyčajná reasociácia okolo 0.5 sekundy a rýchla reasociácia iba 0.01 sekundy. Podľa našich dát je teraz podiel reasociácií využívajúcich fast roaming 10 %. Zlepšenie môžete spozorovať (alebo naopak, zhoršenie môžete prestať pozorovať) pri pohybe po chodbách, ale tiež bez pohybu, keďže klienti sa občas reasociujú aj na základe menších zmien signálu. Jedným z miest, kde toto funguje horšie, je na schodiskách, keďže tam môže byť predikcia budúceho AP nesprávna a v takom prípade bude musieť následne dôjsť k plnej asociácii – používajte teda radšej výťahy. Záverom ešte dodajme, že je šanca, že malé množstvo starších zariadení môže mať s touto technológiou problém – ak (by) ste na niečo také od doby zapnutia narazili, dajte nám vedieť.
Linuxové učebňové stroje
Pridané Kdenlive: Na linuxové stroje sme na žiadosť nainštalovali nástroj na editáciu videí Kdenlive.
Problémy s Gnome Tracker Miner FS: Na základe nášho monitoringu vyššej dlhodobej záťaže linuxových strojov (prvotnou motiváciou pre existenciu monitoringu bolo hlavne odhaľovanie situácií, kedy na nejakom stroji bežia zabudnuté procesy vyťažujúce CPU, ktoré by mohli negatívne ovplyvňovať ďalších používateľov stroja) sme už nejakú dobu pozorovali občasné zvýšenie záťaže na náhodných strojoch, ktorého príčinou boli neustále opakované pády služby Gnome Tracker Miner FS v dôsledku poškodenia databáze SQLite (služba sa reštartovala každé dve sekundy). Zdá sa, že k tomuto dochádzalo v prípade, že mal používateľ dve súbežné prihlásenia v grafickom prostredí. V dôsledku tohto by vám zrejme nefungovalo vyhľadávanie súborov v Gnome. Problém sa nám podarilo vyriešiť tak, že v prípade pádu tejto služby zabezpečíme pomocou systemd spustenie opravnej služby, ktorá spustí tracker3 reset -s, a následne už k opakovanému pádu služby nedochádza.
Softvérové vybavenie a prostredie
Nové moduly unix@fi: Doplnili sme softvérové moduly neovim-0.9.0, blender-3.5.0 (vrátane lokálnej verzie blender-3.5.0-loc), gcc-13.1 a gdb-13.1.
Doinštalovaný tshark na servery: Na Aisu, Anxura a Auru sme sprístupnili balíček tshark, ktorý je textovou obdobou nástroja Wireshark na analýzu sieťovej komunikácie. Hoci nie je možné (a samozrejme ani žiadúce), aby bola sieťová komunikácia na týchto strojoch odchytávaná bežnými používateľmi, tento nástroj má stále svoje opodstatnenie vďaka možnosti práce s uloženými súbormi typu .pcap(ng), a to hlavne keď sú potrebné pokročilejšie filtrovacie možnosti, než ponúka tcpdump.
Limit počtu webových procesov na Aise: Nejakú dobu dozadu sme zvyšovali limit na počet procesov (presnejšie vlákien) na Aise (z 512 na 1024), ktorý sa uplatňuje pri prihlasovaní cez SSH. Ukázalo sa však, že tento limit sa nachádza ešte separátne aj v konfigurácii komponentu suEXEC webservera Apache (s pôvodnou hodnotou 512) a tam sme ho zabudli zvýšiť. To mohlo spôsobiť (a aspoň v jednom prípade aj spôsobilo) nefunkčnosť webových aplikácií pri prekročení tohto limitu (v tom lepšom prípade s oznámením chyby vyčerpania limitu na počet procesov). Normálne by na túto situáciu upozornila alebo jej úplne predchádzala kontrola detegujúca blížiace sa vyčerpanie tohto limitu, ale tá sa aktivovala až pri vyššom limite (75 %, t. j. 768). Túto chybu sme napravili a toto štvrté miesto, kde sa číslo limitu uvádza, sme zmienili do konfiguračného súboru, ktorý funguje ako primárny zdroj tejto hodnoty.
Služby
Eliminácia rozostrenej farebnej tlače: Na kopírkach v budovách A a C sme opravili konfiguráciu tlačových front (v podobe súboru PPD) tak, aby sa pri farebnej tlači použila na stránkach s farebnými prvkami pre tlač čiernych/šedých prvkov priamo čierna farba (K) a nevyrábala sa pomocou zmiešavania ostatných farieb (CMY). Zmiešavanie totiž spôsobovalo v dôsledku určitej tolerancie zarovnania farebných kaziet isté rozostrenie, ktoré bolo viditeľné a rušivé hlavne u textu. Tento problém bol o to exponovanejší, že rozhodnutie o výbere kaziet robia tlačiarne pre každú stránku zvlášť, a teda stránky čisto v odtieňoch šedej vyzerali inak než tie, ktoré obsahovali i nejakú farebnú farbu.
Rýchlejší tlačový dialóg zariadení mimo FI: Štandardnou politikou fakultného firewallu je, že nepovolenú komunikáciu potichu zahadzujeme. Kolegami z windowsovej sekcie sme boli upozornení, že zariadenie, ktoré má nakonfigurovanú fakultnú tlač, môže pri vynesení zo siete FI narážať na to, že zobrazenie dostupných tlačiarní trvá veľmi dlho. Bližším skúmaním sa ukázalo, že takéto zariadenie sa pokúša komunikovať cez porty UDP 443 a TCP 135 nášho tlačového servera a trvá až dve a pol minúty, kým toto vzdá. Problém je, že počas tejto doby je program, ktorý vyvolal tlačový dialóg, neresponzívny. V rámci pokusov o úpravu firewallu sa ukázalo, že zmena DROP na REJECT pre UDP 443 nemala žiadny efekt, keďže informácia o v takomto prípade zaslanom pakete ICMP port unreachable zjavne nedoputovala u klienta na správne miesto. Rovnaký pokus s TCP 135 bol podobne neúspešný, ale po zmene spôsobu odmietania na TCP reset došlo k výraznému zrýchleniu a aplikácia už nebola zaseknutá 150 sekúnd, ale „len“ 30 sekúnd. Zdá sa, že toto je limit toho, čo sme schopní dosiahnuť s rozumným úsilím. Pre úplnosť dodajme, že tragickosť tých 30 sekúnd nie je až taká vypuklá vzhľadom na to, že pri vyvolaní tlačového dialógu v sieti FI (keď nedochádza k žiadnemu zahadzovaniu komunikácie s tlačovým serverom) trvá zamrznutie 12 sekúnd…
Rozsypaná tlač na copy4b cez Sambu z macOS: Od používateľa sme dostali upozornenie na to, že pri tlači na copy4b z macOS cez Sambu sa vytlačí nezmyselný text. Konfiguráciu tlačovej fronty sme upravili a tento problém pre túto tlačiareň sme tak vyriešili. Toto opatrenie bohužiaľ nejde nasadiť plošne, keďže na niektorých tlačových zariadeniach táto úprava tlač zas rozbíja. Preto budeme tento typ problému na iných tlačových zariadeniach riešiť až po prípadnom podnete.
Detekcia vyčerpania pseudoterminálov: V súvislosti s minulomesačným vyčerpaním pseudoterminálov (PTY) na Aise sme doplnili detekciu tohto problému na linuxových staniciach/serveroch do nášho monitoringu Nagiosom. Pre zaujímavosť, ide to dosiahnuť vynútením alokácie PTY uvedením prepínačov -tt programu SSH (pre už existujúcu kontrolu), hoci to so sebou nesie určitú nevýhodu v tom, že každá takáto kontrola bude teraz viditeľná vo výpise last.
Spravované stroje v prehľade účtu: Do prehľadu fakultného účtu na Fakultnej administratíve sme doplnili sekciu so zoznamom spravovaných strojov. Ide o rovnaký zoznam ako je dostupný i v správe zariadení.
Dlhšie zobrazovanie obrázkov na infopaneloch: S cieľom dať náhodnému pozorovateľovi našich infopanelov viac času na prečítanie informácii sme predĺžili dobu zobrazovania plagátov z 8 sekúnd na 15.
Opravené odkazy na prihlasovacej obrazovke GitLabu: Na prihlasovacej obrazovke GitLabu FI sme opravili nefunkčné/neoptimálne odkazy vedúce do našej technickej dokumentácie.
Fakultný web a technická dokumentácia
„Nefunkčné“ CRYPTED_PASSWORD v Stratus.FI: Do dokumentácie Stratus.FI sme doplnili upozornenie, že u novších distribúcií je heslo uložené v CRYPTED_PASSWORD použiteľné len z VNC, nie cez SSH (v dôsledku predvoleného nastavenia PermitRootLogin prohibit-password u servera SSH).
Odkiaľ sú dostupné FI DB: Do technickej dokumentácie sme doplnili informácie o tom, odkiaľ sú osobné fakultné databázy dostupné. Doteraz sme to uvádzali len u niektorých typov databáz priamo v aplikácii vo Fakultnej administratíve (a aj to sme to zobrazovali len v prípade, že ste ju mali vytvorenú).
Zmienky o Musách v /tech/: V technickej dokumentácie sme konečne začali priznávať existenciu strojov Musa v B011.
Windowsové inštalátory tlačiarní: V zozname tlačových zariadení sme jasnejšie odlíšili odkazy na inštalátory pre Windows (využívajúce tlač priamo cez CUPS verzus tlač cez Sambu).
Vedeli ste, že…
… (hromadné rozosielanie mailov) hromadnejšie rozposielanie mailov je potrebné lepšie si rozmyslieť? Dnešné mailové prostredie je vďaka nevyhnutnosti boju proti spamom často pomerne nedôverčivé a je žiadúce, aby ste prípadné rozosielanie konzultovali s nami na unix@fi: jednak kvôli zníženiu šance zhoršenia reputácie nášho poštového servera a jednak kvôli užitočným technickým tipom (napr. správne nastavenie obálkových/hlavičkových odosielateľov/príjemcov). A samozrejme by ste nemali zabúdať na fakt, že hromadné rozosielanie spamov je nevhodné, pokiaľ ide o poštu, ktorá nie je príjemcami vyžiadaná – dotazníky, nerelevantné príliš plošné informácie či už vôbec nehovoriac o inzercii.
… (schránka presmerovaná mimo FI a spamy) ďalším dôsledkom nutnosti boja proti spamom je, že pokiaľ si pomocou presmerovania pošty doručujete poštu do schránky inde, môže pri tom dochádzať k zahadzovaniu pošty, ktorá má na základe kontrolou SpamAssassinom vysokú pravdepodobnosť toho, že ide o spam. Pri filtrovaní pošty vo všeobecnosti platí, že je najvhodnejšie ju robiť až v cieľovej schránke, aby mohol mať jej vlastník nejakú priamu kontrolu nad filtrovaním spamu na mieste, kde poštu číta. Postupom rokov sprísňujúcejšie sa podmienky prevádzkovania poštového servera na internete nás však tlačia k tomu, aby sme s ohľadom na reputáciu nášho poštového servera predchádzali tomu, že z nášho poštového servera budú vďaka presmerovaniam odchádzať spamy a mohol by sa dostať do DNSBL. Preto sa snažíme tieto spamy detegovať ešte pri prijímaní, aby sme odosielajúcemu serveru mohli vygenerovať nedoručenku, a aby sa o tom prípadný legitímny odosielateľ nesprávne rozpoznaného mailu dozvedel. Túto detekciu tiež realizujeme len pomocou nástroja SpamAssassin za použitia vysokej bodovej hranice potrebnej na označenie mailu za spam. Pravdepodobnostný dSpam sa pre tieto účely nevyužíva.
Záverom
Máte pripomienky, návrh na vylepšenie alebo jednoducho potrebu pochváliť nás? :-) Napíšte nám mail či využite IT ideas.
Ak vás tieto novinky zaujali, môžete si zapnúť sledovanie blogu a následne zapnúť posielanie mailových upozornení.
