Ez is csak szarabb lett, mióta a vmware megvette... Mostanában történt valami (most 3006.4-en vagyunk).
Szóval van egy job, de akár egy sima test.ping is, amit kiküldök valahány gépre, vagy '*'-ra. A gépek egy része:
Minion did not return. [No response]
The minions may not have all finished running and any remaining minions will return upon completion. To look up the return data for this job later, run the following command:
salt-run jobs.lookup_jid 20231114094736830359
És akkor 'salt-run jobs.lookup_jid 20231114094736830359' megmutatja azokat a minionokat, akik válaszoltak (meg hogy mit). De aki nem válaszolt vagy amúgy hibát adott, arról egy büdös szó nincs. Plusz ennek a végére nincs summary sem, szóval nemhogy arról gözöm sincs, hogy ki csinálta meg és ki nem, de még azt sem tudom hány (hacsak pl. grep-pel meg nem számoltatom), ki adott hibát.
Szóval ez így teljesen használhatatlan. Próbáltam nézni a új default konfigot, és abból pár opciót még berakni (főleg timeoutok), semmi nem változott.
Továbbá a konfig végigböngyőzése közben találtam (valszeg ez is valami újabb opció), bekapcsoltam a random_master-t - mert elvileg enélkül csak az elsőhöz kapcsolódik (nem tudom ez mit jelent, mert mindkét master működött rendesen amúgy), ennek az lett az eredménye, hogy közli, hogy amúgy ignorálja mert csak egy master van megadva (nem), innentől ráadásul ahhoz se tud kapcsolódni - még szerencse hogy nem vertem minden minionra restartot, mert mehettem volna végig az összes minionon és kézzel visszatenni a régi konfigot.
Kezd vicc lenni ez a cucc.
Másnak vélemény, tapasztalat?
Hozzászólások
Kb. 8 éve használtam pár hónapon át, akkor is kábé ez volt róla a benyomásom mind neked most :(
Ez eddig nem így volt.
Igazi timeoutba csak akkor lehetett futni, ha valamiért a halálán volt a minion (vagy bármi oknál fogva be volt lassulva), vagy épp az első enroll ment, és minden state-et tolt ráfele, csomagokat töltött le, telepített, stb. Plusz, ha salt-run-nal lookupoltad az eredményt, akkor ott ugyanúgy listázta, aki nem válaszolt. Summary se kellett.
Hab a tortán (ez is pár verzió óta van), hogy valami új formátumban érkezik a cucc + gondolom "fejlesztettek" is rajta, hozza a saját pythonját meg minden szarját, ami annyira zseniális (azelőtt se volt villám mondjuk), hogy windowsra egy test.ping majdnem 10mp.
"Sose a gép a hülye."
Megnéztem time-mal mennyi ideig fut egy sima "salt '*' test.ping", és kb. pont 1 perc után adja vissza a shellt. Ez csak azért érdekes, mert baromira nincs sehol 60s/1m timeout érték, se általam megadva, se defaultba.
"Sose a gép a hülye."
Akárhogy csűröm-csavaron, amelyik minion lefut valami istenverte timeout-ra, onnan baszik visszaconnectálni amíg nem restartolom. Ez így egy kalap szar....
"Sose a gép a hülye."
Ha a minion configba berakom az ipv6: True-t, akkor sem tud a masterhez csatlakozni (igen, igen, teljesen rendben van az ipv6 mindkét oldalon, a master listen-el is rajta).
"Sose a gép a hülye."
Pozitívum: ha kiküldesz egy job-ot egy pillanatnyilag nem elérhető minionra, akkor miután elérhető lesz és visszacsatlakozik, megcsinálja. (Gondolom nem az örökkévalóságig, van valami queue lifetime, de egy service vagy gép restartra, rövid network problémára simán jó...)
Viszont itt is negatívum: salt-run-nal hiába kérdezed le a job statusát, kurvára nincs benne ez a minion, aki amúgy utólag (jól) megcsinálta.
"Sose a gép a hülye."
Teljesen szét vagyok esve, semmi időm nem volt ennek a fostalicskának a cseréjével foglalkozni, úgyhogy azóta is megy. A workaround a lehulló kliensekre és a memóriazabálásra is az lett, hogy kiküldtem windowsokra meg linuxra is egy taskot, óránként újraveri a salt-miniont cronból meg task schedulerből. Remek, "működött".
Erre most megint elkezdtek elhullani a kliensek. Nézek utána hogy mi a p*csa van... Azok tűntek el, amik már 3006.7-re updatelődtek.
[ERROR ] The master key has changed, the salt master could have been subverted, verify salt master's public key
Azt mondja valami változott a master kulcson, úgyhogy legyek szíves törölni (én, kézzel)..
If you are confident that you are connecting to a valid Salt Master, then remove the master public key and restart t...lt Minion.
The master public key can be found at:
/etc/salt/pki/minion/minion_master.pub
Szóval rm -f /etc/salt/pki/minion/minion_master.pub, systemctl restart salt-minion, és megy...
Eszem f*szom megáll.... Miféle hulladik szennytalicska lett ez?
"Sose a gép a hülye."
Direktben soha nem hasznaltam meg salt-ot csak SUSE manageren "keresztul", de ilyen problemakat soha nem tapasztaltam vele. Kb a nullarol (nem teljesen, par nagyon alap dolog AutoYaST-al megy) ezzel "lakom be" a servereket (domainba leptetes, appok telepitese, config fajlok ratoltese, stb stb...szoval lenyegeben kb minden)
Hát az alatt a fél óra alatt amíg felhúzod vele állapotra a gépet, nem is nagyon lehet... Addig többnyire megy.
"Sose a gép a hülye."
nyilvan nem vegez muveleteket a servereken allandoan a salt, de pl patcheles stb is azza megy Suse Managerben de ott sem szokott vele gond lenni. Amit mondjuk eszrevettem, hogy ez azota van, miota minden serverem SUSE.. Ubuntuval, sot meg centos-al is voltak gondok (salt minion offline volt, ez volt a gond legtobbszor)
"Szerencsére" megérkezett a 3007, néhány gép már le is frissített.
Windózon a service azóta el se indul, service manager szerint "paused" (nem is emlékszek hogy láttam már ilyet). Kiváló. SóTamagocsi
"Sose a gép a hülye."
A paused mint service state már elég régóta létezik:
When a service is paused, it can maintain internal state, including cached information or possibly even a queue of waiting work items. The service can then be resumed to pick up where it left off.
If the service is stopped, internal state is discarded. Starting the service again should repeat all initialization.
Csak annyit mondtam, hogy még nem hiszem hogy láttam ilyet élőben...
"Sose a gép a hülye."
Blogolok ide róla ismét egy kicsit:
Szóval a 3007 azóta se megy nekünk (pedig elvileg van már rá megoldás, valami vc libaryt kell feltenni pluszban kézzel), úgyhogy 3006.7-en mennek a windows-ok...
Na de az új installok ezzel se mennek, ami felettébb érdekes. Egy pythonos utf-8 hibát fosik, amihez így good lock hogy találd ki mi baja. Most a délelőttöt rászántam eme szívásra.
A telepítés után a konfigurálást egy powershell scripttel csinálom:
Nos, kivételesen nem a salt szaródott el "visszamnőlegesen". Hát akkor mi? "Természetesen" az univerzális, stabil, egyszerű, mindenre jó powershell. Ezt találtam:
https://stackoverflow.com/questions/40098771/changing-powershells-defau…
Ezt úgy itthagynám áttekintésre, hogy a powershell verzióktól illetve magától a tool-tól (pl. Cmdlets that write) ami a fájlt írja, mennyire függ hogy mi lesz a kimeneti fájl kódolása. Egy hányinger...
Szóval, a powershell script elejére kell egy $PSDefaultParameterValues = @{ '*:Encoding' = 'utf8' } beállítás, és jó.
Én azt hittem már ~15 éve tól vagyunk ezeken a karakter encoding szarakodásokon, de úgy tűnik windowsban még mindig és, sőt bővül a katyvasz.
"Sose a gép a hülye."
Ezer év után a minap csináltam egy kutya közönséges BAT állományt, hogy a kollégák egy telepítőt mindenféle kapcsolókkal felparaméterezve, silent módban könnyen tudjanak használni USB drive-ról szükség esetén.
Megdöbbentem, hogy a kiírt státusz üzeneteim össze-vissza karaktereket tartalmaztak a képernyőn. A sima BAT-ba be kellett írni egy parancsot, amivel megadom, hogy CP1250-nel fusson, mert úgy jelentek meg ehylesen az ékezetes karakterek...
Én sem gondoltam, hogy 2024-ben, Windows-on ott tartunk, hogy nem default UTF8 minden, amit az összes többi rendszer más szerintem megugrott vagy 10 éve.
Powershell-t szerencsére nem használok, mert nem Windows a munkám célterülete, de azzal is kapcsolatba kerültem mostanában, és csak pilláztam, hogy több főverzió van belőle mostanra, amik nem feltétlen egymás váltói, hanem egymás mellett élnek. :-O
Abból az utolsó "élményem" kb. 5-6 éves, amikor szintén bat-ban csináltam egy scriptet, ami összeszed mindenféle OS meg hardverinfókat a gépről, és kiírja egy txt-be (volt akkor egy nagy géppark-felmérés munkánk, bőven voltak még XP-k is, amin még hírből se volt powershell, emiatt)
Hát ott is a wmic, reg command és társai... Beszarsz, de ahány ilyen "tool", annyi encodingban adja a kimenetét (kb. mint a linkelt oldalon a powershell-es cuccok). És akkor igen, ez még megfejeleve a CMD-nek az ANSI/CP852/CP1250/LATIN1/LATIN2 szarakodásával. Beautiful.
Mit sem változott.
"Sose a gép a hülye."
Még nincs vége. Szóval így már UTF8 lesz a fájl, csak ott az elején a BOM. A konfigot így megeszi, viszont a minion_id-ba a BOM bekerül "szemétként" (ami a gyakorlatban egy pontként reprezentálódik), és emiatt szar minion id látszik. Hogy is lehet kivenni? Hát sehogy! Csinálj saját függvényt!
https://stackoverflow.com/questions/5596982/using-powershell-to-write-a…
function Out-File-UTF8-noBOM { param( $str, $dest ) " " | out-file -encoding ASCII -noNewline $dest $str | out-file -encoding UTF8 -append $dest }"Sose a gép a hülye."
Szóval ez lett a vége, így már tényleg jó:
$PSDefaultParameterValues = @{ '*:Encoding' = 'utf8' } $minionconf = "master: - egyik - masik ssl: True minion_id_lowercase: True master_finger: 'fd:ca:00:ed:13:9a:9e:ab:61:04:36:03:ba:63:41:3b:c6:55:0c:76:e1:8b:8a:50:16:b7:0d:26:06:3d:a1:3e' master_tries: -1 random_startup_delay: 10 ping_interval: 1 " [System.IO.File]::WriteAllLines("C:\ProgramData\Salt Project\Salt\conf\minion",$minionconf); [System.IO.File]::WriteAllLines("C:\ProgramData\Salt Project\Salt\conf\minion_id",$([System.Net.Dns]::GetHostByName($env:computerName).HostName.tolower())); restart-service salt-minion"Sose a gép a hülye."
a powershell a jovo :D