systemd zabbix-agent user

 ( gyuri2012 | 2019. október 10., csütörtök - 2:29 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Köszi!

Szóval a csomagolt systemd configgal a zabbix bármilyen jogosultságot tud szerezni magának?

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

Sudo-t használom ahogy írtad, viszont shellt szeretnék neki adni.

Átírja config file-ját hogy rootként és kilövi magát, systemd még indítja rootként...

Ha systemd-ben direkt megadom hogy user=zabbix (lehet ugye?) akkor mi történhet a fenti esetben?

AllowRoot=1 kell neki.

Az a célom hogy legyen shellje, tudja magát szerkeszteni, újraindítani (sudoers), de ne tudjon magának plussz jogokat szerezni, csak ha a gyökerek plussz adnak neki sudoers-ben (userparametereknek)

Ha az /etc/passwd-ben beállítod, hogy a shell-je /bin/false helyett /bin/bash legyen, vagy sh, vagy ... stb, akkor lesz shellje.
De miért kell, hogy legyen shellje? Mit nem tud shell nélkül?

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

Miert kell hogy varialhassa a konfigjat?

Olykor szükséges és a zabbix admin nem gyökér.

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.

az elindul a monitorozas az nalad mit jelent? valakinek telepiteni kell az agentet.

ja, pont erről szólt a kérdés. Az agentet automatikusan telepíti, később pedig más jogosultsággal tudja azt configolni.

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

A konkrét feladat annyi volt, hogy a zabbix admin usere tudja konfigolni a zabbixot, amit csak a zabbix user nevében futtathat.
A probléma az volt, hogy a zabbix configjában volt megadva hogy kinek e nevében indítja systemd, ezen kellett változtatni.

en is uzemeltettem tobbszazas kliensszamu zabbixrendszert. a zabbix agentbe csomagba belecsomagoltam az osszes userparametert es meroscriptet.

centos/redhat infrastruktura volt. sajat repoval. sajat buildelt zabbix-agent rpmmel.

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"

Alapvetően folyamatokat monitorozunk.

Disc io..., mármint db!?

persze. a history* tablak, es az ezzel kapcsolatos muveletek, mint a housekeeping.

Mi a legjobb módszer ha egy db szerver?
https://zabbix.org/wiki/Docs/howto/mysql_partition ?
pgbouncer ?

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.

meg mindig nem vilagos hogy mit is akarsz: mit akar matatni a zabbix a sajat configjaban? :/

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

Miért, te üzemeltetsz zabbixot anélkül hogy matatnál a configjában?

persze, egyszer beallitom es jolvan. ha meg megis modositani kell a configon azt meg a puppet rakja le

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

Szóval akkor puppetnek van joga.

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.

Nem az lenne a legegyszerűbb megoldás erre, hogy a konfigot a zabbix user tulajdonába adod? Úgyis csak neki kell, más nem használja - de innen kezdve mint tulajdonos, simán szerkesztheti...