Priority

dnes 16:59 | Přečteno: 106× | Za vším hledej Linux | poslední úprava: dnes 17:51

Každý má své priority a podle toho eskaluje i problémy.

A tak se můžeme dočíst, jak prof. MUDr. Jiří Horáček, Ph.D., FCMA říká: „Nepovažuji za správné, aby lidé, kteří sem přináší peníze, to znamená píšou a dostávají granty, měli nižší platy než úředníci, kteří ty peníze spravují.“ Upozornil někdo pana profesora na to, že si to pak bude muset bez těch lidí vyřizovat sám? Uvědomuje si vůbec kolik je s tím papírování a kolik je s tím stresu?

A podobně se to má také s IT. Na úřadě byl (a možná ještě je) z hierarchického hlediska IT pracovník – úředník. Ale přístup mnoha lidí zmrznul v době, kdy to ještě fungovalo jako v seriálu IT Crowd kdy se jim plazil IT pracovník někde pod stolem a nebo čekal na to, až ho zavolají, aby jim zachránil data z jejich zavirovaného počítače.

Jenže doba se změnila. Dnes už nikdo z IT osobní počítače neřeší. Maximálně ještě tak ty pracovní a to až se najde čas. Priority i práce IT pracovníka je úplně jinde, než priority a práce pana profesora, který je sice z hierarchického hlediska nadřízený, ale dnes již prakticky zcela závislý na tom, jak dobře IT zaměstanec dělá svoji práci. A čas od času se najde někdo, komu je to potřeba připomenout. Obvykle na to stačí, když mu výsledek dlouhodobé práce sežere vadný disk.

Lapálie s bránou

Uživatelé disklessových laborek mají přístup do svých linuxových uživatelských profilů prostřednictvím SSH brány, kterou je virtuální stroj, co se od běžného laboratorního disklessu v laborkách liší jen tím, že má přidanou jednu konfigurační vrstvu a sendvič má jen z pěti vrstev.

Je to virtuální full-diskless, který nemá žádné blokové zařízení, kde by měl nakešované nějaké vrstvy. Všechny vrstvy poskytuje NFS server read-only, takže i kdyby se nakrásně podařilo ten stroj někomu nabourat přes nějaké uživatelské konto, dostane se maximálně na data onoho uživatele.

Sice by si mohl pod ním spustit nějaký proces, ale ten poběží jen dokud se ten stroj z nějakého důvodu neotočí. Reboot jen několik sekund a děláme ho čas od času v rámci údržby když je zaplácnutá RAM, nebo když se objeví nějaký problém, který by se tím mohl srovnat – jako tomu bylo kupř. teď o víkendu.

Používá se tam overlay, stejně jako v laborkách. Na NFS server nic zapsat nejde a veškeré změny provedené na úrovni operačního systému jsou pouze v RAM. Takže při restartu se zahodí a vše je tak jak bylo předtím.

Úplně dole je vrstva, do které strká věci pro studenty APO Pavel Píša. Nad ní je systém – v podstatě to samé co dostanete, když použijete debootstrap, a nad tím konfigurační vrstvy. Tak jsou postaveny v podstatě všechny stroje disklessové infrastruktury. Liší od sebe se jen konfigurací. Laboratorní stroje mají navíc vrstvy kde je další software a pomocí konfiguračních vrstev lze řešit i různé HW kombinace, aniž by bylo nutné něco instalovat.

Pochopitelně to má i své nevýhody – základ je sdílený, proto se do něj v průběhu semestru pokud možno nerýpe. Sice máme odzkoušeno, že to většinou spuštěné systémy ustojí, protože jsme to tak dělávali, dokud šlo jen o laborky DCE. Ale od dob kovidových už se tomu bráním zuby nehty, protože nehodlám riskovat, že případná změna, se kterou někdo přijde poté co už běží výuka, rozhasí něco jiného. Blbé to je, pokud se něco nestihne (tak jako letos), protože se pak se s tím musí počkat až skončí semestr. Jakmile začne, řeší se jen to co nefunguje.

Mezi výhody ale patří to, že pokud se objeví nějaký problém, lze poměrně snadno a rychle vystopovat jeho příčinu a najít řešení. K tomu je ale potřeba vědět, minimálně to kdo a s čím má problém.

O víkendu mi napsal jeden z uživatelů e-mail, že se nemůže na tu SSH bránu přihlásit. Příčin může být povícero, takže jsem mu odepsal, aby mi upřesnil přes jaký login to zkouší. Na té bráně totiž běží poměrně striktně nastavený fail2ban a přes login zjistím IP adresu, ze které to uživatel zkoušel a následně i to, co se během přihlašovací procedury dělo.

Přihlášení funguje tak, že se nejdřív ověří jeho login. Tam může nastat první problém. Ověření vůči MS AD není tak rychlé jako tomu bylo vůči lokálnímu ldapu a pokud je někdo zbrklý a zkusí to víckrát za sebou, může skončit v jailu. Až po ověřen dojde na přihlášení. A teprve po úspěšném přihlášení stroj pošle signál, kterým se ověří zda uživatelský profil existuje, nebo ne. Pokud neexistuje, tak se založí, jinak zůstane jen záznam v logu, kde je uveden čas, ip adresa ze které ten signál odešel a login ověřeného uživatele – to je jediná „stopa” po které čas od času jdeme. Co má či nemá uživatel v profilu je mi fuk.

Následně se ten stroj pokusí ten uživatelský profil připojit a když se to nepodaří, dozví se uživatel z vygenerovaného souboru na ploše, že jeho profil není dostupný a vše co uloží je pouze v RAM, takže se to po odhlášení zahodí.

Uživatelské profily se sdílejí z jiného NFS a nejčastější příčinou, proč se profil nepřipojí, je to, že klientská stanice nemá IP adresu z povoleného rozsahu. Ale může za tím být i jiný problém, se kterým ovšem nic nenadělám protože má příčinu mimo disklessovou infrastrukturu a je potřeba kontaktovat některého kolegu.

Jenže teď to bylo něco jiného, jak jsem zjistil poté co mi odepsal.

Ten stroj byl nedostupný.

I to se občas stane, když je plná RAM to se řeší restartem. Proto je důležité takový problém eskalovat, jak to udělal on. Tudíž jsem to otočil a sledoval co se bude dít. Vše vypadalo ok i přihlášení přes SSH proběhlo bez problému. Tak jsem mu odepsal (jako obvykle) ať to znovu vyzkouší. Ale hned ráno, když jsem přišel do práce, jsem to otestoval pro jistotu ještě jednou – a nic. Nefungoval ani ping.

To už bylo divné. Ani zevnitř, ani zvenčí. Přitom na stroji vše ok. Zatížení nula nula nic, porty otevřené, žádný ban a přes interní IP adresu se připojit šlo. Traceroute končil na firewallu, poslal jsem tedy výstup kolegům s dotazem, jestli náhodou nedošlo k nějaké úpravě na firewallu. Poslal jsem také traceroute z vnitřní sítě, ale to už jsem si všiml, že veřejná IP adresa rozhraní na tom stroji je jiná než by měla být.

Co to? Letos teda bylo změn požehnaně, ale zrovna u tohoto stroje jsem konfiguraci už dlouho neměnil.

Ale jedna změna přeci jen nějaký vliv mít mohla. Pavel Píša mne minulý týden upozornil na chybu v souboru rc.local, kterou jsem v úterý 30. září opravil. Týkalo se to hlavně laboratorního sendviče, ale ten soubor existuje v mnoha konfiguračních vrstvách a používá se i na tomhle stroji, kde jsem ji rovněž opravil, ale na tomhle stroji nastavuje také routování. A v ten moment mi svitlo! Ten rc.local se spouští přes systemd. IP adresa je statická, ale co když do toho kecá Network-manager?!

A taky že jo. Tím se všechno vysvětlilo. Bezprostředně po restartu, než do toho začal žvanit Network-manager, byla IP adresa správná – proto jsem se v neděli večer úspěšně přihlásil. Jenže systemd po nějaké chvíli Nahodil Network-manager, ten slíznul jinou IP adresu z DHCP a bylo vymalováno. Tak jsem ho zkusmo shodil, spustil ručo rc.local a voilá – bylo po problému.

Kouknul jsem se tedy do overlaye co je potřeba do konfigurační vrstvy přidat, aby se ten Network-manager nespouštěl a bylo vyřešeno. Vyřešilo by to i nastavení odpovídající IP adresy v DHCP, ale to už je věc kolegy, co ho má pod palcem.

Každý má své priority

Pravdou je, že z hlediska IT je obvykle větší problém, když se dostane nezvaný host tam kam nemá, než když se někam nedostane ten, kdo by se dostat měl. Proto má řešení potenciální bezpečnostní díry větší prioritu než to, že se někdo nemůže někam přihlásit. I kdyby to byl pan profesor. Ale pochopitelně i to, že někdo potřebuje dostat svouje data má svou prioritu, takže platí: „Vyřešíme to ihned, jakmile na to přijde řada, ale určitě se připomeň.” Ale když se nepřipomeneš…

A tak jsem až ex post našel e-mail, který mi Pavel poslal už ve středu prvního října, poté, co jsem udělal tu změnu o které jsem psal. Možná by mi docvaklo kdyby subjekt uvedl, tak jako tem uživatel, slovem „Problém..”, „Nefunguje..”, „Nejde..” nebo „Nemůžu..”, ale to, že zrovna něco neodpovídá na ping mi ve chvíli kdy fail2ban zařezával jednu IP adresu za druhou přišlo jako zcela normální prkotina. Kdyby to chtěl eskalovat, napsal by ještě jednou, nebo mohl poslat sms, ale ani pro něj to nebyl akutní problém, jelikož ten přístup zrovna nepotřeboval.

Poučení, či snad lépe – doporučení

1. I za banalitou se může skrývat vážná chyba. Nikdo se zlobit nebude, když o ní dáš někomu vědět.
2. Neřeš takové věci přes sociální sítě. Pokud to hoří a znáš číslo – zavolej. A když ne, tak napiš e-mail. Ten bude mít datum i čas, a máš se pak na co odkázat, až se budeš chtít připomenout.
3. Subjekt začni jedním z těch slov co jsem napsal a jsi rovnou k věci.
4. Klidně se připomeň. I maily chodí se zpožděním a pokud se objeví mezi tím co už bylo vyřešeno, dají se snadno přehlédnout. A nezapomeň napsat, že už jsi psal tehdy a tehdy z té a té adresy, ať se to dá dohledat. A je dobré dát zpětnou vazbu i když problém zmizí.
5. A když máš pocit, že na tebe všichni kašlou a tvůj problém stále trvá, připomeň se klidně ještě jednou, protože se stává, že se sejde víc problémů najednou. Každopádně tím dáš najevo, že ti na řešení záleží.
6. A nevyvolávej paniku a stres. Ničemu to nepomůže.

       

Komentáře

[GeorgeWH]

... fail2ban... ... klientská stanice nemá IP adresu z povoleného rozsahu...

... Ten rc.local se spouští přes systemd. IP adresa je statická, ale co když do toho kecá Network-manager?!...

Ty vole, to je bordel...