Eida.cz - Jak zas nebyl čas

Jak zas nebyl čas

14. prosince 2017, 17:58 Eida

Někdy to tak přijde, že všechny dokonalé plány najednou zhatí jeden jediný okamžik. Možná je to vyšší zásah, možná si na nás brousí zuby Microsoft, dost možná prostě sem tam něco důležitého opomeneme a pak se nám to jako bumerang vrátí se vší silou přímo do obličeje. No a nebo je to všechno jen vánoční náhoda.

When you are confusef, don’t forget to try not to kill someone.

Před několika týdny už byla situace nadále neudržitelná, jedna z webových .NET aplikací s WPF začala mít takové nároky, že to už snad ani nebylo legální, nebo spíše splnitelné na stávajícím virtuálu s dvaatřicetibitovými Windows 7 a jejich nativní IIS. Jedno jadérko Xeonu E3 a maximální množství 3 GB RAM představovalo limit, nad který se nedalo už jít. Tak začala etapa přípravy nového stroje se stejnými OEM Windows, akorát tedy s dvojnásobným paměťovým objemem a čtyřiašedesátibitovou instalací. Po zkušenostech to nebyla žádná výzva, prakticky stačilo aktivovat IIS, vložit jí odpovídající UNC cestu, ověřit se proti doméně a jelo se. Vlastně ne. Staré Foxko se svými VFP olé, skončilo už v roce 2008 a nikdo od něj nečekal návrat do budoucnosti, kde budou bitíky už jen přibývat a všechno bude postupně nadrelační a superobjektové. No jasně. Na řadu pak musel přijít Microsoft SQL Server, který konečně může nativně běžet pod Linuxem. Zvolili jsme… ale co to povídám, když mám hlavní slovo, zkrátka použil jsem pro něj CentOS 7 s nastavením SELinux politiky plus mínus v legislativních rámcích tajných dokumentů EU a pak akorát upravil firewall na NATování z libvirt hosta. Legrační je, že vlastně v izolovaných prostředích není možné NATovat prostřednictvím hosta z jiných virtuálních subnetů, přestože to z fyzické LAN vlastně jde. No co už, tak se zkrátka vyrobil nový subnet a bylo. Ale o to teď nejde.

Na fyzické síti pak ještě běží miniaturní virtuál s Debianem 8 v roli kavárny doménového řadiče Active Directory. Na tom by nebylo nic špatného, po pokusech z uplynulých let je konečně nasazen v production a jeho parametry, totiž využití pod 512 MB RAM a sotva desetinu jednoho CPU jádra, by složily do kapsy všechny originální Servery 2016 R6, které musí povinně běžet na těch nejnovějších a nejdražších strojích. Jelikož je ale všude na tenhle provoz málo místa, muselo se vymyslet zatím dočasné řešení pro umístění domovských jednotek a profilů uživatelů. Nic snazšího, řeklo by se, prostě jsme čapli jeden z vyřazených WD Re disků a připojili ho jako fyzické zařízení přímo do KVM. Je potřeba si tady uvědomit, že Samba jako AD DC pracuje s NT oprávněními, které překládá jako UNIX ACL a místo, kam zapisuje, musí umět user_xattr, acl. Takže původní plán s minjíkem mít JFS úplně nevyšel, prostě tam běží ext4 a je to taky v pohodě. Sazmozřejmě to úskalí - nainstalovat nový fyzický disk prostě chce celý hardware vypnout a pak znova zapnout. I když pokus udělat to jako hotswap by tu byl, jen prostě nefungoval SATA kabel, takže se vlastně nic nestalo.

Ještě před tou výměnou probíhal tak trochu vánoční úklid v síti. Ono je vždycky jednodušší navrhovat všechno od začátku, než se snažit pomocí integrace postupně obnovovat stávající mission-critical architekturu. Ale k věci - přestože by to asi málokoho napadlo, grafický virt-manager při procházení cest a mountování staženích .iso obrazů vytváří storage konfigurace pro démona, libvirtd. To je hodně špatná situace, pokud někdo jako ne-root stahuje CDčko do svého ~/Downloads/ a pak se prostě rozhodne ho buď úplně smazat, nebo prostě změnit svoje stažené soubory k nepoznání a přerozházet všechny dosud stažené věci na síťové cesty, aby je pak mohl znovu použít i někdo jiný. Protože pak přišel reboot, celý host nabíhal znovu a startoval všechny svoje démony, jak bývá obvyklé. Pak na řadu dorazil konečně libvirtd, který se stará o spouštění instancí KVM/QEMU, zapnul první stroj a pak, tramtadadá, zhavaroval s velmi tvrdým SEGFAULTem. Co budu povídat, tohle napravit zabralo o nějaké tři hodiny navíc proti původnímu plánu a zas nebyl čas, jelikož jsme museli utíkat na velmi vtipný a poučný koncert.

Ale to pořád není všechno. Virtuální stroje nakonec všechny po opravě cest naběhly, ale z nějakého důvodu nebylo možné používat zmíněnou webovou aplikaci. Ta je normálně, jako v minulých letech, schovaná za Apache v roli reverzní proxy a nikdy s tím nebyl problém. IIS používá sebou podepsaný certifikát, který Apache víceméně ignoruje a navenek se prezentuje certifikátem od Let’s Encrypt autority. No a potíž se projevovala najednou v tom, že některé prohlížeče z nějakého důvody nedržely .NET session, ať už poslanou v URL, nebo jako zabezpečené cookie. Zděšení, že to někde jde a někde ne, vyvolalo spekulace o užívání drog a bezesné chvíle strávené debugováním všeho možného. Nakonec se ukázalo, že všechno, co fungovalo, fungovalo vlastně špatně a naopak, co nefungovalo, se chovalo na výsost správně a zaslouží si to hvězdičku.

Pes, resp. rarášek, byl zakopaný tentokrát hodně, hodně hluboko. Postupné trasování hlaviček přes cURL ukázalo, že session vypršela zhruba hodinu před samotným vysláním požadavku. Huh? To pořád ale nevysvětlovalo, proč třeba textové prohlížeče s aplikací normálně pracují, ale třeba mobilní Safari vůbec. Za všechno stejně mohl hodně špatný Internet, jaký ISP u Králíkových v současnosti nabízí, ovšem z mé chýše se už celkem slušně kreslilo třeba RDP, takže by se mohlo ukázat něco víc. Je to smutné, že k Windows vlastně není normálně možné přistupovat bez GUI, on i ten PowerShell je dost směšný. Že je něco opravdu v nepořádku, tomu mohlo tak trochu napovídat, že doménové přihlášení trvalo neuvěřitelně dlouhou dobu. No a pak… pak to přišlo. Vpravo dole, kde obvykle Windows zobrazují hodiny, se ukázal čas - ale ne takový, jaký ukazoval Mac vpravo nahoře. On nebyl čas! Byl o hodinu vedle.

No jistě, KVM host je při startu jako hardware nastavený na GMT a je jen záležitostí guest OS, jak se s tím vyrovná. V tomto případě Windows 7 tedy nijak. No ale aby doména AD dělala, co má, musí být na řadiči taky poskytovatel času, tedy NTP server. On se stará kromě podepisování paketů a ověřování totožnosti doménových uživatelů v časových rámcích taky o to, aby měly všichni připijení klienti správný čas. No a teď si to debugni, na Windows, kde i w32tm /resync skončí jen se suchým hlášením, že se to prostě nepovedlo. Naštěstí mít po ruce UNIX s normálním klientem se díky VPN dotazem ntpdate -q dc1, ntpdate -q ntp.lan opravdu vyplatilo, protože zpátky přišlo cosi jako no server suitable for synchronization found. O trochu výše ovšem zářila skutečná příčina. Obyčejně to funguje tak, že DC je v síti ještě synchronizován s NTP serverem v LAN, který si pak bere skutečný čas z kořenových NTP serverů, například z tik.cesnet.cz. No a vtip je, že jeho autorita závisí na vrstvě, takže když tam svítí stratum 16, dost možná to asi nebude to pravé. DC má ručně kompilovaný NTPd, který měl, jachach, překlep v ntpd.conf, kde je možné falšovat strata určitých strojů. Takže správně se napaštilo fudge ntp.lan stratum 2 a po rebootech už bylo vše ok. Joj.

Naproti tomu bylo v uplynulých dnech i něco pozitivního, totiž i když zas nebyl čas, stejně bylo potřeba najít pár okamžiků na úplně novou instalaci High Sierry na jeden stroj. Vlastně ho zase stačilo jen vzít do budníku, spustit Internet recovery, za pár minut to bylo stažené a jelo se. Jde ale hlavně o to, že instalace z vlastní vůle vyrobila na vestavěném SSD nový Apple FS, a to i přestože tam byl ponechaný HFS+. A kupodivu to je velice rychlé a použitelné, takže nehrozí žádné zdržování ve chvílích, kdy zas nebude na nic čas. Ale o tom už zkrátka asi jsou Vánoce - o mytí času.

Eida
Tento článek přečetlo již 107 čtenářů (0 dnes).

Komentáře

Nový komentář