abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 19:00 | IT novinky

Příspěvek na blogu Mozilla Hacks představuje alianci s názvem Bytecode Alliance založenou společnostmi Mozilla, Fastly, Intel a Red Hat. Cílem aliance je dostat aplikace ve WebAssembly i mimo webový prohlížeč.

Ladislav Hagara | Komentářů: 0
dnes 18:11 | Nová verze

Byla vydána nová major verze 1.4.0 webového poštovního klienta Roundcube (Wikipedie). Podrobný přehled novinek na GitHubu. Roundcube je nově responzivní, tj. podporuje také tablety a chytré telefony, viz náhledy.

Ladislav Hagara | Komentářů: 0
dnes 17:11 | Nová verze

Byla vydána nová stabilní verze 18.06.5 linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Přehled změn v Changelogu. Jedná se o opravné vydání OpenWrt 18.06.0 vydaného v červenci 2018. Pro zájemce o testování je k dispozici první RC verze OpenWrt 19.07.0.

Ladislav Hagara | Komentářů: 0
dnes 16:55 | Nová verze

Byla vydána verze 2.0 svobodné federalizované platformy pro sledování a sdílení videí, alternativy YouTube s podporou P2P, PeerTube (Wikipedie). Přehled novinek v příspěvku na Framablogu. Za vývojem PeerTube stojí nezisková organizace Framasoft snažící se mimo jiné nahradit svými svobodnými Frama službami služby společnosti Google (De-google-ify Internet). Bohužel ale musí některé své služby omezit.

Ladislav Hagara | Komentářů: 0
dnes 10:11 | Komunita

Na přelomu října a listopadu proběhla v Lyonu GStreamer Conference 2019, tj. konference vývojářů multimediálního frameworku GStreamer. Videozáznamy přednášek byly zveřejněny na portálu UbiCast.

Ladislav Hagara | Komentářů: 0
včera 13:33 | Zajímavý článek

Christian Ude, bývalý dlouholetý starosta Mnichova, v rozhovoru pro německý Linux Magazin vzpomíná na projekt LiMux, kdy město přešlo na vlastní linuxovou infrastrukturu a OpenOffice.org (posléze LibreOffice), ale příští vládnoucí koalice se rozhodla vrátit se k produktům Microsoftu.

Fluttershy, yay! | Komentářů: 56
včera 13:22 | Komunita

Uživatelé Linuxu ve VirtualBoxu obvykle instalují Přídavky pro hosta (Guest Additions) pro lepší podporu emulovaného hardwaru. Brzy už ale nebudou přídavky potřebné. Ovladač vboxguest se dostal již do Linuxu 4.16 v dubnu loňského roku. Včera vydal Linus Torvalds Linux 5.4-rc7 (LKML). Přidán byl ovladač vboxsf (VirtualBox Shared Folder) pro sdílené složky.

Ladislav Hagara | Komentářů: 1
10.11. 23:44 | Nová verze

Byla vydána nová verze 1.40 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.40 bylo vydáno také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

Ladislav Hagara | Komentářů: 0
10.11. 01:22 | Nová verze

Byla vydána nová verze 6.4.0 správce digitálních fotografií a videí digiKam (digiKam Software Collection, Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení. Nový digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.

Ladislav Hagara | Komentářů: 0
9.11. 12:11 | Zajímavý článek

Webový prohlížeč Mozilla Firefox 1.0 byl vydán před 15 lety, 9. listopadu 2004. Článek v magazínu Fast Company připomíná vývoj zastoupení Firefoxu mezi uživateli webu, jeho propad ve prospěch Google Chrome a následný vývoj, zvláště orientaci Mozilly na ochranu soukromí uživatelů a hodnoty formulované v manifestu.

Fluttershy, yay! | Komentářů: 17
Jaké hodinky nosíte (nejčastěji)?
 (26%)
 (7%)
 (10%)
 (56%)
Celkem 87 hlasů
 Komentářů: 2, poslední dnes 16:00
Rozcestník
Štítky: není přiřazen žádný štítek

www.AutoDoc.Cz


Vložit další komentář
23.10. 18:04 Zdenek 'Mst. Spider' Sedlak | skóre: 38 | blog: xMstSpider
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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
23.10. 18:20 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
23.10. 19:22 marek_hb
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 23.10. 20:24 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů

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í.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Jendа avatar 23.10. 21:01 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
Bojíte se 5G sítí? Pořiďte si domů radar, který veškeré 5G sítě spolehlivě zaruší!
23.10. 22:16 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
24.10. 00:13 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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а avatar 24.10. 05:31 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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)
Bojíte se 5G sítí? Pořiďte si domů radar, který veškeré 5G sítě spolehlivě zaruší!
24.10. 12:58 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 24.10. 10:19 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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ší)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
24.10. 13:05 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 24.10. 13:13 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů

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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
24.10. 15:19 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 24.10. 17:43 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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í).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
24.10. 18:01 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 :-D
24.10. 18:05 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
s/těch znak/těch sad/
xkucf03 avatar 24.10. 18:11 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
24.10. 19:31 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
Možná ;-)
23.10. 21:58 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
xkucf03 avatar 23.10. 22:03 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů

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.?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
23.10. 22:10 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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/
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
k3dAR avatar 23.10. 22:37 k3dAR | skóre: 57
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů

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 :-)
porad nemam telo, ale uz mam hlavu... nobody
k3dAR avatar 23.10. 22:44 k3dAR | skóre: 57
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
k tomu pluginu kdyztak info tady
porad nemam telo, ale uz mam hlavu... nobody
Jendа avatar 23.10. 21:02 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
Bojíte se 5G sítí? Pořiďte si domů radar, který veškeré 5G sítě spolehlivě zaruší!
xkucf03 avatar 23.10. 21:20 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů

+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)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
24.10. 22:36 Zdenek 'Mst. Spider' Sedlak | skóre: 38 | blog: xMstSpider
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
24.10. 23:15 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 24.10. 23:38 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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ě.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
25.10. 07:16 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 25.10. 12:28 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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í ;-)
25.10. 12:54 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 25.10. 13:12 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 25.10. 13:42 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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í.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
25.10. 13:35 alkoholik | skóre: 38 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
25.10. 13:50 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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á).
25.10. 12:57 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
24.10. 22:32 Zdenek 'Mst. Spider' Sedlak | skóre: 38 | blog: xMstSpider
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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).
23.10. 18:09 SNIPER
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
Co za hlupáka psalo anketu?

Možnosti:
  • 1
  • true
  • true
  • true
  • true
  • true
  • true
k3dAR avatar 23.10. 22:40 k3dAR | skóre: 57
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
je to sice "nevhodne" formulovane, ale i prumerna opice pochopi ze jde o rozsahy "od do"...
porad nemam telo, ale uz mam hlavu... nobody
23.10. 20:33 Odin1918 | skóre: 5 | blog: Valhalla
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
Za mlada jsme na toto pouzivali ansible, nebo jak se to jmenovalo. Bylo to celkem jednoduche a rychle na nauceni se.
23.10. 20:44 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
24.10. 08:19 rajcze | skóre: 6 | blog: rajcze | kus od Brna
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet.
24.10. 09:59 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 Puppet1,2 i ansible3. 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.
24.10. 11:25 m.
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
24.10. 11:43 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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ě.
24.10. 13:15 m.
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
24.10. 15:53 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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
24.10. 15:09 rajcze | skóre: 6 | blog: rajcze | kus od Brna
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 :)
Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet.
24.10. 15:28 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
…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.
23.10. 21:24 Andrej | skóre: 9
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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!
Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
24.10. 02:18 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 avatar 24.10. 10:23 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů

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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
24.10. 15:14 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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 :)
24.10. 10:37 Andrej | skóre: 9
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
24.10. 15:24 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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а avatar 24.10. 22:05 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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á.
Bojíte se 5G sítí? Pořiďte si domů radar, který veškeré 5G sítě spolehlivě zaruší!
24.10. 23:12 Andrej | skóre: 9
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
25.10. 02:50 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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)
25.10. 09:45 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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...
25.10. 13:40 alkoholik | skóre: 38 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
No tvl, to jsou picoviny.
At si zmaze public z authorized_keys a da pokoj!
xkucf03 avatar 25.10. 13:42 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
+1
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Jendа avatar 25.10. 17:21 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
Co se dělá když máš klíč v čipové kartě/TPM a tak nelze nijak odevzdat?
Bojíte se 5G sítí? Pořiďte si domů radar, který veškeré 5G sítě spolehlivě zaruší!
k3dAR avatar 25.10. 18:07 k3dAR | skóre: 57
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
u desktopu bejva TPM na konektoru ;-)
porad nemam telo, ale uz mam hlavu... nobody
28.10. 12:02 Andrej | skóre: 9
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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.
Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
28.10. 12:19 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
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...
24.10. 13:57 Lovec perel
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
Co znamená ten zápis v anketě 2<5 apod? Že dva je menší než pět?
24.10. 15:20 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
Narůstající počet od dvou do pěti.
24.10. 21:23 debian+
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
Posledna polozka v ankete mala byt: 1000+
24.10. 21:46 Radek Podgorny | skóre: 16
Rozbalit Rozbalit vše Re: Vzdálená správa většího počtu strojů
to skoro zni jako idealni pripad pro omnirun

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.