Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Standa Blábol

Stran: 1 [2] 3 4 ... 11
16
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 18:42:30 »
Treba v GO je to pres gorutiny s prstem v nose, mechanismus channelu je z bezpecny a blbuvzdorny
S tou bezpečností ani blbuvzdornstí bych to nepřeháněl. Stačí si přes channel nevhodně poslat pointer a je na světě problém úplně stejnej jako v C. A vzhledem k tomu, že pointery na structy jsou tak nějak default... Zákeřnější varianta stejné chyby je poslat si sice kopii structu, ale nevšimnout si, že má přes pointer embeddovaný jiný struct. Moc pěkná chyba, hledat ji je čirá extáze :)

Opravdu blbuvzdornou konkurentnost má Erlang, kde chybu tohodle typu udělat z principu nejde, protože sdílet paměť mezi vlákny ("procesy") prostě nejde a basta :) I tam samozřejmě pořád zůstává možnost deadlocku.

No to je sice pravda, lec musim s tim pointerem aktivne prasit dale v main threadu.
Pokud pouzivam aspon trochu stabni kulturu, poslu pointer do IN channelu a v main threadu zapominanm na jeho existenci, tam se to bezpecne posle do jedne instance gorutiny (tudiz nenastane situace, ze 2 gorutiny delaji na stejnem pointeru) a vysledny pointer na vysledny gorutinou modifikovany struct nacpu  do OUT channelu, odkud si to v main threadu zase vytahnu.

Takze staci nebyt uplny dobytek a prace v GO je rozumne bezpecna.


17
Vývoj / Re:Práce s vlákny v C
« kdy: 20. 01. 2021, 03:11:28 »
Mimo puvodni dotaz.
Multithreading v C je pain a porad jednou nohou v pruseru. Business kod taky pain, prenositelnost a devops peklo.
A to nejenom pri vyvoji ale hlavne dale pri zmenovkach a udrzbe.
Neznam samozrejme pozadi tohoto programu, ale zvazil bych pouziti vhodnejsiho jazyka.

Treba v GO je to pres gorutiny s prstem v nose, mechanismus channelu je z bezpecny a blbuvzdorny
Nebo v Jave pri pouziti netty.io

18
Server / Re:Dva GIT servery proti jednomu piskovišti
« kdy: 13. 01. 2021, 16:28:29 »
Pokud se to té VPN musíte přihlašovat ručně, můžete si nanejvýš to pushování na server zákazníka usnadnit nějakým skriptem, abyste pořád dokola nemusel psát stejné parametry gitu. Ale jestli to vůbec stojí za to, prostě po git push na svůj server ještě spustíte git push zakaznik (pokud si ten zákazníkův klon pojmenujete jako zakaznik).

Chapu, nastavim si 2 remoty a pro ne 2 searatni URL, vzi popis zde: https://gist.github.com/rvl/c3f156e117e22a25f242

Dik za hint

19
Server / Re:Dva GIT servery proti jednomu piskovišti
« kdy: 13. 01. 2021, 15:52:12 »
Git je distribuovaný systém, můžete mít libovolné množství naklonovaných repository. Git server není nic speciálního, je to jen repository naklonované na počítači, který je obvykle trvale dostupný. Úplně základní varianta je řešit to ručně – tj. pushovat nejen do vašeho serveru, ale také na server zákazníka. Což je samozřejmě otravná ruční práce náchylná na chyby. Jednodušší bude na serveru si nastavit hooky a při commitu změny automaticky pushovat i na server zákazníka. Pokud se tedy z vašeho Git serveru dostanete na server zákazníka.

Nedostanu.

Muzu pushnout k sobe, pak pripojit VPN a pushnout k zakaznikovi.

20
Server / Dva GIT servery proti jednomu piskovišti
« kdy: 13. 01. 2021, 11:01:34 »
Resim ted problem jednoho piskoviste a dvou nezavislych GIT serveru.

Mam svuj GIT, kde si udrzuji svuj kod.
Zakaznik navic pozaduje, aby ten samy kod byl udrzovan i v jeho GITu, ktery mam dostupny pres jeho VPN.
Urcite jste uz nekdo neco podobneho resil, existuje pro toto nejake rozumne reseni?

21
Software / Re:Dohledový systém
« kdy: 11. 01. 2021, 13:53:30 »
Zabbix som naposledy skúšal pred niekoľkými rokmi a narazil som vtedy na viaceré problémy, ktoré ho robili z môjho pohľadu v porovnaní s "Nagios klonmi" horšie použiteľným. Spomínam si na nasledovné:

1. Nemožnosť upravovať frekvenciu testovania v prechodných stavoch.

U Nagiosu som bol zvyknutý na to, že testujem dostupnosť povedzme 1x za 10 minút a keď nastane error, tak to pretestujem ešte povedzme 2x v odstupe 1 minúta a ak sa chyba opakuje, tak generujem notifikáciu. Takto mám istotu, že nebudem zbytočne notifkovaný pri náhodnom jednorazovom zlyhaní testu (zlyhania musia byť minimálne 3), testovať mi normálne stačí iba raz za 10 minut a aj tak sa o poruche dozviem najneskôr do 12 minút od jej vzniku.

V Zabbixe toto možné nebolo a buď som teda testoval každú minútu stále (čo je zbytočný load) alebo ak som testoval iba každých 10 minút, tak som sa o probléme dozvedel až po 30 minútach, alebo som ho musel hlásiť už po jednom zlyhaní (čo zvyšovalo riziko falošných poplachov).

2. Veľmi obskurný jazyk na definíciu alertov so spústou obmedzení
Napríklad si pamätám, že ak mi dva testy (data sources) vracali údaj typu string (napríklad serial number nejakého deploynutého datasetu) tak nebolo možné zapísať alert ktorý by sa aktivoval na základe zhody/nezhody týchto reťazcov, porovnávať sa dali len numerické hodnoty.

A už vôbec nebolo možné napísať podmienku toho typu, že "aktivuj alert ak sa tieto dva údaje nezhodujú dlhšie ako 5 minút".

3. Limitované možnosti offloadovania testov na agenta
Štandardne všetky testy robil Zabbix server, bola aj možnosť nechať testy vykonávať agenta s tým, že ich výsledky iba "reportuje" na Zabbix. Problém ale bol, že tieto testy  nevedel agent vykonávať paralelne, čiže ak sme ho nechali robiť viacero testov a jeden z nich z nejakého dôvodu trval dlho (čakalo sa na timeout), tak aj vykonávanie všetkých ostatných testov na danom agentovi bolo zastavené a "nestíhalo".

Toto sú hlavné problémy, čo si z testovania Zabbixu pamätám.  Budem rád, ak niekto, kto pozná súčasné verzie Zabbixu, potvrdí, či to stále platí, alebo to už bolo nejako vyriešené.

Ad 1.
Zabbix resi obdobny problem jinak.
Sbira se normalne s periodou 1 minuta, pricemz na item je aplikovany preprocessing step "Throttling - Discard unchanged with heartbeat", takze hodnota je pollovana fyzicky co minutu, zapis do historicke DB co 10 minut, kdyz dojde k problemu, automaticky se ukladaji zmenene hodnoty s periodou minuta. Preprocessing i vlasni mereni se deji na proxy, server dostane uz predzvykany vysledek.
Tento mechanismus odhali chybu po 3 minutach, namisto 12, pri stejnych pozadavcich na historickou DB.
Jinak s nasazenim TimescaleDB time-series extension do postgresu spolu se zapnutou kompresi se vykonove dostavame uplne jinam, velka radu vykonnostnich omezeni uz neni potreba resit.
A pokud je precejen nutno pouzit vyse popsany mechanismus z duvodu omezeni loadu na merenem prvku, mozno lokalne naskriptovat a metriky zasilat asynchronne senderem, tak bych to resil ja. Dalsi alternativa je custom plugin v GO do Zabbix Agent2.

Aktivovat alert pokud se dve metriky neshodovaly vice nez 5 minut, slo vicemene vzdycky. Bud krapet neohrabane, ze se porovnavaly shody retezce ve vzorku LAST && LAST-1 && LAST-2, az se pokrylo cele pozadovane okno, nebo se udelal dodatecny computed item (nastaveny aby se neukladal do historic DB, jenom se bral z cache), s informaci 0/1 ok/bad a ten se vyhodnotil min(5m)=1.

Ad 2. Porovnavat stringy slo vzdycky, nyni je uz primo mozno aplikovat preprocessing step "Regex substr", vyparsovat ho cislo a ulozit jej numericky.

Ad 3. Zabbix agent1 psany v C mel v defaultni konfiguraci povolene 4 processing thready, po vycerpani threadu ostatni checky staly. Zabbix agent 2 je psany v GO a vsecko sere paralelne do gorutin. To ovsem nic nemeni na faktu, ze UserParameter skripty maji byt rychle a jednoduche, mely by skoncit do 5 sec, jinak je vhodne pouzit neco jineho.  Typicky dlouhe checky nechat agentem jenom invokovat a vysledek posilat asynchronne zabbix senderem (pouziva stejny TCP port jako Zabix Agent v active modu, takze zde neni problem s firewall rules) Pripadne, nyni je moznost jednoducheho dopsani pluginu v GO do agenta2, ten pak muze uplne cokolivek.  Treba novy Oracle monitoring je napsany jako modul do agent2 - sam si drzi session spojeni a provadi SQL dotazy do session views.

22
Software / Re:Dohledový systém
« kdy: 11. 01. 2021, 11:03:49 »
- Zabbix - zdaleka nejlepsi z techto, ve verzi 5.x + proxy + pluggable agent2 psany v GO + ansible oficialni modul + pyzabbix knihovna + TimescaleDB + Grafana - absolutne nejlepsi feature set, ostatni se ani neblizi.

Tohle by mne zajimalo, co to umi. Proxy je mi jasna, agent2 taky pouzivam - ale ten je podporovan je nekterych verzich debianu (zavislost na ssl apod).
S ansiblem mam ten problem, ze pak je problemove to spravovat z GUI.
Co mne nejvic zajima - k cemu ten pyzabbix, k cemu ta timescaledb (ja to mam v postgresql). Jak je to s tou grafanou - co se tam musi udelat, kazdy graf kazdeho monitorovaneho modulu se musi prevytvorit ci jak?

Pro Ansigle je GUI AWX, osobne pro ansible GUI nepotrebuju.
Pyzabbix je knihovna pro Python pro praci s Zabbix API a zabbix sender. Da se s tim velice jednoduse na zabbixu naskriptovat cokoliv, co udelas z GUI.
TimescaleDB je time-series extenze do postgresu, samo se to pak stara o housekeeping a podporuje kompresi metric dat, typicky ping metrika, kde je v 99% porad 0 (OK) se zkomprimuje do par KB. Ale toto ocenis spise u vetsich instalaci, pro male monitorovane baze postaci holy Postgres
Greafana: https://www.zabbix.com/integrations/grafana
Ale popravde, posledni verse Zabbix dashboardu jsou z Grafany opajcovane a maji obdobnou funkcionalitu.


23
Software / Re:Dohledový systém
« kdy: 11. 01. 2021, 09:39:02 »
My two cents.

Ze zde dikutovane trojice, Nagios (+klony), Zabbix, Prometheus se to ma takto:

- Nagios uz nechte zdechnout, byl prvni a proto je rozsireny, jinou vyhodu nema

- Zabbix - zdaleka nejlepsi z techto, ve verzi 5.x + proxy + pluggable agent2 psany v GO + ansible oficialni modul + pyzabbix knihovna + TimescaleDB + Grafana - absolutne nejlepsi feature set, ostatni se ani neblizi.
Zabbix vsak vyzaduje vytvoreni pevneho modelu monitorovaneho sveta, ktery se polluje. Neni vhodny pro dynamicke kontejnerove aplikace, kde kontejnery vznikaji a zanikaji podle aktualniho loadu

- Prometheus + AlertManager - specializovany dohled vznikly pro potreby Kubernetes, resi problem dynamickych kontejneru. Jinak je funkcne dost omezeny a je to defacto funkcionalni navrat k devadesatym letum, kdy letely hloupe eventove konzole + RRD. V pripade kontejneru to ale jinak nejde, tam se pevny model monitorovaneho sveta ve stylu Zabbixu, CA Spectrum, EMS Smarts proste udelat neda.
Existuje pro to spousta rovnaku na ohybaky typu SNMP exporteru, funcionalite Zabbixu v teto staticke oblasti se to ani neblizi.

Resultat:
Pokud chci monitorovat staticky svet -> Zabbix
Pokud chci monitorovat pouze dynamicky svet (kontejnery) -> Prometheus
Pokud mam oboje -> Zabbix a AlertManagerem do nej preposilat vyhodnocene eventy z Promethea

24
Software / Re:Dohledový systém
« kdy: 09. 01. 2021, 10:22:31 »
Pro tyhle ucely rozhodne Zabbix s TimescaleDB na historii a proxyny na offload sberu metrik + ansible na spravu zabbixu, je tam pro zabbix luxusni modul + agent2 psany v GO s jednoduchou moznosti vlastnich pluginu

Nagios a jeho klony uz nechte konecne zdechnout.

25
Hardware / Re:Vybírám tablet k Vánocům
« kdy: 21. 12. 2020, 20:41:55 »
@Standa Blábol: mohl byste prosim overit, jestli na Lenovo M10 funguje Whatsapp...? Diky.

Ted je to zabaleny na dne skrine a rozbali se to 24.
Ale nevidim zadny duvod, proc by to nemelo jit, me whatsapp jel naprosto vsude a tohle je Android 10.

26
Hardware / Re:Vybírám tablet k Vánocům
« kdy: 21. 12. 2020, 14:15:37 »
Zrovna vcera jsem to resil a nakonec jsem skoncil u https://www.alza.cz/lenovo-tab-m10-plus?dq=5769969&o=2

U tabletu je 4GB RAM minimum, zbytek je vicemene podruzny, CPU vykon dnes neni problem.

Android tablety s malym mnozstvim pameti neumoznuji vice profilu, coz je u domaciho tabletu sdileneho vice detmi krucialni featura.
Bez profilu je z toho hloupej iPad.

Vcera jsem si s tim chvili hral, aby kluci meli po rozbaleni rovnou nastaveny tablet i s jejich ucty, Android 10 (alzak pise 9) a funguje to pomerne svizne. Displej velice pekny.

27
Distribuce / Re:Proxy přístup na internetové repozitáře
« kdy: 04. 12. 2020, 14:25:34 »
Nakonec jsem to vyresil pomoci tinyproxy.
Ted to jede jak po masle a jediny, co bylo potreba nastavit, byl IP rozsah stroju, co mohou k proxy pristupovat.

Squid mi pripada obecne nejaky cely zesraty, HTTPS jsem nerozjel vubec, HTTP se divne skubalo a bylo to pomale.

Diky vsem za hinty.

28
Distribuce / Re:Proxy přístup na internetové repozitáře
« kdy: 03. 12. 2020, 21:37:17 »
1) Repozitáře jsou snad podepsané, takže lokálně a vlastně i po netu je HTTP v pohodě, ne?

2) Druhé řešení, které bych zvolil, je vykašlat se na proxy v té síti, a repozitáře si tam natáhout SSH tunelem. Přihlásit se tam se
Kód: [Vybrat]
ssh -R 8888:repozitář:80 -R 8889:repozitář:80 a v seznamu repozitářů pak jako repozitář nastavit http://localhost:8888.

Pekna myslenka, kdyz nepujde nic lepsiho.
Ty servery chci managovat ansiblem za pouziti standardnich roli z ansible galaxy a ty si repa dokonce samy pridavaji, napr zabbix repo. To tech ansible roli se mi hrabat nechce, aby to sestavovalo tunel na pocatku kazdeho playbooku.
Pokud by jela https proxyna, prijde mi to systemove cistsi.

A hlavne jsem kdesi videl, ze proxivane repa jely pres https proxynu nacerno udelanou jakymsi sharevare udelatkem na W10.
Nejak ti prece musi jit.

29
Distribuce / Re:Proxy přístup na internetové repozitáře
« kdy: 03. 12. 2020, 21:29:10 »
No, pokud je na serverech vypnutý přístup na internet, většinou to má dobrý důvod a naopak není důvod to porušovat.
Přístup do repozitářů a vývojové nástroje bych na server nedával.

Obvykle se projekt sestaví a teprve výsledek se deployuje na server. Na to stačí push přes SFTP, SCP atp.

Normalni reseni je, ze ve firme maji svoje privatni repa managovane pres satellite6.
Nechat servery shnit bez security updatu je sice zajimava metoda, ale snazim se ji vyhnout.
V one firme nemaji privatni repa a ja se na nejake potrebuju dostat.
Kdyz primo dnf podporuje praci s HTTPS proxy, predpokladam, ze to nejak jit musi.
Squid instalace podle webovych tutorialu mi pro https neseje (zrejme.HSTS), tinyproxy to pro jistotu nepodporuje vubec, dal jsem nezkoumal.


30
Distribuce / Proxy přístup na internetové repozitáře
« kdy: 03. 12. 2020, 19:18:30 »
Mam u zakaznika nekolik Centos8 serveru bez pristupu k internetu a potreboval bych na nich mit pristup na internetove repozitare, klasika Centos, EPEL, Postgres apod.

Na jednom ze stroju muzu dostat internet, potrebuju nejake reseni, aby na repa mohly i ostatni stroje.

Zkousel jsem nasadit squid v noncaching modu, na http se curlem proxovane dostanu, https aniprt.

Resil jste nekdo podobny problem?
Jak rozjet https na sqid explicit https proxy, popr jestli neexistuje nejake uplne jine reseni, jak se dostat na repa.

Stran: 1 [2] 3 4 ... 11