Szeressük a systemd-t!

The D in Systemd stands for 'Dammmmit!' A nasty DHCPv6 packet can pwn a vulnerable Linux box

( TCH | 2018. 10. 27., szo – 23:10 )

A régi network managerek elavultak, mert Poettering kimondta rájuk, tehát idő és szükségszerű volt kiváltani őket egy - az anyaprojekthez méltó - új, egységes és modern megoldással, így most már mindenütt egységesen szar lett az egész network management... (Kivéve ahol nincs ez az ótvar bughegy...)

A systemd-hez képest de. Már csak azért is, mert nem asszimilálta a fél rendszert. Amúgy meg egy raklap init rendszer létezik, ha nem tetszik a System V, vagy a BSD féle, akkor tessék, van választék.

A hibát már javították, mire a cikk megíródott, nincs mire beküldeni patchet. A systemd pedig koncepcionálisan rossz, arra meg nem lehet patchet írni.

Azért az egy /etc/rc scriptes bughalmaz szerintem messze sz@rabb volt, mint a systemd-s unitosdi, és egy sysvinit is elég gyengén muzsikál függőségek kezelésében.
Az, hogy "asszimilálta a fél rendszert" az erős túlzás, ahhoz, hogy a futó és a létező szolgáltatások kezelése jól működjön (függőségek, ezerféle módon megírt vackok kiementeinek, álalpotainak kezelése, stb.) ahhoz elég sok dolgot kell a systemd hatásköre alá rendelni.
Hogy hányféle init rendszer van, azt nem kell bemutatnod, mondjuk úgy, volt néhányhoz szerencsém, az elmúl röpke közel harminc év alatt, amióta *nix rendszerek vannak a közelemben.
Eleinte nekem sem tetszett a systemd, elsősorban amiatt, mert rengeteg dolog változott, azonban amióta aktívan systemd-s rendszereket tutujgatok, és egyre jobban megismerem a hasnzálatát, működését, ez a véleményem alaposan megváltozott. A saját véleményem ilyetén változását ismerve, szívesen venném, hogy szerinted mi az, ami "koncepcionálisan rossz" a systemd-ben önmagában? Nem a sysvinit-es, illetve arra tákolt mindenféle lommal összehasonlítva (amit speciel a systemd-hez hasonlóan marhára nem ismerek/használtak jól a linuxos "fejlesztők", látva a rengeteg extragány scriptet, meg azt, hogy gyakorlatilag "elfelejtették" használni a futási szinteket (is)).

> Azért az egy /etc/rc scriptes bughalmaz szerintem messze sz@rabb volt, mint a systemd-s unitosdi

Szerinted.

> Az, hogy "asszimilálta a fél rendszert" az erős túlzás, ahhoz, hogy a futó és a létező szolgáltatások kezelése jól működjön (függőségek, ezerféle módon megírt vackok kiementeinek, álalpotainak kezelése, stb.) ahhoz elég sok dolgot kell a systemd hatásköre alá rendelni.

Akkor miért nem működik jól?

> Hogy hányféle init rendszer van, azt nem kell bemutatnod, mondjuk úgy, volt néhányhoz szerencsém, az elmúl röpke közel harminc év alatt, amióta *nix rendszerek vannak a közelemben.

Mit jelent az, hogy néhányhoz? Lehet, hogy pont a rosszabbakba futottál bele. Ha 30 éves UNIX-os múlttal szerinted a systemd a legjobb init rendszer, akkor az elég szomorú.

> A saját véleményem ilyetén változását ismerve, szívesen venném, hogy szerinted mi az, ami "koncepcionálisan rossz" a systemd-ben önmagában?

Már megint? Komolyan, a systemd hívők sose olvassák el az ilyen jellegű cikkeket, posztokat, amik ezeket fejtegetik? Amióta csak ez a förmedvény színrelépett, azóta - nálam okosabb - szakemberek ezrei fejtegetik, hogy mi a baj vele. Ami azt illeti, a fentebbi linken össze is van gyűjtve egy raklap ellenérv; hát én is szívesen venném, ha ezeket tételesen cáfolnád és nem söpörnéd le az egészet azzal, hogy "deasysvinitszar", meg "dezegysystemdhateroldal".

Soroljam a systemd előnyeit a bughalmaz scriptekhez képest, pláne azokhoz, amit Linux-os környezetben voltam kénytelen kijavítani, illetve megoldani, hogy sysvinit esetén a futási szinteket is normálisan lehessen használni Linuxon is? Vagy épp az initscripttel indított vackokat, amit inittabból illett volna indítani, és viszont? Ja, hogy a Linux-os körökben a meglévő eszközök méy ismerete sohasem volt követelmény, inkább írunk egy másikat?

"Mit jelent az, hogy néhányhoz?" - Csak kereskedelmi UNIX/Unix-jellegű rendszerből volt vagy fél tucat, Linux meg 0.93-as kernel meg tán 1.02-es SLS disztribúció óta nagyjából mindegyik jelentősebb terjesztés - és nem csak itthoni játszós gépen.

Én nem vagyok "systemd hívő" (aki pár éve hozzád hasonlóan az általad linkelt, illetve ahhoz hasonló tartalmakra mutogattam!), csak mostanra látom a systemd hasznosságát, illetve értelmét. Meg a hibáit is - de ezekkel együtt is vannak olyan előnyei, amit a Linuxokon korábban használt init-rendszerek nem adtak meg, illetve csak gányolással tudtak prezentálni.
Anno a Windows 3.11 még config.sys és autoexec.bat fájlokat hasnzált, és elég volt hozzá. Azóta picit fejlődött a Windows-os környezet boot/folayamtkezelés dolga is...

Ha neked a systemd nem tetszik, lelked rajta - van még olyan terjesztés, ami nem használja - igaz, lassan kipusztul ugyanúgy, mint ahogy kihalt sok más dolog is, és mégis működik minden tovább :-)

-1, az osszes (itt elkovetett) hozzaszolasodra.

A topikban szereplo remote code execution issue nem hiba (amint te nevezed), hanem egy ordenare sec. hole. Btw. en nem latom 'bughalmaznak' a sysvinit megoldasat, legalabbis a systemd-vel osszevetve biztosan nem (bagoly mondja). Ha abbol indulok ki, hogy minel hosszabb a kod, annal tobb hiba van benne, akkor egy init rendszernel a kevesebb a tobb. Szoval a systemd OS az OS-ben koncepcio bizony a fucked by design mintapeldaja.

Btw. ha egy init script tenyleg bug-os, akkor inkabb fixalom azt, mintsem hogy oruljek, hogy milyen faszan hamarabb felall a rendszer, ami holnap mar nem az enyem. A systemd az uj bind/sendmail!

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Sec.hol, el...ták, javították, ahogy a debijányos karbantartó által "fixált" ssl-es mókát is. ja, az picit tovább tartott, mármint hatását tekintve...
Az initscript javítgatása legyn már a karbantartó feladata - ha meg nem tudja, mi és hogyan lett kitalálva a sysvinit-ben, akkor előbb azzal kapcsolatban kerüljön képbe.

A sendmail-es hasonlat jó - azt is sokan köpködték, mert nem tudták/akarták/voltak képesek alaposan megismerni/megtanulni - köztük én is, aztán egy jó oktatónak hála néhány nap után már direktben is ment a sendmail.cf matatása, miközben mindenki az n+1 másik, "itt-ott bugos" MTA bűvöletében élt. Aztán az újabb szoftverek kiforrották magukat, és a komolyabb tudású leváltotta a butábbat, és ez azóta is mgetörtént már nem egy esetben...

A systemd szerintem nem rossz, csak nehezen egyeztethető össze a közel ötven éve "*nix filozófia" néven emlegetett, és itt-ott bizony alaposan túlhaladott elvekkel.

Tesen forkolni egy "realunx" OS-t, benne választhatóan n+1 "hagyományos" init rendszerrel, m+1 ütemezővel, fájlrendszerrel, shellel, meg miegyébbel, aztán ennyi. Ja, és persze a hálózatot szigorúan ifconfig használatával matatni, mert az az igazi :-P

A sendmail-es hasonlat jó - azt is sokan köpködték, mert nem tudták/akarták/voltak képesek alaposan megismerni/megtanulni

nem ertetted meg, amit irtam: nem a sendmail elbaszott konfigja (amiert szinten kijart volna a lapattal fejbeveres Vixie-nek) a lenyeg, hanem a botranyos security history-ja (es ugyanez igaz a bind-re is). Akinek sendmail / bind futott a gepen, az konstans eletveszelyben volt. Na ugyanez a helyzet a systemd-vel is. Venema (a postfix iroja) szerint az o eseteben kb. 1000 soronkent van egy bug a kodban. Namost ezt vesd ossze egyreszt a systemd projekt loc szamaval, masreszt azzal, hogy a pottering hulye eddigi tevekenysege alapjan te hany kodsorra saccolsz 1 bug-ot a systemd-ben.

Sec.hol, el...ták, javították, ahogy a debijányos karbantartó által "fixált" ssl-es mókát is. ja, az picit tovább tartott, mármint hatását tekintve...

ez hogy jon ide? A ketto egyreszt egymastol fuggetlen dolog, masreszt az utobbi 1 (max. 2) disztribuciot erintett, mig a pottering hulye bug-ja sokat, harmadreszt ez a bug nem a projektben volt, hanem egy random disztro maintainer-e tette bele (azt most ne firtassuk, hogy az openssl kb. edestestvere elbaszottsagban a systemd-nek).

A systemd szerintem nem rossz, csak nehezen egyeztethető össze a közel ötven éve "*nix filozófia" néven emlegetett, és itt-ott bizony alaposan túlhaladott elvekkel.

az semmikeppen nem tulhaladott, hogy 1 tool csak 1 dolgot csinaljon, de azt jol.

Ja, és persze a hálózatot szigorúan ifconfig használatával matatni, mert az az igazi :-P

az 1. gondolatom az utolso sorodra a bitch please, de jobban belegondolva, nem latom (nezd el nekem, biztos az ebed utani kajakomatol lehet), mi a problema azzal, ha egy rc script mondjuk pont az ifconfig-gal huz fel egy interface-t...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Anno a sendmail esetében ott volt a lehetőség, hogy készüljön egy jobb, és váltsa ki a sendmail-t. A qmail-nek nem sikerült (mert az alkotóját divat volt utálni, ergo a daemontools is hasonló okból nem lett sikeres). Exim, Postfix manapság jól érzik magukat, köszönik szépen.
A sysvinit, meg az abból kinőtt, vagy csak azt lecserélni szándékozó megoldások nagyszerűen elindultak, csak valahogy mégsem azokat kajálták meg a kereskedelmi disztribek összeállítói, hanem systemd vonalat tolják. Volt, hogy az Exim-et nyomták (mert csak), miközben a Postfix sem volt rossz, sőt...

Egy tool egy dolgot csinál: a rendszerszintű folyamatokat kezeli és szolgálja ki. Valamit kihagytam...?

Az ifconfig egy "deprecated" tool, iproute2 elég régóta van, nagyjából azóta "vezetik ki" az ifconfig, route, netstat, meg tán az arp parancsokat, de baromi nehezen megy, mert rengeteg script, tool még ezeknek az alkalmazásoknak a szöveges kimenetére van illesztve, és a lustaság, meg a "ha működik, miért változtatnánk rajta" elv alapján senki sem hajigálja kifelé ezeket a programokat. Ja, meg persze meg kéne tanulni az új toolt használni, ami való igaz, szintén macera...

Lehet a múltba révedni, és ragaszkodni a "régi jól bevált" dolgokhoz hájblézer módra, csak sajna a világ szépen eltrappol azok mellett, akik így gondolkodnak, tetszik, vagy sem.

a rendszerszintű folyamatokat kezeli és szolgálja ki. Valamit kihagytam...?

igen: azt, hogy ez egy amorf BS. Es erosen izzadsagszagu, mert nyilvanvalo ostobasag szembemenni vele, ezert elegge meghajlitottad, hogy a systemd-re is ra lehessen huzni. Csak szolok, hogy ne mondd, hogy senki nem mondta: a systemd-re ez meg nyomokban sem igaz. Ez egy OS az OS-ben: http://without-systemd.org/wiki/index.php/Arguments_against_systemd#Sco…

Lehet a múltba révedni, és ragaszkodni a "régi jól bevált" dolgokhoz hájblézer módra, csak sajna a világ szépen eltrappol azok mellett, akik így gondolkodnak, tetszik, vagy sem.

mi van, allamtitkarnak keszulsz? Jovanna, csak a csusztatas/tereles miatt kerdeztem. Egyreszt teny: a systemd egy eleve elbaszott koncepcio, akarmennyire is "erre trappol a vilag" (most hagyjuk, hogy eme allitasod mennyire tenyszeru). Masreszt ez a "vilag szepen eltrappol" egy kisse eros allitas pusztan azert, mert valaki elegedetlen a systemd-vel.

LOL, ugy veded a systemd-t, mintha az egyebkent muszakilag abszolut jogos kritikakkal a magyar embereket tamadtam volna...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Tehát jól írtam, hogy a systemd a rendszerfolyamatokat kezeli, és azoknak az igényeit szolgálja ki. Mindenestől, nem külön n+1 féle egyedileg tákolt motyóval, hanem egyben. Meg közben megoldja (egy kóddal, nem alkalmazásonként külön-külön) a privilégiumkezelést, a chroot-ot, az erőforráslimitet, estébé - összesen egy helyen. Igen, megvan annak a veszélye, hogy ha ez az egy hely bugos, akkor nagy a baj, viszont ha alkalmazásonként külön-külön vannak ezek a funkciók megírva, akkor a kódsorok száma többszöröse (ráadásul alkalmazásonként egyedi) annak, amennyiből a systemd megoldja, úgyhogy ha azt mondod, hogy x soronként van egy hiba, akkor az n darab alkalmazás n*x sorában akár n-szer annyi hiba is lehet, mint a systemd azonos funkciójú részében.

Szerinted rossz koncepció, anno sokmindenre mondták, hogy az, de ennél tovább nem jutott a dolog - lehet nekiállni jobbat alkotni, kiütni a nyeregből a systemd-t. Az meg számotokra sajnálatos tény, hogy a kereskedelmi terjesztések, azaz az üzleti világban használt Linuxok bizony ha tetszik, ha nem, ebbe az irányba tartanak, és elvárt, hogy ismerd és tudd használni ilyen környezetben.

-1

a rendszerfolyamatokat kezeli, és azoknak az igényeit szolgálja ki.

ez meg mindig egy kodos, amorf megfogalmazas, azaz BS.

az alkalmazasok zome nem csak systemd-s linuxon fut. Ebbol kovetkezik az, hogy nem epithetnek arra, hogy ezeket a feature-oket 'majd ugyis megoldja a systemd', hanem ezeket (amennyiben tamogatjak) nekik kell megoldani.

megvan annak a veszélye, hogy ha ez az egy hely bugos, akkor nagy a baj

igen, ezt idorol idore sajnos latjuk (pont ugy, mint a sendmail / bind eseten)

viszont ha alkalmazásonként külön-külön vannak ezek a funkciók megírva, akkor a kódsorok száma többszöröse (ráadásul alkalmazásonként egyedi) annak, amennyiből a systemd megoldja, úgyhogy ha azt mondod, hogy x soronként van egy hiba, akkor az n darab alkalmazás n*x sorában akár n-szer annyi hiba is lehet, mint a systemd azonos funkciójú részében.

ez viszont nem annyira koszon vissza a bug reportokban, hogy x app iroi elrontottak a chroot() hivast. Ami valoban kod duplikacio (legalabbis abban az ertelemben, hogy benne van x, y, es z alkalmazasokban), de ilyen tartalmu bugtraq levelre nem emlekszem.

Szerinted rossz koncepció, anno sokmindenre mondták

megint terelsz. Egyreszt hogy 'anno sok mindenre mondtak' nem enyhiti a systemd miatti fajdalmat, masreszt sokak szerint rossz a systemd koncepcioja.

lehet nekiállni jobbat alkotni, kiütni a nyeregből a systemd-t.

nem kell. Nekem - veled ellentetben - nem volt fajdalommal teli az eletem a sysvinit rendszerekkel. Masfelol mar nem is allamtitkari, hanem egyenesen kormanyszovivoi magaslatokba emelkedsz, amikor azt javaslod, hogy pl. a Redhat majd (majd ezek utan!) elengedi a pottinger hulye kezet, es az x jobb rendszert atveszi.

Az meg számotokra sajnálatos tény, hogy a kereskedelmi terjesztések, azaz az üzleti világban használt Linuxok bizony ha tetszik, ha nem, ebbe az irányba tartanak, és elvárt, hogy ismerd és tudd használni ilyen környezetben.

nem tudom, ezt mi alapjan raktad ossze a fejedben. Arrol szo sem volt, hogy barki (ebben a topikban) is elveszett lenne egy systemd-s disztronal. Ez csak a te fejedben van, hogy csokkentse a kognitiv disszonanciadat: a systemd egy eletveszelyes kalap szar egy dilettans kokler kezebol vs. minden kersekedelmi disztro systemd-t hasznal.

De hogy egy kicsit visszaforditsam a fejedre a dolgot: a vilag egyre inkabb a kontenerek fele halad, amiben nem fut systemd, meg akkor sem, ha pl. centos 7 az, igy azokban kb. a hajadra kenheted a systemd rendszerfolyamat kezelo "finomsagait". Aki meg nem halad a korral.... majd te befejezed...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

"ez viszont nem annyira koszon vissza a bug reportokban, hogy x app iroi elrontottak a chroot() hivast. Ami valoban kod duplikacio (legalabbis abban az ertelemben, hogy benne van x, y, es z alkalmazasokban), de ilyen tartalmu bugtraq levelre nem emlekszem."

https://www.cvedetails.com/google-search-results.php?q=chroot

valogass kedvedre :D

Ha abbol indulok ki, hogy minel hosszabb a kod, annal tobb hiba van benne, akkor egy init rendszernel a kevesebb a tobb

Ezzel a gond csak annyi, hogy ugyan a PID 1-ből kidobtál minden "felesleges" kódot, de így ugyanez a kód jobb-rosszabb minőségű glue scriptekben/binárisokban N példányban fog rosszul szerepelni (triviálisan: privilégiumok eldobása, chroot környezetekbe zárás, erőforrás limitek stb. Bele lehet őket taknyolni az init scriptekbe [mindegyikbe külön-külön!], aztán lehet jó kis "konfig fájl formátumot" (értsd: simán source-olt shell scriptnek használt kulcs-érték párok...) kitalálni, hogy melyik opció kell hozzá és az milyen beállításokkal stb.
Vagy ezeket egy helyen megcsinálhatod, és a teljes rendszert tekintve kevesebb kódot kapsz.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

-1

pont forditva tortent: pid 1-be emelt be a nyomorultja csillio oda nem tartozo dolgot. Amiket felvetettel, azok mar eddig is meg voltak oldva. De vegyuk ezeket sorra!

- privilegiumok eldobasa: ezt maga az alkalmazas teszi meg, nincs ehhez szukseg kulso tamogatasra. Vagy a konfigjaban, vagy cli parameterkent be tudod allitani, hogy milyen user legyen belole.
- chroot kornyezetbe zaras: ha a chroot(2)-re gondoltal, azt is kezelni tudja az alkalmazas sajat hatokorben
- eroforras limit: setrlimit(2)-vel detto

Mondom, ezek faek egyszerusegu dolgok (bar az ember barmit kepes elszabni), amit nem init scriptekben kell (bar ott is lehetseges), hanem az erintett alkalmazasban. Ha glue binarist emlitesz (gondolom, valami system wide elerheto utility-rol van szo), akkor annak funkcionalitasa szinten csak 1 helyen van, igy ez nem erv a systemd mellett. Glue scriptek eseten (amikkel a korabban emlitett funkciokat akarod megvalositani) meg nehez olyan ordenare sec. hole-okat nyitni, mint systemd-nel.

Ami pedig az "a teljes rendszert tekintve kevesebb kódot kapsz." ervedet illeti - meg ha igy is van, bar alatamasztast nem adtal hozza - sajnos a minoseg eleg hitvany...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

"privilegiumok eldobasa: ezt maga az alkalmazas teszi meg... satöbbi" - igen, minden alkalmazás küön-külön, vagy jól, vagy sehogy oldja meg magának a privilégiumok elhajítását, a chroot-ot, az erőforráslimitet, cgroup-ozást... Alkalmazásonként külön-külön kóddal - vagy sem.

Pl. egy raklap saját service unit-om, amik ha nem férnek el egy sorban, sh fájlba mennek, egyébként maga a parancs megy a unit fájlba (pl. backup scriptek). Azokat nem szeretném rootként futtatni, kezdhetném azzal, hogy copy pastelek mindegyiknek az elejére egy fél kilós részt, ami kitúrja az /etc/defaults-ból vagy az /etc/sysconfig-ból, hogy milyen userre váltson, milyen munkakönyvtárat használjon, állítson-e be magára CPU/IO/memória limitet és ha igen, mekkorát. Aztán ha találok benne egy hibát, javíthatnám 30-50-100 példányban. Vagy megírhatom systemd unit-ként, és ezeket a limiteket állítgathatom és továbbra is csak az az egy scp process fog futni.

De ugyanígy kb. minden, ami inetd-stílusú indításra készült és elvárja, hogy a supervisorsuper-server már a helyes user nevében indítsa.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

juj! Az a kisebbik gond, hogy 30-50-100 olyan kodos dolgot dobsz be, amirol messzirol buzlik, hogy koze nincs a valosaghoz.

copy pastelek mindegyiknek az elejére egy fél kilós részt, ami kitúrja az /etc/defaults-ból vagy az /etc/sysconfig-ból, hogy milyen userre váltson, [...]

ez meg a nagyobbik. Mert ha te megizzadsz azzal, hogy pl. az /etc/defaults alol kiszedd az adott app beallitasait, vagy beallitsd, hogy milyen userkent fusson az app, akkor a linux kezdoben szivesen elmagyarazzak.

De a legnagyobb meg az, hogy ha ugyanazt a reszt "30-50-100 peldanyban" copy-paste-eled. Reflexbol nyomnam ra a -2-t (btw. code review nem rulez nalatok?). Mert ennel nagyobb faszsagot es antipattern-t nehezen tudok elkepzelni :-) De nyilvan ez az elofelteves kell, hogy megalljon az ingatag ervelesed.

De ugyanígy kb. minden, ami inetd-stílusú indításra készült

2018-ban ki hasznal inetd( funkcionalitas)t? DJ Bernstein cuccait nem er mondani. De kivancsiva tettel, hogy te miket futtatsz ilyen modon...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

De a legnagyobb meg az, hogy ha ugyanazt a reszt "30-50-100 peldanyban" copy-paste-eled.

Vagyis azt mondod, van értelme _egy_ implementációnak, aminek a meglétére több szoftver építhet? ;) Mintha a systemd _pont_ ezt a funkciót akarná betölteni.

2018-ban ki hasznal inetd( funkcionalitas)t?

pl. Xvnc. Illetve ha kiterjesztve az "inetd funkcionalitást" bármilyen socket-aktiválás ér, akkor az OpenSSH-tól kezdve a Cockpit-ig rohadt sok minden. Ha systemd-s rendszered lenne, egy systemdctl list-units -t socket részletes listát adna ;)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Vagyis azt mondod, van értelme _egy_ implementációnak, aminek a meglétére több szoftver építhet? ;) Mintha a systemd _pont_ ezt a funkciót akarná betölteni.

nem. En azt mondom, hogy az elszabott megoldasoddal magad lotted tokon. systemd nelkul is megoldhato korrekt modon a dolog.

X alkalmazas beallitasai legyenek a /etc/defaults/x alatt, ami egy shell-bol source-olhato file. Igy az adott alkalmazas init scriptjeben ezek a valtozok kapasbol megvannak. De tfh ez egy nagyon trukkos app (csak ugy, mint a 29-49-99 tobbi cuccod. Ezen a ponton probalom nem elrohogni magam), amit chroot-olni kell, meg limiteket beallitani, meg meg nem tudom mit. Ebben az esetben csinalnek egy szinten source-olhato file-t (pl. /etc/defaults/nehez-az-elet.sh), es ebben implementalnam 1 helyen a dolgot. Analogiat hasznalva, kb. 1 lib-et csinalsz igy, amit 30-50-100 helyen hasznalsz. Modositani pedig csak 1 helyen modositod.

pl. Xvnc.

oke, nyertel

Illetve ha kiterjesztve az "inetd funkcionalitást" bármilyen socket-aktiválás ér, akkor az OpenSSH-tól kezdve

-1, ez egy otromba koncepcionalis mellenyulas. Mar csak azert is, mert pl. az sshd nem valt usert, nem dob el privilegiumokat (ugy, ahogy varnad a systemd kontextusaban)

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Modositani pedig csak 1 helyen modositod.

Vagy tudod, használom a systemd-t, és nem lesz egy saját scriptem, aminek a tutujgatásához sok sikert az utódomnak (és scriptenként még egy "konfigfájl" [újabb futtatott kód, btw., hiába akarjuk confignak beállítani]). Mert így lesz neked egy ilyen scripted, nekem egy ilyen scriptem, Bélának a másodikon egy ilyen scriptje, ... És utána bele kell nyúlnom minden disztribútortól származó init scriptbe, ha használni akarom benne a nehez-az-elet.sh által nyújtott API-t. És...

Mar csak azert is, mert pl. az sshd nem valt usert, nem dob el privilegiumokat (ugy, ahogy varnad a systemd kontextusaban)

A 22-es port miatt kell neki az a privilégium, ami a socket activationnel kiváltható (hogy egyébként a fél világban kell turkálnia a /home-tól kezdve a kerberos keytabig, az már más kérdés).
De pl. itt egy alkalmazás, amit nem tudsz leszorítani a root jogkörről, pedig sok mindenhez nem kéne neki hozzáférés.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"ez meg a nagyobbik. Mert ha te megizzadsz azzal, hogy pl. az /etc/defaults alol kiszedd az adott app beallitasait, vagy beallitsd, hogy milyen userkent fusson az app, akkor a linux kezdoben szivesen elmagyarazzak."

Mondjuk ha picit visszavennél az egóból és a "mindenki hülye csak én vagyok helikopter" mentalitásból - amit már feltűnően sokszor tanúsítottál - akkor rájöhetnél, hogy nem az a baja a kedves illetőnek, hogy nem jutott túl a linux kezdőn, hanem az, hogy ezt meg kell csinálni, mindenhol újra és újra. Érdekes módon ilyenkor már nem számít a LOC a kódduplikáció meg ilyen egyéb dolgok.

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

Mondjuk ha picit visszavennél az egóból és a "mindenki hülye

ez csak a te fejedben van ezzel a helikopteres hulyeseggel. De meg mielott nagyon belelovalnad magad a szalmababbal valo kuzdelmedbe, hadd irjam le ismet, hogy siman meg lehet oldani a fentebb targyalt feature-oket ugy, hogy 1x kell (nem implementalnod, hanem csak) hasznalni az elerheto lehetosegeket. Ami nem bonyolultabb, mint a 30-50-100 db systemd unit file szerkesztese...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Én meg a rénszarvi vagyok. :)

Látszik mekkora katyvasz a linux. Meg mennyi vitát szül a sok okos ember írta csomagokból összevadászott rendszer fölé gányolt mindentudó.

Mennyivel szebb a hálózat inicializálás melyik szkript legyen helyett:

/etc/methods/cfginet - A többi meg jön az ODM-ből.

De ez már offtopic. :(

A Linux-only rétegnek az ODM-et ne emlegesd, mert megkapod tőlük azt, amit anno bő húsz éve egy ifjú kollégától, hogy registry a'la IBM, és fúj :-) Azért van annak előnye, ha átláthatóan, egységesen terveznek meg valamit ahelyett, hogy elvileg jól tervezett gombócokat raknának halomba, ami, ha minden jól megy, szépen meg fog állni kupacban, de ha nem, akkor nagyon nem, és lehet celluxozni a bogyókat :-)

Mármint úgy érted több ezer alkalmazás, igaz? Mert így ugyanazt a privilégium eldobást/chroot/setrlimit/nice/ionice/összestöbbi [nézz rá egyszer a systemd.resource-control man page-re]... meg kell oldanod egy apache-ban, nginx-ben, lighttpd-ben, postfix-ben, mysql-ben, postgresql-ben, ..., mindenben, aminek egy pillanatig is kell rootként indulnia (vagy amit az init rendszer rootként indít). És persze ugyanennyi példányban kell konfig fájl/command line argument/füstjel parse-oló kód (ha meg maga az indított démon nem támogatja ezeket, akkor kezdődik a shell scriptből körbetaknyolás, vagy a semmi és buktál 1-1 réteg plusz védelmet). És...

Lentebb linkeltél egy JajCsúnyGonoszSystemdOldalt [btw, imádom, hogy kiírják, hogy "mekkorabloatscopecreep" és egy felsorolásban felsorolják az összes systemd ernyőprojektbe tartozó projektet, amik nagy része opcionális és a legtöbb disztró alapból nem használja :) ], ott linkelnek egy Ayer vs. Strauss vitát [https://www.agwa.name/blog/post/systemd_is_not_magic_security_dust és az összes folytatása valami random címen szerepel a wikio oldalon, mert másodjára már nem találtam meg]: amit Ayer nem ért meg, hogy _ha_ az összes alkalmazás tökéletes lenne és gondoskodna _minden_ biztonsági szolgáltatás megfelelő használatáról (ahogy nem teszik), akkor nem lenne szükség külső eszközökre. De nem teszik, így van.
Addig viszont egy kifejezetten kényelmes dolog, hogy az indított démontól függetlenül pl. le tudom tiltani a fájlrendszer azon részeit, amihez biztosan nem kell, hogy hozzáférjen, fekete vagy fehér listázhatom, hogy hálózaton melyik IP-kkel beszélgethet, stb. És persze, a SysV init is csinálhatná azt, hogy indít egy külön processt, ami elvégzi ezeket a beállításokat, aztán elindítja a tényleges démont, azzal annyit érnél el, hogy egy systemd komplexitású program PID2-ben futna...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

meg kell oldanod egy apache-ban, nginx-ben, lighttpd-ben, postfix-ben, mysql-ben, postgresql-ben, ..., mindenben, aminek egy pillanatig is kell rootként indulnia

es (amit azt fentebb irtam, elnezest, hogy ismetlem magam) meg is oldottak, mert muszaj nekik, mert nem csak systemd-s linuxon futnak.

És persze ugyanennyi példányban kell konfig fájl/command line argument/füstjel parse-oló kód

ez szinten elkerulhetetlen, mert ezek az alkalmazasok meg szamos 'egyeb' (sic!) beallitast is hasznalnak, amihez semmi koze pl. egy init rendszernek. Ezert muszaj, hogy tudjanak sajat konfig file-t olvasni. Egyszerubb alkalmazasoknal eleg lehet par cli opcio is. Btw. azert vannak eleg jol szabvanyosithato konfig formatumok is, pl. json, yaml, whatever, amire akar lehetne egy (g)libc funkcionalitas.

amit Ayer nem ért meg, hogy _ha_ az összes alkalmazás tökéletes lenne és gondoskodna _minden_ biztonsági szolgáltatás megfelelő használatáról

hogy Ayer mit nem ert, azt nem tudom. De amit te biztosan nem ertesz az az, hogy egy init rendszernek mi koze van ahhoz, hogy pl. milyen IP-t erhet el x alkalmazas a halozaton? (Pont ezt roja fel a hivatkozott resz) Te erted azt, hogy egy init rendszerrol beszelunk, nem egy hatarvedelmi eszkozrol?

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Te erted azt, hogy egy init rendszerrol beszelunk

Akkor visszakérdezek: _ki_ oldja meg, hogy a kernelben egyébként ott levő lehetőségeket ki tudd használni?

Ha letolod az alkalmazásra, akkor azok tele lesznek Linux-specifikus dolgokkkal (hasonlóan: OpenBSD, FreeBSD, NetBSD, ...). Ha letolod a csomagolókra, akkor jön a keresztbe-kasul scriptes taknyolás (ami nem szerencsés, mert guideline-ok ide, guideline-ok oda, maintainertől függően csapnivalóak is lehetnek) vagy az upstream folyamatos patchelgetése. Kiszervezheted külön programba (... meh, azért cgroup ide, cgroup oda, a processzek követéséhez kell a PID1) és akkor goto 1: kinek a felelősége legyen a külön programhoz az alkalmazás-specifikus konfigok összeállítása (upstream, disztribútor, üzemeltető).

Egyébként pedig nem a systemd fogja ilyenkor megvizsgálni, hogy jé, ez a csomag hova megy meg hogy a PID312 hozzáférhet-e a /home-hoz: ő továbbra is csak a cgroup managementet végzi, hogy ezzel sokkal hatékonyabban lehet biztonsági és erőforrás limiteket állítani, az a kernel érdeme.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

konkretizalni kellene, hogy milyen kernelben levo lehetosegeket akarok hasznalni? A valasz lehet az, hogy nem akarom hasznalni. Lehet az is, hogy pid 312 user x-kent fut, mig a /home alatt semmi nem olvashato az o userevel. (Egy prod szerveren amugy ezt mondvacsinalt dolognak erzem.) A csomagok hova mennek problemakorere egy egesz iparag epult mar ra, es adott ra megoldast. De pl. a docker is eleg jol tudja hasznalni a cgroups feature-t, lehet vele csillio limitet force-olni, capability-ket engedni, amit akarsz.

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

> docker

Úh, docker, na azt ne emlegesd fel. Vagyis pontosabban a compose-t. Ott is volt funkcionalitás arra, hogy lehessen megadni függőséget és health check opciót, majd beközölték a fejlesztők, hogy nem, bocs ez nem a mi feladatunk, old meg mással vagy tákolj magadnak valami shell scriptet a konténeredbe, hogy a függőséged egyébként életképes-e...

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

eppenseggel lehetne a dockerben egy olyan feature, hogy megadhasd, hogy mit tegyen az unhealthy kontenerrel (kill, restart max. 3x, ...), es ugyan valoban szerencsetlen lepes, hogy beletesznek egy feature-t, majd kiveszik (felteve, hogy tenyleg ez tortent), de ettol fuggetlenul a healthcheck a legtobb helyen azt jelenti, hogy te mondod meg, mikor healthy a kontenered. Ami tipikusan pl. egy curl parancs, de lehet ennel komplexebb logikat is osszehozni. Ugyhogy marad a docker felemlegetese...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

"(felteve, hogy tenyleg ez tortent),"

There are several things to be aware of when using depends_on:

- depends_on does not wait for db and redis to be “ready” before starting web - only until they have been started. If you need to wait for a service to be ready, see Controlling startup order for more on this problem and strategies for solving it.

- Version 3 no longer supports the condition form of depends_on.

[...]

Szóval tök jó, hogy van healthcheck, csak épp értelmetlen. Azt is problémásnak találom, hogy nincs mód arra, hogy te belülről kifele jelezd, hogy hello docker, most már healthy vagyok. Nincs is olyan státusza a konténernek, hogy starting.

Szóval most perpill az a hivatalos álláspont, hogy taknyolj bele egy shell scriptet a konténeredbe, ami figyeli, hogy a függőséged healthy-e vagy sem: https://docs.docker.com/compose/startup-order/

Mit ne mondjak? Ez így egy összecelluxozott takonykupac. Számomra teljesen kifordított gondolkodás, hogy ahelyett, hogy én mondanám meg magamról, hogy kész vagyok, mások próbálják teafüvekből és celluxozott szarhalomból kitalálni, hogy vajon valóban elérhető vagyok-e. Ahelyett, hogy lenne egy rendes inicializálási rendszer.

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

Szóval tök jó, hogy van healthcheck, csak épp értelmetlen.

-1, maradjunk annyiban, hogy a te fejedben nem all ossze a dolog. Nagyon kiverte nalad a biztositekot ez a shell script dolog - ami megint csak a te fejedben van, mert egyaltalan nem kotelezo scriptet irnod. Sok esetben egy sima curl http://localhost || exit 1 is eleg a Dockerfile-ba, mint healthcheck. Aminek hatasara a docker meg tudja mondani, hogy az adott kontener koser vagy sem.

Aztan mar rajtad all, hogy mit csinalsz, ha unhealthy, mert a monitorozo rendszered ertesit. Eldobod, es inditasz egy uj kontenert, whatever. Mondom, szerintem is lehetne a docker demonnak olyan funkcioja, hogy megadhassam, mit csinaljon, ha egy kontener beteg lesz.

ahelyett, hogy én mondanám meg magamról, hogy kész vagyok

felteszem, ezen a ponton a 'jol vagyok' allapotra gondoltal. Nem akarlak meggyozni arrol, hogy ez most is igy mukodik. Btw. a kubernetes-ben mar van starting allapot is (ami educate dguess alapjan nyilvan a docker healthcheck feature-t hasznalja, es kb. az 1. OK check-ig starting allapotban van), ill. megadhatod neki, hogy mit csinaljon a beteg kontenerekkel.

Mit ne mondjak? Ez így egy összecelluxozott takonykupac.

nem ertem a hisztidet. Miert hasznalod akkor? Miert nem probalsz meg egy alternativ kontener megoldast, pl. rkt, hatha az jobb? Vagy miert nem hagyod a kontenerek vilagat beken, es maradsz meg virtualis gepeknel, vagy aminel akarsz?

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

"Sok esetben egy sima curl http://localhost || exit 1 is eleg a Dockerfile-ba, mint healthcheck."

Értem én. Ettől ez még egy ótvar nagy cellux. ahelyett, hogy az induló service bebillentene egyetlen egy flaget, hogy hello, kész vagyok, kell 60 másik függőség és egyedi, úrja és újra feltalált takony, hogy kiderítsd, hogy a szerencsétlen konténer healthy-e vagy sem. Szerinted mi a több? A komplett curl és a többi cucc az összes libbel, amit használ vagy egy kód, amin egy service egy státuszt vissza tudna jelezni?

"nem ertem a hisztidet."

Hát ez itt a nagy baj. zeller is írta már fentebb: az, hogy valamit eddig maradiságból vagy lustaságból így csináltak, az nem biztos, hogy a létező legjobb megoldás.

"Miert hasznalod akkor?"

Mert egymagamban nem fogom szétrúgni hírtelen felindulásból az egész infrastruktúrát az egész cég/szolgáltatás alatt. (Egyébként van terv a kubernetesre, de ez most nem prioritás.)

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

ahelyett, hogy az induló service bebillentene egyetlen egy flaget, hogy hello, kész vagyok

ok. Es ha hirtelen meghal vagy csak elkezd kohecselni a szolgaltatasod, akkor honnan fogja tudni a docker, hogy ki kene billenteni azt a flag-et?

kell 60 másik függőség és egyedi, úrja és újra feltalált takony, hogy kiderítsd, hogy a szerencsétlen konténer healthy-e vagy sem.

nem gondolkodtal meg azon, hogy valami agyturkasz segitseget kerd, hogy ellenallobb tudj lenni a vilag megprobaltatasaival szemben? Nincs olyan ember nalatok, aki nem a szajat huzza mindenert, ami nem ugy mukodik, ahogy o szeretne (vo. saxus ops kalandjai), hanem egyszeruen csak megcsinalja a melot?

zeller is írta már fentebb: az, hogy valamit eddig maradiságból vagy lustaságból így csináltak, az nem biztos, hogy a létező legjobb megoldás.

eleg eroltetett ezt a docker allitolagos bajaira rahuzni, foleg ugy, hogy itt semmilyen maradisagrol nincs szo, hanem egyszeru pebkac.

Mert egymagamban nem fogom szétrúgni hírtelen felindulásból az egész infrastruktúrát az egész cég/szolgáltatás alatt. (Egyébként van terv a kubernetesre, de ez most nem prioritás.)

de azert, remelem, elmondtad nekik, mekkora maradi es lusta nepseg, meg a hisztit a celluxozott takonyrol, a 60 masik fuggosegrol, meg a . De eleve nem is ertem, hogy tortenhetett meg, hogy ezt a docker-es orultseget le tudtak nyomni a torkodon...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Na látod, erről beszélek. Pofád kurva nagy tud lenni és mindenki más hülye rajtad kívül. Ha meg valakit (megjegyzem, kollégákat is) zavar(ja) a szarhalom meg a cellux, akkor persze hülye, hisztis és egyébként is pebkac.

Bocsika, ha valamit csak igénytelenül lehet megcsinálni, akkor nem fogok hozzá tapsikolni. Még akkor sem, ha egyébként perpill. nincs jobb alternatíva. (Helyből tudnám mondani neked az integrációs tesztjeinkhez használt szoftvereket, amit szintén mindenki utál itt, mert van vele baj bőven, de attól még használjuk, mert a többi ismert alternatíva még rosszabb vagy más use-casekre jó. Ettől még nem fogjuk azt mondani, hogy minden fasza vele.)

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

Ettől még nem fogjuk azt mondani, hogy minden fasza vele.

hidd el, mi rokon lelkek vagyunk. Nekem sem tetszik egy csomo minden, pl. a systemd, es en is batran kimondom, hogy mekkora kalap szar. Azt a sok mindent, amit te kakinak tartasz, annak nagy reszet en is annak tartom. A maradekon meg rohogok, hogy mar megint mit szerencsetlenkedsz es inkabb allnal felre, engednel oda valakit, aki csak fele annyit picsog, es hajlando rinyalas helyett megcsinalni a melot. Ahogy a muvelt kubai manager erdeklodne: are you part of the problem, or part of the solution?

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

> Soroljam a systemd előnyeit a bughalmaz scriptekhez képest, pláne azokhoz, amit Linux-os környezetben voltam kénytelen kijavítani, illetve megoldani, hogy sysvinit esetén a futási szinteket is normálisan lehessen használni Linuxon is? Vagy épp az initscripttel indított vackokat, amit inittabból illett volna indítani, és viszont?

Sorolhatod, műszaki érvekre mindig nyitott vagyok. Csak akkor én meg fel fogom sorolni, hogy mennyivel több problémát teremtett, mint amennyit megoldott. (Főleg, mivel jó freedesktopos módon a megoldott problémák legalább felét ő maga teremtette, hogy megoldhassa.)

> Ja, hogy a Linux-os körökben a meglévő eszközök méy ismerete sohasem volt követelmény, inkább írunk egy másikat?

Hát igen. És így született a systemd is, nem tűnik fel?

> Csak kereskedelmi UNIX/Unix-jellegű rendszerből volt vagy fél tucat, Linux meg 0.93-as kernel meg tán 1.02-es SLS disztribúció óta nagyjából mindegyik jelentősebb terjesztés - és nem csak itthoni játszós gépen.

A kereskedelmi rendszerekben általában pont a régebbi, bevált, letesztelt rendszereket pakolják, a Linuxok többségén meg vagy a SysVInit vagy az Upstart fut. Konkretizálhattad volna egy kicsit jobban. Az S6-ot próbáltad például? Ahhoz még Linux sem kell, bármilyen POSIX kompatibilis rendszeren elfutkorászik, akár kereskedelmi UNIX-okon is.

> Én nem vagyok "systemd hívő" (aki pár éve hozzád hasonlóan az általad linkelt, illetve ahhoz hasonló tartalmakra mutogattam!), csak mostanra látom a systemd hasznosságát, illetve értelmét. Meg a hibáit is - de ezekkel együtt is vannak olyan előnyei, amit a Linuxokon korábban használt init-rendszerek nem adtak meg, illetve csak gányolással tudtak prezentálni.

Oké, de kifejthetnéd, hogy miféle hasznosságok vannak, amik más init rendszerrel csak gányolással oldhatóak meg, mert ez a levegőben lógó körülírás, hogy régebben te is utáltad, de most megszeretted, ez így tényleg a megtértek hitbuzgóságára hajaz... A gányolásról meg annyit, hogy ha kinyitod a szótárat a "gányolás" szónál, akkor egy systemd kódrészlet lesz ott illusztrációként.

> Anno a Windows 3.11 még config.sys és autoexec.bat fájlokat hasnzált, és elég volt hozzá. Azóta picit fejlődött a Windows-os környezet boot/folayamtkezelés dolga is...

És születtek is egyéb initrendszerek is.

> Ha neked a systemd nem tetszik, lelked rajta - van még olyan terjesztés, ami nem használja - igaz, lassan kipusztul ugyanúgy, mint ahogy kihalt sok más dolog is, és mégis működik minden tovább :-)

Nem tűnik úgy, hogy a Slackware vagy az MX Linux ki akarna pusztulni. Vagy a Devuan. Utóbbi inkább egyre népszerűbb. Az megvan, hogy a distrowatch.com-on direkt van egy olyan filter opció az init rendszerre, hogy "not systemd"? Vajon miért?

Szerintem a systemd iszonyat el van bonyolitva, es egy csomo dolog builtin.

Rengeteg peldat tudnek mondani, de csak egyet mondok:

nfs-rol bootolnak a szamitogepeid,(30db), mindegyiknek adj egy sajat hosztnevet. Jah systemdben ez is builtin oszt' nem lehet.

De van millio+1 pelda. Barmi egyedit szeretnel ami nem a mainstream irany (szerver inditas, laptop inditas), meg vagy love.

Es van alternativa, en az openrc-vel szemezek.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

nfs-rol bootolnak a szamitogepeid,(30db), mindegyiknek adj egy sajat hosztnevet. Jah systemdben ez is builtin oszt' nem lehet.

https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html#

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

az se mukodott (emlekszem ra, meghogy mostmar mindenre sajat parancs van).

De nem tudom mi volt a konkret nyug.
Porogtem rajta kb. egy hetet egyebkent.
Meg egy eletre megutaltam a systemd-t:-(

Konkretan a fejlesztesi idobol 30%-ot elvitt;-(, es ebbe minden szoftveres oldalt beleszamolok (kliensoldal, szerveroldal, halozatepites, gui).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

> A saját véleményem ilyetén változását ismerve, szívesen venném, hogy szerinted mi az, ami "koncepcionálisan rossz" a systemd-ben önmagában?

A fejlesztő (hozzáállása). Nem képes beismerni a hibáját, olyan mintha alapvető dolgokkal nem lenne tisztában. Milyen lehet a kód minősége ezekután? Hirtelen a két legismertebb bug ami eszembe jutott:
https://github.com/systemd/systemd/issues/5644
https://github.com/systemd/systemd/issues/6237

@@
"You can hide a semi truck in 300 lines of C."

Hozzáállás vs. koncepció. Most akkor melyik? Eddig magával a koncepcióval volt gond, nem azzal, hogy mennyire khm. elfogadott a fejlesztője.
Ha meg ennyire topa alak, akkor tessen forkolni egy "systemd-ng"-t, és jobb fejlesztői gárdával csinálni egy olyat, ami egy-az-egyben berakható a mostani helyére.

Engem maga a systemd mint ötlet nem zavar, viszont míg a SystemV init-et simán meg tudtam érteni és tanulni kb. egy man inittab elolvasásával.

A systemd-t nem kellett megértenem és megtanulnom eddig, viszont előfordult már, hogy a korábban megszokott módon le akartam állítani egy szolgáltatást, ő meg vagy nem is értette a régi parancsot, vagy úgy tűnt, hogy működik, de valójában mást csinált, mint amit akartam és mint amire számítottam.

Hol lenne érdemes elkezdenem olvasni? man systemd?

A systemd több, és többet tud, mint a sysvinit, ezért egy manpage nem lesz elég. Ha szolgáltatások kezelésről van szó, akkor a systemctl felé keresgélj, egyébként meg google://"first steps systemd" teljesen jó lesz :-)
Ja, és előtte a fejben lévő sysvinit-es tudást/best practice dolgokat érdemes offline-ba rakni, hogy ne zavarjon :-P

Poetteringnek van egy pár postból álló blogpost sorozatja lassan egy évtizeddel ezelőttről, a "The systemd for Administrators Blog Series" címsor alatt linkelik az összeset a systemd freedesktop-os oldalán (https://www.freedesktop.org/wiki/Software/systemd/), azt érdemes átfutni, elég sok minden okát meg lehet belőle fejteni. Egyébként indulj a man systemd.unit-ból, ott majd látod, hogy milyen unitok típusok vannak egyáltalán ill. a fent említett man systemctl-ból.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)