Stalo sa, stane sa
Nefunkčná inštanciácia kontajnerov na Aure do 2. 6.: Od 15. 5. do 2. 6. (moment nahlásenia, za čo ďakujeme) nefungovalo na Aure inštanciovanie kontajnerov Podmanu využívajúcich GPU. Súvisí to s automatickou aktualizáciou balíčkov (v tomto prípade šlo o egl-wayland) a tým, že Nvidia CTK ukladá svoju konfiguráciu do /etc/cdi/nvidia.yaml, kde sú však uvedené cesty ku knižničným súborom, vrátane presných verzií. Tento súbor sme nechali generovať raz denne.
Preťaženie Aury 16. 6.: Na Aure došlo v pondelok 16. 6. medzi 02:40 a 08:00 k výraznému preťaženiu výpočtami. Problematické procesy sme ukončili.
Zamýšľaná PC učebňa v S405: Reorganizácie PC učební nekončia! Po suboptimálnych skúsenostiach s primalými učebňami C117 a C123 vznikol zámer presunu ich vybavenia do S405, pričom je cieľom linuxová/dualbootová učebňa s 25–30 miestami. Z C117 a C123 by zrejme zostali bez PC. Presný plán sa však ešte vyvíja.
Výpadok Eduroamu 30. 6. a 1. 7.: V pondelok 30. 6. došlo od 20:25 do 08:24 ďalšieho dňa k výpadku funkčnosti autentizácie do siete Eduroam, a to v dôsledku problémov na úrovni celej univerzity. Existujúce pripojenia k sieti toto neovplyvnilo.
Infraštruktúra a hardvér
Časozber búrania déčok: V medzičase sme v komentároch pridali odkazy na separátne Full HD 60 FPS záznamy jednotlivých kamier.
Voľné videokáble v PC učebniach: Po doplnení videokáblov k jednému ostrovčeku v PC hale a nedávnom avíze sme konečne dotiahli rozšírenie tejto možnosti aj do ďalších učební. Doplnili sme takto 41 pracovných miest (na počet 53), a to káblami s koncovkou HDMI a USB-C (na striedačku) prakticky do všetkých PC učební. Výnimkou je C121 s all-in-one, ktoré toto technicky neumožňujú. Dostupnosť videokáblov sme premietli do mapy miestností (viď ikonka monitora) a káble sme zároveň pre lepšiu viditeľnosť označili žltou páskou.
Učebňové stroje s Linuxom
Rozuzlenie občasných problémov Nymfe01: Už skoro od nepamäti sa na Nymfe01 párkrát za mesiac vyskytnú chyby jadra, súvisiace s neplatnými ukazovateľmi do pamäte alebo s problémom pri deduplikácii XFS. Pôvodne sme podozrievali nejaký problém s GPU alebo XFS (navyše išlo o pilotný stroj s XFS pre /var/tmp). Ale až výrazné zintenzívnenie frekvencie chýb nás primälo pozrieť sa na problém lepšie a po krátkom prieskume sa vďaka memtesteru ukázalo, že problém je s fyzickou pamäťou, ktorej časť bola chybná:
FAILURE: possible bad address line at offset 0x00000002076ac870
FAILURE: 0x8102e703a838b635 != 0x68068f3c5e6cb635 at offset 0x00000000876ad860
Pre úplnosť dodajme, že s chybnou pamäťou sa u bežných učebňových PC stretávame celkom zriedka, hoci u serverov ide momentálne o najporuchovejší komponent (keď nerátame rotačné disky, ktoré už trocha ustupujú). Pamäť Nymfe01 sme teda vymenili a XFS sme pre istotu skontrolovali a stroj je snáď už zas v dobrej kondícii.
Ešte ako zaujímavosť zmieňme, že súborový systém je vo všeobecnosti možné kontrolovať a opravovať len v odpojenom stave, čo sa triviálne dosahuje pomocou umount. V tomto prípade sme však stále dostávali chybu o neodpojenom súborovom systéme, a ako sme už párkrát na tento typ problému narazili (nie, nejde o SELinux…), problém spôsobovali mount namespaces, takže kontrola XFS uspela až po odpojení /var/tmp odvšadiaľ:
for PID in $(lsns -n -l -t mnt -o pid); do ps u $PID; umount -N $PID /var/tmp; done
xfs_repair /dev/mapper/ubuntu--vg-vartmp
Pomalšosť niektorých Nymf: V rámci ručného zaplátavania rizikovejšej diery v udisks2/libblockdev sme si všimli, že pár Nýmf bolo konzistentne (och, vďaka za dobre reprodukovateľný problém!) pomalších o 50 % (konkrétne beh apt update). Kedysi sme už na takýto mysteriózny problém narazili a rozuzlili sme ho na degradovanú sieť so 100 Mbps. Tentokrát sme po chvíli skúmania prišli na to, že problém je napríklad s
dd if=/dev/urandom of=/dev/stdout bs=1M count=1k
kde sa rýchlosť líšila až štvornásobne, hoci s väčším množstvom dát pomer klesal. Pohľad na
watch -n 0.2 lscpu -ae
s pracovnými frekvenciami CPU naznačoval, že na niektorých strojoch sa frekvencia od základnej (800 MHz) smerom k maximu (4000 MHz) odliepala pomalšie, a odtiaľ to už nebol dlhý proces k skúmaniu /sys/devices/system/cpu/*/cpufreq/, kde sa perpetrátorom ukázalo byť odlišné nastavenie energy_performance_preference: pomalšie stroje mali nastavené power a ostatné balance_performance alebo performance.
Zistili sme však, že toto nastavenie je meniteľné napr. z menu v Gnome, a zákaz zmeny pomocou Polkitu, podobne ako to robíme u nastavení siete alebo možnosti vypnutia PC, zrejme možný nie je. Nakoniec sme to teda vyriešili zákazom služby power-profiles-daemon a ručnou úpravou hodnoty v sysfs. Pre úplnosť dodajme, že nastavenia energy_performance_preference neznamenajú, že by sme neustále bežali na 4000 MHz (a mali výrazne väčší odber energie), ale určujú len rýchlosť, s ktorou CPU frequency governor reaguje na vyťaženie CPU. Ďalšia zo zaujímavejších záhad bola teda vypátraná, preskúmaná a vyriešená.
Koniec nonstop prevádzky A219: Nonstop prevádzku A219 (kvôli výuke GPU) sme po troch mesiacoch 25. 6. zas zrušili.
Prázdninový režim PC učební: Trvá od stredy 2. 7. do piatka 12. 9. (pred mačiatkom semestra). Viď výveskovú správu.
Technická nástenka v C1: Vzhľadom na presun veľkej časti PC do C1 sme nástenku, ako máme pred PC halou, umiestnili aj do C1. Nachádza sa v prístupovej chodbičke z dvora a obsahovo sa bude zrejme zhodovať s halovou.
Softvérové vybavenie a prostredie
Nové moduly od používateľov: helix-25.01.1 (i ako default)
Služby
Možnosť vyhradenia GPU na Aure: Informujeme, že v prípade odôvodnenej potreby je dočasne možné na žiadosť vyhradenie GPU karty na Aure, typicky s cieľom pre FI dôležitého (intenzívnejšieho) očakávaného využitia. Toto bol technicky o niečo väčší oriešok, než sme čakali, tak ho pre zaujímavosť priblížime:
- Test úpravy štandardných prístupových práv súborov zariadení
/dev/nvidia$N pomocou chmod a chown na Nymfe s Ubuntu prešiel podľa očakávaní, ale u RHELu nie. Pri akomkoľvek používaní týchto zariadení (napr. i nvidia-smi) sa práva vrátili nazad.
- Až dodatočne sme zistili, že to ovládač Nvidia implicitne opravuje tieto práva vždy na
root:root, 0666. Je možné zmeniť to pomocou parametrov LKM s prefixom NVreg_DeviceFile a/alebo NVreg_ModifyDeviceFiles (viď /usr/share/doc/nvidia-driver/html/faq.html na Aure), ale to vyžaduje odpojenie ovládača (a krátke zneprístupnenie GPU), čo je vo všeobecnosti problematické: /dev/nvidia$N majú bohužiaľ celkom často otvorené i procesy, ktoré ho aktívne nevyužívajú.
- Ďalšou častou radou internetu bolo použiť pravidlá subsystému udev, ale tie sa uplatňujú typicky len pri štarte systému a toto riešenie by narazilo na úplne rovnaký problém ako
chmod a chown.
- Napadol nám i SELinux, ale kvôli jeho relatívnej komplikovanosti sme túto možnosť nepreferovali.
- Posledným a už úspešným pokusom bolo použitie ACL. Vzhľadom na vlastníctvo
root:root a fakt, že ovládač je k ACL indiferentný, sme iba doplnili špecifickejšie reštriktívne ACL pre skupinu student a povoľujúce ACL pre konkrétne účty, čím sme konečne dosiahli požadovaný cieľ.
Dodajme, že s možnosťou väčšej prípravy vopred by toto riešenie bolo určite jednoduchšie: výpadok GPU, respektíve reštart Aury, a mať ako vlastnícku skupinu dedikovanú skupinu, kde by sme len upravovali členstvo, ale v tejto situácii sme neboli.
No a poslednou zapeklitosťou je ešte fakt, že číslo GPU z výstupu nvidia-smi a pod. typicky nekorešponduje s /dev/nvidia$N. Preklad je ale možný napríklad nasledovne:
join -o 1.2,2.2 \
<(nvidia-smi --query-gpu=uuid,index --format=csv,noheader | tr -d , | sort) \
<(grep -hE 'GPU UUID|Device Minor' /proc/driver/nvidia/gpus/*/information | \
awk '{print $3}' | paste - - | sort) \
| sed 's/^/GPU#/; s! ! = /dev/nvidia!' | sort
Šablóna AlmaLinux 10 v Stratus.FI: Hľa!
Skúškové sedenie v mape miestností: V mape miestností sme špeciálne sfarbili prihlásenie skúškového sedenia – svetlá fialová.
Zrušený Dvorak z odpovedníkového skúškového sedenia: Vzhľadom na nižšiu používanosť a zdĺhavejšie prepínanie medzi rozloženiami klávesnice sme pod Linuxom zrušili Dvorak (pod Windows prítomné nebolo).
Ovládanie skúškového sedenia doktorandmi: Ovládanie mali doteraz prístupné zamestnanci FI (pracovný pomer i dohoda) a vyučujúci predmetov na FI. Toto väčšinou umožnilo prístup aj doktorandom, ale ukázalo sa, že nie všetkým, tak sme ešte explicitne pridali toto právo i doktorandom.
Oprava hodín v obmedzenom skúškovom sedení: Zistili a opravili sme nezobrazovanie widgetu s hodinami v obmedzenom skúškovom sedení, ktoré sa teda týkalo len anglickej verzie sedenia. Problém bola premenná prostredia LANG=en_US, ktorú sme pre tento program upravili na LANG=C.
Neuspávanie obrazovky v odpovedníkovom skúškovom sedení: Umožnili sme vypnúť uspávanie obrazovky v odpovedníkovom skúškovom sedení (nepovinný parameter dpms=no), čo môže zjednodušiť identifikáciu skúškových miest skúšanými pri príchode na skúšku (zvlášť ak medzi jeho zapnutím a príchodom človeka uplynie pár minút).
Krátke údržby GitLabu už bez avíza: Kvôli bezpečnostným aktualizáciám GitLabu alebo rebootom VM do nového jadra obvykle párkrát mesačne nemáme fakultný GitLab na chvíľu (typicky do 5–10 minút) dostupný. Aktualizácie softvéru GitLab aplikujeme obvykle hneď v záplatové stredy, večer. Reštart VM do nového jadra (za posledných 12 mesiacov sme realizovali 15-krát) plánujeme zas na jednu hodinu ráno, vrátane avíza o plánovanom výpadku v GitLabe. Aby sme zbytočne nespamovali v rozhraní GitLabu s pomerne rutinnými akciami, nebudeme ďalej tieto avíza zverejňovať.
Reverzné DNS pre CGNAT adresy ÚVT v sieti FI: Na DNS servery obsluhujúce požiadavky zvnútra siete FI (ares1, ns2) sme dokonfigurovali preklad reverzných záznamov DNS pre adresy z CGNAT rozsahu 100.64.0.0/10 používaného na úrovni univerzity/ÚVT. Preklad hostnames na IP adresy (dopredné záznamy) už prirodzene fungoval. Pre funkčnosť prekladu IP na hostnames u privátnych rozsahov adries, ktoré môže (ale nemusí) každá inštitúcia používať plne vo svojej réžii, je totiž nutné lokálny server DNS nasmerovať na autoritatívne servery danej inštitúcie. Pre úplnosť dodajme, že univerzita používa ešte adresný rozsah 10.0.0.0/8 a na FI používame rozsah 172.16.0.0/12. (Pre IPv6 z podstaty problému a kornukopie adries neexistujú zodpovedajúce rozsahy adries IPv6.)
Vedeli ste, že…
… („stop“ a nonstop prevádzka strojov) Učebňové linuxové stroje z dôvodu šetrenia elektrickou energiou až na pár výnimiek neprevádzkujeme nonstop. Za bežných okolností sa automaticky prebúdzajú o 7:00, aby sme zabezpečili ich okamžitú pripravenosť pre výuku. Následne sú vypínané podmienene o 20:00 (ak na nich nie je nik prihlásený) a nepodmienene po 22:00 (vrátane zobrazenia vyháňajúceho odpočtu). Cieľom automatického bootovania (a tiež nášho skúmania prípadných reštartov) strojov je snaha zabezpečiť, aby sme mali stroje (i vďaka monitoringu) vždy v známom funkčnom stave a prípadné chyby dokázali automaticky odhaliť a riešiť.
Malý počet učebňových linuxových strojov (nymfe{01,02,03}, musa01) však prevádzkujeme v režime nonstop z dôvodu možnosti práce na diaľku alebo možnosti kontroly prostredia (dostupnosť softvéru a podobne). Nonstop prevádzka však v praxi obnáša reštart vždy o piatej ráno, ktorý trvá typicky okolo 60 sekúnd. Dôvodom je uplatnenie automatických aktualizácií, vyčistenie bežiacich procesov či uvedenie stroja do známeho základného stavu.
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í.
