Cannot open access to console, the root account is locked.

... es akkor ott bassza meg a pötterix onmagat ahol van!

Hozzászólások

Ja, abszolut publikus - csak ez most igy kikivankozott. Nyilvan nalam az a default hogy mindenhonnan repul a pötterix, de valamiert a RPi + Raspbian kombinacional meghagytam. Szeretem a kihivasokat, tudok elni, mittudomen :)

Na, es a legujabb ultimate pötterixizmus az a kovetkezo: ebbe az RPi modulba amivel most jatszom, masodlagos sd-kartyat is bele lehet tenni. Es akkor gondoltam hogy hozzateszek egy sort az /etc/fstab-ba hogy a /dev/mmcblk1p1-et csatolja fel a /data-ra. Na, csak ott rontottam el hogy reboot elott elfelejtettem a /data konyvtarat letrehozni. Nyilvan semmi rendszerkritikus nincs benne mert mi a branerert lenne. No, es az elso reboot utan a cimbeli uzenet fogadott, miutan a teljes bootfolyamat osszeomlott azert mert a /data-t nem tudta felmountolni(!). Soros konzolrol nem tudtam megjavitani (ld uzenet lenyege), a netkapcsolat nem allt fel, teljes kaosz.

Es most ezekutan azon hogy a /etc/network/interfaces-ba beirt allow-hotplug taggal megaldott USB-s Ethernet interface nem jon fel magatol, na, az ilyeneken mar meg sem lepodok. Mindenhol jol mukodik ez, kiveve a pötterixen.

Szoval igen, ra kell szannom a faradtsagot hogy kiirtsam a potterixet a raspbianrol is. Mar reg meg kellett volna tennem, rohogve visszahozta volna a befektetett idot :/

Hát igen, ha jót akarsz magadnak, akkor a systemd-t irtani kell. Én is kiirtottam az Orange Pi-s Raspbianból, még úgy is, hogy a csomagok egy részét gányolni kellett, pl. a

policykit-1

is systemd-függő volt, úgy, hogy nem is volt az, azaz a binárisok köszönték, jól mentek nélküle, de a surmó debilány team bedrótozta a csomagba a systemd-t mint függőséget. Azért, hogy ne lehessen megkerülni. Egy csomó csomagnak függősége, úgy, hogy nem is használja maga a lib vagy app. Ezért jó, hogy van Devuan, meg MX Linux, csak sajnos pont az ilyen lapkákra nincs.

Vagy bármi más, ami nem debilke/buguntu vonalról érkezett - ha van egyáltalán olyan. Egyébként az fstab-ot sysvinit-es környezetben sem ajánlatos elkufni...

Egyébként meg tessen a root-nak jelszót adni (mert ugye raspbian-on ha jól tévedek direkt nincs jelszava - van viszont x vagy más a shadow-ban, ami pont ezt a problémát képes generálni), oszt' jó'van.

Nem systemd-s, hanem rendszerösszerakós problémának tűnik: raspbian-on ha jól tévedek, a root account teleptés után zárolt állapotban van, egészen addig, amíg nem adsz neki jelszót. Ez egyik oldalról jó, mert nincs ddefault jelszavas root usered, másfelől rossz, mert ilyen esetben a sulogin jól mexivat. Vagy adsz a rootnak jelszót, vagy a boot-ot téríted el úgy, hogy init=/bin/bash legyen :-)

A telepítés során zároltan hagytad a root usert, azaz megtiltottad, hogy azzal bármikor be lehessen lépni - akár sulogin-nal is, ami a boot során felmerülő hibák esetén a root usert belépteti.
Igen. tudjuk, anno az ősidőkben ilyenre odabacarintott a rendszer egy root joggal futó shellt, aztán oldd meg - gyakorlatilag a fizikai hozzáférés implicit módon biztosított root jogosultságot.

Az raspbian default telepítésben zárolt root userrel érkezik, ha minden igaz, kapsz egy pi usert, amivel megy a sudo - legalábbis amikor én néztem, valahogy így működött. Tehát alapból zárolt a root, és ha ezt nem változtatja meg a raspi használója, akkor bizony belefuthat ilyen pofonba, amibe apal kolléga is.
A "kérdezze meg" akkor valid opció, ha garantálható(!), hogy aki választ ad, az jogosult a rendszer működésével kapcsolatos döntést meghozni - ehhez az nem elég, hogy "de ott áll mellette", ahogy te elvárnád. Ha meg zárolt a root user, akkor kirakhatna login promptot, de a root useren kívül rendszerindítás kellős közepén másnak semmi keresnivalója, ergo csak az épp zárolt root usereddel léphetnél be...

Erre lentebb már kétszer is válaszoltam, mármint, hogy van-e az ott álldogálónak joga-e skipet nyomni, de mindegy, akkor induljunk ki abból, hogy nincs, hacsak nem igazolja magát.

Kérdem akkor: van-e olyan lehetőség a systemd-ben, hogy mount fail esetén feltegye a kérdést, hogy skip vagy login és skip esetén root password-öt kérjen? Mert még mindig arról van szó, hogy nincs opcionális skipping, vagy always fail van, vagy always skip, legalábbis ezt mondjátok SzBlackY-val.

És kérdem továbbá: hogy amennyiben van, ha mind a javításhoz, mind a skiphez root login-t kér, ami zárolt root account esetén nem fog működni, akkor hogy fogod kijavítani a rendszert, ha fel sem tudod bootolni? Persze, eltérítem a boot-ot, hogy egy shell-t hozzon fel. Ez valid válasz, csak így viszont dönti azt az érvet, hogy ne legyen joga eldönteni a júzernek root account nélkül, hogy skippelhet-e vagy sem, nem?

"hogy fogod kijavítani a rendszert, ha fel sem tudod bootolni" - mint jogosult rendszergazda odamegyek, és igen, a bootmanagerben oldom meg azt, hogy root jogosultság igazolása nélkül is hozzáférjek a fájlrendszerhez. meg adok a rootnak jelszót, hogy ilyen gond a későbbiekben ne legyen. Ez nem azonos azzal, hogy bárki, aki ott van, dönthet egy hiba kezelésének a módjáról.

A boot folyamatot ugyanúgy bárki el tudja téríteni, akár a takarítónő is, mert ott nincs jogosultságkezelés. De mondom, induljunk ki abból, hogy bármilyen interakcióhoz root jogosultság kell; van erre lehetőség, hogy root jogosultság ellenében rákérdezzen a systemd, hogy skip vagy shell? Mert eddig csak az volt, hogy előzetesen be lehetett állítani, hogy mit döntsön, mindig skip vagy mindig shell.

Tudom, hogy le lehet jelszavazni, de nem ez a lényeg. Erre adj választ, mert sokadik forduló óta kerülöd: induljunk ki abból, hogy bármilyen interakcióhoz root jogosultság kell; van erre lehetőség, hogy root jogosultság ellenében rákérdezzen a systemd, hogy skip vagy shell? Mert eddig csak az volt, hogy előzetesen be lehetett állítani, hogy mit döntsön, mindig skip vagy mindig shell.

Nem az volt a kérdés, hogy mi kell ahhoz, hogy bármilyen interakciót lehessen kezdeményezni.
Lehet root jogosultsággal, _nem zárolt_ root account esetén választani, hogy csak skip vagy shell? Ez az, amire nem vagy hajlandó válaszolni. Nem bármilyen interakció, nem szarakodni akarunk: mount failed, give root password, skip or shell?

Nem, hogy megkérdezze, hogy aki a gépnél van, annak van-e joga dönteni (azaz root-e) ,és utána megkérdezze, hogy mit csinálj. A SysV init implikálja, hogy root az, aki a gépnél van. A sulogin más, az single-user mód, az totál más dolog, mint a boot folyamán megkérdezni, hogy root vagy-e, és ha igen, mondd meg, mi történjen a többi boot folyamattal.
Ez a legszebb a suloginnál még: If the root account is locked, no password prompt is displayed and sulogin behaves as if the correct password were entered.

LOL.

Nem kell security programot tárolni rendszerkönyvtárakon kívül. Legyen mondjuk egy webszerver, aminek a /var/www-je külön partíció és 10 percenként rsyncelve van egy backup szerverre. A skip-re bökő takarítónő most tett elérhetővé, de működésképtelenné egy szolgáltatást és törölte a backup szerverről a másolatot.

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

Boot közben fail, majd a Pistike azt mondja a promptnál, hogy skip és köszönöm, el is baszódott. Pedig Pistike nem root a gépen.
Viszont ha jól értem a szavaidat, akkor igazából a boot folyamat biztosítására elég az, hogy korlátozzuk, hogy fizikailag ki férhet hozzá a géphez, ez kellően elég biztonság, szoftveresen már semmi szükség rá.

> Te mondtad, hogy a SysVinit megoldás a problémára.

Én ilyet nem mondtam. Én azt mondtam, hogy a SysVInit engedi a skipet is és te dönthetsz, nem azt, hogy a SysVInit a megoldás. Kértem, hogy ne adj szavakat a számba.

> Pedig a SysVinit behoz egy security risket (sulogin, lockolt root accounttal is ad egy root shellt).

Tény, de security riskből a systemd oldalon sincs hiány; hogy is volt, amikor invalid usernévnél a root-ra revertelt? Egy érv a SysVInit ellen, nem érv a systemd mellett. Tonna alternatív initrendszer van.

hogy is volt, amikor invalid usernévnél a root-ra revertelt?

Ez speciel a mai napig így van, mert by design ilyen a konfig fájl parsere (egyébként _csak 0-val kezdődő_ értékre futott rootként, 1asdasd-al már uid=1 stb., nem numerikus karakterrel kezdődő, de nem valós usernév értéknél a konfig parser nem számként értelmezi az értéket, a systemd megpróbálja feloldani a nevet uid-re, nem sikerül neki, úgyhogy error)

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

Tudom, hogy nem javították, mert Lennart bátyó szerint ez nem bug. De a probléma nem is ott van, hogy most Poettering megint szembemegy a POSIX-szal és önkényesen szab mindenféle szabályt a felhasználónevekre: az a probléma, hogy akár invalid, akár nem, ne a root-ra reverteljen. De ezt a múltkor már kiveséztük.

Anno bőven a systemd előtti érában is per definitem az volt a szabál' hogy az usernév nem kezdődhet számmal, mert a számmal kezdődőből a számként értelmezhető részt UID-ként fogja értelmezni a rendszer, úgyhogy ez _sem_ systemd-s sajátosság, bár sokan nem tudják.

Egyrészt a POSIX ilyet nem írt elő. Voltak olyan tool-ok (pl.

adduser

), amik egy változóból (pl.

NAME_REGEX[_SYSTEM]

) rántották be a helyi névszabályt, de volt kapcsoló (pl.

--force-badname

), hogy ne foglalkozzon a konvenciót áthágó nével, hozza csak létre. (Egyébként egy alapból stringként kezelt stringnek miért értelmezné különféle módon a különféle részeit a rendszer? Miféle system vagy tool csinálta ezt? Mármint a systemd-n kívül.)

Másrészt az önkényesen invalidált számmal kezdődés a kisebbik baj. Nem ezért akarták meglincselni elsősorban Poetteringet, hanem azért, mert a root-ra revertelt. Az azért elég nagy security risk.

De pont az a lényeg, hogy _nem_ a rootra revertel, hanem arra a uid-ra, amilyen numerikus karakterekkel összefüggően kezdődik a usernév: a 1337haxxor usernévnél uid=1337-el fut.

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

0 esetén viszont a root-ra revertel. És így pl. az ominózus

0day

mindjárt ezt csinálta, azon bukott ki a balhé, de a Poettering által használt

0pointer

usernév is.

Kérdés itt is áll: egy alapból stringként kezelt stringnek miért értelmezi különféle módon a különféle részeit a rendszer? Ennek mi értelme?

Nem értelmezi különféle módokon, pontosan ugyanaz a parser fut rá, mint az összes többi értékre, ahol szerepelhet szám vagy string.

Egyébként nem akkor lenne _igazán_ bloat a systemd, ha egy többek által bad practice-nek (értsd: számmal kezdődő usernév, de mint ahogy írtad, több esetben toolok által tiltva is van) kapcsán egy nagyon csúnya edge case (számmal kezdődő user nevében indított service, amire egyébként még mindig nem kaptunk valós use case-t) külön kódot kapna?

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

De ennek mégis mi értelme van? Az usernév az egy string, nem egy szám, pláne nem vegyesen szám és szöveg.

Nem, attól, hogy simán szövegként kezel valamit, éppen hogy kevésbé lesz bloatabb, mint ha parse-álni kéne egy adatmezőt. A felhasználóneven nincs mit parse-álni, az szöveg. Maximum egy regexpet rá lehet engedni, hogy annak megfelel-e, de ez sem kötelező. Amúgy meg nem nekünk kell usecase-t adni arra, hogy miért kéne engedni a számmal kezdődő nevet, hanem nektek arra, hogy miért kéne tiltani. És az nem usecase, hogy mert a systemd így értelmezi. Ki kérte ezt a baromságot, mi az értelme? Mi a francért kellene a loginname elejét számként értelmezni?

> Mert a felhasználónév _és_ uid is használható ott.

Loginnévnél? Ilyet sem a POSIX, sem más nem ír elő. Választ kaphatnék végre arra a kérdésre, hogy ha ez nem systemd marhaság, akkor hol találták ki ezt és miért, mi ennek az értelme, hogy valami ami egyértelműen szöveg, azt minek akarják integerként értelmezni? Milyen rendszerben volt ez rendszeresítve, hogy egy username-et váró adatmező UID-et és username-et is elfogad és valami syntax-convention helyett úgy dönti el, hogy melyiket kapta, hogy számmal kezdőik-e vagy sem? Mert ez agyfasz. Akár a systemd szerzője találta ki, akár másutt volt először.

> Speciel K&R kérte, lásd még atoi ;)

K&R kérte, hogy a UNIX-okban a loginnevekre direkt húzzák rá a szövegből integerre konvertáló függvényt. Nem tudom, hogy ez hogy jött ki, de eddig ez viszi a prímet ebben a topikban. A kérdés az volt, hogy miért értelmeznének loginneveket számként és erre te indoknak azt adod, hogy mert a C nyelv általános függvényei között van ASCII to integer átalakító? Ez most komoly? Ha van ilyen, akkor rá is kell húzni? Remélem, ez csak valami rettenetes vicc volt.

Választ kaphatnék végre arra a kérdésre, hogy ha ez nem systemd marhaság, akkor hol találták ki ezt és miért, mi ennek az értelme, hogy valami ami egyértelműen szöveg, azt minek akarják integerként értelmezni?

Hogy megadhass akár nevet akár uid-et. "Jaj, de azt két külön mezőben kéne". Ok, melyiknek legyen magasabb prioritása (azzal együtt, hogy sehol máshol nincs a systemd konfigban prioritás). Ha a system-wide unit fájlban definiált UserId=0-t /etc-ben override-olom UserName=foobar-ral, melyik nyerjen? Függetlenül az adhoc meghatározott prioritástól?

Egyébként meg tessen menni az indiánokhoz is sírni, náluk a User direktíve usernév vagy #uid formátumú. Pedig felülcsaphatom az /etc/password-öt, mert én jobban szeretem, ha a root-om #root, de a rohadt szemét Apache ezt elvette tőlem.

K&R kérte, hogy a UNIX-okban a loginnevekre direkt húzzák rá a szövegből integerre konvertáló függvényt.

Nem, ők csak bevezették azt a szokást, hogy atoi("0pointer") == 0 és atoi("1pointer") == 1 és létrehoztak egy nyelvet/környezetet értelmes hibakezelés nélkül, ezzel lassan fél évszázada megfertőzve több generációi programozót, hogy edge case-ekre nem figyelünk, különösen, ha az edge case out-of-scope, mert anti-pattern [aki bullshit-bingózik, annak ez a mondat remélem egész sor lett]

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

> Hogy megadhass akár nevet akár uid-et. "Jaj, de azt két külön mezőben kéne". Ok, melyiknek legyen magasabb prioritása (azzal együtt, hogy sehol máshol nincs a systemd konfigban prioritás). Ha a system-wide unit fájlban definiált UserId=0-t /etc-ben override-olom UserName=foobar-ral, melyik nyerjen? Függetlenül az adhoc meghatározott prioritástól?

Egyfelől kicsit szelektíven reagálsz: én felkínáltam lehetőségnek a syntax-convention-t is. A POSIX szerint kisbetű, nagybetű, szám, pont, underscore és hyphen lehet benne, de ez utóbbival lehetőleg ne kezdődjön (feltételezem azért, hogy ha egy parancsnak usernevet kell megadni, akkor ne kapcsolónak vegye az argumentumot), ennek megfelelően az összes invalid karaktert fel lehet használni tag separation-re, pl. kettősponttal elválasztod, hogy

user=datatype:data

(omitted datatype esetén revertel a default szöveges értelmezésre) és akkor

user=0-val_kezdodo_user_name_aki_az_uid_11-es

és

user=UID:11

. Vagy valami ilyesmi. A lényeg, hogy ambiguous data ne lehessen és ne reverteljen egy számmal kezdődő név esetén egy totál másik felhasználóra, rossz esetben a root-ra.

Másfelől még mindig várom a választ, hogy ez így hol volt még rendszeresítve, mert eddiglen csak a systemd-ben láttam ilyet.

> Egyébként meg tessen menni az indiánokhoz is sírni, náluk a User direktíve usernév vagy #uid formátumú. Pedig felülcsaphatom az /etc/password-öt, mert én jobban szeretem, ha a root-om #root, de a rohadt szemét Apache ezt elvette tőlem.

Ennyire nem érted, hogy elsősorban nem az a baj, hogy a systemd nem engedi a számmal kezdődő userneveket, hanem az, ahogy az adatot értelmezi és reagál rá? Ugyanis az utóbbi eredménye az előbbi. Ha Poettering csak simán kitalálta volna, hogy innentől nem szabad számmal kezdődő neveket használni, akkor maximum kiröhögik, vagy leanyázzák, hogy már megint hülye. De itt arról van szó, hogy egy fundamentally broken interpreting concept miatt kreált kurwa nagy sechole-t próbál bugfix helyett policy-vel "orvosolni"! (Számként értelmez valamit, amit nem kéne és teljesen más user nevében fog futni a cucc...)

> Nem, ők csak bevezették azt a szokást, hogy atoi("0pointer") == 0 és atoi("1pointer") == 1

De ki a faszom kérte, hogy ezt húzzuk rá valamire, amire nem kell? Hol használták ezt usernevekre? Mert ti ezt állítjátok, hogy ez nem systemd találmány, hogy az autentikációra használt szöveges adatot kétféleképpen lehet értelmezni és a numeric prefix dönti el, hogy melyik. Hol?

> és létrehoztak egy nyelvet/környezetet értelmes hibakezelés nélkül, ezzel lassan fél évszázada megfertőzve több generációi programozót, hogy edge case-ekre nem figyelünk, különösen, ha az edge case out-of-scope, mert anti-pattern [aki bullshit-bingózik, annak ez a mondat remélem egész sor lett]

Az megvan, hogy ezzel kvázi elismerted, hogy amit a systemd csinált az egy nagy fasság?

Az megvan, hogy ezzel kvázi elismerted, hogy amit a systemd csinált az egy nagy fasság?

Inkább azt, hogy a lehető legkisebb faszság, amit elkövethettek: azt már tisztázuk, hogy az nem játszik, hogy külön direktíva a usernév és a userid, mert rengeteg ellenérv szól ellene, tehát marad, hogy vagy csak UID vagy csak usernév, esetleg a kettő között különbséget teszel. A kettő között amint elfelejted a POSIX-ot (szevasz pl. SSSD, amit joska@REALM alakú userneveket mappel alapból, az @-et nem látom a felsorolásodban, a Winbind, ami REALM\foo [külön jó móka konfig fájlokban a random escape szekvenciák megszülése hozzá) marha nehéz különbséget tenni: lásd a fenti Apache-os példát, ahol annyi történt, hogy az egyik ritka (és sok rendszeren tiltott... BTW, a Debian tui/gui felületeken a pontot tartalmazó usernevet pl. visszadobja) edge case-t egy másik ritka edge case-re cserélted.
Elbaszott design? Az. Örökölt? Igen.

És akkor a másik, "a csúnya gonosz pöttering hozzáállás, a rohadék wontfixel!!!!négy!". Oké, üljünk le, találjunk ki egy megoldást, pl. egy olyan prefixet, ami garantáltan nem lesz usernévben (javaslon a NUL byte-ot vagy a kocsivissza-újsort, kb. minden más lesz). Ezzel eltörtél _minden_ olyan konfigot, ahol uid-et használtak, világszerte.

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

> Inkább azt, hogy a lehető legkisebb faszság, amit elkövethettek

Mi? Az, hogy elég nullával kezdeni és revertel a root-ra? Hát szerintem ez a legnagyobb baromság, amit elkövethettek...

> azt már tisztázuk, hogy az nem játszik, hogy külön direktíva a usernév és a userid, mert rengeteg ellenérv szól ellene, tehát marad, hogy vagy csak UID vagy csak usernév, esetleg a kettő között különbséget teszel. A kettő között amint elfelejted a POSIX-ot (szevasz pl. SSSD, amit joska@REALM alakú userneveket mappel alapból, az @-et nem látom a felsorolásodban, a Winbind, ami REALM\foo [külön jó móka konfig fájlokban a random escape szekvenciák megszülése hozzá) marha nehéz különbséget tenni: lásd a fenti Apache-os példát, ahol annyi történt, hogy az egyik ritka (és sok rendszeren tiltott... BTW, a Debian tui/gui felületeken a pontot tartalmazó usernevet pl. visszadobja) edge case-t egy másik ritka edge case-re cserélted.

És? Ezzel kizártál minden egyéb megoldást? Csak mert nem. Ha mindenáron az a mániád, hogy minden karaktert akarsz használni usernévben és egyetlen direktívát akarsz rá használni, akkor is van több épeszű megoldás a datatype specifikálására: pl. +1 direktíva rá.

user-dt=uid
user=11
user-dt=string
user=0-val_kezdodo_user_name_aki_az_uid_11-es

És itt is, ha az

user-dt

nincs megadva, akkor ugyanúgy stringnek veszi az

user

tartalmát.
Ezzel nem törtél el semmit, kompatibilis maradtál mindennel, amivel csak akartál és még azt a fránya invalid-user-revertet is preventáltad.

> Elbaszott design? Az. Örökölt? Igen.

Örökölt? De honnan? Légy szíves, most már mutassatok egy valamilyen UNIX-ot, ahol az volt a practice, hogy ha az usernév számmal kezdődött, akkor azt autentikációkor UID-ként értelmezte a rendszer. Bármilyet. Ha 1982-ből mutattok valami System III-as issue-t, akkor is elfogadom, hogy volt a systemd előtt ilyen, csak akkor meg fogom kérdezni, hogy miért kellett lemásolni egy 40 éves bad practice-t; a régmúlt fasságai a jövő követendő példái?

> És akkor a másik, "a csúnya gonosz pöttering hozzáállás, a rohadék wontfixel!!!!négy!". Oké, üljünk le, találjunk ki egy megoldást, pl. egy olyan prefixet, ami garantáltan nem lesz usernévben (javaslon a NUL byte-ot vagy a kocsivissza-újsort, kb. minden más lesz). Ezzel eltörtél _minden_ olyan konfigot, ahol uid-et használtak, világszerte.

Adtam prefix mentes megoldást fentebb.

Adtam prefix mentes megoldást fentebb.

Oké, loop, melyiknek van prioritása, melyiknek van prioritása override-kor stb., lásd fenn. Egy direktívának _kell_ lennie.

hogy ha az usernév számmal kezdődött, akkor azt autentikációkor UID-ként értelmezte a rendszer.

Ha túlléptünk azon, hogy POSIX, _technikailag_ egy 0NULfoobar (NUL a tényleges nulla értékű bájt) speciel egy snmpd -u paraméterét megakasztja és root-ként fog menni ;) [azt meg nem is említem, hogy ha compile-kor nincs getpwnam vagy pwd.h, akkor a 0pointer nemes egyszerűséggel uid=0 lesz ott is...]

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

> Oké, loop, melyiknek van prioritása, melyiknek van prioritása override-kor stb., lásd fenn. Egy direktívának _kell_ lennie.

Itt nincs override, én nem arról beszéltem, hogy az egyik direktíva userid-et ad, a másik username-t, hanem arról, hogy az egyik direktíva a user kulcs adatának típusáért felel, a másik pedig az értékéért. Nem ugyanazért felelnek, tehát nem override-olják egymást. Ha pedig arra gondolsz, hogy két ütköző unit file van és egyikben ez van, másikban az, akkor visszakérdezek, ha csak egy direktívád van, akkor mi a prioritás, mi fog override-olni mit? Mert csinálhatja ugyanezt akkor is, ha a típust külön direktívával határozod meg.

> Ha túlléptünk azon, hogy POSIX, _technikailag_ egy 0NULfoobar (NUL a tényleges nulla értékű bájt) speciel egy snmpd -u paraméterét megakasztja és root-ként fog menni ;) [azt meg nem is említem, hogy ha compile-kor nincs getpwnam vagy pwd.h, akkor a 0pointer nemes egyszerűséggel uid=0 lesz ott is...]

De bakker, akkor te ott szabályszerűen termináltad a stringet, ott nem arról beszélünk, hogy a string számmal kezdődik, hanem arról, hogy a string egy szám...

akkor mi a prioritás, mi fog override-olni mit?

Vendor-specific (/usr/lib/systemd/system/*.[unit-type]) < System-specific override (/etc/systemd/system/*.[unit-type]) < System-specific drop-in (/etc/systemd/system/FOO.[unit-type].d/*, lexikografikus sorrendben).

Ha override-olsz egy unit-ot, az abban levők lesznek érvényesek. Ha drop-innel felülbírálsz, akkor minden direktívánál a legutolsó előfordulás (értelemszerűen, ami nincs drop-inben felülbírálva, ott az eredeti unit fájlban szereplő érték) szerepel.

De bakker, akkor te ott szabályszerűen termináltad a stringet, ott nem arról beszélünk, hogy a string számmal kezdődik, hanem arról, hogy a string egy szám...

Oks, és ha nincs getpwnam, akkor kimarad a teljes ág és az strtoul visszatérési értéke azonnal uid lesz (szevasz K&R-féle miazahibakezeléslol hozzáállás). Ami 0pointerre... uid=0 lesz.
Ha gondolod, jelentsd náluk secu bugként, tied lehet a dicsőség a megtalálásáért, az oldalukon levő stable (5.8) verzióban még biztosan ott van.

Szerk.: sőt, rosszabb, ha nincs getpwnam, akkor _minden_ nem numerikus értékre 0 lesz, vagyis azt csinálja, amit fentebb a systemd-re láttatni akartál (root-ra fallbackel)...

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

> Vendor-specific (/usr/lib/systemd/system/*.[unit-type]) < System-specific override (/etc/systemd/system/*.[unit-type]) < System-specific drop-in (/etc/systemd/system/FOO.[unit-type].d/*, lexikografikus sorrendben).

Ha override-olsz egy unit-ot, az abban levők lesznek érvényesek. Ha drop-innel felülbírálsz, akkor minden direktívánál a legutolsó előfordulás (értelemszerűen, ami nincs drop-inben felülbírálva, ott az eredeti unit fájlban szereplő érték) szerepel.

A kérdésnek az volt a költői fele, a lényegi az volt, hogy amennyiben az adattípust egy külön direktívával adod meg, akkor mi gátol meg, hogy ugyanezt az override mechanizmust kövesd?

> Oks, és ha nincs getpwnam, akkor kimarad a teljes ág és az strtoul visszatérési értéke azonnal uid lesz (szevasz K&R-féle miazahibakezeléslol hozzáállás). Ami 0pointerre... uid=0 lesz.
> Ha gondolod, jelentsd náluk secu bugként, tied lehet a dicsőség a megtalálásáért, az oldalukon levő stable (5.8) verzióban még biztosan ott van.

A

system.c

1437. sorától kezdődő

int netsnmp_str_to_uid()

függvényre gondolsz?

int netsnmp_str_to_uid(const char *useroruid) {
    int uid;
#if HAVE_GETPWNAM && HAVE_PWD_H
    struct passwd *pwd;
#endif

    uid = atoi(useroruid);

    if (uid == 0) {
#if HAVE_GETPWNAM && HAVE_PWD_H
        pwd = getpwnam(useroruid);
        uid = pwd ? pwd->pw_uid : 0;
        endpwent();
#endif
        if (uid == 0)
            snmp_log(LOG_WARNING, "Can't identify user (%s).\n", useroruid);
    }
    return uid;
    
}

Ez a

0pointer

-ra, amennyiben nincs

getpwnam

, azt fogja csinálni, hogy kiszórja a logba, hogy

Can't identify user (0pointer).

ugyanis, ha az uid=0 akkor az invalid, tehát ezt hiába jelenteném secu bugnak, mert nem az.

> Szerk.: sőt, rosszabb, ha nincs getpwnam, akkor _minden_ nem numerikus értékre 0 lesz, vagyis azt csinálja, amit fentebb a systemd-re láttatni akartál (root-ra fallbackel)...

Alámszerkesztettél, ld. feljebb, ez sosem fallbackel root-ra, mert az uid 0 invalid. Nem tűnik fel a commentben felette, hogy

 * @return Either a user number > 0 or 0 if useroruid is not a valid user
 *   name, not a valid user number or the name of the root user.

Keress rá a használatra:

snmpSSHDomain.c:957

és

agentx_config.c:99

; mind a két esetben le van kezelve, hogy uid=0: error.

Azonfelül, ez egy tool; most komolyan ezt akarjuk ráhúzni az egész UNIX világra, hogy egy tool-ban is így van?

Nem, agent/snmpd.c


#if HAVE_UNISTD_H
        case 'u':
            if (optarg != NULL) {
                char           *ecp;
                int             uid;

                uid = strtoul(optarg, &ecp, 10);
#if HAVE_GETPWNAM && HAVE_PWD_H
                if (*ecp) {
                    struct passwd  *info;

                    info = getpwnam(optarg);
                    uid = info ? info->pw_uid : -1;
                    endpwent();
                }
#endif
                if (uid < 0) {
                    fprintf(stderr, "Bad user id: %s\n", optarg);
                    goto out;
                }
                netsnmp_ds_set_int(NETSNMP_DS_APPLICATION_ID, 
				   NETSNMP_DS_AGENT_USERID, uid);
            } else {
                usage(argv[0]);
            }
            break;
#endif

Te kértél csak egy példát. Adtam csak egy példát, hogy igen, a usernév-userid együttes kezelése (azt is megmagyaráztam, hogy miért _szükséges_) sok más helyen is szaros, pont ezért.

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

> Te kértél csak egy példát. Adtam csak egy példát, hogy igen, a usernév-userid együttes kezelése (azt is megmagyaráztam, hogy miért _szükséges_) sok más helyen is szaros, pont ezért.

Én egy UNIX-ot kértem, ami ezt csinálja, nem pedig egy tool-t; ezt akarjuk ráhúzni az egész UNIX világra, hogy egy tool-ban is így van? Ezt már az előbb is kérdeztem, csak nem válaszoltál rá. Nagyon nem mindegy, hogy egy opcionális tool csinál valami marhaságot, vagy pedig az az initrendszer, amit minden Linux "adaptált". Ezt "örökölte" meg a systemd?

Azonfelül nem válaszoltál arra kérdésre sem, hogy amennyiben az adattípust egy külön direktívával adnád meg egy systemd unit-ban, akkor mi gátol meg, hogy multi-unit file esetén ugyanazt az override mechanizmust kövesd, mint normál esetben? Csak mert ezzel preventálnád a bad revertet és nem törnél el semmit.

Én egy UNIX-ot kértem, ami ezt csinálja, nem pedig egy tool-t;

Könyörgöm, az egész UNIX a C-s gyökerek (mármint most éppen történetiség, nem a szerzői) miatt tele van ugyanezekkel a "jóleszazúgy" edge case-kkel. Biztos vagyok benne, hogy ha nagyon keresnénk, találnánk olyan "standard" tool-t is (btw, szerinted mi része egy UNIX-nak és mi nem?), ami megfelelően elcseszett felhasználónévre kiakad (ill. meg kéne kérdezni a Solaris fejlesztőit, hogy miért tették bele azt a figyelmeztetést, amit lentebb képernyőképen linkeltél)

Azonfelül nem válaszoltál arra kérdésre sem, hogy amennyiben az adattípust egy külön direktívával adnád meg egy systemd unit-ban, akkor mi gátol meg, hogy multi-unit file esetén ugyanazt az override mechanizmust kövesd, mint normál esetben?

És itt is, ha az user-dt nincs megadva, akkor ugyanúgy stringnek veszi az user tartalmát.
Ezzel nem törtél el semmit, kompatibilis maradtál mindennel, amivel csak akartál és még azt a fránya invalid-user-revertet is preventáltad.

Egyetlen gond, hogy nem, vagy ha igen, akkor nem változtattál semmit.
Melyik legyen a default? Feltehetően a string. Akkor aki eddig csakazértis 0day-t írt root helyett, annak eltörted a konfigját. Ha pedig uid, akkor _mindenkinek_ aki felhasználónevet használt [kb... mindenki] eltörted a konfigját.
Akkor legyen három érték: legacy, uid, string. A kérdés ugyanaz, melyik legyen az új default. Ha legacy, akkor nem javítottad pont a hibát, ha uid/string, akkor pedig ugyanott vagy, mint fent.

or textual form)

Erre van a getpwname hívás. Helló!

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

> Könyörgöm, az egész UNIX a C-s gyökerek (mármint most éppen történetiség, nem a szerzői) miatt tele van ugyanezekkel a "jóleszazúgy" edge case-kkel. Biztos vagyok benne, hogy ha nagyon keresnénk, találnánk olyan "standard" tool-t is (btw, szerinted mi része egy UNIX-nak és mi nem?), ami megfelelően elcseszett felhasználónévre kiakad (ill. meg kéne kérdezni a Solaris fejlesztőit, hogy miért tették bele azt a figyelmeztetést, amit lentebb képernyőképen linkeltél)

Lehet, hogy találnánk még ilyen tool-t, de itt az init rendszerről beszélünk (ami garantáltan része egy UNIX-nak), azért abban egy ilyen jellegű hiba jóval súlyosabb probléma. Nem mindegy, hogy az init csinál valamit, vagy egy sima tool. (A Solaris fejlesztői egyébként valószínűleg az ilyen módon megírt toolok miatt adták be ezt a warningot, de ez csak warning, nem block.)

Egyébként értem, hogy mire akarsz kilyukadni, csak a logikát nem látom mögötte: ha elismered, hogy a systemd féle megoldás szar, akkor miért próbálod mentegetni azzal, hogy ezt mások is csinálják? Az mentség, hogy a másik is?

> Egyetlen gond, hogy nem, vagy ha igen, akkor nem változtattál semmit.
> Melyik legyen a default? Feltehetően a string. Akkor aki eddig csakazértis 0day-t írt root helyett, annak eltörted a konfigját. Ha pedig uid, akkor _mindenkinek_ aki felhasználónevet használt [kb... mindenki] eltörted a konfigját.
> Akkor legyen három érték: legacy, uid, string. A kérdés ugyanaz, melyik legyen az új default. Ha legacy, akkor nem javítottad pont a hibát, ha uid/string, akkor pedig ugyanott vagy, mint fent.

Igazad van. Akkor azok, akik szándékosan abuzálták ezt a bugot-t és 0day-t írtak root helyett, azoknak a konfigja beyond repair. A többi problémát orvosolta. Fair enough. IMHO. De szólj, ha szerinted nem.

> Erre van a getpwname hívás. Helló!

Jogos, ezt benéztem. Késő van.

Egyébként értem, hogy mire akarsz kilyukadni, csak a logikát nem látom mögötte

A logika annyi, hogy sajnos van ez a hülye berögződés régről, hogy a usernév és a userid kölcsönösen egyértelműen megfeleltethetőek és mindkettő mindig képezhető a másikra (messze nem biztos - amíg /etc/passwd van csak, addig technikailag jogos), ami miatt van ez a régi beidegződés, hogy használható egy konfigurációs opcióként (hogy aztán kérnek-e mondjuk # prefixet, az más kérdés). Ugyanez a bug láthatóan ott van másik toolban. Akkor miért _csak_ a systemd-n kérjük számon, hogy egy alapvetően olyan rendszeren, ahol a legtöbb disztró nem warningol, hanem megtiltja a számmal kezdődő felhasználónevet a saját toolkészletében (lásd a NAME_REGEX, amit írtál), de legalábbis a doksiban ajánlott megkötéseket ír a usernévre (szintén Debian: It is usually recommended to only use usernames that begin with a lower case letter or an underscore). [btw, pl. a user slice-ok miatt szükség is van az uid-ekre, tehát az se működik, hogy simán az egyiket kivágjuk... most már :( ]

Ebből a szempontból szvsz. szerencsésebb a Windows-os kilométer hosszú SID-es megoldás, mert úgy legalább _senkiben_ fel sem merül, hogy egy belső ID-t használjunk a vele többé-kevésbé ekvivalens felhasználónév helyett.

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

> A logika annyi, hogy sajnos van ez a hülye berögződés régről, hogy a usernév és a userid kölcsönösen egyértelműen megfeleltethetőek és mindkettő mindig képezhető a másikra (messze nem biztos - amíg /etc/passwd van csak, addig technikailag jogos), ami miatt van ez a régi beidegződés, hogy használható egy konfigurációs opcióként (hogy aztán kérnek-e mondjuk # prefixet, az más kérdés). Ugyanez a bug láthatóan ott van másik toolban.

De ez nem egy univerzális gyakorlat. Még ha van is még egyéb tool - hangsúlyozom tool - ami elköveti ezt a hibát, ez akkor sem nevezhető általánosan elfogadott megkötelítésnek, még távolról sem. Már csak azért sem, mert eddig csak egy darab opcionális tool-t sikerült felmutatni, de olyan UNIX-ot, ahol a komplett rendszer, vagy legalább az init így viselkedett volna, olyat nem. Egyszóval ez egy hiba. Az valóban kiderült, hogy nem csak a systemd követi el...

> Akkor miért _csak_ a systemd-n kérjük számon, hogy egy alapvetően olyan rendszeren, ahol a legtöbb disztró nem warningol, hanem megtiltja a számmal kezdődő felhasználónevet a saját toolkészletében (lásd a NAME_REGEX, amit írtál), de legalábbis a doksiban ajánlott megkötéseket ír a usernévre (szintén Debian: It is usually recommended to only use usernames that begin with a lower case letter or an underscore). [btw, pl. a user slice-ok miatt szükség is van az uid-ekre, tehát az se működik, hogy simán az egyiket kivágjuk... most már :( ]

...de a systemd az, amit letoltak az egész Linuxos világ torkán, hogy márpedig ezt így kell csinálni, márpedig abban pont konszenzusra jutottunk, hogy ez egy fasság és nem így kell csinálni. Viszont a fejlesztője szerint ez egy feature és nem bug és így kell csinálni és punktum. Ez itt a nagy probléma. Tetszik érteni a nüansznyi különbséget? Egyrészt ezért kérjük számon ezt a bugot a systemd-n, mert az van piedesztálra állítva, hogy úgy kell init rendszert csinálni. Hogy? Szarul?

Ami a

NAME_REGEX

-et illeti: ez egy változó, ami ráadásul tool-specifikus. Csak az

adduser

foglalkozik vele, azonfelül, mivel változó, ezért, ha akarom, át is állítom. Ezt megkötésnek, vagy tiltásnak nevezni nagyon erős túlzás. Ahogy a többit is, amit felsoroltál; ezek javaslatok, nem tiltások. És itt térünk vissza megint a systemd-re, hogy miért van rajta számonkérve. Induljunk ki abból, hogy ezeket a javaslatokat azért teszik, mert van még pár ilyen tool, mint az

snmpd

, ami ezt a balfasz gyakorlatot követi. Ezt a problémát a tool-ok javítása helyett konvenciókkal kerülgetni szintén baromság, csakhogy feltételezhetően ezek régi, '80-as, '90-es évekből ittmaradt cuccok, történelmi okokból kifolyólag kissé nehézkes lenne a viselkedésük utólagos megváltoztatása. Viszont a systemd jelenkori cucc, aktívan fejlesztik és a viselkedése kb. hétről-hétre változik, így is mindennaposak a backward-compatibility-breakage-ek, tehát ezt simán lehetne orvosolni, pl. a fentebbi javaslatommal (csak az szívná meg, aki direkt abuzálta ezt a bugot és 0xyz nevekkel revertelt direkt a root-ra, de az meg úgy járt), de ehelyett csak simán WONTFIX és kész. Ezt is tetszik érteni? Ez a másik, amiért a bugot számonkérjük a systemd-n, mert ez egy jelenkori software, aminek a fejlesztői sokévtizede ismert és elkerülhető hibákat követnek el és nem hajlandóak őket fixálni.

A harmadik pedig, amiért számonkérjük, az az, hogy a systemd esetén ez csak egyike a temérdek problémának.

Ami pedig a "csak" kitételt illeti, mármint, hogy "csak a systemd-n kérjük számon", nos az meg egyszerűen nem igaz. Én egy szóval nem mondtam, hogy ha ezt másutt csinálják, az teljesen rendben van; éppen ellenkezőleg: én explicit kijelentettem, hogy "ez agyfasz. Akár a systemd szerzője találta ki, akár másutt volt először."

Azon felül az snmpd manualja azt írja, hogy:

-u UID 

Change to the user ID UID (which can be given in numerical or textual form) after opening listening sockets.

Tehát ott egyértelműen UID-et vár, nem pedig username-et, vagy UID-et! Ez így gizike-gőzeke, helló! Arról volt szó, hogy olyan példa kell, hogy vegyesen kezeli, úgy, hogy a numerikus prefix dönti el, hogy melyik. Úgyhogy bocs, de a példád invalid ebből a szempontból is.

"De ki a faszom kérte, hogy ezt húzzuk rá valamire, amire nem kell?" Ők, te húgyagygú, ők! Tudod, ők tervezték a Unix-ot, meg a B-t, amiből aztán lett a C-nyelv, úgyhogy lehet náluk panaszkodni, őket lehet hülyézni, hogy "demiért így?" - de mint írtam, Ken Thompson pont, hogy ezt így hagyná, és maximum a creat() függvény végére rakna egy e-t. Ja, és mindezt még bőven a posix nevű szabvány/előíráshalmaznak a kitalálása/összerakása előtt.

Idézet a Solaris 10-hez tartozó passwd manpage-ből: "The first character should be alphabetic and the field should contain at least one lower case alphabetic character. A warning message is displayed if these restrictions are not met."

> Ők, te húgyagygú, ők! Tudod, ők tervezték a Unix-ot, meg a B-t, amiből aztán lett a C-nyelv, úgyhogy lehet náluk panaszkodni, őket lehet hülyézni, hogy "demiért így?" - de mint írtam, Ken Thompson pont, hogy ezt így hagyná, és maximum a creat() függvény végére rakna egy e-t. Ja, és mindezt még bőven a posix nevű szabvány/előíráshalmaznak a kitalálása/összerakása előtt.

De ennek mi a fasz köze van a login autentikációnál az username értelmezéséhez? Arra mutassatok már egy példát, hogy melyik UNIX az, ami a számmal kezdődő userneveket UID-nek veszi. Ne csak dobálózzatok vele, hogy

atoi()

mutassatok egy UNIX-ot, ami rá is húzta a loginnevekre. Mondom azt is elfogadom, ha ez egy ősrégi UNIX, csak akkor meg ne gyertek azzal, hogy a systemd a jövő, ha egy sokévtizedes marhaságot másol...

> Idézet a Solaris 10-hez tartozó passwd manpage-ből: "The first character should be alphabetic and the field should contain at least one lower case alphabetic character. A warning message is displayed if these restrictions are not met."

Egyrészt: should be alphabetic != cannot be numeric

De ami még fontosabb: warning message != Revert to UID xxx

Ez egy slowaris 10 kézikönyvlap, korábbit nem találtam, a nyomtatott SystemV manpage készletem meg nem tudom, merre van :-/ Ugyanott, aholezt az idézetet találtam, meg is magyarázzák, hogy miért problémás a numerikus vagy számként értelmezhető usernév, illetve csoportnév.
A warning az a felhasnzáló létrehozásakor jön vissza (ott ugyanis explicit módon adott, hogy az adott karaktersorozat nem uid, hanem usernév), viszont ott, ahol az usernevet _is_, és az uid-et _is_ lehet használni, ott problémát okoz, illetve okozhat.

Hagyd, az előbb adtam neki egy 0dayt (legalábbis _pontosan_ ugyanabban az értelemben, mint amiben ez volt anno 0day...), de nem győzi meg :(
Pedig kb. ez volt a negyedik man page, amit megnyitottam, hogy melyik közismert démon fogad el usernevet és userid-et egy kapcsolóval/direktívával, ez volt az első, ami nem prefixel uid-et, és tádám, ott van benne pont ugyanaz a "bug".

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

> Hagyd, az előbb adtam neki egy 0dayt (legalábbis _pontosan_ ugyanabban az értelemben, mint amiben ez volt anno 0day...), de nem győzi meg :(

Bakker, legalább várd már meg, amíg válaszolok...

> Pedig kb. ez volt a negyedik man page, amit megnyitottam, hogy melyik közismert démon fogad el usernevet és userid-et egy kapcsolóval/direktívával, ez volt az első, ami nem prefixel uid-et, és tádám, ott van benne pont ugyanaz a "bug".

És csodák-csodája: nincs benne, mert ha uid=0, akkor error-t ad. Direkt becopyztam a forrást.

Ka a K&R rövidítés nem mindd neked semmit, akkor olvass utána, kicsoda Ken Thompson meg Dennis Ritchie. Mondom, némi informatikatörténeti alap nem árt, és talán némi szakmatörténeti olvasgatás után ez is kiderül, hogy miért úgy működik a bejelentkezés, ahogy.

Ja, Ken Thompson-t amikor megkérdezték, hogy mit csinálna másképp, ha újratervezné a Unix-ot, akkor annyit mondott, hogy a creat() végére odarakná az "e"-t. Szóval az atoi()-hoz pont nem nyúlna hozzá :-)

> Ka a K&R rövidítés nem mindd neked semmit, akkor olvass utána, kicsoda Ken Thompson meg Dennis Ritchie. Mondom, némi informatikatörténeti alap nem árt

Ez most komoly? Tudom, hogy mit takar ez a rövidítés, pontosan azért kérdeztem rá, hogy ezt most viccnek szánta-e, vagy sem. Miből szűrted le ezt a fasságot, hogy nem tudom? Ennyire hülyének nézel, hogy nem tudom, hogy ki Thompson, meg Ritchie? Vagy érvek híján már megint személyeskedsz? Burkolt lefaszozás után jön a burkolt lehülyézés?

> és talán némi szakmatörténeti olvasgatás után ez is kiderül, hogy miért úgy működik a bejelentkezés, ahogy.

Miért, hogy működik a bejelentkezés? Ha beírom a loginname helyére, egy non-systemd-infected rendszeren, hogy 0kecske, akkor root leszek? Ez most vicc?

root@Csabi:~# useradd 0kecske
root@Csabi:~# passwd 0kecske
Adja meg az új UNIX jelszót:
Írja be újra a UNIX jelszót:
passwd: a jelszó sikeresen frissült
root@Csabi:~# usermod --shell /bin/bash 0kecske
root@Csabi:~# su 0kecske
0kecske@Csabi:/root$ exit
exit
root@Csabi:~# userdel 0kecske
root@Csabi:~#

Én nem ezt tapasztaltam.

És akkor mit csinálsz a broken rendszerrel? Nem tud bebootolni, nem tudsz rá bejelentkezni. Vagy megint lehet

init=/bin/sh

, de az meg pontosan ugyanaz, mintha bármit elfogadott volna root passwordnek és adott volna egy root shellt, akkor most mennyivel vagyunk előrébb? A GRUB lejelszavazása pont ebben az esetben nem játszik, hiszen ha a root password-öt nem állították be, akkor miért pont a GRUB jelszót állították volna be?

> hiszen ha a root password-öt nem állították be, akkor miért pont a GRUB jelszót állították volna be?

Azert ne ugy tervezzunk mar operacios rendszereket, hogy szandekosan a security-analfabetakat varunk uzemeltetonek. A systemd nem tudja, van-e GRUB jelszo, ugyhogy legyen az a feltetelezes, hogy a rendszert egy szakerto telepitette eles kornyezetben, es opcionalisan ezen lazitsunk, ne forditva.

> Azert ne ugy tervezzunk mar operacios rendszereket, hogy szandekosan a security-analfabetakat varunk uzemeltetonek.

Akkor a windowsnál miért csinálják? :]

> A systemd nem tudja, van-e GRUB jelszo, ugyhogy legyen az a feltetelezes, hogy a rendszert egy szakerto telepitette eles kornyezetben, es opcionalisan ezen lazitsunk, ne forditva.

Körbe-körbe futunk. Ha nem írtam le hússzor, hogy felőlem kérjen root password-öt, csak engedjen választani utána és had döntsem el én, hogy mit szeretnék, akkor egyszer sem.

Jelszót csak attól az usertől fogadhat el, aki nincs zárolva, és akinek egyáltalán van jelszava. A raspbian default telepítésnél a root zárolt, és nincs jelszava. De ezt már leírtam korábban is. Egy bejelentkezésre nem engedélyezett, jelszóval nem rendelkező usert hogyan azonosítson a rendszer? Na hogyan? A poszt-toló pont azzal szívta meg, hogy nincs/nem volt a rendszerben olyan user, amely megfelelt volna az uid=0, van jelszava, nincs zárolva feltételeknek.

De azt, hogy te vagy a rendszer tulajdonosa (vagy annak egy megbízottja) igazolod azzal, hogy beírod a root jelszót.

De egyébként az igény jogos, szerintem dobj egy feature requestet Pöetteringnek, már így is akkora bloat a systemd, hogy a systemd-playgroundcomputerd komponens nem oszt nem szoroz, és akkor egy playgroundcomputerctl --set yes -el beállíthatod, hogy ha bármi hiba van boot közben (pl. egy NFS kiszolgáló nem érhető el), akkor azonnal adjon egy root nevében futó shellt :) [bár erős a gyanúm, hogy ilyen hülye biztonságtudatosság bulllshitre hivatkozva tuti default off-al szállítaná az összes disztró :( ]

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

#define nem_kritikus_mount - ja, hogy ilyen nincs, csak annyi, hogy "nem tudtam felhúzni a könyvtárat, de megyünk tovább, aztán vagy belerohad valami, vagy nem" - Nem tudom, hogy vagy vele, de nekem az az elvárásom, hogy ha a rendszer elindul, normál futási szintre eljut, akkor ott a beállított adatterületek álljanak rendelkezésre, mert azért vannak beállítva az fstab-ban boot során felcsatolandóként.

Ahhoz hogy egy szerencsetlen login promptot kapj a rendszeredhez, boven elegendo kell legyen a /bin, /lib, /etc meg az /sbin jelenlete. Pont ez a lenyege annak hogy a javak nagy resze az /usr/bin, /usr/sbin ala kerulhet: hogyha az /usr valami miatt nem jonne fel, akkoris legalabb ra tudsz pislantani a rendszeredre hogy mi a wtf van. Igen, akkor nem tudsz kiscicas videot lejatszani meg midnight commanderezni, de legalabb van promptod meg netkapcsolatod.

> #define nem_kritikus_mount - ja, hogy ilyen nincs, csak annyi, hogy "nem tudtam felhúzni a könyvtárat, de megyünk tovább, aztán vagy belerohad valami, vagy nem"

#define nem_kritikus_mount szájbakúrt_adatkönyvtár|bármi_ami_nem_kell_ahhoz_hogy_a_rendszer_felálljon

Úgyhogy de: van ilyen.

> Nem tudom, hogy vagy vele, de nekem az az elvárásom, hogy ha a rendszer elindul, normál futási szintre eljut, akkor ott a beállított adatterületek álljanak rendelkezésre, mert azért vannak beállítva az fstab-ban boot során felcsatolandóként.

Nem értek egyet: ha lereportolja, hogy gáz van és megkérdi, hogy mi legyen, akkor ugyanott vagy, hogy kaphatsz egy root shellt javításra, ha annyira akarod, de úgy legalább lehetőség van arra is, hogy a hiányzó mountot leszarhasd és mehess tovább. Ha pl. a családi fotóknak/videóknak beraksz egy nagyobb HDD-t és átmásolsz rá mindent, de az fstabban elfelejted az UUID-et átállítani, akkor mégis mi van, ha felkel nélküle a következő bootkor? Semmi. Észreveszed és kijavítod az fstabot, amikor épp ráérsz. Ezzel szemben, ha lehetőséged sincs skippelni, akkor kurwára fogsz örülni, hogy egy adott céges vagy akármilyen vészhelyzetben, amikor kurwára kellene a géped és amikor minden másodperc számít és a kutyát nem érdekli, hogy fel tudja-e csatolni a családi fotókat/videókat tartalmazó meghajtót, akkor baszakodhatsz azzal, hogy előbb átírd az UUID-et és rebootolj.

Tehát hogyan döntse el a boot folyamat, hogy adott hiba csak warning, nem valamilyen vital component működését veszélyezteti? A "bármi_ami_nem_kell_ahhoz_hogy_a_rendszer_felálljon", mint "nem kritikus" definíciója eléggé laza, és messze nem határozza meg tételesen, hogy az fstab mely bejegyzéseit lehet skippelni, és melyikekre van mindenképp szükség.
Ha nem fontos, akkor noauto, és kézzel, vagy első meghivatkozáskor (automounter) csattanjon fel az adott terület, ahogy az anno ki lett találva, nagyon helyesen. De azt is megteheted, hogy noauto, és rc.local vagy hasonló poton csinálsz egy jól irányzott mount-ot.

Azt hiszem nem érted, mi a bajom: kérdezze meg az épp ott álló fasztól, hogy mi legyen és ne döntögessen semmit. Ne döntsön se pro, se kontra. Nem tisztje eldönteni, hogy mi fontos, vagy mi nem, döntse el a júzer, mert ő tudja, nem az init rendszer. És nem, ne root shellt adjon neki.

Az épp ott álló TCH-tól egy dolgot kérdezhet: a nem zárolt uid=0 felhasználó jelszavát, és ha azt tudja, akkor már dönthet a továbbiakról. Attól, ugyanis, hogy ott meredezel a raspi mellett, még nem garantált, hogy jogosult vagy a rendszerhibára érdemben reagálni.
"ne root shellt adjon neki" - minthogy a hiba elhárításához uid=0 processzt kell indítani, így nem igazán van más módszer, mint egy olyan shell-t adni, ami ilyen joggal fut - ha van ilyen, bejelentkezésre jogosult user, és az ott álló TCH ennek a felhasználónak ismeri a jelszavát.

Vicces egyebkent mert mindekozben van egy ilyen hisztije is a potterixnek ezen az rpi + raspbian rendszeren:

[FAILED] Failed to start Create Volatile Files and Directories.
See 'systemctl status systemd-tmpfiles-setup.service' for details.

Jul 13 18:18:43 raspberrypi systemd[1]: Starting Create Volatile Files and Directories...
Jul 13 18:18:43 raspberrypi systemd-tmpfiles[248]: rm_rf(/var/lib/sudo/ts): Read-only file system
Jul 13 18:18:43 raspberrypi systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE
Jul 13 18:18:43 raspberrypi systemd[1]: Failed to start Create Volatile Files and Directories.

Mondom pesze, mert a teljes rendszer full readonly-kent jon fel. Na, erdekes, ez is ilyen uber-piros betukkel kiirt "FAILED" basz, de ettol erdekesmodon nemhogy teljes rendszerosszeomlas nem kovetkezik be, meg nem ker sulogin-t, hanem csak ugy siman tovabbmegy mintha mise' tortent voln.

Nem, nem keresek ebben logikat. Merthogy:
- a /data nem elerheto: osszeomlas + sulogin
- a /var/log alatt valami nem szazas: jaja, fasza, mehetunk tovabb!

Speciel még tud is ilyet a systemd :)

nofail

With nofail, this mount will be only wanted, not required, by local-fs.target or remote-fs.target. Moreover the mount unit is not ordered before these target units. This means that the boot will continue without waiting for the mount unit and regardless whether the mount point can be mounted successfully.

(https://www.freedesktop.org/software/systemd/man/systemd.mount.html)

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

De, a systemd tudja, lásd az összes, a unitok függőségeire/sorrendjére vonatkozó részt... (pl. ha a /var/www/-t nem tudod mountolni, attól még a rendszer feláll, de ha az httpd-nek megadod függőségként, akkor nem fogja ráindítani az üres FS-re)

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

Hát, ez szerintem nagyon mellément, én a csomagfüggőségekről beszéltem, a topicnyitónak volt boot-baja. (És a fő baj nem az volt, hogy a root account zárolva van, annak valóban semmi köze a systemd-hez, hanem az, hogy egy nem kritikus mountpoint hiánya miatt összedőlt az egész. Nyilván, ha az fstab teljesen el van baszva, annyira, hogy nem lehet értelmezni, az SysVInit alatt is halál, de itt az fstab intakt volt, csak hiányzott a célkönyvtár. Egyébként SysVInit alatt még a rossz UUID-ekbe sem hal bele, csak skippeli az entry-t. Kivéve persze, ha rendszerkritikus volt a bejegyzés, akkor az is összedől, de amúgy nem.)

"egy nem kritikus mountpoint hiánya miatt összedőlt az egész" - ahogy egyéb esetben is, ha az fstab-ban lévő dolgokat nem tudja felhúzni, akkor root beavatkozást kér, és ahhoz jelszóval rendelkező, nem zárolt root felhasználóra van szükség. És ez bizony jobb, mintha részlegesen összerakott fs-sel felmegyünk 1-es futási szint fölé.

Bootnál? Arról, hogy bebootoljon? Éles szerveren ha ilyen előfordul - mármint, hogy bullcrap van az fstabban - akkor ott úgyis nagyon masszív elkúrás-kaszkád van, tehát ott úgyis a rendszergazda fog ott állni a bootoló gép mellett. Az otthoni/munka desktop gépeken meg hóttmindegy ki tud rányomni arra, hogy skip.

A gond ott lehet hogy nincs rendes fuggoseg-kezeles itten. Ilyen szintu sulogin-nel "normalis esetben" akkor talalkozik az ember amikor mondjuk a bootloaderben szarul konfiguralsz fel egy raid-et. Vagy nincs mdadm-od a rootfs-ben es/vagy md.ko-d az initramfs-ben. Na, akkor az panik, es mehet a sulogin es/vagy init=/bin/sh hogy tessek javitani. De az hogy az osszes mountpoint egy kalap ala van veve es egy olyan reszfolyamat baszodik el aminek nincs fuggosege? Ja! Hogy megsincs egy kalap ala veve:


[  OK  ] Reached target Local File Systems (Pre).
         Mounting /var/log...
         Mounting /tmp...
         Starting udev Coldplug all Devices...
[  OK  ] Mounted /tmp.
[  OK  ] Mounted /var/log.

Erdekes, barhonnan is nezzuk.

Kiveszed az elsődleges kártyát
Ra van forrasztva :) De persze, sodimm-modul kivetellel majd OTG-boot bekapcsolasaval gyorsan ment a javitas (mount /dev/sdx2 /mnt && mkdir /mnt/data && umount /mnt).

Mondjuk "a soros konzol beizzitasa potterix alatt" is egy elmeny volt:
- elso talalat: oh, csak a kernel cmdline-ban kell engedelyezni, es akkor a potterix intelligens es elinditja (gyakorlatban: a lofaszt indit el, termszetesen)
- masodik: systemctl enable serial.console @ getty.ttyAMA0.blabla [...] (gyakorlatban: ez persze enable allapotban van, mit akarok?)
- es akkor kis turas utan: valami `systemctl unmask ...` kellett. Es azota megy.
Na, erre mondanam azt amit itten feljebb a kollega hogy "tudni kell haladni a technologiaval". Mert oke hogy egy odvas szopas de legalabb le van irva (valamelyik internet-bugyorba) es valamennyire(?) talan(?) kovetkezetes(?) is.

Nade hogy az allow-hotplug mi a kenkoves banatert nem megy az USB-s Ethernet adapterrel mikor az altalam raforrasztott MCP251x-es CAN interface-szel meg megy (olyannyira hogy meg "laborkorulmenyek" kozott meg tenyleg hotplug is volt, maramennyire a SPI + modprobe egyutt az lehet), az egy rejtely. Igazabol csak ezzel tobb idot csesztem el mint minden mas rpi + potterixszel egyuttveve, de mar asszem kezdem elengedni :/ Annyit nem er :)

Jaja, az. A biztonsag kedveert azert osszeomlasztom igyis a rendszert, kivancsi vagyok mi lesz akkor a reakcio.

[...]

Igy valoban atment full-featured single user-modba. Szoval azon kivul hogy emergency-ben volt a potterix, tokeletesenen mukodik a rendszer, tokkal-vonoval-zubehorokkel. Szoval igen, egy elmeny ez az egesz!

en ilyenkor mindig ranezek az openrc projectre. Most is vagy fel orat olvasgattam a commitokat es az issueket

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

systemd.unit=rescue.target
--
"Sose a gép a hülye."

biztos ez volt a problema?

az en szemet systemdm manualjaban (systemd.mount(5)) ez all: "If the mount point does not exist at the time of mounting, it is created."
kiprobaltam es tenyleg igy mukodik, de tudom, tudom, ne dontse mar el helyetted, hogy csinalsz e mountpointot vagy sem.

Nem tönkrement, hanem a felhasználó által elszúrt beállítású motyó. És inkább ez legyen, mint egy, a boot során fellépő hiba esetén használható általános módszer root jogosultságot igénylő döntésre. Mert ha van ilyen, az támadható. Nem véletlen, hogy a rapbian így van összerakva, csak ezt te nem akarod/tudod felfogni.

Persze az init bootkori átírásával javítható, nesze neked security. Te nem akarod felfogni, hogy lehet a secure beállítás opt-out is. Nyugodtan lehetne olyan opció benne, hogy ha nem tudta mountolni, akkor kérjen/ne kérjen password-öt a skiphez. Egyébként meg kezd már kissé elmenni komolytalanba a dolog, mert komoly rendszeren, éles szerveren még csak-csak elő lehet jönni a security/nemjátszósgép dumával, de a RPi/Raspbian az kb. deklaráltan játszós cucc...

A GRUB jelszavazása valóban hiányzik a teljes biztonsághoz, illetve ezen felül még a / fájlrendszer cryptofs-re rakása is, ebben igazad van. De attól, hogy n darab lehetőségből kettő még ott van, attól az, hogy n-2 rendesen be van állítva, teljesen rendben van. Lehetne eszed is, meg felfogóképességed, hogy a raspbian-t nem így csinálták meg - de nincs :-P Csinálj egy saját tchbian disztrót fail-open inittel (Hint: raspbian-ban tedd defaulttá a jelszó nélküli root usert és/vagy a telepítőbe hegeszd bele, hogy kötelezően legyen jelszava a root-nak), és máris lesz egy számodra megfelelő raspi-s rendszer - amit persze nem lesz célszerű otthagyni úgy, hogy másnak fizikai hozzáférése lehessen, hiszen a root userrel konzolról szépen lehet próbálkozni...
A raspi szerinted játszós cucc - más szerint meg mondjuk egy kirakott display-t hajt meg ügyféltérben, vagy épp adatgyűjtést csinál, vagy épp vezérlési feladatai vannak - Nem véletlen, hogy egy rakat gpio lába van neki, amit -talán meglep téged, de sokan, sokhelyen használnak is.

Neked nincsen eszed, ha csak személyeskedni tudsz. Ötvenszer lefutottuk már ezt a kört, de még mindig nem tudod felfogni, miről beszélek. A GPIO meg nem lep meg, előző melóhelyen az volt a munkám, hogy arra épülő cuccokat programozzak, de ugye te megint csak személyeskedni bírsz, érvek híján. Inkább erre a posztra válaszolj, hogy a fene nagy biztonságoskodás közepette, hogy bírsz ekkora systemd fan lenni, miközben ezer sebből vérzik.

Lehet_ne_ olyan is a raspbian, amilyet te elképzelsz, de te nem tudod felfogni, hogy a raspbian nem olyan, ahogy te elképzeled, mert annak, aki összerakta, az veled ellentétben a fail-safe irányt tartja elfogadhatónak, nem a fail-open-t.

Az username nem kezdődhet számmal téma jelen szempontból nem releváns, ha nagyon fáj, akkor indíts róla szavazást/blogbejegyzést, hogy szerinted a Unix eredeti tervezői ebben (is) idióta f@szok voltak.

Szóval mit csonáljon egy fail-safe alapon tervezett init rendszer (a boot folyamat, vagy a diszk közvetlen kiszedése és az adatok ilyen módon történő elérhetősége nem scope), ha a root usernek nincs jelszava, és emiatt le van tiltva? Hogyan kezelje fail-safe módon a boot során felmerülő hibát _fail-safe_ módon?

Erre is válaszoltam, erre sem válaszoltál.

Ne hazudj, én nem állítottam, hogy a UNIX eredeti tervezői faszok voltak. Ti állítottátok (hamisan), hogy ők találták ki ezt az agyfasz UID<=>username megfeleltetést, merthogy a C-ben van string=>integer konverter függvény, akkor tuti, hogy ők felelnek ezért is (OMG), de ezidáig egyetlen UNIX-ot nem tudtatok mutatni, ahol ez rendszerszinten így lett volna, csak egy tool-t. Te nem tudsz mást, mint személyeskedni, meg szavakat adni a másik szájába, hogy véletlenül se kelljen a lényegre reagálni, mert akkor még kiderülne, hogy valid érveid nincsenek?

Miért, a rendszert úgy hogy javítsa meg, ha "a boot folyamat, vagy a diszk közvetlen kiszedése és az adatok ilyen módon történő elérhetősége nem scope"? Olyan gusztustalan kettős mércével mérsz, hogy nem lehet leírni. Egyébként meg két poszttal feljebb válaszoltam erre, hogy lehetne a rendszerben ilyen opció, de véletlenül pont arra a részre nem bírtál érdemben reagálni, csak hárítani, hogy de nem így működik, meg személyeskedni. Értsd: mondjak megoldást, de ha mondok, akkor hülye vagyok, mert nem ez van benne, miközben a kérdés az, hogy hogyan lehetne. ROFL.

A válaszod mellébeszélés volt, mert a kérdésre, miszerint "Szóval mit csonáljon egy fail-safe alapon tervezett init rendszer (a boot folyamat, vagy a diszk közvetlen kiszedése és az adatok ilyen módon történő elérhetősége nem scope), ha a root usernek nincs jelszava, és emiatt le van tiltva? Hogyan kezelje fail-safe módon a boot során felmerülő hibát _fail-safe_ módon?" nem azt írtad le, hogy mit csináljon, hanem azt, hogy "Tehát amire a többség szavaz, az a helyes, meg az a jó? A többségnek mindig igaza van? Együnk tehénszart? Már megint?"
Tehát szerinted a fail-safe az tehénszar. Gratulálok.

Te írtad: "Persze az init bootkori átírásával javítható, nesze neked security. Te nem akarod felfogni, hogy lehet a secure beállítás opt-out is."

Igen, b+ lehetne - de ott, ahol a fail-safe az alapelv, ott nem az - ahogy a raspbian-nál sem. Erre egyébként válaszoltam: "De attól, hogy n darab lehetőségből kettő még ott van, attól az, hogy n-2 rendesen be van állítva, teljesen rendben van."

Szóval Mit csináljon az init (bsd, sysv, akármi, systemd) akkor, amikor fail-safe az alapvetés, és nincs elérhető (jelszóval rendelkező, nem zárolt) uid=0 user, és a boot során hiba történik?

Erre még explicit és elfogadható válaszod nem volt - jó lenne, ha erre válaszolnál.
Írhatod azt is, hogy a fail-safe en bloc baromság, és a takinéni is nyomhasson egy enter-t, sőt nem is, sz@rja le az init, hogy egy mount sikertelen, vagy egy szolgáltatás nem bír elindulni - majd jön a rendszergazdabéla, meg sudo, aztán jól rendberakja. Nos?

Én nem ezt írtam, csak már megint képtelen vagy értelmezni az olvasottakat.

Többször leírtam, hogy a következő beállítások lehessenek, failed mount-kor: just skip, ask password for skip, ask password for shell. Amennyiben a root felhasználó zárolva van és password-required beállítás van, arra is válaszoltam, hogy az szívás. Leírtam, explicit, de te megkérdezed újra és újra. Mit nem értesz?

A "just skip, ask password for skip, ask password for shell" közül az első nem fail-safe, tehát rossz válasz. A másik kettő megint rossz válasz, hiszen a root user, más, szintén security okból, zárolt, jelszóval nem rendelkezik, tehát nem használható, hiszen nincs jelszó hash, amihez hasonlítani lehtene a beírt jelszót, ergo igen, szívás, nincs rajta mit vitatkozni.
Viszont ezért nem a systemd-t kell szidni, merthogy normálisan, fail-safe módon összerakott tetszőleges init esetén ez van: ha nincs root jogú usered, aki be tud lépni, akkor szopóág.

Tehát szerinted az a válasz, hogy nincs jó válasz? Így mi értelme vitatkozni, ha direkt úgy izzadod ki a kérdéseidet, hogy ne lehessen rájuk általad elfogadható választ adni? Egyébként meg nem igaz amit írsz, mert itt jön képbe, hogy a fail-safe az jó ha van, de az nem jó, ha kötelező. Ez igazán nem a világ, hogy legyen egy mezei unauth opció is, amit a rendszergazda engedélyezhet, ha nem kritikus a gép.

A második felében ugyan igazad van, csak azt basztad el, hogy rossz embernek írtad, mert azt én is mindjárt a legelején leszögeztem, hogy a rootpass hiánya nem a systemd hibája. (És már ott is eltévesztetted a házszámot, meg a kommentet...)

" legyen egy mezei unauth opció is, amit a rendszergazda engedélyezhet, ha nem kritikus a gép" - tessék feldobi a raspbian készítőinél feature request-ként - egyébként meg lehet fail-open-re is konfigurálni a raspbian-t is, csak nem szokás - a köztes állapotra meg egy sudo passwd tökéletes megoldást ad :-)

> a köztes állapotra meg egy sudo passwd tökéletes megoldást ad :-)

Ja, csak te végig ezen lovagoltál, hogy ez nem történt meg, nincs root, mert az zárolva van, mert csak. Ezidáig végig ezzel nyaggattál, hogy de arra adjak választ, hogy de úgy oldjam meg, hogy nincs root. Most meg hirtelen megoldássá lép elő, hogy van root... Egy a jelszó, kettős mérce, állj közénk és harcolj érte!

A poszt arról szól, hogy zárolt root, nincs jelszava, és el van keffintve az fstab. Erre jött az, hogy systemd szr@r, és hogy miért nem ad lehetőséget arra, hogy a user döntsön, mi legyen. Azért nem, mert by design ha nincs valid root user és neki jelszava, akkor nincs, "amihez képest" authnetikációs adatot kérjen/ellenőrizzen. Te azon lovagoltál, hogy de miért nem engedi meg az arra ténfergő akárkinek ilyenkor, hogy döntsön, miért nem ad választási lehetőséget adott állapotban is. Sokadik körben csak leírtad, hogy ez valóban szívás, és végül implicit módon elismerted, hogy ez bizony pebkac, nem az init rendszer hibája, még ha nehezen is ment...

Ha _nincs_ root, akkor nincs mihez képest felhasználói interakciót kérni, ergo ezt megelőzendő még működő rendszeren, előre gondolkodva kell a root-nak jelszót adni, hogy a zárolt állapotból kihozva, később ne jelentsen problémát a boot-folyamat rendszergazdai beavatkozást igénylő megakadása.

> A poszt arról szól, hogy zárolt root, nincs jelszava, és el van keffintve az fstab. Erre jött az, hogy systemd szr@r, és hogy miért nem ad lehetőséget arra, hogy a user döntsön, mi legyen.

A systemd szar, hiába próbálod megmagyarázni, hogy nem az; már tavaly is próbáltad, de akkor sem sikerült.

> Azért nem, mert by design ha nincs valid root user és neki jelszava, akkor nincs, "amihez képest" authnetikációs adatot kérjen/ellenőrizzen. Te azon lovagoltál, hogy de miért nem engedi meg az arra ténfergő akárkinek ilyenkor, hogy döntsön, miért nem ad választási lehetőséget adott állapotban is.

Nem, én a lehetőség beállíthatóságát hiányoltam.

> Sokadik körben csak leírtad, hogy ez valóban szívás, és végül implicit módon elismerted, hogy ez bizony pebkac, nem az init rendszer hibája, még ha nehezen is ment...

Ez meg aztán csúsztatás a javából; mint már leírtam - és belinkeltem - egy feljebbi posztban, én mindjárt az elején leszögeztem, hogy ez nem a systemd sara volt, ráadásul már akkor is rossz posztra sikerült reagálnod.

> Ha _nincs_ root, akkor nincs mihez képest felhasználói interakciót kérni, ergo ezt megelőzendő még működő rendszeren, előre gondolkodva kell a root-nak jelszót adni, hogy a zárolt állapotból kihozva, később ne jelentsen problémát a boot-folyamat rendszergazdai beavatkozást igénylő megakadása.

Értem, tehát ha én mondom, hogy kínálja fel a "skip with password" opciót, akkor az nem, mert olyankor nincs root, mert ne legyen, ha meg te rakod össze, akkor meg

sudo passwd

és minden meg van oldva. Ez ilyen systemd-s logika lehet.

Szerinted a systemd sz@r. Amott hasonló magvas és saját tapasztalattal/szakmai véleménnyel alátámasztott (ja nem) kérdésedre írtam: "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." - és ezt tartom most is.

"Nem, én a lehetőség beállíthatóságát hiányoltam." A választási lehetőség nem ekkor van, hanem akkor, amikor az r=1 user telepít, és vagy ad a rootnak jelszót ((egyben unlock), vagy sem. Ha ad, akkor a boot megrottyanásakor van választási lehetősége, ha nem ad, akkor nincs.

"Értem, tehát ha én mondom, hogy kínálja fel a "skip with password" opciót, akkor az nem, mert olyankor nincs root" - nem érted - vagy nem akarod érteni. Az adott probléma onnan indult, hogy a raspbian-on default telepítésben a root-nak nincs jelszava (lockolt). Ezt rakta össze a raspbian "alkotója". Ha az, aki telepíti, ezzel -és ennek a következményeivel, lásd indító poszt- együtt tud élni, akkor nincs feladata, használhatja úgy. Ha viszont gondot okozha a boot lerohadása, akkor adjon a rootnak egy k. jelszót a telepítés/hasnzálatba vétel után, és meg van oldva a probléma - aztán amikor kimegy production-be mondjuk az ügyféltérben lévő tévé mellé sorszám/menetrend/reklámmutogató eszköznek, akkor meg lehet visszazárolni a root-ot, hogy kevésbé legyen törhető az eszköz. Mondom kevésbé, nem azt, hogy egyáltalán nem.

> Amott hasonló magvas és saját tapasztalattal/szakmai véleménnyel alátámasztott (ja nem) kérdésedre írtam:

Már megint csak személyeskedésre futja érvek helyett? Mondjuk érveid eddig se nagyon voltak, csak beszólásaid, meg abszurd, alá nem támasztott konklúzióid, meg lelkesen +1-eztél, ha SzBlackY írt valamit. A fail-safe root-ban van némi igazságod ugyan, de azt meg mint kitárgyaltuk, független az init rendszertől, tehát a systemd-t eddig nem igazán sikerült megvédeni...

> "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." - és ezt tartom most is.

Én meg erre írtam, hogy "ez így tényleg a megtértek hitbuzgóságára hajaz", csak válaszolni nem sikerült rá.

> "Értem, tehát ha én mondom, hogy kínálja fel a "skip with password" opciót, akkor az nem, mert olyankor nincs root" - nem érted - vagy nem akarod érteni. Az adott probléma onnan indult, hogy a raspbian-on default telepítésben a root-nak nincs jelszava (lockolt). Ezt rakta össze a raspbian "alkotója". Ha az, aki telepíti, ezzel -és ennek a következményeivel, lásd indító poszt- együtt tud élni, akkor nincs feladata, használhatja úgy. Ha viszont gondot okozha a boot lerohadása, akkor adjon a rootnak egy k. jelszót a telepítés/hasnzálatba vétel után, és meg van oldva a probléma - aztán amikor kimegy production-be mondjuk az ügyféltérben lévő tévé mellé sorszám/menetrend/reklámmutogató eszköznek, akkor meg lehet visszazárolni a root-ot, hogy kevésbé legyen törhető az eszköz. Mondom kevésbé, nem azt, hogy egyáltalán nem.

Mondhatnám én is, hogy nem érted, vagy nem akarod érteni: ha én mondom, hogy legyen "skip with password", akkor miért az a duma, hogy de a root az default zárolva van, egyébként meg miért

sudo passwd

és el van intézve?

Nem megtértek hitbuzgósága, hanem azoknak a véleményét osztom, akik a problémák mellett az előnyeit is látják, és használják. Tudom, binugzos körben még a sysvinit-es futási szinteket sem nagyon használták rendesen - hogy a "mert minek", vagy a "mert nem értem" okból, az jó kérdés.

"ha én mondom, hogy legyen "skip with password", akkor miért az a duma, hogy de a root az default zárolva van," - Mert itt és most a raspbian default telepítéséről van szó, ahol ez a helyzet. Azaz nincs olyan jelszó, amivel lehetne ellenőrizni, hogy aki a billentyűket nyomkodja, az Gizike, gőzeke, vagy rootjogúvérpistike. Neked kéne olyan, hogy ne root shell-t adjon hiba esetén az init rendszer a root jelszó bekérése után, hanem automatikusan mellőzze a felmerült hibát. Mindet. Is. Mert ha belegondolsz, az összes, automatikusan nem kezelt hibaág ugyanoda fut: (ha van jelszavas, nem lockolt root usered), root jelszó és shell, amiben kikalapálhatod, továbblökheted a bootot, satöbbi. Nomostan gondolj bele, hogy valamennyi hibaállapotra(!) meg kellene oldani a hiba figyelmen kívül hagyását, illetve az ahhoz szükséges lépséeket tudnia kéne az initnek. De pont az a helyzet, higy automatikusan nem skippelhető hiba esetén esik ki ide a boot folyamat...

Ezt nem győzöm elégszer ismételni: egy érv a SysVInit ellen még nem érv a systemd mellett, amikor egy tonna egyéb initrendszer van még kettejükön kívül. Előnyök? Egyet mondj a timereken kívül. Tavaly ezt is végigveséztük SzBlackY-val, de a végére a timereken kívül semmi nem maradt az előnyökből, amikkel viszont jön a messze több hátrány.

Egyáltalán nem arról volt szó, hogy minden hibát mellőzzön, hanem a nem kritikus felcsatolási hibákat. Hogy mi a nem kritikus? Na, ezt dönti el a júzer, amikor válaszol a skip vagy shell kérdésre. És ezen felül nem csak a Raspbian default telepítéséről volt szó. A topikindító valóban arról beszélt, de én nem, már a legelején sem, én általánosságban beszéltem, dehát ha eddig tízszer nem írtam le, hogy már a legelején rossz embernek reply-ztél, akkor egyszer sem...

A hsz.-ban hol emeltem ki, hogy systemd/sysvinit/akármiről van szó? Sehol. Normális, fail-safe esetben ha nincs elérhető root usered, akkor ugyanígy mexívtad. Nekem pl. előny a systemd-s unitokban az, hogy komplex függőségeket lehet bennük értelmesen, egységesen kezelni. Nem, a sysvinitre gányolt scripthalmazok, amikben csillió+1 helyen van ugyanaz, vagy majdnem ugyanaz megvalósítva, az messze nem ilyen - pláne a Linuxos környezetben, ahol a sysvinit-es futási szintek értelmes használatát is mellőzi mindenki - pedig baromi jól lehet(ett) velük a boot folyamat "eredményét" szabályozni. Ezt mondjuk hiányolom a systemd-ből, de enélkül lehet élni (hiszen a sysvinit-es Linuxok is élnek valahoy...). Azt viszont, hogy user/group/umask/függőségek/szolgáltatásállapotok rendesen és egyszerűen kezelhetők a unit-fájlokkal, az kifejezett előny.

"nem arról volt szó, hogy minden hibát mellőzzön, hanem a nem kritikus felcsatolási hibákat" - Minden hiba esetén, amit automatice nem tud kezelni ugyanoda esik ki a folyamat, tehát ugyanott kell kezelni az összeset, egyformán.

"Hogy mi a nem kritikus? Na, ezt dönti el a júzer, amikor válaszol a skip vagy shell kérdésre." - Nem, szerinted nem a user, hanem bárki, aki a konzolhoz épp akkor hozzáfér. Ezt viszont authentikáció nélkül nem fail-safe, hanem fail-open megközelítés, márpedig az alapvetés az, hogy fail-safe gondolkodunk - és ha ez nem felel meg a használónak, akkor majd ő nyissa ki, tegye fail-openné a rendszert.

Kiemelted? Az egész bekezdés arról szólt és azt írtad, hogy "azoknak a véleményét osztom, akik a problémák mellett az előnyeit is látják, és használják". Én erre kérdeztem, hogy miféle előnyök? A SysVInit hiányosságai pedig még mindig nem érvek a systemd mellett. OpenRC? s6? A többiek?

Na, ez viszont már a systemd hibája, mert asszimilálta a mountot és onnantól kezdve egy szaros mount is internal errornak számít és lehet ugyanott, egyformán kezelni őket. Ezt is minek kellett...

Már megint GOTO 10: erre írtam (hatszázhatvanhatodszor), hogy lehetne egy sima skip, egy skip with password, meg egy root shell lehetőség, de ilyenkor mindig jössz azzal, hogy de a Raspbianban nincs defaultból root, holott itt már régen általánosságban beszélünk a dologról; általában úgy telepítik fel a rendszergazdák, hogy legyen. Raspbianon is csinálni kell és akkor lesz. És akkor lehet root passworddel skippelni. És az fail-safe. De a probléma nem ez, hanem az, hogy vitatkozunk itt a fail-safe-ről, megállás nélkül, mert mindig visszatereled ide a dolgot, mert nem érted, hogy a systemd-nél, ha lett volna aktív root, akkor is elcrashel a boot folyamat, a saját - elbaszott - mount subsystem miatt. Érted? Skip with password + nincs root = failed system => PEBKAC, skip with password hiánya miatti failed mount + van root = failed boot => PEIPH.

Írtam olyan előnyöket, meg nem csak én, hanem mások is, amik valódi előnyként jelentkeznek a linuxhuszárok initscriptnek nevezett gánykupacaival szemben. Bár azokhoz képest sokszor a "bármi" is csak jobb lehet. De te mindet ignoráltad. Nekem pl. jól jön, hogy egy fostos java-s alkalmazásszervernél az uid/gid/umask egyszerűen, kényelmesen beállítható, nem kell csillió+1 scriptben gányolni, hogy úgy viselkedjen, úgy működjön, úgy hozza létre a fájlokat, ahogy azt elvárom. És szintén előny, hogyha megkérdezem, hogy aktív-e a szolgáltatás, akkor nem n+1 féle módon scriptből gányolva nézi meg, hogy futkorászik-e az adott daemon. Meg előny, hogy tudok olyat csinálni, ami a sysvinit-nél "feltételes respawn"-ként lenne leírható - ha lenne ott ilyen. Meg egyáltalán, tudom kontrollálni a szolgáltatás(ok) automatikus újraindulását... Hogy a dbus-os okosságokról ne is beszéljünk.

"hogy lehetne egy sima skip, egy skip with password, meg egy root shell lehetőség," - Add fel feature request-ként a systemd fejlesztőinek. Komolyan mondom, hiszen ez óriási tömeges igényként jelentkezik - vagy legalábbis te úgy érzed. De tedd hozzá, hogy minden esetben legyen ilyen, akkor is, ha nincs aktív (jelszóval rendelkező/nem zárolt) root user...

Az asszimilálta a mountot az érdekes... A sysvinit-nél nem az initscriptek mélyén volt elrakva a mount...? Ja, hogy standardizálta, és unitként működik?

Nekem szólt, hogy sz@r van a palcsintában, reszeljem ki az fstab-ot. Kireszeltem, és tényleg ennyi volt. Van ugye a nofail mount opció, ami doksi szerint a device hiánya esetén nem ad hibát - meg kéne nézni, hogy tényleg csak akkor engedi tovább, vagy a mountpoint hiánya/fájlrendszer hiánya esetén is.

Nem ignoráltam, válaszoltam rá: van más initrendszer is a világon a SysVIniten és a systemd-n kívül, kérdeztem, hogy mi a helyzet a többivel, OpenRC, s6, stb. Ezeket már többször felsoroltam, de végig leszartad, képtelen voltál erre az egész topic alatt válaszolni. Nem a systemd az egyetlen, aminek unit-jei vannak.

Adja fel a faszom, én már nem használom ezt a szart. És már megint nincs aktív root. Milyen érdekes. Az mindig akkor van, ha úgy akarsz érvelni és akkor nincs, ha úgy akarsz érvelni. Érdekes. Nem kettős mérce és nem vallásos imádat, még véletlenül sem.

Standardizálta? Mit? Egy 1971 óta létező UNIX parancsot? Ami minden UNIX-ban benne van? Hogy mi van? Hát már hogy lehetne standard, amikor Linux-only? Inkább ezt is magába olvasztotta és megtűzdelte a Poetteringista fasságokkal... Miért jó, hogy mindent beleöntünk az init rendszerbe? Mikor kerül sor a kernelre és a kuglikrómra?

Igen, de itt jön képbe, hogy amíg külön parancs volt, addig volt lehetőség posztponálni az

fstab

"kireszelését". A

nofail

meg nem tudom mit csinál a systemd-ben, normál

mount

tool jelenléte esetén boot közben beszól, hogy ez így nem jó, skip vagy fall to login prompt.

"én már nem használom ezt a szart" - szóval a legtöbb kereskedelmi LÉinuxnak a közelébe se szagolsz. "mindent beleöntünk az init rendszerbe" - nem mindent, csak azokat a dolgokat, amik a rendszer elindulásához és működéséhez szükséges, és egységes felügyeletük és beállításuk kívánatos. " A nofail meg nem tudom mit csinál" RTM: man 8 mount ; man 5 fstab, csak hogy okosodj (de volt már idézve, mire szolgál). Ahol nem működik, ott sajnos ez a lehetőség nincs meg - ott csak noauto opcióval meg egy valag scripttel körbeöntve tudod megoldani nagyjából ugyanezt.

> szóval a legtöbb kereskedelmi LÉinuxnak a közelébe se szagolsz.

Azokon kívül nincs tán élet? BSD-k, Solaris, OSX, különféle egyéb UNIX-ok, egyéb OS-ek (pl. Haiku) meg a systemd mentes Linuxok? Azonfelül, ha épp olyannal kell dolgozni, akkor de, odaszagolok. De ha rajtam áll, hogy mit használok (és úgy szokott), akkor systemd nélkül.

> nem mindent, csak azokat a dolgokat, amik a rendszer elindulásához és működéséhez szükséges, és egységes felügyeletük és beállításuk kívánatos.

Pontosítsunk: ez a mantra, hogy a systemd fejlesztői software-vendor-lock-ot játszhassanak a Linuxban. Csakhogy az egységesítés és az egybeépítés nem ugyanaz. A systemd pedig egybepakol egymáshoz nem tartozó szolgáltatásokat, egy rettenetesen elbaszott saját függőségi rendszer keretein belül. Márpedig azok a megoldások,amik túlzásba viszik az integrációt, azok mindig szarok lesznek, mert egy hiba dominóeffektust válthat ki, boríthatja az egészet. És itt külön rossz, ha borul, mert a systemd-n keresztül megy egy raklap systemd-fertőzött systemd-függő cucc (GNOME3, lol) is és ilyen esetben azok is pusztulnak. Ergo egy systemd komponens megborulása a teljes rendszert a sírba viheti. A KISS elvet nem véletlenül találták ki: minél bonyolultabb, annál hajlamosabb hibázni. És ez minősített eset, mert egy csomó cucc került bele, aminek kurwára semmi keresnivalója nincs az initben.
De amúgy tényleg, mi a faszt keres pl. NTP (timesyncd) a systemd-ben? Vagy DNS (resolved), méghozzá olyan, ami cache-poisoning-prone... Ja, a mai napig nem reagáltak erre a bejelentésre. Na, így lehet feature-requestet, vagy bugreportot küldeni nekik. Vagy leszarják, vagy NOTABUG, WONTFIX.

> " A nofail meg nem tudom mit csinál" RTM: man 8 mount ; man 5 fstab, csak hogy okosodj (de volt már idézve, mire szolgál).

ROFL, ezt hogy sikerült így kiollózni? Idézem magamat: "A nofail meg nem tudom mit csinál >>>a systemd-ben<<<" Direkt csináltad, hogy hülyének állíts be? Tudsz te mást csinálni, mint a vitapartnert támadni? Vagy csak úgy olvastad el ezt a posztot is, ahogy az eddigieket: a felét se, a többit meg odaképzelted és arra reagáltál.

De amúgy tényleg, mi a faszt keres pl. NTP (timesyncd) a systemd-ben? Vagy DNS (resolved), méghozzá olyan, ami cache-poisoning-prone...

systemd init rendszer vs. systemd ernyőprojekt (de akkor már adok neked tippeket: minek a systemd-importd, persze, már a rendszer image-ket is a systemd akarja kezelni fúúúj).

"A nofail meg nem tudom mit csinál >>>a systemd-ben<<<" Direkt csináltad, hogy hülyének állíts be?

Speciel tényleg copy-pasteltem már a systemd dokumentációból a system unit nofail tulajdonsághoz (amit behoz az fstabból) tartozó leírást, ami tartalmazza, hogy a függőségi fát hogy befolyásolja...

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

Nem. Én azt mondtam, hogy azt nem tudom, hogy a systemd-ben mit csinál, nem azt, hogy általánosságban nem tudom. Azt még le is írtam, nem tudom feltűnt-e. Örülök, hogy megint nem tudsz olvasni. Nem azért vagyok vulgáris, mert ideges vagyok, hanem mert alapból így szoktam beszélni. Tudom, ez nem szép dolog, de ez van. Viszont, lentebb írtam, hogy te vulgaritásról ne prézsmitálj, mert egyrészt te is trágár vagy, másrészt meg - ami viszont sokkal rosszabb - te nem csak simán így kommunikálsz, hanem személyeskedsz, beszólsz, mocskolod a másikat. Azzal te mit mutatsz? Te nem tudsz uralkodni magadon, nem én.

"Nem azért vagyok vulgáris, mert ideges vagyok, hanem mert alapból így szoktam beszélni." - Ha ez igaz, akkor komolyan javaslom, hogy keress fel egy szakembbert, mert ez elég csúnya személyiségzavarnak is lehet a következménye, amit értelmes munkáltató nem igazán szokott díjazni.

Miért jó, hogy mindent beleöntünk az init rendszerbe?

Mert a szolgáltatásoknak _kell_ az alattuk levő storage. Persze, írhatsz scriptet, ami megnézi, hogy sikerült-e felcsatolni a /var/mail-t mielőtt elindítja a Dovecotot, akár át is írhatod a disztrib init scriptjét ezzel a checkel. Akár a distrib init scriptje tartalmazhat is egy részt, ami végignyalja az fstab-ot és megnézi, hogy a /var/mail alatti összes mount sikerült-e.

Ugyanez pepitában mondjuk egy libvirt: taknyolhatnál init scriptet, ami egy sysconfig-beli shell scriptben felsorolt összes helyre végigszalad és megnézi, hogy felette minden mount sikerült-e, hogy a user fel tudja vinni a saját image helyeit és ne induljon el a libvirtd úgy, hogy a VM-ek storage filejai nincsenek ott.

És lehetne még sorolni egy csomó más démont.

Aztán persze ha már minden init scriptben kisebb-nagyobb különbségekkel ott van ugyanez a logika, akkor majd lehet jól - természetesen disztro-specifikus implementációkkal - egységesíteni, hogy csak egy source kelljen minden init scriptbe...

Na, _ezért_ hasznos, hogy az init rendszer a mountokkal is törődik.

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

Egyrészt ez elég erős túlzás, hogy minden scriptben nagyjából ugyanaz a logika lesz, mert nem lesz. Másrészt, a kisebb-nagyobb különbségekkel mi lesz? Beletaknyoljuk az initbe azokat is? Direkt egy-egy daemon kedvéért? Nem. Ahogy már tavaly is írtam ugyanezekre az érveidre (csak nem válaszoltál), az a helyes, ha szét van bontva. Nem kell mindent beleönteni az initbe, mert csak egyre több bugja lesz.

Oks, akkor az init ne csinálja. Akkor marad, hogy _minden_ szolgáltatáshoz tartozó init script maga nézi végig, hogy egyébként olyan állapotban van-e a rendszer, hogy indítható legyen a daemon.

Egyrészt ez elég erős túlzás, hogy minden scriptben nagyjából ugyanaz a logika lesz, mert nem lesz.

Akkor meg csak reméljük, hogy minden oké volt (és nem bökött senki a Skip-re ;) ) és ott vannak a működéshez szükséges adatok. Ha meg nem, max. nem működünk, vagy viszünk magunkkal más rendszereket is (lásd a korábbi nem is ritka "replikált tartalom" példát), nem gond...

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

Na, te csak ne tarts előadást a kultúrált szövegezésről, meg a tartalmas hozzászólásokról. Pont te ne. Voltam én itt húgyagygú (sic!), fasz, hülye többször is (nem listázom be); másra sem voltál képes, mint a személyeskedésre. Ezek után, hogy pont te prézsmitálj, hogy valaki csúnyán beszél, az már a legalja.

Senki nem írta, hogy fasz vagy, én prónáltam kulturáltam megfogalmazni, hogy bárki, aki ott áll a raspi környékén, a húgyagyú meg a Szomszéd nője c. örökbecsű filmből jött :-) Bár igen, ott "húgyagyú barom" a jelző :-) Amit te a systemd alkotóival szemben levágtál, nos, az az egy szál áthallásos fasz, illetve húgyagyú jelzőnél picit erősebb, hogy finom legyek. Ráadásul olyan embereket ekézel, meg aggatsz rájuk és a munkájukra jelzőket, akik nálad vélhetően sokkal jobban átgondolták és átlátják azt, amit te felfogni, megérteni, megismerni sem akarsz.

Persze, persze, én leírom, hogy az ott álló fasztól, amire neked az a reagálásod, hogy az ott álló TCH-tól. Nem mintha a poén nem állna, de ettől még személyeskedés. Ha meg filmekből idézel, akkor meg tedd pontosan, de egyébként tök mindegy, honnan idézel egy sértést, az attól még sértés marad. (Függetlenül attól, hogy igaz-e vagy sem, mert lehet, hogy húgyagyú vagyok, de ha igen, akkor nem azért, mert utálom a systemd-t, vagy mert még érvelni is van pofám a véleményem mellett.)

Ami a systemd alkotóit illeti...

Ad 1. Nem mindegy, hogy a téma tárgyát képző embereket illeted valamilyen jelzővel, vagy a vitapartneredet, érvek híján.
Ad 2. Poettering személyét sehol nem illettem semmilyen jelzővel, maximum a viselkedését, tehát amit állítasz, az úgy kamu, ahogy van.
Ad 3. Mi ez a tekintély alapú érvelés? Híres, vagy fontos emberről nem lehet véleményt formálni?

Ami pedig a munkájukat illeti, hát ha szerinted ezt átgondolták, akkor ezt gondold át még egyszer, mert ki fog lukadni az oldalam a röhögéstől. (Nem.) Elég nagy baj, ha a szart nem lehet a nevén nevezni. A systemd pedig szar. Nálam okosabb szakemberek ezrei fejtegetik netszerte mindenféle cikkekben, blogposztokban és különféle fórumokban, hogy mennyire de az. Olyanok, "akik nálam vélhetően sokkal jobban átgondolták és átlátják azt, amit én felfogni, megérteni, megismerni sem akarok".

Az megvan, hogy még Torvalds is összeakaszkodott a systemd fejlesztőkkel?

Részben off: egyébként a systemd forrásában sehol nem találom a hivatkozott stringet, bőven lehet, hogy ezt nem is a systemd csinálta :)

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

Előző héten kiesett nálunk is egy "apró" systemd bug, ami ismét megerősített abban, hogy ahol lehet, még hanyagoljam a systemd-t, nem elég kiforrott/stabil. Van egy elég komplex rendszerünk AWS-en, aminek egyik része kb. 4000 darab EC2 instance-t foglal magában (különböző típusúak és nagyságúak, tehát pl. de ugyanarra a custom AMI-ra építve működtetik ugyanazt a cél szolgáltatást, ami nekünk épp kell). Ezeken akartunk némi systemd-vel ütemezett, halálosan egyszerű mókát futtatni minden instance-on a v229-ben bevezetett "RandomizedDelaySec" segítségével. Mondanom sem kell, hogy az insták 1-2%-án nem futott le az időzített processz... Log üres, minden üres, csak azt látni, hogy pár tucat instance-on nem történik semmi, holott a timer listában (gyk. betöltve) ott van aminek lennie kell. Pedig kéne... Semmi hasonlóság, ismétlődés nincs az insták (típusai) között, és már vagy két hete meg vagyunk lőve a kérdésben...

Hol vannak ilyenkor a systemd specialistak? zeller? Szblacky?

En a magam reszerol annyit tudok hozzaszolni, hogy a systemd total alkalmatlan barmilyen corner case-re.
Kellett nektek leterni a kitaposott osvenyrol.

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

Azt várod, hogy nulla infó alapján (oks, valami mégis: a timer unit-ban van egy RandomizedDelaySec direktíva) álljunk neki a fórumban debugolni?
Egyébként systemctl status foo.{service,timer}, journalctl -u foo.service, systemctl show foo.timer, systemctl show foo.service (ezt akár egy működő és nem működő példányon is futtatni és cmp) és máris el lehet indulni...

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

Ha mar systemd talanyok:
etc/hostname beallitasa /proc/cpuinfo alapjan.

Azaz van tobb azonos rendszer, ami read-only filerendszerrol bootol nfs-en keresztul.

Az alapproblema, hogy az /etc/hostname nem lehet symlink a systemd vilagban, mert akkor nem mukodik.

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

Lennart válasza néhány reply-al később:

hostnamed and friends live in a sandbox these days, that prohibit
write access outside of /etc, and read access to various other
dirs. If you play such symlink games, you have to turn that off. See
the systemd-hostnamed.service service file, specifically
ProtectSystem= and similar options.

Vagyis: ha megcsinálta volna a systemctl show systemd-hostnamed-t (lásd debug step-ek fentebb ;) ), látta volna, hogy be van rá kapcsolva egy csomó védelmi mechanizmus...

És közvetlenül ezalatt mondott egy megoldást, ami egy by design támogatott use case / konfigurációs megoldás (rw /, read-only /usr, az etc üres vagy amit nagyon muszáj azt a tempfiles.d húzza be a /usr-ből) - ahogy azt a Fedora 17-ben (az se ma volt) debütált egyesített /usr okait magyarázó doksiban (https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/) le is írta.

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

ami szerintem szar megoldas.

Mar a koncepcio is hibas (/ rw, /usr/data ro, versus /ro /usr/data rw).

Raadasul egy ramba tarolt filerendszerbe egyszeruen nem fer bele kismillio file, amit sose irunk, es csak azert van ott, mert a komplett /etc-t oda kellett tenni a systemd miatt (az /etc/hostname miatt)

Meg ha a komplett / rw, akkor hogyan tud nfs-en keresztul tobb rendszer letezni hogy ne piszkitsak ossze egymast

Vagy irhatnek security-t is. Fogod a komplett /-rol csinalsz ellenorzo osszeget, es fel ev mulva ranezel biztos lehetsz benne, hogy nem piszkalta meg semmi se.

Ez a lennart egy igazi worksforme emberke.

(a ProtectSytemet meg fogom nezni)

---
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 / is lehet ro (ennek minden előnyével és hátrányával), ekkor viszont gondoskodnod kell arról, hogy az initrd már felcsatolja a /data-t is, hogy a systemd a boot korai szakaszában elérje a /etc/hostname-t.

Vagy irhatnek security-t is.

Lásd a fentebb linkelt /usr merge posztot: fogod a teljes /usr-t (ami by design a vendor provided rész), csinálsz róla egy checksum-ot és fél év múlva megnézed. (egyébként ez is érdekes olvasmány a témában: http://0pointer.net/blog/projects/stateless.html)

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