Vzdálená správa většího počtu strojů

23.10.2019 16:37 | Přečteno: 2656× | Za vším hledej Linux

Ačkoliv je abclinuxu server, kde by se dala očekávat vyšší koncentrace linuxových adminů, jsem mnohdy na pochybách. Proto si dovolím připojit na závěr tohoto blogpostu připojit malou anketu. V blogpostu se ale chci zmínit o terminálových multiplexorech a nástrojích, které využívám k souběžné práci na větším počtu vzdálených strojů.

Terminálový multiplexor je aplikace, která umožňuje v mít rámci jedné instance otevřených několik terminálů současně. Kdo nepracuje se vzdáleným strojem přes terminál, tak se bez něj obejde, ale pokud něco řešíte na vzdáleném stroji přes ssh připojení, jde o neocenitelného pomocníka.

Terminálový multiplexor začíná být zajímavý teprve když obsluhujete přes terminálovou konzoli několik strojů současně, nebo pokud potřebujete se vzdáleným strojem pracovat z různých míst.

Mezi nejstarší aplikace tohoto typu patří GNU screen, jehož první release se objevila roku 1987. Já ho začal používat zhruba před 10 lety, abych nemusel v práci čekat než mi na vzdáleném stroji dojede nějaká operace. A používám ho dodnes, pokud chci spustit úlohu u které mě zajímá mě co se vypisuje na monitor.

Spouštím ho po přihlášení přes ssh na vzdáleném stroji – kdybych spustil screen u sebe, tak by to bylo na nic, jelikož by se při vypnutí stroje veškeré operace na vzdálených strojích přerušily.

Základní klávesovou zkratkou, po které následují klávesové skratky pro příslušné akce je (ve výchozím stavu) Ctrl+a. Po které následuje stisk klávesy d (detach), pokud potřebuji konzoli odpojit abych mohl odejít. Po tomto příkazu se aktuální instance screenu odpojí od konzole a zůstane dál běžet na pozadí. Pak se můžu odhlásit a jít domů.

Chci-li z domu zkontrolovat, jak zpracování úlohy probíhá, stačí se přihlásit přes ssh a příkazem screen -r si odpojenou instanci připojit.

Příkazů pro screen existuje pochopitelně mnohem víc, ale to si můžete dohledat jinde. Tady postačí jen když zmíním, že v rámci jedné instance může existovat více "oken", které lze vertikálně i horizontálně dělit a tak mít – v rámci jednoho "okna" – otevřených několik terminálů současně.

Bohužel screen má jednu zásadní vadu – a to, že tohle rozdělení oken po odpojení nezachová. To byl důvod, proč jsem začal používat tmux. Ten se obsluhuje podobně jako screen. Ve výchozím stavu používá základní terminálovou zkratku Ctrl+b a tak je schopen koexistence se screenem, aniž by docházelo ke kolizi klávesových zkratek.

I v jeho případě, pokud se po základní klávesové zkratce stiskne klávesa d (detach) dojde k odpojení spuštěné instance od terminálové konzole. Rozdíl je pouze v tom, že tmux pro opětovné připojení používá klíčové slovo – tmux attach. Hlavní "killer feature" je, že tmux rozdělení oken zachová a navíc rozměry okna přeškáluje podle aktuální velikosti monitoru. Proto ho využívám především když chci na vzdáleném stroji v rámci jednoho "okna" sledovat několik terminálů současně.

Souběžná práce na více strojích

Jelikož disklessový linux vůbec s lokálním diskem nepracuje, neměl jsem dlouhou dobu potřebu pracovat na více strojích současně, dokud jsme nezačali v jedné z učeben využívat diskless linux i pro distribuci a administraci lokálně instalovaných MS Windows.

Aby mohl na linuxových strojích paralelně spouštět import, začal můj kolega Martin využívat pssh (ParallelSSH), které přes vícenásobné (multiply) asynchonní ssh připojení umožňuje paralelně spouštět na vzdálených strojích potřebné příkazy. ParallelSSH však podporuje pouze ověření SSH klíčem, což je nevýhodné pokud potřebujete pracovat souběžně na různých strojích, kde není váš klíč naimportovaný.

U disklessu který používá jeden systém pro všechny stroje tenhle problém nebyl, ale když jsem začal řešit také linuxové stroje v laboratořích kybernetiky, které měly původně systém nainstalovaný lokálně, mi tohle omezení začalo vadit. Ale všiml jsem si, jak kolega který ty laboratoře do té doby řešil, k jejich administraci používá aplikaci cssh (ClusterSSH). A začal jsem ho také používat.

Výhodou cssh je, že si lze rovnou na příkazové řádce generovat seznam strojů s nimiž chci pracovat a také hromadně nastavit uživatele, přes kterého se chci zrovna přihlašovat. Po spuštění se otevře pro každý stroj samostatné terminálové okno, u kterého je pro každou další instanci mírně posunuté barevné schéma. To usnadňuje orientaci, pokud je oken hodně a jsou překrytá záhlaví.

Pokud na cílovém stroji ssh server neběží, nebo je stroj vypnutý nebo vytuhlý, tak se po chvíli otevřená konzole ukončí. Jelikož vím, kde se stroj s příslušnou IP adresou nachází, mohu jít rovnou na místo zkontrolovat jeho stav.

V laboratořích DCE, kde se používá jak disklessový linux, tak lokálně instalované MS Windows, využívám cssh nejenom k tomu abych na strojích vzdáleně pracoval, ale i k tomu, abych zjistil, zda-li na něm zrovna běží MS Windows nebo Linux – viz můj starší blogpost o práci s Windows 10 přes OpenSSH.

Z cssh se mi stal opravdu oblíbený nástroj. Ale s tím, jak se disklessový linux rozšířil do dalších laboratoří, mne práce s hromadou otevřených oken začala stále víc frustrovat. Dokud šlo maximálně o dvacet strojů per laboratoř, tak to bylo v pohodě. ClusterSSH má klávesovou zkratku Alt+r, po které se otevřené terminály přeskupí do dlaždic. Ale v současné době "pasu" už víc než 180 strojů s různým HW vybavením a v 7 laboratořích (učebnách). Přičemž zrovna ty, ve kterých je strojů nejvíc (po 40 strojích) jsou vytíženy tak že od pondělka do pátku, od půl osmé ráno do šesté večer není jediná pauza, během níž by bylo možné ve všech laboratořích současně otestovat, zdali všechny stroje komunikují jak mají.

Moje oficiální pracovní doba by se měla vejít do rozmezí od 8:00 do 18:00, ale prakticky se dá s laboratořmi pracovat pouze večer, nebo o víkendech a i to se mnohdy nedá, protože se u nás konají i různé víkendové akce, takže v laboratořích pořád někdo ke. Obzvláště ke konci semestru a během zkouškového odbdobí je zcela běžné že studenti straší v laborkách i o víkendech.

A to je největší výhodou disklessu, že po odladění je víceméně bezúdržbový – teda pokud se zrovna nezblázní některý switch. I tak jsem se ale začal poohlížet po řešení, které by mi umožnilo komfortnější způsob práce a zcela náhodou jsem se dozvěděl o terminálovém multiplexoru terminator (Terminator), který má implementované funkcionality umožňující paralelní práci se skupinami terminálů. Super aplikace pro okenní prostředí, která na první pohled vypadá jako tmux, ale je to python + GTK3. Až na ty zdrojáky udržované přes Bazaar. Z toho by jeden blil. Naštěstí existuje distribuční balíček.

Prostřednictvím layoutů a zapnutého broadcastu na vybranou skupinu terminálů by mělo jít dosáhnout podobné funkcionality, jakou nabízí cssh. Ovšem bez toho, že bych měl po monitorech roztahaných desítky oken. Obsah terminálů lze zoomovat a pomocí klávesových zkratek lze s nimi v rámci jednoho okna šoupat dle libosti, aniž by bylo nutné přerovnávat ty ostatní. V podstatě mi chybí pouze jediná funkcionalita – seřazení oken do kaskády.

       

Anketa

Komentáře

[Ruža Becelin]

Spravovat vic jak 10 stroju je prace pro CM (CFEngine, Puppet, Chef, SaltStack, Ansible)

Taky jsem pouzival (a obcas jeste spustim) cssh, do nejakych 50 stroju se to dalo, pak uz to bylo neprehledne

[Aleš Kapica]

V blogpostu je jasně uvedeno, že se používá diskless, který jede z jednoho bodu, takže použití uvedených nástrojů je zcela irelevantní. Správa není jen o instalaci.

[marek_hb]

Bohužel screen má jednu zásadní vadu – a to, že tohle rozdělení oken po odpojení nezachová

a já si říkal, že něco dělám blbě. díky díky díky pane

[xkucf03]

Další zásadní nevýhoda (těchto nástrojů obecně) je to, že když odtamtud chceš vykopírovat víceřádkový text, tak se text označuje po řádcích napříč těmi virtuálními okny. Tyhle nástroje byly nejužitečnější v dobách textových terminálů a konsolí (bez X). Ale když už člověk GUI má, tak je lepší i pro tohle používat GUI nástroje (např. rozdělení pohledu v Konsoli nebo to řešit na úrovni DE a mít více oken), které jdou ovládat i klávesnicí.

[Jendа]

Další zásadní nevýhoda (těchto nástrojů obecně) je to, že když odtamtud chceš vykopírovat víceřádkový text, tak se text označuje po řádcích napříč těmi virtuálními okny.

A nefunguje tam scrollování (samozřejmě to má vlastní scrollback, ale ten nereaguje na grafické posuvníky X terminálu, tažení myší atd.). To je hlavní důvod, proč to nepoužívám.

[marbu]

Podpora pro myš jde v tmuxu zapnout. Pak by ses přes klávesovou zkratku přepnul do scrollback režimu a mohl používat kolečko myši na scrollování nebo klikáním označovat text v daném scrollback bufferu.

[kralyk z abclinuxu]

Další zásadní nevýhoda (těchto nástrojů obecně) je to, že když odtamtud chceš vykopírovat víceřádkový text, tak se text označuje po řádcích napříč těmi virtuálními okny.

konsole umí blokové označení - Ctrl + Alt + táhnu myší.

A nefunguje tam scrollování (samozřejmě to má vlastní scrollback, ale ten nereaguje na grafické posuvníky X terminálu, tažení myší atd.). To je hlavní důvod, proč to nepoužívám.

V tmuxu mám nastaveno

bind -n M-Pageup copy-mode -eu

(tj. alt + pgup) na vstup do scrollback režimu, funguje mi v tom módu i kolečko myši. Ale osobně mi stačí pgup a pgdown, v lokálních sessions taky používám jen shift+{pgup, pgdown, home, end} a scrollbar nemam zobrazený (popravdě mi moc není jasný, k čemu v terminálu je).

Jak řeší lidé, kteří nepoužívají screen nebo tmux, když chtějí někde spustit nějakou dlouho trvající operaci třeba s nějakým výstupem a mezitim třeba měnit svoji fyzickou lokaci, připojení apod.? tmux mi na tohle přijde krásně pohodlný.

[Jendа]

V tmuxu mám nastaveno

bind -n M-Pageup copy-mode -eu

(tj. alt + pgup) na vstup do scrollback režimu, funguje mi v tom módu i kolečko myši.

Hmm. Já dělám velmi často to, že někde začnu označovat a táhnu a ono to scrolluje. A pak taky používám funkci na zkopírování celého scrollback bufferu do schránky (používám Terminator (GTK2 verzi) a tam je na to plugin), to by byl dost opruz implementovat když mi tam běží SSH (muselo by se to připojit na ten stroj a dumpnout scrollback z tam běžícího screenu/tmuxu, kterých navíc může být několik). A dost často potřebuju abych mohl ve scrollbacku hledat i když spojení na vzdálený stroj už není (umřel, reboot, …).

a scrollbar nemam zobrazený (popravdě mi moc není jasný, k čemu v terminálu je)

Pro odhad velikosti scrollbacku a kde se v něm zhruba nacházíš. Ano, asi bych dokázal vymyslet praktičtější indikátor.

Jak řeší lidé, kteří nepoužívají screen nebo tmux, když chtějí někde spustit nějakou dlouho trvající operaci třeba s nějakým výstupem a mezitim třeba měnit svoji fyzickou lokaci, připojení apod.?

Ano, tohle je jediný use-case, kdy screen používám. (a samozřejmě nadávám když něco spustím bez něj, trvá to dýl než jsem čekal, a reptyr/retty řekne něco o tom že process grupa má blbě filedeskriptory a nejde to přehodit)

[kralyk z abclinuxu]

Hm, ok, to je jiný usecase. Btw. tmux zobrazuje vpravo nahoře pozici/velikost v řádcích... Jestli to je praktické, je otázka...

a samozřejmě nadávám když něco spustím bez něj, trvá to dýl než jsem čekal, a reptyr/retty řekne něco o tom že process grupa má blbě filedeskriptory a nejde to přehodit

přesně tak

[xkucf03]

Jak řeší lidé, kteří nepoužívají screen nebo tmux, když chtějí někde spustit nějakou dlouho trvající operaci třeba s nějakým výstupem a mezitim třeba měnit svoji fyzickou lokaci, připojení apod.? tmux mi na tohle přijde krásně pohodlný.

Přesně k tomu ten GNU Screen používám. Ale to ostatní mi přijdou takové rovnáky na ohýbáky. Když už mi tu běží desktop s GUI, tak dává smysl používat primárně GUI nástroje – nikoli textové nástroje, které vznikly v prostředí, kde neexistuje WM nebo DE, takže se správa oken nebo třeba schránka musela řešit jinak a v tom textovém režimu.

Když mi screen/tmux poběží přes SSH na jiném stroji, tak tam asi těžko bude fungovat jeho schránka sdílená mezi jeho instancemi. Já ten text potřebuji dostat do schránky v X, což je standard používaný napříč aplikacemi v mém pracovním prostředí.

Blokové označení sice funguje, ale vloží mi tam zalomení řádků, kde nemá být. Zatímco když v Konsoli vykopíruji třeba dlouhý příkaz (přes několik řádek) nebo dlouhý výpis, který je zalomený tou Konsolí, aby se vešel do okna, tak mi to zachová původní řádky, ale když mi ty řádky zalamuje screen, aby se vešly do jeho oken, a vykopíruji z toho blok textu, tak v něm mám i tato nežádoucí zalomení.

Pokud jde o klávesové zkratky, ty mohou úplně stejně fungovat i v GUI aplikacích. GUI resp grafický režim neimplikuje nutnost používání myši.

Jinak tedy: i když mi tu běží Xka a KDE, tak tu mám plno oken s textovými terminály, běží mi tu Emacs v textovém režimu, docela rád používám Midnight Commander a používám i ten Screen… ale nedělal bych z nouze ctnost – třeba ten mc používám, protože mi vyhovuje jeho jednoduché UI, používám ho navzdory tomu, že je textový, nikoli proto. (samozřejmě používám i Dolphin, někdy přetahuji soubory myší, někdy kopíruji přes schránku, někdy s nimi pracuji přes příkazový řádek… prostě používám způsob, který mi v danou chvíli přijde nejvhodnější)

[kralyk z abclinuxu]

Pravděpodobně by se to dalo relativně snadno řešit v emulátoru terminálu. Emulátor o těch hranicích "oken" obvykle ví, protože se tam invokují ty escape sekvence na designaci/změnu znakový sady právě za tímhle účelem, navíc IIRC mají tendenci si to renderovat nějak po svém, protože prohnat to přes unicode text rendering engine je zbytečné a může to vytvářet grafický artefakty.

Takže nějak naimplementovat 'chytrou' selekci v "okně" by nemělo být až tak obtížný.

[xkucf03]

Vždyť o tom mluvím výše:

Ale když už člověk GUI má, tak je lepší i pro tohle používat GUI nástroje (např. rozdělení pohledu v Konsoli nebo to řešit na úrovni DE a mít více oken), které jdou ovládat i klávesnicí.

Na tom není co řešit – tohle už je vyřešené – třeba v té Konsoli, ale věřím, že i v jiných emulátorech terminálu. Prostě jen označíš myší kus textu, vykopíruješ třeba do editoru a zachová ti to původní řádky, i když v tom emulátoru terminálu byly zalomené, aby se vešly do okna.

[kralyk z abclinuxu]

Nerozumíš mi. Mám na mysli to, že (např.) konsole by mohla vědět o těch "okýnkách" které kreslí curses-based a podobné CLI/TUI aplikace (protože ty informace většinou stejně už má - musí je vést v rámci vt102 state machine a potřebuje je k renderování), takže by mohla umět vybírat text v TUI "okýnku" *.

GUI okýnek nebo rozdělení pohledů v konsoli se to nijak netýká. GUI je samozřejmě fajn (nejsem ten typ, co by používal tmux i lokálně), ale je mi to nahouby, když chci vzdálenou persistentní session. Např. nedávno jsem na vzdáleném stroji spouštěl afl-fuzz, který běžel v několika instancích výsledku asi tejden. Na to ti je lokální GUI k ničemu.

*) Nefungovalo by to pro CLI aplikace kreslící okýnka jinak než pomocí VT box/line drawing charset, ale to většina afaik nedělá.

[xkucf03]

konsole by mohla vědět o těch "okýnkách" které kreslí curses-based a podobné CLI/TUI aplikace (protože ty informace většinou stejně už má - musí je vést v rámci vt102 state machine a potřebuje je k renderování), takže by mohla umět vybírat text v TUI "okýnku" *.

Byl by k tomu nějaký zdroj? Tohle se mi nějak nezdá.

Asi nemyslíš to, že by Konsole koukala na změny barev nebo hledala znaky jako │ a podle nich odvozovala, že to je okno a text pokračuje na dalším řádku, ne?

Nefungovalo by to pro CLI aplikace kreslící okýnka jinak než pomocí VT box/line drawing charset, ale to většina afaik nedělá.

Aha, takže asi myslíš. To je právě ten rovnák na ohýbák. Jasně, nějaká taková chytristika by tam být mohla, stejně tak by to mohlo umět třeba vybírat sloupce z výpisů relpipe-out-tabular, ale otázka je proč? Resp. proč nepoužít raději to rozdělení pohledu v Konsoli nebo obdobnou funkci v jiném emulátoru terminálu nebo třeba možnosti DE (klidně dlaždicového) a otevřít si víc oken.

Asi jediný smysl by byl pro vzdáleně běžící aplikace ve screenu, kde ti stačí jedno SSH spojení přes které protáhneš víc oken a víc výstupů vzdálených aplikací (i když SSH tedy umí multiplexovat a sdílet jedno TCP spojení pro víc relací).

[kralyk z abclinuxu]

Byl by k tomu nějaký zdroj? Tohle se mi nějak nezdá.

Asi nemyslíš to, že by Konsole koukala na změny barev nebo hledala znaky jako │ a podle nich odvozovala, že to je okno a text pokračuje na dalším řádku, ne?

TUI aplikace typicky nerenderují znaky jako │ , i když ti to tak může připadat.

Viz třeba tady, VT102-like state machine má 4 "sloty" pro "znakovou sadu". Tohle samozřejmě pochází ještě z doby, kdy nebyl Unicode etc., těch znak existuje několik pro různé jazyky + sada pro kreslení rámečků. V praxi se dnes používá pouze sada "US ASCII" (reálně Utf-8), kód 'B' a právě sada pro rámečky - kód '0'. Pomocí příslušných escape sekvencí si aplikace nastaví, která sada má být v jakém slotu a pak aktivuje příslušný slot pro např. kreslení rámečku buď natrvalo nebo pro následující znak.

Napiš si do terminálu echo -e '\e)0\xe' a sleduj, co se stane

Navíc - jak už jsem psal v tom prvním komentáři - pro emulátor je v zásadě lepší např. nekreslit Unicode znak '│', ale vyrenderovat tu čáru prostě jako čáru, je to rychlejší a bez artefaktů. konsole tohle dělá u mnoha znaků (viz zdroják).

Tohle jsem myslel tím, že ten emulátor v podstatě už má ty informace o hranicích těch "okýnek", protože ví, jaký znak kreslí jakou "znakovou sadou" (ve smyslu VT102 znakové sady, s Unicode to nemá nic společného).

Asi jediný smysl by byl pro vzdáleně běžící aplikace

Ano, to mám samozřejmě na mysli, však to taky píšu v tom komentáři

[kralyk z abclinuxu]

s/těch znak/těch sad/

[xkucf03]

Tohle jsem myslel tím, že ten emulátor v podstatě už má ty informace o hranicích těch "okýnek", protože ví, jaký znak kreslí jakou "znakovou sadou"

Zajímavé, dík.

Nechceš to tedy do té Konsole doimplementovat? :-) Asi jako další režim výběru (vedle normálního a blokového), který označoval text uvnitř rámečku.

[kralyk z abclinuxu]

Možná

[marbu]

Tohle zrovna v tmuxu spokojeně používám přes klávesové zkratky: přepnu se do scrollback režimu a pak v něm skáču a označím co potřebuju skoro jako ve vimu. V jiném okně můžu udělat paste do vimu nebo jinam.

[xkucf03]

A jak to dostaneš do nějaké GUI aplikace? Nebo třeba i do textové, ale běžící v jiném okně, na jiné ploše atd.?

[marbu]

Paste můžu pohodlně udělat jen do něčeho, co beží v tmuxu. Ale protože mi skoro všechno v nějakém tmux sezení běží a všechny tmux instance jsou klienti jednoho serveru, nemívám s tím problém: i kdybych něco označil v jednom tmux okně a paste udělal v druhém, bude to fungovat. Paste do gui dělám přes dočasný textový soubor, ale kdybych tohle potřeboval často, existuje na to plugin: https://tmux-plugins.github.io/tmux-yank/

[k3dAR]

Další zásadní nevýhoda (těchto nástrojů obecně) je to, že když odtamtud chceš vykopírovat víceřádkový text, tak se text označuje po řádcích napříč těmi virtuálními okny. Tyhle nástroje byly nejužitečnější v dobách textových terminálů a konsolí (bez X). Ale když už člověk GUI má[...]

pouzivam Byobu(nad tmux), rozlozeni si pamatuje (s trochou kompromisu(mc obnovi jen 1 panel a pokud je mc pres sudo, tak je potreba jit do ciloveho adresare pred pustenim mc) i po rebootu pri pridani tmux-resurrect pluginu), viceradkove kopiruju tak ze dane cast prepnu do fullscreen... pouzivam to primarne na ssh->server->byobu ale i na lokalnim NB, pouzit GUI nastroj nepotrebuju a predpokladam ze bych o cast funkci stejne prisel

[k3dAR]

k tomu pluginu kdyztak info tady

[Jendа]

Spravovat vic jak 10 stroju je prace pro CM (CFEngine, Puppet, Chef, SaltStack, Ansible)

Ne když na každém běží úplně jiné věci.

[xkucf03]

+1, starám se o celkem dost strojů (fyzických bude tak kolem deseti, ale virtuálek mnohem více), ale každý je v podstatě unikátní, každý dělá něco jiného, takže to moc automatizovat nejde. (maximálně tak automatizovat apt update ; apt full-upgrade)

[Ruža Becelin]

Automatizovat jde (temer) vsechno, snad krome balastu od IBM, BMC, apod.

Rovnice je: smysl=zisk/namaha

jak uz jsem psal Jendovi, pro 10 stroju bych se s tim nedelal.

Tedka se pohybuju v prostredi, kde jdou stroje do tisicu a to je manualne nezvladatelne.

[Aleš Kapica]

Tedka se pohybuju v prostredi, kde jdou stroje do tisicu a to je manualne nezvladatelne.

Tak to je pochopitelné. Já mám tu výhodu, že se jedná o linuxové desktopy u kterých je žádoucí aby měly podle potřeby identické softwarové vybavení. Toho jsem dosáhl tím, že používám dynamický ramdisk. Stroj dostane z DHCP hostname, a na základě toho se mu předhodí konfigurace do ramdisku. Tím odpadá konfigurace pxe menu, protože je pro všechny stroje stejná.

Pochopitelně situace, kdy je třeba instalovat tisíce strojů, které si pak mají žít vlastním životem, nebo mají sloužit pouze jako kontejner pro nějakou webovou appku je to pochopitelně jiné.

[xkucf03]

Pochopitelně situace, kdy je třeba instalovat tisíce strojů, které si pak mají žít vlastním životem, nebo mají sloužit pouze jako kontejner pro nějakou webovou appku je to pochopitelně jiné.

Ty můžou být taky bezestavové a pokud jich je hodně stejných, tak by to šlo řešit podobným způsobem, jako ty tvoje desktopy. Sice třeba ne přes PXE, ale tak, že by se do nich nezasahovalo, nikdo by je nespravoval a prostě by se celá virtuálka zahodila a spustila by se nová z aktualizované šablony. V případě třeba různých proxy nebo DNS serverů to může být docela dobré řešení, pokud jich má člověk hodně.

[Aleš Kapica]

Jo. Takhle mi to funguje. Letos s tím jak jsem řešil diskless přes wifi už mám know-how i pro mnohem divočejší situace. Zatím byl (a je) ten diskless závislý na síťové konektivitě. Ale s přepsáním mcachefs bych uměl udělat ty stroje zcela autonomní - vezmeš holý stroj, zaregistruješ mac adresu a finito. Jakmile by ho dotyčný nastartoval, tak by se defakto během použití nejenom nainstaloval ale i průběžně aktualizoval a v případě, že by mu síť zkolabovala by žil autonomním způsobem, dokud by se konektivita opět neobnovila.

Když tak nad tím přemýšlím - bylo by to ideální řešení pro linuxová mobilní zařízení. Pokud jde o vyriabilitu, tak používám sendvič - tzn. že je technicky možné aby si uživatel navolil jaké softwarové vybavení v tom chce mít, aniž by cokoliv instaloval.

[Heron]

Rovnice je: smysl=zisk/namaha

Ano, toto je dost podstatné. Sám jsem se ansible poctivě snažil používat asi dva roky na skupině stejných serverů do počtu dejme tomu 30 a použití ansible bylo mnohem pomalejší a náročnější, než to dělat ručně. Bylo to v době hype kolem "pokud se přihlašujete na servery ručně přes ssh, tak to děláte blbě" kdy mnozí doporučovali to používat i na jeden stroj.

Možná je to tím, že jsem za ty roky praxe se stovkami serverů zvyklý ty věci dělat rychle a na lecos mám svalovou pamět, nebo tím, že mi příliš nevadí občas dělat 30 stejných opakujících se akcí nebo nevím, ale ansible (zkoušel jsem puppet, díval jsem se i na chef, ansible mi přišlo nejlepší) bylo prostě násobně pomalejší a náročnější. Už třeba jen oprava chyb. Když mám v hosts 30 strojů, tak chyba se jedním příkazem dostane na všech 30 a služba na všech strojích nejede*. Je tedy potřeba mnohem více testovat. Když se uklepnu při nastavení jedné služby na jednom stroji, tak to zjistím okamžitě a oprava je prakticky hned. Tj minimální plocha a minimální čas. Chápu, že pro tisíce serverů už je automatizace nutnost a nějaké testování na testovací skupině 100 strojů je součástí práce.

Další věcí jsou chybějící moduly. V době, (tj tak dva roky na zpět), když jsem ansible používal, tak krom notoricky provařených věcí chyběly moduly na všechno. Rady "najděte si to na internetu" jsou úsměvné. Prošel jsem si několik modulů, které lidi prezentovali na githubu a všechny byly špatně (nebo ne špatně, ale téměř okamžitě jsem viděl možnost, jak je rozbít). Zcela evidentně je psali lidé, kteří o dané problematice (tj o tom, co se má nastavit) nevěděli vůbec nic a jen nadšeně napsali modul na první use case, který jim fungoval. Toto není profesionální přístup ani vhodné doporučení pro profesionální nástroj.

Takže ansible nakonec používám pro primitivnější věci. Sjednocení základních balíčků (všude chci mít nějaké balíčky a je celkem opruz navštívit všechny stroje, pokud se rozhodnu přidat další balíček), výměna klíčů a nějaké základní služby. Určitě by to šlo jinak, dřív jsem měl deb balíček bez obsahu ale s nastavenými závislostmi na jiných balíčkách, takže stačilo udělat update tohoto balíčku a všechny ostatní závislé balíčky se nainstalovaly automaticky. Apod.

*) Úplně klasická chyba je správa ssh klíčů. Ansible se připojuje na stroj přes ssh, je prakticky nutné používat klíče a má i modul na správu ssh klíčů. No takže, se stalo, že jsem si takto vymazal přístupové klíče a už jsem se tam nepřihlásil a ansible pochopitelně taky ne. (Komu se nikdy nic podobného nestalo, až si to hodí

[Aleš Kapica]

Vtipné je, když zapomeneš, že ti konfiguraci hlídá puppet, uděláš změnu a pak ti začne být divné proč se to revertne. Načež následuje náročný proces ponoru do hlubin vzpomínání co kde a jak vlastně je. To byl důvod, proč jsem to přestal takovým způsobem řešit. Opravdu jsem už fakt nechtěl absolvovat opakované hloubání nad aktuální dokumentací Puppetu.

[Heron]

No ono to s těmi managed / unmanaged je ještě úsměvnější.

Ansible a myslím, že to platí tak nějak pro všechny podobné nástroje, se zabývá pouze tím, co má v playbooku. Tj pokud chci nainstalovat nějaký balíček a nastavit jeho službu, napíšu si roli a přidám si jí do playbooku a ten spustím. Služba se nainstaluje a nastaví. Fajn. To chceme.

Potom časem tu službu přestanu potřebovat. Co ale s playbookem? Když jen odstraním danou roli, tak se ta služba neodinstaluje. Takže je potřeba na dát novou roli "odstranění služby". No fajn, tak se nám odstranila.

Za několik let je playbook plný rolí, které něco instalují a nastavují a odinstalovávají a odstraňují.

A někdo řekne, ano, je to deklarativní popis toho, jak vypadá server. Ale je opravdu? Když přijde někdo nový a zeptá se "jak mám dostat server do provozního stavu" a odpovědí mu je: nainstaluj minimal a spusť tam playbook. Ok, server se mu přivede do produkčního stavu. Potom začne ten playbook studovat a vidí tam Tasky: Remove Apache, Install nginx. No ale na tom jeho stroji žádný apache nebyl. Ten playbook najednou nedává smysl (i když ve výsledku dělá, co má - task remove apache prostě proběhne a po jeho ukončení tak apache skutečně nebude), ale z hlediska dokumentace stroje to příliš smysl nedává.

Takže vidím zásadní problém v tom, jak správně udělat unmanage nějaké služby.

[xkucf03]

A někdo řekne, ano, je to deklarativní popis toho, jak vypadá server. Ale je opravdu? Když přijde někdo nový a zeptá se "jak mám dostat server do provozního stavu" a odpovědí mu je: nainstaluj minimal a spusť tam playbook. Ok, server se mu přivede do produkčního stavu. Potom začne ten playbook studovat a vidí tam Tasky: Remove Apache, Install nginx. No ale na tom jeho stroji žádný apache nebyl. Ten playbook najednou nedává smysl (i když ve výsledku dělá, co má - task remove apache prostě proběhne a po jeho ukončení tak apache skutečně nebude), ale z hlediska dokumentace stroje to příliš smysl nedává.

To mi připomíná aktualizaci datového modelu. Tam ti po letech taky vznikne dlouhý seznam postupných kroků, které historicky dávaly smysl, ale když konfiguruješ nové prostředí, tak tě to fakt nezajímá a nechceš si tou celou historií procházet (byť automatizovaně). Řešením je si tam udělat nějaké „záchytné body“ – typicky pro major verze – které popisují stav v tom bodě. A inkrementálně se nasazují pouze změny zavedené v rámci jednotlivých minor verzí.

[alkoholik]

Pricetny clovek provozuje Puppet pod Foremanem s krasnym dashboardem, ve kterem naprosto jasne vidis, ktery stroj se zrovna hrabal v konfiguraci vcetne audit logu s diffem toho, co presne provedl.

[Aleš Kapica]

Příčetný člověk se s Puppetem rozešel dřív, než se stal Foreman použitelným nástrojem.

Neříkám že stál puppet za prd, ale využíval jsem ho primárně v druhé práci, kterou jsem definitivně zabalil před třemi lety. Pak jsem jeden čas používal ansible, než se ukázalo že mi to v podstatě jen přidává práci (protože na ty stroje nehrabu jen já).

[Aleš Kapica]

Prošel jsem si několik modulů, které lidi prezentovali na githubu a všechny byly špatně (nebo ne špatně, ale téměř okamžitě jsem viděl možnost, jak je rozbít). Zcela evidentně je psali lidé, kteří o dané problematice (tj o tom, co se má nastavit) nevěděli vůbec nic a jen nadšeně napsali modul na první use case, který jim fungoval.

Jako bys mi z duše hovořil. A to neplatí bohužel jen pro ansible a orchestrační nástroje.

[Ruža Becelin]

Od toho jsou tridy v CM. Ale pro 10 masin bych se s tim nedelal.

Jak rikam, delal jsem v infrastrukture, co vyrostla z deseti na 500+ serveru, do tech +-50 se to dalo pres CSSH, pak jsem zacal silhat po CM (CFE) a od 100 stroju nahoru to byla nutnost.

Bylo tam asi tricet ruznych typu serveru, dost z nich s unikatni konfiguraci a parametricky se to dalo dobre rozdelit (a opanovat).

[SNIPER]

Co za hlupáka psalo anketu?

Možnosti:

• 1
• true
• true
• true
• true
• true
• true

[k3dAR]

je to sice "nevhodne" formulovane, ale i prumerna opice pochopi ze jde o rozsahy "od do"...

[Odin1918]

Za mlada jsme na toto pouzivali ansible, nebo jak se to jmenovalo. Bylo to celkem jednoduche a rychle na nauceni se.

[Aleš Kapica]

A co by jsi s tím ansiblem na těch strojích dělal, když na nich nic není. Leda tak swapovací oddíl.

[rajcze]

Naprosto bez trollingu - na jaky konkretni operace je potreba se ke kazdymu tomu diskless klientu manualne pripojit, ze je ansible (nebo jiny podobny nastroj) nezvladne minimalne polo-automatizovat (tedy prinejmensim "vyradit klienty kde je vsecko v poradku")? Vzhledem k tomu ze Ansiblem jde na klientovi spustit naprosto libovolny prikazy/skripty me fakt zajima co jsou ty neautomatizovatelny pitfally diskless stanic.

[Aleš Kapica]

Vždyť jsem to napsal Někde se také používají lokálně instalované MS Windows a diskless se využívá k jejich distribuci a následnému doménování. Jinde se zase využívá lokální disk pro kešování (u robotů na kterých běží diskless přes WiFi).

U disklessu se také využívá swapovací oddíl, pokud existuje. Ale ty stroje mají různou HW kombinaci, což vyžaduje plnou kontrolu nad tím co se děje, a to ansible nezajistí. Přes hromadný vzdálený přístup velice rychle – vizuálním srovnáním – zjistím, u kterých strojů jsou přehozené disky, kde chybí swap, který stroj má málo paměti, kde se v dmesgu objevují chyby. A případně mohu odstartovat smart aby se disky otestovaly. & etc. & etc. Fantazii se meze nekladou.

Jinak vás mohu uklidnit. S orchestračním software mám bohaté zkušenosti. Používal jsem Puppet^1,2 i ansible³. Takže vím jak je používat. Ale také vím jaké mají mouchy a kdy spíš přidělávají práci, než aby pomáhaly.

[m.]

U disklessu se také využívá swapovací oddíl, pokud existuje. Ale ty stroje mají různou HW kombinaci, což vyžaduje plnou kontrolu nad tím co se děje, a to ansible nezajistí. Přes hromadný vzdálený přístup velice rychle – vizuálním srovnáním – zjistím, u kterých strojů jsou přehozené disky, kde chybí swap, který stroj má málo paměti, kde se v dmesgu objevují chyby. A případně mohu odstartovat smart aby se disky otestovaly. & etc. & etc. Fantazii se meze nekladou.

Tak na tohle pouzivam monitoring, ktery zjisti, jak se veci maji a v pripade neschody me na to upozorni. A protoze si nehodlam pamatovat kraviny, tak jak maj veci vypadat mam napsane v souboru. A kdyz uz jsem se obtezoval to nekam napsat, tak mam ansible, aby zajistilo, ze je vsechno udelane tak jak bylo definovano.

[Aleš Kapica]

A co bys na tom chtěl monitorovat?

Reálně situace vypadá úplně jinak. Jako kupř. letos. Zrušila se jedna laboratoř, ty stroje se nacpaly porůznu do těch ostatních. Některé nahradily stávající, jinde se daly úplně nové. Některé mají NVME disky, jiné SATA disky. Některé startují přes UEFI jiné přes BIOS. Některé mají na discích pozůstatky původně používaného systému a ty nemáš kdy zjišťovat co kde je, protože výuka už běží. Takže jsi nakonec rád, že se ti podařilo dát alespoň dohromady jejich MAC adresy a záznamy v DHCP, což je základ.

Všechno ostatní už lze řešit vzdáleně. Jenže kdy? Hrabat na stroje studentům pod rukama nechceš, a v podstatě ani nemůžeš, protože nevíš zda-li někdo na stroji zrovna dělá, nebo ne. A přesně o tom je vzdálená správa – přihlásíš se na ty stroje co žijou, zjistíš jestli na nich zrovna někdo nedělá a pak můžeš případně něco dělat ty.

Naštěstí u full-disklessu už není nutné dělat nic zásadního. Ten se spokojí se s tím, když na lokálním disku najde swap. Ale wireless diskless využívá lokální kešování přes mcachefs a to má bohužel svoje mouchy, které se musí řešit individuálně.

[m.]

Muj monitoring vi, kde jsou disky toho, ci ktereho typu, jakou maji velikost, jake oddily atp, kde je swap, jestli je v souboru nebo na svem vlastnim oddilu, jak je velky, kolik je kde pameti, jak je vyuzivana a cim, jestli se v dmesg obeviliy chyby atp. Samotny alerting je pak jen sada pravidel, kterou se ta data prohani a na zaklade toho se pripadne vyhlasi nejaky alert. Ale to neni pointa. Neni se treba nekam prihlasovat a zkoumat, proste se podivam do "datatabze" a vsechno co me zajima se dozvim.

Kazdopadne jak to ctu, tak vidim, ze nase prostredi neni zdaleka tak heterogenni jako to vase, takze je otazka, zda-li je nas pristup u vas vubec pouzitelny. Napriklad nemivame zbytky systemu nekde, proste bud se to pouziva a nebo to k nicemu dobre neni, pak se to vyhodi, na disk se prdne novy image a basta. Ansible (ble, nemam ho moc rad) pak podle ucelu toho stroje obstara zbytek.

Full diskless je celkem vyhra prave kvuli absenci stavu.

My na cache pro nfs pouzivame toto: https://linux.die.net/man/8/cachefilesd . Taky je to obstarozni kus sw, ale funguje spolehlive (pokud vim, tak neumi pouzivat tmpfs, takze na systemu bez disku je k nicemu). Na durhou stranu, pouzivame ho jen na jednu specifickou ulohu, kde se kazdy den pusti asi 300 stejnych stroju, ansible je po startu nastavi, pak po jejich zarazeni do clusteru par hodin zpracovavaji davku a pak se zase vypnou a zahodi. Je otazkou co bych rikal o spolehlivosti cachefilesd, kdyby se to pouzivalo na vic rozdilnych vecech.

[Aleš Kapica]

Pokud jde o kešování, hledal jsem poměrně dlouho a zkoušel kde co. Jednu chvíli už jsem jásal, že to mám. Jenže pak se ukázalo, že to řešení je nepoužitelné, jelikož se při něm publikovaly do horních vrstev symlinky jako soubory. Což je nepoužitelné, pokud nad tím má běžet systemd, který pak nefunguje. Takže znovu. Až jsem natrefil na odkazovaný mcachefs, který tenhle problém nemá. Opět jsem zajásal a pak zjistil, že je blbě navržený a nejlepší by bylo to přepsat. Ale jednak na to není kdy, a pak by to pro mne znamenalo kompletně přehodit na půl roku výhybku v hlavě. Rychlejší a jednodušší bylo napsat skript, kterým se to dá vyřešit, až to bude nutné. Týká se to jen cca 16 strojů.

Jen tak čistě ze zájmu. Ty stroje se pouští v jedné lokalitě, nebo na různých sítích? A pro ten cluster používáte zookeeper, nebo něco jiného?

Nezmínil jsem totiž, že u nás mají ty laborky na různé VLAN. A taky jsem do toho nezapočítal stroje v tzv. "duhovkách", které jsem na vlastní oči ani nikdy neviděl. Ty fungují tak, že pxe menu katedry počítačů (které ty laborky patří) má v menu položku, která udělá chainload na naše pxe a dál už to všechno jede z infrastruktury DCE.

Dřív jsem také zkoušel použít ansible alespoň pro zálohování konfigurací serverů, ale nakonec jsem došel k tomu, že mě to vlastně vůbec nezajímá, protože se stejně řeší případ od případu a stroje se objevují a mizí, aniž by se o tom se mnou někdo bavil. Na mě se obracejí až když je problém. Za což všem zainteresovaným děkuji, neboť mi to dává dostatek prostoru abych se mohl věnovat diskuzím na abclinuxu a zároveň při tom i něco kloudného udělat 8-P

[rajcze]

Vždyť jsem to napsal - je to mozny, ale jak jsi asi pochopil, tak pro me ... v jedné z učeben využívat diskless linux i pro distribuci a administraci lokálně instalovaných MS Windows. pro me proste neni "konkretni, neautomatizovatelny krok". Pokud jsem neco minul ve zbytku clanku, samozrejme se kaju, ale prislo mi to jen jako oda na cssh (nic proti tomu).

zjistím, u kterých strojů jsou přehozené disky, kde chybí swap, který stroj má málo paměti, kde se v dmesgu objevují chyby. A případně mohu odstartovat smart aby se disky otestovaly. & etc. & etc. Fantazii se meze nekladou. OK, asi mam malou predstavivost, ale porad tam nevidim nic co by bylo nutny delat manualne. Tim nerikam ze Ansible je reseni, jen me prekvapuje ta (prinejmensim implikovana) manualnost neceho co zni prudce automatizovatelne.

Kazdopadne i tak dik, sice jsem se nic nedozvedel, ale to nevadi. Hlavne ze jsi spokojeny a pokud mozno tezce nahraditelny :)

[Aleš Kapica]

…ale prislo mi to jen jako oda na cssh (nic proti tomu).

No tak to ti opravdu jen tak přišlo, poněvadž primárně jsem chtěl upozornit na terminator, který umí něco podobného, ba i něco navíc.

…a pokud mozno tezce nahraditelny :)

Ó kéž by tomu tak bylo. V takovém případě skonám s klidem v duši, až mě skolí někdo na přechodu. Bohužel realita se zdá být poněkud jiná. Pokud bys věděl o takových náhradách, sem s nimi. Rád jim svoje know-how předám dřív než na to dojde.

[Andrej]

pouzivanie roznych uctov na pristup k roznym serverom riesi subor ~/.ssh/config

distribuciu ssh kluca na vzdialeny server riesi ssh-copy-id

inak pekny prehlad, vdaka!

[Gilhad]

ja v lokalnim ~/.ssh/config mam jen

IdentityFile ~/.ssh/ids/%r@%h.key

a v adresari ~/.ssh/ids/ pak soubory typu user1@masina1.key user2@masina.key spravce@pocitac.nekde.neco.key ..... s prislusnymi klici :)

[xkucf03]

Máš pro každý vzdálený server unikátní pár klíčů?

[Gilhad]

Dokonce pro kombinaci user a server :)

Me to dava smysl, nekde jsem gilhad, nekde user (a rada jinych taky) jinde user (a jednoznacny), nekde admin (a par dalsich taky), na druhou stranu admin muzu byt na strojich patricim ruznym skupinam, takze aspon pro ty sdilene identity to nechci (ci dokonce ani nemuzu) sdilet mezi ruznymi skupinami.

Takhle je to jednoduche a prakticky nic me to nestoji (novy par vytvorim hned a je to par bytu). Pokud se meni server, nebo do nej ziskavam/ztracim pristup, tak je jednoduche dovodit, co se pro me meni :)

[Andrej]

naco je dobre mat pre kazdy server unikatny kluc?

pride mi to uplne zbytocne, jedine ze by ti admin servera odmietol pridat tvoj kluc, ale to je taka zakladna a zaroven uplne bezpecna poziadavka ze si neviem predstavit zdovodnenie.

[Gilhad]

Casto jsem adminem dokonce ja, ale zase davam prednost tomu, mit oddeleny soukromy zivot a jednotlive zakazniky dost tlustou carou. A i v tom soukromem zivote maji ty servery ruzne role, nektere mam fyzicky pod kontrolou, nektere ne a nektere ani fyzicky neexistujou, takze mit jedno univerzalni (byt komplikovane) heslo pro vsechny mi prijde jako zbytecne riziko, kdyz vytvoreni noveho je okamzik, nestoji to nic, naistaluju to hned a od te doby si to pamatuje stroj, nikoli ja.

Takze proste mam zvyk pro novy ucet, nebo novy stroj vytvorit novy klic a hodit ho tam (nebo ho tam nechat hodit). Pokud uz s danym strojem/uctem nechci mit nic spolecneho, tak to zase smazu a smytec. (a nemusim premyslet, jestli za 5 let to pujde kvantove hacknout na nejake supergrafarne s vyuzitim dosud neznameho bocniho kanalu a ze teda bych mel pregenerovat hesla pro vse, kam jeste chodim, protoze co kdyby si nekdo ze zalohy neceho kam davno nechodim ten muj klic dopocital.

Ty mas pro vsechny sluzby, ktere kde pouzivas, stejne jmeno a stejne heslo? A povazoval bys to za rozumne doporuceni?

[Jendа]

Nějak nechápu to plynulé přecházení mezi klíčem a heslem. Heslo se na druhou stranu posílá, takže ten stroj ho ví. To mít stejné na více místech je samozřejmě nesmysl (protože ho ten stroj na druhé straně jednoduše ukradne). Klíč se jaksi neposílá.

[Andrej]

obavam sa ze z poslednej vety vyplyva ze asi nechapes ako a na co sa pouzivaju ssh kluce.

a odpoved je: mam jeden ssh kluc ktory pouzivam uz dlhe roky pre vsetky svoje pracovne aj sukromne servery.

Ak by som sa chcel na konkretny server logovat do roznych uctov tak by som na to zase pouzil ten jediny ssh kluc. Rozlisenie uctu sa predsa robi loginom, nie je potrebne to akokolvek komplikovat unikatnym ssh klucom.

A k supergrafikam ktore dokazu z verejneho kluca vypocitat jeho privatny protikus mam len to ze ak by sa takyto HW potuloval po svete tak moje cracknute ssh kluce budu ten najmensi problem co ma bude trapit.

[Gilhad]

ssh klicem prokazuju druhe strane, ze ja jsem (cizi) identita za kterou se vydavam tim, ze mi posle neco zasifrovaneho (u ni) verejnym klicem a ja to soukromym klicem dokazu (u sebe) rozsifrovat a naopak ze dokazu (u sebe) neco tim soukromym klicem zasifrovat tak, ze ona to rozsifruje tim verejnym klicem (u ni). Pak podle mi veri, ze jsem ta (cizi) identita, za kterou se vydavam.

Jmenem a heslem prokazuju cizi strane, ze jsem ta (lokalni) identita, za kterou se vydavam (a vse se kontroluje u ni).

---

Ono to vzniklo pred dlouhou radou let, kdy jsem mel jen jeden pocitac a od zakaznika jsem dostal pristup na jeden jeho server v ramci sdilene identity admin (a to privatni klic), takze jsem si zalozil admin@zakaznik a bylo dobre (no nebylo to spravne reseni z jeho strany, ale s linuxem jsem zacinal a resil vic dulezitejsich problemu (jak se zorientovat v linuxu hned, jak napsat pozadovanou funkcionalitu, jak ... a vsechno stylem "vcera bylo pozde"), klice jsem zacal resit o radu let pozdeji) a zaroven jsem dostal vlastni ucet pro soukrome veci, kam jsem si okamzite nageneroval vlastni par a dal tam jen verejny klic (gilhad@zakaznik) - tehdy bylo pripojeni drahe a misty i blbe dostupne, vetsinou pomale, takze to byl dobry benefit odtamtud stahovat a vyrizovat si veci. Zaroven mel par dalsich stroju, kam mel pristup kazdy admin, takze jsem dostal zase privatni klice a mel admin@stroj1, uzivatel@stroj1, uzivatel@stroj2 a tak a v ramci "jednoduchosti" ten stroj2 byl naklonovany na vic pocitacu, ktere vetsinou nebyly zapnute, nebo pristupne - tak jsem si rozkopiroval ty klice a mohl se snadno logovat kam jsem potreboval, kdyz to zrovna bezelo) pak jsem si tam udelal par pokusnych uctu test1@zakaznik test2@zakaznik a tak a zkousel, co se stane, kdyz nekde prava budou a nekde ne a tak jsem generoval dalsi pary.

Ten trik s user@id v adresari fungoval snadno, daly se zkouset skripty a tak a kopie stroje2 nesly snadno modifikovat, takze jsem skoncil se sadou klicu, kde nektere byly stejne, jine ruzne, vetsina generovana na ruznych strojich za ruznym ucelem a jednoduchym navodem, jak delat dalsi. Vyvojarsky tym byl maly, vetsina veci se sdilela, ja si osobni veci drzel stranou, takze to davalo smysl. nekde jsem to generoval jako ja, pro sebe, nekde jako vyvojar, pro skupinu a nekde jako zakaznik, pro lidi, co netusili nic, jen to chteli mit jednoduche (a pak jsem se tam musel hlasit jako oni a jejich jmenem veci opravovat).

takze jednoduche pravidlo - pro kazde nove user@id vygenerovat klice, ty, ktere me uz nezajimaji zahodit, abych se tam nedostal (a pripadne se mohl vymlouvat, ze nemam prava, at zaridi oficialni cestou, abych je dostal - a to uz si radsi precetli ten manual a udelai to sami).

no a teprve o par let pozdeji jsem se zacal zajimat o to, jak ty klice skutecne funguji a pouzivaji se spravne, ale to uz ten seznam user@id byl docela dlouhy a s vetsinou by bylo obtizne nejak hnout (ono to pak vyhnilo casem) a naopak pokus o prihlaseni na tester@masina bud prosel (a pak jsem tam prava mel a chtel mit), nebo neprosel (protoze jsem si klic smazal a tudiz vedel, ze tam nemam lozit, i kdyz byl admin lemra a ze seznamu klicu me tam nevyhodil, protoze ani netusil jak se to dela a ze by to delat mel)

No a ten skript, kterym to bylo obalene jednoduse psal do komentare klice "kdo@odkud -> jako@kam" takze kdyz jsem to casem ruzne cistil, tak se to udrzovalo snadno (a bylo snadne zjistit, co mam "povolene" a co ne a kam vsude muzu primo).

S tou posledni vetou jsem prestrelil, spis jde o to, ze nova hesla generuju s lepsim sifrovanim, stara predelavam obcas, protoze to obcas znamena nejdriv zjistit, kam vsude prolezla a kde teda ma byt nove. Ale pohled at uz do ~/.ssh/ids na prislusnem stroji ukaze snadno, ze tam jsou klice pro uz neexistujici stroje a melo by se s tim neco udelat, nebo naopak do ~/etc/authorized_keys pak snadno odhali, ze tam jsou klice ze stroju, ktere uz neexistuji, takze zaslouzi smazat, nebo je nahradit novejsi variantou - pripadne, ze tam jsou klice, ktere byly docasne zkopirovane odjinud a ze mam zjistit, jak to s tema strojema prave je)

(a vedlejsi efekt je, ze muzu novemu spravci klidne predat soukromy klic git_instalace@zakaznik (nebo testerovi tester@zakaznikuv_klient) i kdyz mi ten stroj neni zrovna dostupny, aniz bych vyrazne ohrozil gilhad@zakaznik, natoz admin@zakaznik - a pak si tam v klidu dat novy klic, az to pujde snadno)

[Vantomas]

Trochu jsem čekal, že za tímhle přiběhem bude, že končící zákazník trval na odevzdání privátní části klíče a zamezil přístupu na server zaříznutím VPN, takže klíč už nešlo vyměnit. Sám jsem se přesně s takovýmhle problémem setkal...

[alkoholik]

No tvl, to jsou picoviny.
At si zmaze public z authorized_keys a da pokoj!

[xkucf03]

+1

[Jendа]

Co se dělá když máš klíč v čipové kartě/TPM a tak nelze nijak odevzdat?

[k3dAR]

u desktopu bejva TPM na konektoru

[Andrej]

odovzdavat privatnu cast kluca (subor) ma zmysel len ak je kluc v nejakom HW. Toto je IMHO iny pripad - konkretne trvanie na uplne zmatocnom pouzivani klucov sposobom ktory vec len komplikuje a nedava ziadnu vyhodu.

[Vantomas]

Je to třeba deset let zpátky a šlo o to, že zákazník se rozhodl sjednotit správu IT pod jednoho dodavatele, takže začali s inventarizací a sháněli se po přístupech. O správě Linuxu vůbec neměli páru a po pár vyměněných emailech došli k závěru, že chtějí privátní část kliče.

Nakonec to stejně dopadlo tak, že jsem se o to ještě pár měsíců subdodavatelsky staral, než si tam dali server s Windows...

[Lovec perel]

Co znamená ten zápis v anketě 2<5 apod? Že dva je menší než pět?

[Aleš Kapica]

Narůstající počet od dvou do pěti.

[debian+]

Posledna polozka v ankete mala byt: 1000+

[Radek Podgorny]

to skoro zni jako idealni pripad pro omnirun