Konfigok 2018-ban.

Figyelem! A következő ponst rantolást tartalmaz. Ha nem tetszik, ne olvasd.

Kernelt lehet patchelni restart nélkül, de egy kurva servicet nem lehet konfigolni restart nélkül. Linux ecosystem dióhéjban. Köszi 2018.

( Atekka | 2018. 03. 26., h – 13:48 )

Ha ez nem így lenne a change és incidens és hasonló managereknek nem lenne munkája a nagy IT cégeknél, most komolyan kivennéd a szájukból a kenyeret?:D
Régen volt ez jó mert az ssh konfigot ha eltoltad és mondtad neki hogy read konfig again és restart kicsaptad magad alól simán, mostmár legalább elég sok helyen ezt kivédték, szóval van haladás de még messze vagyunk.

ugyan egy docker kontenerben lehet birizgalni a telepitett cuccok konfigjait, de ez elegge anti-pattern. A szokasos eljaras, hogy a Dockerfile konyvtaraban modositod az ott levo konfigot, majd ujraepited az image-et (vo. immutable image-ek)...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

ott egy jelenleg kötelező és átlagos frissítés

{
-ha egyáltalán megcsinálja amire írták
-ha nem áll fejre tőle az egész cucc
-ha nem hordoz olyan bugokat amivel egy újabb updatet fog kérni jó esetben egy hét múlva
-ha nem futtatsz semmi kritikusat
}

újraindítás nélkül szintén szart sem ér. mindez bevállalható

{
-ha előre meg tudod tervezni a dolgokat
-ha nem fosol attól, hogy a restart akár 3+ óra kiesést fog jelenteni
-ha nem fosol attól, hogy hibára futás esetén még a rollback is kimarad, kék vagy fekete képernyőt hagyva
}

remélem jól összefoglaltam :)

ui a legtöbb helyen Windowst használok

--
Vortex Rikers NC114-85EKLS

Kb. így célszerű.
De működik részlegesen és az src subsytem teljes mellőzésével is. (Refresh helyett kill -1, már ha olyanod van.)
Ez három olyan módszer, ami a systemd-t évtizedekkel megelőzte. ;)
Persze a kép akkor lesz teljes, ha a lap alján kattintod a System Resource Controller-t is.

( uid_4263 v | 2018. 03. 26., h – 15:22 )

Áruld már el hogy a Linux kernel hányadik sorában van ez behardcodeolva? Az hogy a Linuxon használt service-id jórésze nem tud reloadolni nem a Linux hiánya. Az nginx tud. Oszt?

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

https://www.freedesktop.org/software/systemd/man/systemctl.html

"reload PATTERN…

Asks all units listed on the command line to reload their configuration. Note that this will reload the service-specific configuration, not the unit configuration file of systemd. If you want systemd to reload the configuration file of a unit, use the daemon-reload command."

A systemctl -t elfogadom ecosystem -nek, az tud config reloadolni, persze az adott service -nek ezt támogatnia kell.
Kérem kapcsolja ki.

"Éppenséggel de, viszont így értelmetlen a kerneles kérdés."

Az egész poszt értelmetlen. :)
szerk.: bocsi saxi de inkább sporttal vezesd le a feszkót :D

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

"A systemctl -t elfogadom ecosystem -nek, az tud config reloadolni, persze az adott service -nek ezt támogatnia kell."
Plusz minden initrendszerre ezt tudnia kell, nem csak systemd-re. Mármint léteznie kell a megfelelő, jól megírt illesztőnek, ami tudja azt, amit az init rendszer tud, lekövetni annak változásait, és illeszti a szoftver változásaihoz is. Hajrá. Eléggé sziszifuszi munka ám, ha 4 évente initrendszert cserél az ember.

( sj | 2018. 03. 26., h – 21:19 )

Figyelem! A következő ponst rantolást tartalmaz. Ha nem tetszik, ne olvasd.

en szeretem az ops benazasaidatkalandjaidat olvasni :-)

de egy kurva servicet nem lehet konfigolni restart nélkül.

latatlanban kerdezem: es az miert baj, ha modositod a konfigot, es utana kiadod a restart parancsot? Btw. ahogy fentebb is irtak, gyakorlatilag mindenhol van reload (~ HUP signal kuldesevel)

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

Arról volt szó, hogy bizonyos beállítások módosítása adott komponens újraindításával jár, ami rossz esetben több más dolgot is magával ránt. Ha erre valaki azt mondja, hogy nem fogadható el, hogy emiatt x ideig nem megy valami, akkor az ugye megfogalmaz egy elvárt rendelkezésre állást a rendszerrel kapcsolatban. Ha ezt valaki elfogadja, és azt követeli meg, hogy legyen az illető igénye kielégítve, akkor implicit módon megállapodnak egy adott szolgáltatási szintben. Hogy ezt "sla"-nak, vagy épp "abban állapodtunk meg, hogy..." kezdetű felhasználó oldali anyázásnak nevezzük, gyakorlatilag mindegy.
Ha ezt dev környezet esetében teszik meg úgy, hogy az nem tartható (mert pl. appszerverből csak egy van, nem pedig n darab), akkor az igényre rábólintó illetőt kellő alázattal, de orcán kellene simítani egy méretes péklapáttal.

adott komponens újraindításával jár, ami rossz esetben több más dolgot is magával ránt.

tessek? Mar a koncepciot sem ertem: ha egy komponens ujrainditasa akar egyetlen arra dependalo dolgot is magaval rant (bar ezt jo lenne muszakilag ertelmesen definialni) az a fucked by design esete. Mar csak azert is, mert letezik a timeout intezmenye (igy akar ki is varhatna az X szolgaltatas, amig a neki kello Y ujraindul), vagy lehet retry is, de mindenek elott korrekt hibakezeles az X szolgaltatasban. De mar a "tobb mas dolog" sem koser, mert egy kontenerben elvileg 1 dolognak kene futni. Ha meg a dev gepen 1 kontenerben fut "a minden" (mert a topikindito zero konkretumot osztott meg azontul, hogy mar megint elbenazott valamit, ehehe - bocs saxus), meg ott sem kene akkora lelkitorest okoznia egy restart-nak.

Szoval az idei allas: "Linux ecosystem" (muahaha) : saxus = 1:0

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

+1, egyébként a thread-be ezt HZ hozta be:

( HZ | 2018. március 26., hétfő - 21:25 )

Talán mert van ahol egy service restartja ránt magával ötven másikat ezért percekben, tízpercekben mérhető egy restart ideje?
És van ahol mérik a kieső időt és "díjazzák" is? (SLA mond valamit?)

egy service restartja ránt magával ötven másikat ezért percekben, tízpercekben mérhető egy restart ideje?

jaaaaj, ez a hz fajdalmasan ostoba, annyira fingja nincs arrol, mibe uti azt a buta kis orrat

(SLA mond valamit?)

dev gepen sla... en kerek elnezest. Aki ennyire anti okos, az miert nem tud inkabb hallgatni, ha nyilvanvaloan hulye valamihez...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

Mert te aztán olyan okos(kodó) vagy... Tudod kicsi pöcsfej, én még tapasztalatból beszélek. Ami neked a jelek szerint addig terjed, hogy fel tudsz konfigolni úgy-ahogy egy spam filtert. :D

Egyebekben meg kegyeskedj tartani magad ahhoz, hogy ilyen közvetett formában sem ugatsz hozzám, mert ez elég súlyos takonygerinc állapotra utal esetedben.
Meg egyébként is akkor kezdj szakérteni, ha láttál már komolyabb rendszert is, mint a sarki közért levelező szervere, a maga két userével. Szánalmas... (most azt még figyelmen kívül hagyom, hogy szimplán analfabéta vagy és még tőmondatokat is képtelen vagy értelmezni a jelek szerint)

ui: miután ez a díszfasz állítólag nem olvassa amit írok, felsorolná valaki, hogy sj tképp mihez is ért a pofázáson kívül? :D

Na de itt kezdődnek a problémák. Ugye az alapfelállás az, hogy van egy halom konténerem, ami megkapja envvarban a nem annyira default konfigokat. Ha ezen baszkurálni kell valamit, akkor lehet restartolni az egészet. Ez problémásabb akkor, ha mondjuk valami olyan folyamat fut vagy annak az állapota van tárolva a konténeren belül (most mindegy, hogy memória, tempfile, "permanens" file), ami miatt megbaszhatom, ha újraindítom a konténert.

De vannak további dolgok is, pl. ahol elszakadt a cérna az az volt, mikor lelőttem az egyik konténerem, mert a helyi gépen akartam elindítani a benne futó servicet VS-ből debugra, majd realizáltam, hogy a használt négy másik serviceből kettő portjai nem voltak kivezetve és megbaszhattam magam, indíthattam újra az egész környezetet, ráadásul pg dump-restore-val. (CI build integrációs teszteknél nem fáj, ha elveszik a DB, devnél meg úgy is csak addig kell általában, ameddig a környezet fut, prodon nyilván nem dockerből fut a DB, mielőtt megint jönnél, hogy jajajaj saxus hülye a devopzhoz!!!444)

Szóval itt szakadt el a cérna, hogy egy kurva kernelt fel lehet patchelni downtime nélkül, de egy szájbakúrt portot nem lehet átállítani restart nélkül.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

most, hogy egy fokkal tobbet tudunk, aterzem a fajdalmadat az elveszett allapotok miatt. Viszont az erdekelne, hogy aki osszerakta az image-eket, aszerint megis hogyan kell(ett volna) a futo kontenerekben konfigot modositani? Az meg mindig nem az "ecosystem" problemajanak tunik, hogy nem vezetted ki a portokat megfeleloen, noha tudtad, hogy a docker igy mukodik...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

en eddig ugy tudtam, hogy a port map-pelest nem konfigbol szedi, hanem te adod meg neki cli-bol. Tehat a vegere az derul ki, hogy valojaban a docker-rel van gondod, ami nalad "szar a linux ecosystem" cimszoval csapodott le... :-)

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

Ki beszélt reloadról? :) Arról beszéltem, hogy egy futó konténer port mappingját szeretném módosítani anélkül, hogy széttúrnék vele mindent.

Ideális esetben nyilván annyi, hogy fogom, átírom a compose.yml-ben, aztán docker-compose up és jobb esetben megy minden tovább. Csak ugye a világ nem csak ideális esetekből áll.

Épp ezért lenne egy csomószor tök hasznos, ha menet közben is lehetne állítani dolgokat és mondjuk annak csak egy perzisztált állapota lenne a yml.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™