Stalo sa, stane sa
Nefunkčná sieť FI 6. 3.: Na takmer polhodinu došlo k výpadku siete na FI. Dôvodom bol problém v rámci práce so smerovacou tabuľkou fakultného smerovača. Tieto situácie štandardne zvládneme tým, že jeho rolu automaticky prevezme druhý záložný router, ktorý však bol hneď po prebraní smerovania výrazne preťažený (dôvod čoho sa nám – kvôli jeho preťaženosti a snahe o rýchlu nápravu problému – nepodarilo úplne objasniť), takže sa nám problém podarilo vyriešiť až ručným zásahom a prehodením prevádzky nazad na primárny router.
Výpadok IPv6 na MU 11.–12. 3.: Tu ide o niečo menej viditeľnú vec, keďže IPv4 stále celkom drží prím, ale možno to poslúži ako dobrá ukážka, že tento protokol stále nie je zas tak esenciálny. O deviatej večer začalo dochádzať k problémom s IPv6, ktoré eventuálne vyústili v jeho úplnú nefunkčnosť, občas striedanú krátkymi chvíľami, keď fungoval. Z nášho pohľadu išlo o problém niekde za naším routerom, v sieti MU. Problém sa správcom siete MU podarilo odstrániť ďalšie ráno 09:10. Z pohľadu používateľov však toto bolo zaznamenateľné minimálne (ak vôbec), keďže IPv4 týmto výpadkom nebolo nijak dotknuté.
Nárast problémov s prihlasovaním k Eduroamu: V rámci našej analýzy úspešnosti prihlásení sme zaregistrovali, že 4. 3. došlo k výraznému poklesu podielu bezproblémových autentizačných zážitkov pre klientov v rámci dňa, z dovtedajších cca 94 % až k 70 %. Ide o metriku, ktorú sledujeme od veľkých problémov po celouniverzitných úpravách Eduroamu ešte v apríli 2022 a odzrkadľuje čisto proces pripájania k Wi-Fi sieti Eduroam. Teda tieto problémy nemajú vplyv na kvalitu či funkčnosť pripojenia po tomto momente, teda až na roaming medzi AP v prípade Wi-Fi klientov, ktorí nepodporujú fast roaming. V priebehu mesiaca sa tento náš indikátor pohyboval medzi 70 % až 95 %. Zatiaľ sa nám nepodarilo u správcov univerzitného Eduroamu, ktorí sa starajú o celouniverzitné servery RADIUSu, zabezpečujúce autentizáciu pre klientov Eduroamu s identitou *@muni.cz, zistiť, v dôsledku čoho došlo k takejto výraznej zmene. (K 06/2024 stav napriek našej urgencii trvá.)
Infraštruktúra a hardvér
Aktualizácia Wi-Fi AP a vypnutie PMF: V tomto blogu sa snažím písať o nových veciach, ale občas život ukáže, že niektorá z nich sa neosvedčí a naopak prinesie viac problémov, než úžitku. To je i prípad Protected Management Frames (802.11w), ktorých podporu sme v režime optional zapli na sieti Eduroam v novembri. Ukázalo sa, že po aktualizácii firmvéru Wi-Fi AP na konci februára vzrástol počet pádov služby hostapd, ktorá obsluhuje Wi-Fi klientov. Nejde o dramatický počet pádov a výpadok služby je na 10 sekúnd, ale i tak v rámci toho dôjde eventuálne k disasociácii klienta a nejakú chvíľu toto AP neobsluhuje klientov správne. A takisto o tomto probléme dostaneme my správu, ktorých nadmerné množstvo nie je úplne optimálne. Ukázalo sa, že po vypnutí PMF počet pádov prudko padol (haha.). Alternatívu – zapnúť PMF nie v režime optional, ale required – sme neskúšali, keďže má potenciál spôsobiť problémy klientom, ktorí PMF nepodporujú vôbec (a neradi by sme komplikovali funkčnosť siete zariadeniam, i keď by to boli len malé jednotky percent celkového počtu).
Linuxové učebňové stroje
Aktualizácia Lun: Naše stroje iMac v PC hale sme aktualizovali o verziu vyššie na macOS 13 Ventura (najnovšiu verziu macOS 14 Sonoma už bohužiaľ náš hardvér (kupovaný 2017) nepodporuje a pri neveľkom využití a vysokej cene strojov je otázne, aká je investícia do nich prínosná, kým ich verzia OS má ešte podporu) a XCode na 14.2.3 (z 13.2.1). Okrem toho sme na žiadosť doinštalovali aplikáciu SF symbols (knižnica symbolov/ikoniek).
Problémy s prihlasovaním na macOS: Po aktualizácii Lun sa začali občas (alebo, vzhľadom na nižšiu frekvenciu ich využívania, možno vždy?) počas procesu prihlásenia používatelia sťažovať na problém: zobrazovalo sa dialógové okno ohľadne súkromia, „pracujúci“ kurzor a z tohto stavu sa nedalo jednoducho dostať, takže používateľ zostal zaseknutý v nepríjemnej situácii. Zdá sa však, že šlo o dočasný problém v softvéri, ktorý sám odznel. (K 06/2024 už takéto hlásenia neevidujeme.)
Ťažké noci Nymf: Jeden zo zaujímavejších monitoringov správ z nášho centrálneho systémového logu je sledovanie chýb Too many open files, čo často poukázalo na niektoré menej bežné typy problémov (než sme ich museli začať bližšie skúmať). V tomto prípade priblížime problém Nymf, ktoré sa sem-tam ráno neprebudia. Už je bohužiaľ istou tradíciou, že upratovačky ráno pri čistení stolov (hlavne v B130) občas posunú klávesnicu tak, že kábel od monitora stláča nejakú klávesu a stroj nenabootuje, pretože sa v GRUBe zasekne na prihlásení a správe Enter username: (štyri prípady za marec). Tentokrát však bolo novinkou, že „vhodným“ uložením klávesnice jej kábel držal stlačený Enter, čo síce umožnilo systému dôjsť až do prihlasovacej obrazovky GDM, ale ten, unavený množstvom vytrvale opakovaných pokusov o prihlásenie, toto po chvíli vzdal a začal hlásiť chyby gdm3: Gdm: Could not start command '/usr/libexec/gdm-session-worker': Too many open files. Zaujímavý bug, nie?
Eliminácia spamu v logu od Gnome Tracker: Jeden zo softvérov, s ktorým zápolíme, (hoci takých príkladov by sa našlo aj hneď niekoľko ďalších) je Gnome Tracker. Ten poskytuje podporu pre vyhľadávanie v rámci desktopu Gnome. Dlhodobo s ním ale narážame na rôzne problémy: niekedy dochádza ku korupcii jeho databázy Tracker Miner FS, čo spôsobilo, že začal spamovať používateľský žurnál (journalctl --user) dlhotrvajúcou a intenzívnou záplavou opakovaných správ. Toto sa nám nakoniec podarilo pre naše účely vyriešiť doplnením našej služby, ktorá v prípade pádu používateľskej systemd služby zabezpečila reset databázy a problém vyriešila. Nejakú dobu toto riešenie fungovalo, ale eventuálne začala táto služba spamovať zas z nejakého iného dôvodu. Vzhľadom na to, že tento softvér neposkytuje úplne dobré možnosti konfigurácie (a jeho úplnému vypnutiu by sa možno používatelia nepotešili) (a možno novú vlnu spamu opraví nejaká aktualizácia), nechali sme logy používateľských služieb tracker-miner-fs a tracker-extract zahadzovať. Pre vás ako používateľov to bude mať prínos hlavne v sprehľadnení používateľského žurnálu a tiež vo výrazne dlhšej retencii dát v ňom.
Softvérové vybavenie a prostredie
libasan na AAA: Na Aisu, Anxura a Auru sme doinštalovali knižnicu GCC umožňujúcu používať -fsanitize=address, čo je alternatíva k Valgrindu, ktorá ale zvládne rozoznať pamäťové problémy aj na zásobníku.
Nové moduly unix@fi: llvm-18.1.2.
Služby
Ešte iné krátke výpadky autentizácie na Aise II.: Ako sme avizovali v minulom blogu, ukázalo sa, že používatelia, ktorí dostali pri pokuse o prihlásenie sa na Aisu chybu Permission denied napriek tomu, že zadávali správne prihlasovacie údaje, narazili na bug v SSSD, ktorý sa zjavne začal prejavovať po predsemestrálnej aktualizácii Aisy a spôsoboval, že sa zaplnila cache (KCM SSSD) kerberovských lístkov (umožňujúcich úspešnú autentizáciu), takže eventuálne boli všetky expirované, nové nemohli byť pridané, a používateľ sa nemohol prihlásiť. Toto sme riešili zatiaľ ručne, premazaním cache. V 05/2024 došlo v rámci aktualizácie RHELu z 9.3 na 9.4 k oprave v balíčku sssd-kcm, hoci ideálne riešenie to z nášho pohľadu nie je. Eventuálne teda prejdeme na pôvodný typ cache (keyring v kerneli), ktorý bol implicitným typom cache v RHELi 7.
Aktualizácia OpenNebuly: Softvér, ktorý poháňa našu virtualizáciu Stratus.FI, sme aktualizovali z verzie 6.6 na 6.8. Záujemcovia si môžu pozrieť detailný súpis zmien. Zásadné používateľsky viditeľné zmeny zrejme nenájdete, ale zo zmienkyhodných: ďalšie vylepšenia alternatívneho webového rozhrania FireEdge SunStone či vylepšenia plánovača interného zálohovania.
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í.
