Nem, pl. azert sem, mert a su processz nem az 1-bol fog leszarmazni.

Egyebkent meg:

> Pláne úgy, hogy ez a run0 az egész PAM mechanizmust meg a polkitet berántja maga alá

pont ahogy a sudo is

A sudoval meg az is a gond, h nem all mogotte rendes maintainer garda

tehát ez olyan, mint amikor egy rozsdaboglya autóra ráragasztasz egy gyorstankoló matricát meg rallye feliratú napvédőt?

Tudom, h te nem szereted a systemd-t, de az ipar alapvetoen elfogadta. En egyebkent megszerettem, jatszoshanyos gepekre neha tulzasnak erzodik, de valos eletbeli problemakat tok jol megold. systemd-resolved, journalctl, unit fajlok, mind jobbak, mint ami elotte volt.

Kivéve, hogy rosszabbak. Nem volt még másik *nix probléma, amivel annyit szívtam, mint a resolved ökörségei, a bináris logolás egyenesen baromság, amikor meg unitot kellett volna használnom, sosem működött.

Az "ipar elfogadta": nem, az ipar csak spórol vele, a Red Hat megírja a unitokat, a többiek meg használják. Mindjuk kíváncsi leszek, mit csinál az ipar, ha a Microsoft benyögi annak az arrogáns marhának, hogy conflict of interest nekik a systemd fejlesztése, ezért abba kéne hagyni.

Mi nem mukodott az unittal? Nem tudom, hogy mi az, ami abban nem tud mukodni. Csinalsz egy unit fajlt egy perc alatt, kesz. A harmadik utan mar a vilag legegyszerubb dolga, mindent egy helyen konfigolsz.

"Red Hat megírja a unitokat"

?

resolved: ez az, ami megbizhatoan tudja a kovetkezoket:
- interfeszenkenti DNS feloldas (VPN-ek, kontenerek, stb. eseten letfontossagu)
- DNS over TLS (biztonsag)
- D-Bus tamogatas
- domain-alapu nevfeloldasi szabalyok

Szerintem megegyezhetunk abban, hogy a Tailscale mernokei a vilag tetejet kepviselik, ha Linuxos halozatokrol van szo. Ok irjak:

As an aside, one major difficulty in all of this is that name resolution on Linux systems is very poorly specified, and each of these methods results in slightly different behavior. If we do a resolution for go.akua, what will happen? Will it go to the resolver for the public internet? Will it go to the right split server? Will it get sent over Tor for some reason? Will it get sent to the potentially dodgy DNS server on the public Wi-Fi hotspot at your local coffee shop? Will it get sent over UDP, TCP or DNS over HTTPS? We don’t know. This stuff is not documented and as a result, you need to figure out what it does through blood, tears and heartbreak. For extra fun, the behavior of glibc and musl differs here too. Please document your behaviors when you write new software. This saves so many people so much time.

An example of how to do this right is systemd-resolved. It can do everything a modern split-DNS VPN needs natively, so in theory there’s no extra work (except see below, because reality is not quite as clean as we’d like). The systemd team painstakingly wrote down what they do, and made it unambiguously obvious how you should twiddle things to get what you want. This is the kind of documentation that infrastructure programs should strive to have.

Szoval a resolved
1) mukodik
2) mindent tud, amit egy modern DNS kliensnek tudnia kell
3) reszletesen dokumentalt

nincs mas olyan DNS megoldas, ami ezeket igy mind tudja.

A binaris logolas meg egy erdekes tema, kezdve onnan, hogy minden logolas binaris ...

Azert hasznaljak a systemd-t a a valo vilagban, mert komplex kornyezetekben is jol mukodik.

[ Szerkesztve ]

Mar nemigen emlekszem, mit akartam elinditani vele service-kent; ha jol remlik, 2-3 ilyen probalkozasom volt, aztan hagytam a francba - mert cseszett elindulni. A resolved is hasonlo kaland volt, meloban kellett volna valami flexibilis megoldas, mindenki a resolved-ra mutogatott, hogy az a tuti, de a vege mindig az lett, hogy le kellett tiltani es manualisan konfiguralni az interface-eket. A binaris log, meg mint mondtam, egy egetvero baromsag: ha van text logom, akkor hajszaritoval is elolvasom, mi vagyon irva bele, a binaris loghoz meg kell a sajat kornyezete, hogy olvashato legyen - hurra.

Ez meg messze nem minden, ami miatt a systemd szar, de mivel mar ezeken a hasabokon is leirtam jonehany alkalommal ezeket, nem kezdem elolrol.

[ Szerkesztve ]

Ha tényleg ők a linuxos világ teteje, akkor bajban vagyunk.
"This stuff is not documented ": a valóság az, hogy documented. A resolv.conf-ban szereplő dns szerverhez fordul, pont.

Egyébként a systemd-resolvd-ben az documented volt, hogyha nem jó a névfeloldásod, akkor a google névszerverére fallback-kel? Mert egy ilyen ötlettől a linux kapásból alkalmatlanná válik komolyabb helyeken való felhasználásra.

A dbus támogatás meg micsoda? Minek dbus támogatás a rezolváláshoz? Megint ez a csináljunk egy naaaagy monolitikus böszmeséget a unix alapfilozófiájából történet, ahol pottering nem érti, hogy amit csinál, az fundamentálisan rossz. vannak dolgok, amiket el kell fogadni, mint egy axiómát. A unix az KISS. Ami nem KISS, az nem unix, hanem pl. windows. a systemd nem egy tuningolt unix init, hanem egy totál más rendszer initje, ami alatt tévedésből linux kernel van.

De ezek "filozófiai" kérdések. Az alapvető probléma, hogy a systemd nem működik rendesen. Nem teljesíti a saját ígéreteit, a doksiját. Amíg nem az történik, mint ami a kottában van, addig nincs miről beszélni, az csak a mostani munkahelyén normális, hogy a világ a bétatesztelőjük, debianban eddig ez nem volt.

A systemd elkaristol, amíg az alap dolgokhoz akarod használni. Amikor nekem bonyolultabb dolgokhoz kellett volna systemd támogatás, soha nem sikerült megcsinálni, mindig valami bugba futottam bele. Egyébként meg például milyen vicces, hogy a systemd gyűjti a logokat és forwardolja a syslogd-nek. Miért nem lehet ilyenkor kihagyni a systemd-t? bináris log unixon? minek?

A systemd alapvető baja egyébként, hogy működő, tesztelt, normális megoldásokat cserél le egy katyvaszra, látható előnyök nélkül. Miközben ezzel a cserével a rendszergazdákat arra kényszeríti, hogy erőforrásokat áldozzanak a változás követésére. Minek? Ki fizeti azt meg? Én fizessem meg pottering egoizmusát? A linux régen a szabadságról szólt, nem arról, hogy minden mocskot letolnak az ember torkán. Ha azt akarom, hogy pár egoista barom hülyeségéhez kelljen erőszakkal igazodnom, veszek windows licenszet.

Hát, tényleg ők egyébként Brad Fitzpatrick?

> bináris log unixon? minek?

Ha ezt egy valódi kérdés, szívesen elmagyarázom, de valószínűleg nem valódi.

nem kérdés volt, állítás.
unixon alapvetően minden szövegfájl (a szükséges kivételekkel). erre lett az egész optimalizálva.
a bináris log az olyan, hogyha én beülök egy szték vendéglőbe, akkor nekem hiába magyarázza bárki is, hogy a szója meg a tofu jó, én akkor is sztéket fogok enni. azért van unix a gépeimen, mert szöveges logokat akarok.

mindig az az oprendszer van a gépemen, amellyel a legegyszerűbben meg tudom oldani a feladatomat. tehát ha ascii log elég (mindig elég), akkor nem lesz bináris logom, pláne nem lesz xml meg json meg binary blob logom.

A sudo teljesen jól el van PAM és polkit nélkül is, aki akarja, mindkettőt kiírthatja alóla.

"Azert hasznaljak a systemd-t a a valo vilagban, mert komplex kornyezetekben is jol mukodik."

Nem, azért használják, mert a Debian átvette, és miután az iparban a Linuxos közösség kb. 90%-a vagy Debian, vagy RHEL alapú disztrót használ, ezért a többi kis disztró gyakorlatilag kénytelen volt adoptálni, mivel nálunk nincs erőforrás arra, hogy külön utakon járjanak.

Van egy rakat sudo alternatíva amúgy.

Ha neked elég az ASCII log, akkor több lehetőséged is van azt használni. A világ elég jó részének nem optimális, mert túl komplex (igen - egy JSON logban szűrni sokkal egyszerűbb).

A probléma az, hogy azt gondolod, hogy egy sztékes helyen ülsz, de a többiek azt látják, hogy egy enyhén pityókás, morcos bácsi morog a Hawaii bowl-os helyen valami olyasmiről, hogy ez régen egy jó grillező volt, és követeli, hogy neki adjanak rendes húst

[ Szerkesztve ]

Egy sérült ASCII log még olvasható, egy bináris már nem feltétlenül. Mindenben egyetértek bambano-vel. Én mondjuk unixokon nőttem fel, sokáig csak otthon használtam linuxot, és elég korán (bőven a systemd előtt) beláttam, hogy a linux a unix windows-a. Ez a véleményem azóta se változott, sőt!

A JSON is ASCII
De egyébként vannak olyan flat file db formátumok, amik közel ugyanolyan jól dolgozhatók fel, mint a bináris fájlok, ellenben ember által is olvashatók. Van némi overheadjük ugyan, de az elhanyagolható.

Nem olvashatók ember által, mert ahhoz is beépített eszközök kellenek...

Le tudod írni, hogy mi az a use case, ami journallal nem megoldható vagy nagyon nehéz, a régi fájlonkénti text logokkal pedig könnyű? Ellenpéldat tudok mondani.

Nem ASCII egyébként.

[ Szerkesztve ]

Egy szimpla ASCII fájl olvasásához bármilyen text editor jó, ami kéznél van. Nano, pico, joe, emacs, vi, vim, nvim, akármi. A journalt legfeljebb a journalctl-el tudod olvasni.

Le tudod írni, hogy mi az a use case, ami journallal nem megoldható vagy nagyon nehéz, a régi fájlonkénti text logokkal pedig könnyű? Ellenpéldat tudok mondani.

Írták már, ha pl. megsérül a diszk, a bináris logot nehezebb helyreállítani. Vagy ha maga a journald crashel, cseszheted a logokat. Vagy ha egy szép napon Poettering azt mondja, hogy bocsi, most megváltoztattuk a journalctl-t, nem kompatibilis a régi logokkal...

Oké, menjünk éttermi hasonlattal.
Régen volt mindenféle étterem, majd jött a maffia, mindet erőszakkal átvette, és azóta mind vegán étterem. De az ételt mindig elsózzák és kozmás.

Tehát ne csak azt az állításomat figyeld, hogy a unix filozófiájának nem felel meg a systemd, hanem azt is, hogy egyébként a systemd jelenlegi állapotában egy bughalom.

Más: az előbb jutott eszembe, míg szűkös magányomban agyaltam ( ), hogy a legújabb gyerekvédelmi szabály(tervezet) fényében a systemd-resolvd nem törvénysértő?

Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.

Egyébként a sudo legtöbb sebezhetősége ilyen snassz buffer overflow és hasonlók voltak, ilyesmik ellen meg nem véd a systemd sem (főleg, hogy azt is C-ben írták).

Kell hozzá a SUID bináris, az a fő gond. Ha nincs SUID bináris máris sokkal kevésbé problémás pl. egy buffer overflow.

A SUID/GUID koncepció lehet, hogy rossz, de erre vannak módszerek a különféle LSM-ek képében, mint pl. a SELinux és az AppArmor. Védekezzünk egy szar architektúra ellen ágyúval? Az SELinux egy katasztrófa, borzalmasan nehezen konfigurálható. Az AppArmor egy fokkal jobb, de azt is adott rendszerre kell belőni.

(#34044) sh4d0w Volt nem túl régen olyan projektünk amit valami ruszkik gányoltak SysVinit-el, na az egy kalap fos volt. Közben Yocto-s embedded rendszeren systemd-vel annyi egy unit fájl, hogy megírod a service fájlt (aminek eléggé RTFM manuálja van) és "inherit systemd".

Ezek ilyen filozofalgatasok, neked ez az elkepzelesed az Unixrol, masnak meg mas. Es jelenleg akik alakitjak a Linuxot, ok mashogy akarjak.

> Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.

A Tailscale szeretne valamit megvalositani. Olyasmit, amire oriasi igeny van. Az oprendszernek nem az a feladata, hogy valami filozofianak megfeleljen, hanem hogy lehetove tegyen kulonfele use case-eket. A dinamikus DNS konfiguracio fontos. Ezt resolv.conf hekkelessel nem tudod elegansan es robusztusan megoldani.

egyébként meg ha nem ezt a túlmodernizált módszert tolod, hogy mindent sudo-val, akkor nem kell sudo és nincs a sudo-val biztonsági probléma.

Journalt is tudod massal olvasni. Egyebkent meg journalctl-t pipeolhatod vim-be, ha akarod.

> Írták már, ha pl. megsérül a diszk, a bináris logot nehezebb helyreállítani.

Miert lenne nehezebb? A journal formatum append-only, ugyanugy helyre lehet allitani. Lattal mar eletben ilyen problemat?

Sot, a valosag _pont_ az ellenkezoje. A syslog joval erzekenyebb a crashekre, a journalban atomikus append van, integrity check, tud pl. kriptografikus szignalast (tuti biztos lehetsz benne, h utolag nem nyult valaki bele a logfajlodba).

nem nekem van elképzelésem a unixról, hanem az alkotóinak. és a teljes rendszert ahhoz igazították. az, hogy csővezeték van, olyan parancssori cuccok vannak, amilyenek, az átirányítás meg a file descriptorok rendszere, mind azt mutatja, hogy szöveges feldolgozásra optimalizálták a kernelt. minden más elhajlás. jelen esetben indokolatlan és helytelen.

ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle. lásd még: m$

majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály. mellesleg most is dinamikus a konfig, a dhcp kliens átírja a resolv.conf-ot.

1. Az Unix alkotoinak az elkepzeleseit te is csak ertelmezed, nyilvan a sajat szemszogedbol.
2. Valtozik a vilag, nem kotelessegunk azt csinalni, amit a PDP-11-et hasznalva gondoltak az alkotok. Miert lenne?

> ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle

tok jok ezek a levegobol vett allitasok, nyilvan lehetetlen ertelmes beszelgetes folytatni roluk

> majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály

na jo

Ne haragudj, de ez nem vélmény kérdése. Az egész műszaki világot szabványok határozzák meg, ha nem akkor nem egyéb mint kiscsaj picsogás. van olyan, hogy posix szabvány.

Nem kell feljeszteni azért, hogy fejlesztve legyen. Az meg a minimum lenne, hogy a 21. században a mérnöktársadalom elfogad legalább minimális morális elveket. pl: ha nem romlott el ne javítsd meg, vagy kiss, vagy azt, hogy itt embereknek készülnek a cuccok.

A mérnök tervezzen eszközt az emberek számára és ne a marketinges tervezzel terméket a fogyasztónak.

A legtöbb Linux nem POSIX certified. A szabványok elsődleges célja az interoperabilitás és a minőségbiztosítás. Ha a termék szabványos, de nem oldja meg a problémádat, akkor nem vagy kisegítve. A systemd olyan problémákat old meg, amire korábban nem volt megfelelő megoldás (legalábbis a Linuxos közösség jó része úgy értékelte, hogy nem volt). De a Linux FLOSS, ezért azt használsz, amit akarsz. Ez a fo elonye, szoval nem ertem a gyaszolast

[ Szerkesztve ]

Például log forwarding kissé nehézkes volna, remote logelemzésre. Nyilván ez otthon nem jellemzően kerül terítékre. De a rendszered logolási stratégiáját is kacifántosabb így kialakítani, mint a megszokott facility-kkel, ez viszont meg igényfüggő. Logrotálást egyébként hogyan gondolnád a binárissal kivitelezni? Mindent egybe, ahogy a journald odalöki? Az pedig, hogy a journald nyomja a logokat rsyslogba vagy syslog-ng-be, közröhej.

Nem, egy JSON-ban szűrni sokkal kevésbé egyszerű, mint egy plaintext logfájlban, ha minimális regex ismeretei vannak valakinek. A "világ jó részének" azért komplex feladat egyébként, mert a szakma felhígult.

Sajnos a systemd valóban, mint a kolléga fentebb leírta, az ipar szájába lett taposva, és a legkevésbé sem fogadták el örömmel - inkább lenyelték a békát. Nem nagyon látod jól tehát a helyzetet. Ha tetszik, ha nem: a Red Hat diktál, a kutya ugat (a Debian projekten is volt hőzöngés, és lett is Devuan, csakhogy egyébként sok választásuk nem volt, ha az enterprise terepen meg akartak maradni); és aki kicsit is ismeri a nagyobb cégeket, hogy miként tudnak ilyen-olyan projektek felfutni, az gyaníthatja, hogyan is lett sláger a systemd. Annak ellenére egyébként, hogy irgalmatlanul pocsék a dokumentációja a mai napig; hogy teljesen értelmetlenül ráfekszik mindenre; hogy minden pontján jól érezhetően egy önjelölt revolucionista "csakazértisfordítva" szellemben elkövetett alkotása.

Valóban vannak kézreálló tulajdonságai, például épp egy service unitot megírni viszonylag egyszerű. Mondjuk ha ez kicsivel komplexebb, mint xy tech userrel indítani egy httpd-t, és nem kézenfekvő a unit type, akkor már indokolatlanul macerás. Mellesleg sysvinit alatt sem ördöngösség egy service megírása, csak ugye kevésbé olvasmányos, lásd felhígult szakma. Viszont a systemd a KISS diszciplína célzott arculköpése, pedig az ilyesmiket annak idején elég okos emberek találták ki, még ha nem is huszonévesek voltak very senior divatdevops pozícióban 2,5 éves szakmai tapasztalattal. Már magára ne vegye senki terészetesen.

A log forwardingot pont nagyon tudja a journal, resze volt az eredeti celkituzeseknek. A logrotalas detto, hiszen a journal seekable, ergo a klasszikus logrotalasra nincs is szukseg. Logrotalasra alapvetoen azert van szukseg, mert a regebbi logokat idovel kidobjuk helysporolas miatt, es ezt ugy szokas megcsinalni, hogy a fajlokat dobjuk el, mert a szoveges logokban nem lehet egyszeruen ido szerint seekelni, plusz a fajl elejet truncate-elni maceras. A journalnal nincsenek ilyen problemak.

Tehat a journal alapvetoen kozelebb van a KISS-hez, mint a szoveges logfajlok rotalgatasa, mert arra van kitalalva, hogy logokat taroljon (ellenben a sima szoveges logokkal).

> Nem, egy JSON-ban szűrni sokkal kevésbé egyszerű, mint egy plaintext logfájlban, ha minimális regex ismeretei vannak valakinek.

Nem ertek egyet,
1) a komplex regex nagyon lassu tud lenni
2) minden program hajlamos sajat formatumba logolni, tehat egyszerre tobb program logjat szeretned korrelalni/szurni, akkor az seggfajas.

A tobbi filozofalgatas, szoval nem mennek bele.

Nem tudom, h ti mekkora meretu logfajlokkal dolgoztok, ahol en dolgozom, ott ~ terabajt nagysagrendu log van naponta. Ti grep-et es regexet hasznalnatok arra, h keresgeljetek ennyi logban? (Nyilvan mi is hasznalunk regexeket, stb., de nem ugy, hogy bemegyek a szerverre ssh-val, es a syslog fajlokat elkezdem grepelni.)

[ Szerkesztve ]

Miert lenne nehezebb? A journal formatum append-only, ugyanugy helyre lehet allitani. Lattal mar eletben ilyen problemat?

Igen, láttam ilyet, volt hogy leakadt a SAN, és kb. két és fél órás művelet volt csak az, míg sikerült bebootoltatni a rendszert. Onnantól fogva, vagy vissza tudod varázsolni a journalt, vagy nem, és sok esetben sajnos nem. De amikor a journalctl --verify is csak annyit tud mondani, hogy "invalid argument", na akkor tudod, hogy hosszú napod lesz.

Ez egy kb. 5-6 evvel ezelotti bug, nem? Ez egy bug, nem a journal jellemzoje. Ha a btrfs-nek 2015-ben volt egy data loss bugja, az nem azt jelenti, hogy a btrfs design-ja hibas, es mindenkinek ext2-t kell hasznalnia. Szerintem.

miért nincsenek olyan macerák a journalnál, amiről azt hiszed, hogy text lognál vannak?

és ti a terabyte nagyságrendű logokat összeöntitek egybe?

> és ti a terabyte nagyságrendű logokat összeöntitek egybe?

Persze, hogy keresnél egyébként? Mármint nyilván szénné van indexelve, de nem az van, h van óránként meg szolgáltatásonként egy fájl.

De természetesen strukturált logra van szükség ekkora mennyiségnél.

> miért nincsenek olyan macerák a journalnál, amiről azt hiszed, hogy text lognál vannak?

Mondj egy konkrét példát, és beszélhetünk róla. Legyen mondjuk a log rotation?

[ Szerkesztve ]

hogy rotálod a bináris logokat? eldobálsz fájlokat, nem?
a jobb syslogd-knek meg lehet adni, hogy milyen nevű fájlba logoljon. hogy a gép nevét bele lehet-e rakni a logfájl nevébe, azt még nem próbáltam. hogy dátumot bele lehet-e, tetszőleges formátumban, azt igen, működik. simán tudsz csinálni

/var/log/%Y/%m/%d/syslog

nevű fájlt. nem kell rajta rotálni semmit, max. ráteszel egy linket a hagyományos helyéről.

Persze, hogy keresnél egyébként?

elk

Ez kb. 2 éve történt. Nem systemd bug, hanem egyszerűen sérült volt a journal, és a journalctl nem tudta még verifikálni sem.

Ez egy systemd bug volt, v240 korul fixaltak, akkor fordult elo, amikor a fajl nem volt lezarva rendesen. Lehet, h regi verziot hasznaltatok.

Pontosan, ELK, vagy hasonlo stack. Ezeket celszeruen strukturalt logot etetsz. Persze megcsinalhatod a parszolast sajat szabalyokkal, viszont ha journalbol jon, akkor a melo jo reszet mar megcsinalta helyetted a rendszer. Tehat valami miatt itt csomoan azt szeretnek, ha pl. a severity level beallitasara nekik kene megirni a regexet egyenkent minden processzre, de nem tudom, h ez miert elvezetes.

[ Szerkesztve ]