Saltstack szarakodás

Fórumok

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

Szerkesztve: 2023. 11. 14., k – 14:26

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

Szerkesztve: 2023. 11. 14., k – 14:59

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

Szerkesztve: 2023. 11. 15., sze – 09:11

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

Szerkesztve: 2024. 02. 22., cs – 13:28

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)

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.