systemd zabbix-agent user

Fórumok

systemd honnan tudja hogy a zabbix-agent -et zabbix userrel kell futtatnia?

# cat /usr/lib/systemd/system/zabbix-agent.service
[Unit]
Description=Zabbix Agent
After=syslog.target
After=network.target

[Service]
Environment="CONFFILE=/etc/zabbix/zabbix_agentd.conf"
EnvironmentFile=-/etc/sysconfig/zabbix-agent
Type=forking
Restart=on-failure
PIDFile=/run/zabbix/zabbix_agentd.pid
KillMode=control-group
ExecStart=/usr/sbin/zabbix_agentd -c $CONFFILE
ExecStop=/bin/kill -SIGTERM $MAINPID
RestartSec=10s

[Install]
WantedBy=multi-user.target

Hozzászólások

Esetleg a config fájlból ?


### Option: User
# Drop privileges to a specific, existing user on the system.
# Only has effect if run as 'root' and AllowRoot is disabled.
#
# Mandatory: no
# Default:
# User=zabbix

Fedora 30, Thinkpad x220

Inkább úgy mondanám, hogy bármilyen jogosultságot adhatsz neki. Szerezni nem tud.

De ha abban gondolkodsz, hogy adnál neki más (esetleg root) jogot egy UserParameter miatt akkor inkább ne tedd.
A sudo elegánsabb, szépen lehet vele engedélyezni amire szüksége van, és tiltásban tartani minden mást.

---
"A megoldásra kell koncentrálni nem a problémára."

Köszi, ez világos!
A kérdés inkább az hogy hogyan lehet megoldani azt, hogy a zabbix user variálhatja a zabbix konfigját, de ne tudja megoldani hogy más nevében fusson, több jogosultsága legyen mint neki.

Szerintem így:
# cat /usr/lib/systemd/system/zabbix-agent.service
[Unit]
Description=Zabbix Agent
After=syslog.target
After=network.target

[Service]
User=zabbix
Group=zabbix

Environment="CONFFILE=/etc/zabbix/zabbix_agentd.conf"
EnvironmentFile=-/etc/sysconfig/zabbix-agent
Type=forking
Restart=on-failure
PIDFile=/run/zabbix/zabbix_agentd.pid
KillMode=control-group
ExecStart=/usr/sbin/zabbix_agentd -c $CONFFILE
ExecStop=/bin/kill -SIGTERM $MAINPID
RestartSec=10s

[Install]
WantedBy=multi-user.target

...de systemd-ben nem vagyok járatos. Szerintetek így van még valamilyen módja?

Kérlek mondj egy példát, hogy mikor szükséges a zabbix-agent-nek a saját configját piszkálni.
Elég nagy rendszeren üzemeltetek zabbixot, de nem találkoztam még olyan problémával amit a zabbix önmenedzselése oldott volna meg.
Nem buzerállak, tényleg érdekel...

---
"A megoldásra kell koncentrálni nem a problémára."

Például mikor az emberke telefonál a helpdekre, vagy leadja az igényt valamilyen rendszerben hogy "erre hostra is legyen monitorozás", akkor a helpdeskes/adadmin/valamilyen_rendszer berakja a "monitorozd" csoportba és ennek hatására automatikusan elindul rá a monitorozás.
...vagy amikor az a céges policy hogy az összes hostot kell monitorozni és amit megtalál vmware/egyéb discovery, az automatikusan monitorozva lesz.

"leadja az igényt valamilyen rendszerben hogy "erre hostra is legyen monitorozás","
Ez nálunk nem igény kérdése, automatikus. Arra jönnek spec igények, hogy valami egyedi funkció működését is figyeljük a standardokon kívül.
De az meg egyedi, tehát meg kell csinálni. Ha több azonos is van akkor template.

"vagy amikor az a céges policy hogy az összes hostot kell monitorozni és amit megtalál vmware/egyéb discovery, az automatikusan monitorozva lesz."
Az automatikusan monitorozva lesz, ahogy írtad.
Proxmoxhoz csináltam template-et, ami a clusteren monitorozza az LXC-ket, rájön ha létrejött egy, és onnan figyeli amit kell.

Lehet jobban járnál, ha elmondád a konkrét feladatot, mert szerintem vagyunk itt annyian hogy segítsünk neked megoldani self-config-hack nélkül is. ;)
Felkeltetted az érdeklődésemet... :)

---
"A megoldásra kell koncentrálni nem a problémára."

Ilyesmi megoldás se rossz, csak a config agentenként változhat. A userparameterek és scriptek szintén és bár felmehetne az összesre az összes, folyamatosan fejlesztett, variált dolgok. (ezek itt egy verziókezelőből jönnek)
Csomagot felrakni rendszergazdai jog szükséges, de zabbixnak elég a zabbix user jogosultsága.

Javíts ki, de nekem úgy tűnik, hogy van zabbix usered, de nincse sudo-d sehol.
És azt akarják, hogy monitorozz.
Mert ha lenne root jogod, akkor nyilván fel sem merülne a self-config-hack kérdés. :)

Szerintem ha meg akarsz oldani egy változtatást, szólj az adminoknak _minden_ esetben, és _sok_ ilyen eset legyen, és _gyakran_.
Rövid időn belül kepsz sudo-t. Elhiheted... ;)

(Vagy kirúgatnak, de ez a pesszimista forgatókönyv.)

Szerk: mármint te kapsz usert sudo-val, és nem a zabbix kap sudo-t.

---
"A megoldásra kell koncentrálni nem a problémára."

Semmilyen userem nincs.
A kérdés az, hogy milyen usere/userei/jogai legyenek egy alkalmazásnak és az alkalmazás adminjának ahhoz, hogy az általa üzemeltetett progot (amihez tartozik egy service is) tudja konfigolni, de mást ne.
Nincs abban semmi hack, hogy beállítom a systemd-ben hogy adott service-t milyen userrel indítsa, ez egy alap beállítási lehetőség, azért van, hogy be lehessen állítani!
A gyári zabbix csomagban viszont úgy van beállítva a systemd, hogy arra bízza a kérdést, aki a zabbixot is configolja.
...de ha a kettő nem ugyanaz, akkor el kell térni az alapbeállításoktól.

A sudo-nak meg megvan a maga szerepe, feladata, amire kitalálták. Például hogy a fenti alkalmazásgazda újra tudja indítani a service-ét. (ha nem máshogy, pl systemd)

4.x-es zabbixot, mar eleg jol lehet scriptelni a szerver oldalon.
Eddig egy meroponthoz hozzarendelt depend itemek, regexszel kiszedhette azt ami neki kell.
Mostmar javascripttel komolyabban feldolgozhatod. En peldault hulye formatumu datum konvertalasara hasznaltam,

Ezekkel mar egesz komoly feladatokat meg tudsz oldani agent oldali scriptek nelkul. Oke a javascript senkinek nem a szive csucske senkinek, de legalabb vannak online toolok a teszteleshez. Meg a zabbixnak is van valami,

De visszaterve a scriptekhez.
Ha a zabbix agentet osszecsomagolod az osszes lehetseges scripttel abbol semmi baj nem lesz, az userparameterekbe megadott scriptekbe nem hiv bele addig a zabbix agent.

Na most az eltero verzioju scripteket hasznalni ugyanarra a funkciora elobb vagy utobb kaoszhoz vezet.

Egyetértek, nem származhat belőle baj, ha egybecsomagolom, csak minek..., ill. ha ez egy viszonylag statikus dolog lenne, egyszerűbb is lenne, de nem az.

Az alkalmazásoldali scripteket, programokat jellemzően nem a zabbix administrátorok írják, hanem az alkalmazás gazdái, vagy fejlesztői. ( mivel a zabbix admin nem ért az alkalmazáshoz, stb. Ő csak abban segít, hogy ezt beillesszék (userparameter, zabbix-sender..., és a zabbix szerver oldal)

...és szerintem is probléma szokott lenni ha eltérő verziójú, ill. ha nem a zabbix admin által ismert, tesztelt, ellenőrzött.

Tehát ha csomagolod az agentet, akkor a scripteket, programokat az azokat fejlesztőktől megkapod és belerakod egy csomagba. Mondjuk egy verziókezelőn keresztül kapod meg, hiszen amúgy is ott fejlesztik.

...de ha a terjesztést automatizáltan csinálod, akkor semmi előnye nincs annak hogy minden egyes változáskor (egy scriptben/programban amit a zabbix indít) új zabbix csomagot csinálsz, azzal szemben, mintha csak a scripteknek/programoknak lenne új verziószáma.
Hátránya viszont van.

Javascriptes megoldással nincsen sok tapasztalatom, de biztosan nem lenne a szívem csücske.
Kicsit nyakatekertebb módon persze eddig is meg lehetett ugyanazokat csinálni szerver oldalon, tetszőleges programnyelvben.
Ennek inkább a terhelés/erőforrás része érdekelne majd...
...de mindenképpen jó fejlesztés, egyszer-egyszer, de akkor igen jól jön!

az eltero verzio, es nem teszteles problemajat. verziokontrollal, es tesztelessel oldod meg.

ha nem is akarod nagyon kemenyen fogni a gyeplot. akkor is jo szures, ha te gyujtod be egy helyre a scripteket. lehetoseg szerint a dev/staging rendszereken kiteszteled.

egyebkent ez a scriptelgetes tul van misztifikalva. az hogy alap szinten mukodjon az alkalmazas, es postmortem tudj rola monitoring adatokat mondani, ahhoz memoriajat es processzorhasznalatat kell megnezned.
tudnod kell, hogy listenel X porton.
bizonyos log esemenyekre figyelj.
ha valami statuszfilebe ir valamit.
ezeket kulso script nelkul tudja.
elso korben ezeket valositd meg, utana ha gond van, es ezek nem fedik le, akkor kell lemenni alkalmazas szintjere.

a javascriptes dolgot azert irtam. mert akkor meguszod a agent oldali komolyabb scriptelest. zabbix agent kiad a parancsot. aminek a kimenetet text itemben tarolod. majd depend itemekkel kiszeded a neked fontosat. egyszerubb esetben regexszel. bonyolultabb esetben javascript

zabbix szerverek disk ioban halnak el. a javascript lib konnyusulyu.
https://blog.zabbix.com/javascript-support-in-item-preprocessing/6901/
https://duktape.org/
"Embeddable, portable, compact: can run on platforms with 160kB flash and 64kB system RAM"

particionalas, onmegtartoztatas attol hogy sokmindenszart es surun merjunk.

pg:
fsync = off
synchronous_commit = off
full_page_writes = off
maria/mysql:
innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=128M
innodb_buffer_pool_size=2G

ezek a beallitasok azt jelentik ha elfingik valami akkor nagy adatvesztes lesz. ha ez problema. akkor clusterezd.
nem az acid compilant adatbazisfilek mentenek meg, hanem az ha masik nodera billenes.

zabbixos forumokon vannak szamitasok, hogy mennyi tarhelyet igenyel egy adat x meresi idovel.
ha parszor 10 geprol van szo. akkor mindegy. akar 30 masodpercenkent is merhetsz.
ha ezer fele kozelitesz, akkor 3-5 perc. a history storage period is inkabb 1-2 het legyen, mint honap.

sokszar meresre pelda. a windowsos templatben az LLD felnyalja az osszes virtualis adaptert.
a halozati eszkozok templatjeinel is neha alacsony a update interval. ami 24 portos switcheknel egesz komolyan megdobja a meropontok szamat.

nyilvan. hisz ez a feladata, hogy csomagokat tegyen fel, fajlokat allitson be megfelelore, stbstb.
a zabbix (agent) meg arra van hogy monitorozzon dolgokat.

persze lehet keverni a kettot, csak azt jobb helyen ganyolasnak hivjak :)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem volt szó róla hogy a zabbix-agent configoljon, de amúgy jópofa dolog hogy hidat is lehetne vele építtetni.

Próbálj meg elképzelni összetettebb rendszert mint egy puppet által...
Mondjuk amikor két független cég működik azonos szerveren és két féle konfigmenedzserrel. Az egyik olykor csináltat valamit a másikkal.
Egyébként egy cégen belül is lehet értelme, eltérnek, van amire a puppet praktikus és van amire nem. Viszont semmi akadálya hogy többet is használj más-más feladatokra.