Gummiboot bude začleněn do systemd

Lennart Poettering na Google+ potvrdil, že gummiboot, jednoduchý UEFI boot manager, bude začleněn do systemd. Další připravované novinky, stručný přepis přednášky Lennarta Poetteringa na konferenci Fosdem 2015, na blogu Mattiase Geniara. [Slashdot]

3.2.2015 15:14 | Ladislav Hagara | Komunita

Komentáře

[mirec]

Chápem to správne, že podpora sa týka bezpečného zavádzania modulov pod uefi aby náhodou kernel neloadol keylogger alebo niečo podobné?

[Conscript89]

Netusim, v kazdym pripade to by mel resit kernel a ne init, zavadet jen moduly podepsane duveryhodnym klicem. Cely mi to nejak nedava smysl, leda ze by systemd k necemu pouzivalo funkce pro verifikaci podpisu souboru, nebo nevim (to ostatne porad neni duvod k pohlceni projektu).

[Peter Golis]

Jedná sa o voliteľnú podporu pri ktorej SystemD overí či nebol naštartovaný OS do kompromitovaného stavu. Doterajšie podpisovanie bináriek, a už duplom nejakých skriptov pri štarte stojí za prd. Čo myslíš, koľko trvá hacknutie voľne pohodeného stroja s povoleným štartom z hocakého média, alebo zapnutého stroja s povoleným debug portom (FireWire, Thunderbolt, Express card)?

[Pali]

Jedná sa o voliteľnú podporu pri ktorej SystemD overí či nebol naštartovaný OS do kompromitovaného stavu.

Prosim pekne, ako to moze userspace proces (init) spravit? Ved kernel ma plnu moc nad tym co sa bude diat s userspace procesom...

[Mti.]

Vydrz, to prijde v dalsi verzi.

[Peter Golis]

Napríklad bude podpísaný a bude mať podpísané textové konfiguráky, takže zaručí že nikto dodatočne nemodifikoval init. To podpisovanie textových konfigurákov a skriptov SysV za posledných niekoľko desaťročí pre istotu nikto nedal do produkcie, takže je to krok v pred. Ale hateri prskajú na všetko, čoho sa boja.

[Conscript89]

Takze bude pouzivat jen par stejnych funkci co je v gummiboot pro overeni podpisu kernelu treba? To klidne at delaji, ale neni duvod aby se pak soucasti systemd stal gummiboot. Podle toho by se vsechny systemd zavislosti mely stat soucasti systemd (asi uvazuji takhle, jinak si to nedokazu vysvetlit).

[pavlix]

Podle toho by se vsechny systemd zavislosti mely stat soucasti systemd (asi uvazuji takhle, jinak si to nedokazu vysvetlit).

Minimalizaci externích závislostí dělají všechny možné projekty. Skoro bych řekl, že se to po nich přímo požaduje. Že se něco stalo součástí systemd, za to se za rok za dva zapomene, ale kdyby to bylo potřeba k jeho buildu, budou si na to lidi stěžovat pořád. Slučování projektů do jednoho zdrojového balíku tvořícího základní systém je proces, který by u systemd už neměl nikoho překvapovat. A svým způsobem je to odpověď na to, co všichni chtěli, nainstalovat si pár balíků a mít funkční systém :).

[omg]

HAHAHAHAHAHAHA

http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

ale jo pravidla jsou od toho, aby si nekdo tahal triko a hlavne, aby se porusovaly.

pred 10-15 lety i kdyz po necem podobnem byla poptavka u ruznych projektu okolo kernelu a jinych ficur tak jen navrhnout neco takoveho bylo ostrakizacni.

[pavlix]

http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Jestliže se ty projekty sloučí, tak toto pravidlo nelze vůbec aplikovat.

[omg]

pred 10-15 lety by podobne krkolomne slouceni neprichazelo v uvahu.

[Peter Golis]

a skriptov SysV
Ak bude SystemD zdieľať kľúče s gumiboot-om a kernelom, tak v tom vidím len prínos. Vždy to bude lepšie ako nechránený systém známy niekoľko desaťročí.

[pavlix]

Jak souvisí sdílení klíčů mezi třemi komponentami a začlenění jedné komponenty do jiné?

[Peter Golis]

Asi tak, ako vabenie sa o vzdušnom zámku. Už bolo zverejnené ako sa to začlení? Nejako som si nevšimol. Asi to benude agresívnejšie ako toto:

$ zcat /proc/config.gz | grep SYSTEMD
CONFIG_GENTOO_LINUX_INIT_SYSTEMD=y

[pavlix]

Vzhledem k tomu, že jsi to dokázal zhodnotit a rozpoutat na toto téma diskuzi, předpokládal jsem, že o tom alespoň něco víš a že sem nesypeš jen náhodné bláboly. Asi jsem se zmýlil.

[Peter Golis]

WTF? Poprosím detaily.

[pavlix]

Nevím, jaké detaily čekáš. Myslel jsem si, že se jen vyjadřuješ nešikovně nebo že naopak mně chybí nějaký kontext a špatně chápu, ale po tvém předchozím komentáři jsem změnil názor a jsem teď přesvědčen o tom, že vůbec nevíš, co píšeš.

[Peter Golis]

To, že Tebe chýba kontext nie je môj problém. Skús si prečítať odkazované články.

[pavlix]

Jen jsem nechtěl být zlý. To, že se nedokážeš vyžvejknout opravdu není moje chyba. Pleteš tu páté přes deváté, ani na dotaz nejsi schopný doložit souvislost mezi tím, co píšeš, a tím, na co odpovídáš, místo toho meleš něco vzdušných zámcích. Obávám se, že jsem ztratil o další diskuzi zájem.

[Peter Golis]

Akú súvislosť, môžeš byť konkrétnejší v tom čo Ti nie je jasné?

[pavlix]

Jedná sa o voliteľnú podporu pri ktorej SystemD overí či nebol naštartovaný OS do kompromitovaného stavu.

Tou dobou už je trochu pozdě řešit nějaký bezpečný boot, ne? :)

[Lol Phirae]

Počkej, neblázni, to jim nemůžeš takhle logicky rozbíjet nesmyslné bloatware hračky...

[pavlix]

Máš pravdu, to skutečně nemůžu, jen jsem napsal, proč jsem ten popis od Petera úplně nepochopil.

[Lol Phirae]

Já myslím, že na tom clusterfucku není moc co k pochopení, prostě už se definitivně pomátli. Jeden z popisů možného "fungování" tady v diskusi padl. Pokud si tohle někdo dobrovolně nacpe na svůj počítač, budiž mu země lehká. V té době ale já už na Linuxu rozhodně nepojedu.

[egg]

Resistence is futile.

[xm]

Přestože systemd používám a vyhovuje mi, tak mi to přijde už skoro úsměvné Už jen čekám, kdy Lennart ohlásí, že do systemd zařadil kernel... je to vlastně takovej novej EMACS

[TM]

To už není moc legrační. Je spíše smutné, kam až prznění linuxových dister může dojít za radostného hýkání frikulínů.

[mikirc]

A bude ve finalni verzi systemd pouze jeden soubor pro spusteni a jeden konfigurak? Kdyz vse v jednom tak poradne.

[NemamRadSystemD]

Konfigurak nebude. Stateless voe!

[Hans1024]

Nebo tam bude konfigurace ve stylu registru a bude pribalena jako soucast te binarky

[nyan]

Priste prosim zpravicku az se Lenart rozhodne neco NEzaclenit. To by byla skutocne novinka

[Jardík]

Rozhodl se nezačlenit patche na podporu kompilase s musl C knihovnou, prej glibc rulez them all.

[Lol Phirae]

Lennarte, dej si gumoléčbu do palice.

[the.max]

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář

[pushkin]

Drsně!

[jiri.one]

Vtipné :). Rozhodně zábavnější než Lennartovo oznámení ....

[Pavel Půlpán]

+1

[pavel]

Co by asi hosan rikal na to, kdyz se kdbus patch nakonec neprijme a u cgroups by se co tri mesice prekopavalo API nebo se kompletne opustily ? Porad by tvrdil ze Linux je jen implementacni detail ?

Mozna nastal cas, aby zacal ochutnavat vlastni medicinu

[pavlix]

Co by asi hosan rikal na to, kdyz se kdbus patch nakonec neprijme a u cgroups by se co tri mesice prekopavalo API nebo se kompletne opustily ? Porad by tvrdil ze Linux je jen implementacni detail ?

Myslím, že ano.

[sonma]

Forknou jádro ? Už na to vyčlenili manpower ?

[pavlix]

Co je mi po tom :).

[Grunt]

LOL, ještě jste měli zalinkovat ten origo článek v němčině. To jsou hlody jak sviňa. Doufám že další verze sysetmd vyjde kompletně a pouze v němčině. To už bych asi fakt smíchy padnul na zem než by mi vůbec počítač nabootoval. Jinak jestli to dobře chápu, tak to vůbec nechápu. Na co cpe UEFI boot manager do systemd? Co chce ze systemd načítat UEFI image a jádra?

[Lol Phirae]

"Why stop at the bootloader? Go for the BIOS!"

[omg]

budes mit spravu kontejneru primo misto menu grubu.

[frdrx]

Tak tomuto nerozumím už ani já. Mohl by mi to někdo prosím pomoci pochopit?

[Lol Phirae]

Ententýky dva špalíky, čert vyletěl z metra.

[frdrx]

Díky, to mi moc pomohlo.

[Petr Ježek]

Jako obvykle,když jde o systemd. Man systemd

[omg]

nechapu, proc ho tak setris. vzhledem k obsahu minulych reakci si zaslouzi leda tak poslat do prdele, zapsat na seznam nezamestnatelnych imbecilu a zkostnatelych dinosauru.

a krom toho navic nad ramec jeho obvyklych reakci je sam jeste neschopnych formulovat vlastni nazor cekajici jako relay na zpravu generalni rady, kterou bude papouskovat. ocividne vzhledem k epidemii je narusena distribuce propagandistickeho materialu a frikulynskych drog.

[HonzaRez]

Špatně kolego. Ententýky dvě hmoždinky, mladý člověk šel z metra, byl čepici a obutý a nic se mu nestalo...

[mankind_boost]

Lennart. 'Nuff said.

[pavel]

Tipuju ze do konce roku to uz konecne dojde i tem nejvetsim reatrdum

[frdrx]

Uvidíme. Dám případně vědět.

[Heron]

Za to já to právě pochopil. Chtěl jsem napsat komentář, že zajisté nebude pro místní Lennartboys problém to vysvětlit. Je.

Tohle (a všechny předchozí ohlášení) byl totiž Lennartův test toho, jak daleko se dá ve stupiditách zajít. Evidentně už došel na konec.

[R]

Obavam sa, ze nedosiel...

[Michal Kubeček]

Tak optimistický bych nebyl. Dokud neuvidím, že prozřel Cristian Rodriguez, neuvěřím.

[Grunt]

Ne, ale vážně: K čemu je gummiboot v systemd vlastně dobrý? Ať to pročítám jak chci, nějak na to nemůžu přijít.

[j]

Potrebujou prece nejak nastartovat ten systemd-dhcpd-server ne ... ??? Ten poskytne systemd-dhcp-klientovi IPcko, nacez nastartuje systemd-svn-server aby se overilo, ze tvoje verze je binarne kompatibilni se schvalenou verzi, nacez se sosne systemd-kernel a ten se spusti.

Jakykoli pokus o naruseni procesu bude radne zalogovan a odeslan k posouzeni do nsa.

[pavlix]

Potrebujou prece nejak nastartovat ten systemd-dhcpd-server

Pokud vím, žádný systemd-dhcpd neexistuje, jen systemd-networkd a libsystemd-dhcp. Stavět na něm vtipy vyžaduje dost fantazie :).

[Jakub Lucký]

Bohužel, stavět vtipy na systemd-* nevyžaduje přiliš fantazie, stačí se podívat 0pointer.de a tragikomedie je dost...

[pavlix]

To nic nemění na trapnosti výše uvedeného.

[JZD]

A co Bulánci, jedou?

[Lol Phirae]

Vydrž, Prťka, vydrž! Hned co dodělá systemd-biosd

[R]

systemd-corebootd.

[Jesus Jimenez]

systemd-motherboardd

[Conscript89]

systemd-butterflyd, ale to uz umi Emacs

[R]

systemd-emacsd vyriesi vsetky problemy.

[Martin Matějek]

Aha, takže tohle je cíl - Systemd jako kernel a Emacs jako userspace. Konečně to dává smysl

[mc]

)) Při čtení diskuzních vláken pod zprávičkami "systemd" se často válím smíchy - ani tentokrát to není vyjímka. Doufám, že mi smích vydrží až budu muset opustit aktuální Debian stable.

[ced]

No, Debian testing zatím funguje i se sysV. Jinak bych musel potupně přejí na widle (jinam nemůžu kvůli pracovním aplikacím). SystemD má na mém počítači existenční problémy - tu nefunguje síť, tu se v další verzi každých 20 sekund uspává ... Nejsem asi SystemD kompatabilní.

Docela mě ten kus kriplewaru děsí.

[kralyk z abclinuxu]

Z té diskuse bych sem pastnul zajímavý kousek:

Matthias Klumpp:

+Lennart Poettering Is there a reason for not creating a "systemd project" as umbrella project like "Mozilla", with the goal to provide the complete Linux plumbing layer? By doing that, most of the optional bits could be provided in separate repositories with independent releases, and still be seen as part of "one solution". This might make bootstrapping a system using systemd easier, and also would maybe reduce some of the criticism that systemd is pulling in too much stuff. In any case, I like the newest addition, and as long as it is optional, nobody should have a problem with it 

Lennart Poettering

+Matthias Klumpp I don't see how splitting up repos does any good. I don't see how this makes anything easier for anyone. It certainly makes things a lot more complex for downstreams, since they would have to package 20 packages, instead of just one. And more importantly, for myself: it would make hacking systemd a ton more difficult. Our internal C helpers in src/shared/*.c make hacking on systemd relatively easy. This extensive set of helper functions is one of the reasons we are so productive... If we wanted to make use of that in external projects we'd have to stabilize their API, but that would mean dealing with API breakages, and we couldn't just sed through our tree to fix things up.

People learnt to accept that the Linux kernel is a single repo, too, including the core kernel, but also all subsystems, drivers, and now even client side tools. People also learnt to accept that glibc includes libm, libc, libresolv, libpthread and so on. Things aren't that different for systemd here...

Mít účet na G+ tak tam snad něco i napíšu, protože to je akorát smradlavý alibismus tohle. Nic z toho co jmenuje absolutně není problém. Knihovna C utilit pro interní účely by klidně mohla mít nestabilní API - koho to zajímá. To samý balíčky - 20 balíčků je jakože nějaký velký číslo? Viděl ten člověk někdy KDE4? IMHO naopak většina dister by měla radost, že si to můžou rozškatulkovat dle libosti.

Tohle mě fakt vysírá.

[little.owl]

Nic z toho co jmenuje absolutně není problém.

Vytvaret nekolik repozitaru aniz by se castecne rozdelil projekt a alespon trochu stabilizovaly interfacy nema skutecne smysl.

Tech projektu, kdy se naopak vsechny 'nezavisle' komponenty a moduly nakonec nacpaly do jednoho repositare, aby se to cele trochu stabilizovalo, a vyvoj a testing synchronizoval, jsem zazil uz pomerne dost.

[kralyk z abclinuxu]

Vytvaret nekolik repozitaru aniz by se castecne rozdelil projekt a alespon trochu stabilizovaly interfacy nema skutecne smysl.

No právě!

Tech projektu, kdy se naopak vsechny 'nezavisle' komponenty a moduly nakonec nacpaly do jednoho repositare, aby se to cele trochu stabilizovalo, a vyvoj a testing synchronizoval, jsem zazil uz pomerne dost.

Jo? Tak to mně přijde, že trend je ve většině případů přesně opačný. (Ačkoli výjimky určitě existujou.)

[little.owl]

Jo? Tak to mně přijde, že trend je ve většině případů přesně opačný. (Ačkoli výjimky určitě existujou.)

Mozna u opensource, a jeste jen nektereho - viz. kernel. Kdyz na jedne strane tlaci deadliny a na strane druhe nerealisticke sliby obchodniku, je casto jedna repozitory s CI cesta. Pokusy mit nezavisle vyvijene verzovane moduly, ze kterych se neco sklada na zakazku, mi v praxi mimo vylozene high level bloky moc nefugovaly, prace spojena s narazovou integraci zabila vetsinu moznych benefitu.

[Heron]

Nepopsal jsi právě spíše důvody pro rozdělení? OSS se na žádné termíny nebo stupidní sliby obchodníků ohlížet nemusí, tak se může zaměřit na kvalitu kódu a projektu samotného.

[x]

OSS se na žádné termíny nebo stupidní sliby obchodníků ohlížet nemusí

Ha ha ha.

[Josef Kufner]

Open source a komerčnost jsou dva velmi odlišné parametry. U nekomerčního open source opravdu o termíny nejde, u toho komerčního obvykle ano.

[Grunt]

Přesně tak. Otevřený software ještě nijak neimplikuje, že nejde o software komerční. A zde je názorně vidět jak to potom dopadá

Prostě „Stallman was right…once again“.

[kralyk z abclinuxu]

Mít účet na G+ tak tam snad něco i napíšu, protože to je akorát smradlavý alibismus tohle.

Hmm, tak jsem to nakonec udělal a bylo mi odpovězeno, že - TL;DR - větší modularita zkrátka nebude.

[noo]

Takže se spustí GRUB, ze kterýho se zavede nějaký tenký jádro, které spustí systemd, které spustí gummiboot, který zavede normální jádro, to předá kontrolu systemd, který zavede zbyle moduly a smaže to tinyjádro z paměti.

heštekFuture, já chci v systemd Minecraft!

[little.owl]

Ted jeste systemd-hypervisor do ktereho se nabootuje!

[Jiří J.]

Tím může být klidně systemd samotný, spouštějíc jednotlivé "systémy" přes systemd-nspawn.

[Michal Kubeček]

Lidi, vy jste nepoučitelní… To si pořád ještě myslíte, že dokážete přijít s myšlenkou tak absurdní, aby ji Lennartboys nebyli schopni realizovat?

[smutik]

:), davaju inzinieroviLennartovi nove namaty a napady, uz sa tesim ako od roku 2020 napcha do systemd cely windous a v roku 2022 aj McOX

[pavlix]

A v roce 2025 ho v televizi budou jmenovat tituly jako otec internetu a v roce 2035 už se o něm bude učit ve školách, že ve spolupráci s ostatními hackery vytvořil Linux. Historie se na detaily neptá :).

[mikirc]

v té době už Linux nebude bude systemd/OS a linux bude něco jako dneska dos. Spousta lidí ví, že něco takového existovalo, ale co to bylo už neví.

[little.owl]

Historie se na detaily neptá :).

V 2050 bude povazovan za vynalezce zarovky, a v 2070 za mirotvorce od Stalingradu .

[the.max]

hezký, lepší než vtipy o Norrisovi, akorát že těch o Lennartovi je pořád méně, ale jak tak koukám, rychle se to zlepšuje

[PetrHL]

Mozna se ptam blbe, mozna jsem se na to uz jednou (blbe) ptal, ale okolo vyvoje systemd se nepohybuje nikdo, kdo by mel trochu praxe z realneho nasazeni a realne se musel starat o nejake stroje? Aby to nakonec nedopadlo jak s nasimi politiky, kdy drtiva vetsina nikdy nic nedelala, jsou tam uz od skoly a k realnemu zivotu lidi nepricuchli.

Spravoval Lennart nejake servery? Tusi vubec jak to vypada v praxi? Ne, ze bych se ja ve sprave serveru nejak extra orientoval, ale kdyz nadava i takovy Heron, ktery tomu ocividne rozumi, ma praxi a vi co a jak? Oni v teamu nikoho takoveho nemaji? To tam vsichni ziji v bubline? Same otazky :(.

[Heron]

Spravoval Lennart nejake servery?

To by mě taky zajímalo. Systemd na ostrých serverech ještě nemám (to bohužel přijde s nasazením RHEL7), hraju si s tím na soukromých serverech a to včetně úžasného journalctl. Kromě toho, že se 50% souborů journálu pokazilo (což LP nijak netanktuje), tak se s tím hlavně vůbec nedá pracovat, jak je to pomalé. Aktuálně mám 3GB v journalu (journalctl --disk-usage) a úplně obyčejné journalctl -b (last boot) a stisk END (tj. dostat se na konec, práce v obyč less) je mnohaminutové čekání.

A to se na tom serveru dohromady nic neděje, nic se neloguje. Nejvíc hlášek v logu (co do počtu) je od postfixe, přičemž na ten server přijde tak 200 emailů za hodinu ve špičce. Jako tohle nasadit na ostrý emailový server s provozem 200 tis. za den, tak to můžu logovat rovnou do /dev/null, protože v journalu bych se k těm logům stejně nikdy nedostal.

A to běžně přes less prohlížím 6GB textové logy, takže přibližně vím, jak by se to mělo chovat. (less 6GB log, END, do 1s jsem na konci).

Teď mi jistě kde kdo napíše, že journalctl používám špatně, že když chci na konec, tak potřebuju přepínač xy. To si rovnou odpusťte, standardní nástroje s logy nemají nejmenší problém.

# time journalctl -b -u postfix.service | wc -l
60560

real    1m20.408s
user    0m25.304s
sys     0m57.636s

[Heron]

Jen pro srovnání (cca 6GB, ale hlavně 200x víc řádků):

# time cat postgresql-9.4-main.log.1 | wc -l
10077588

real    0m51.807s
user    0m0.744s
sys     0m8.368s

Má někdo vysvětlení pro to, co journalct dělá 57s v kernelu (SYS)?

[sonma]

Má někdo vysvětlení pro to, co journalct dělá 57s v kernelu ?

Tuším, ale nechci být sprostý :)

Zkus jim k tomu napsat bugreport. Jo vím, to nebylo moc vtipný…

[Jakub Galgonek]

A co vrátí time journalctl -b | wc -l?

[Heron]

# time journalctl -b | wc -l
348880

real    1m7.021s
user    0m29.372s
sys     0m30.804s

Ještě jsem hned po té (když soubory journalu už jsou 100% v IO cache), spustil znovu:

# time journalctl -b -u postfix.service | wc -l
60819

real    1m33.287s
user    0m25.048s
sys     0m58.940s

V DB žargonu bych řekl, že prováděcí plán není úplně ideální, když full table scan bez omezení je rychlejší, než možný index scan s omezením na 17% záznamů.

[ivan]

to bude tim, ze vsichni systemd vyvojari uz pouzivaji SSD disky

[omg]

to by mohlo byt won't fix a resolvnuty s vyhynutim dinosauru.

[tydýt]

jenom proto že stále používám rotační disky, jsem dinosaurus? to snad nemyslej vážně

[kralyk z abclinuxu]

No a proč nemáš nakonfigurované přesměrování do syslong-ng nebo rsyslog?

[Heron]

Mám. Ale k čemu je potom tedy ten vychvalovaný, indexovaný, zabezpečený journal? Jako průtokový ohřívač logů?

[kralyk z abclinuxu]

No to já nevim, já bych nejradši používal systemd bez něj... Jenže to se jaksi autoři neuráčili umožnit...

[j]

Tak to by neslo, to se musi zakazat, du napsat bugreport, ze si nekteri drze forwardujou logy do textu.

[Jesus Jimenez]

a ještě se k tomu drze přiznávají...

[j]

Tak sem to vymyslel, prave na to pisu patch, pravdepodobnost prijeti je 100%, to je jasny.

Journal bude sifrovanej, a klic bude mit vyhradne lennart, to aby nekoho nenapadlo podvadet a logy si cist, pripadne dokonce upravovat.

Vypis bude poskytovan na osobni zadost (zadny maily nebo dopisy), s minimalne 5ti uklonama, a 30ti lichotkama. Pochvalen musi byt kazdy systemd-.*

Vypis bude zasadne poskytovan ve tvaru:

#457AC87FB - Neznama chyba, blizsi informace na http://lennartware.de/457AC87FB

Pricemz na uvedene adresa bude vzasade vzdy informace:

Zadne blizsi informace o chybe #457AC87FB nejsou k dizpozici.

[omg]

cena za log bude 0,02 bitcoiny za znak na osobniho strazce projektu.

[Jiří J.]

Jako průtokový ohřívač logů?

(omlouvám se za komentář bez přidané hodnoty)

[the.max]

Jo, ten je taky dobrej

[michich]

Jestli můžeš, zkus to prosím i s journalctl z aktuálního gitu. V prosinci jsem v této oblasti commitoval několik vylepšení. (Pro test to postačí přeložit a spouštět výslednou journalctl binárku v aktuálním adresáři.)

[Heron]

Zkouším to na Debianu Jessie, systemd 215. Má smysl zkoušet zkompilovat 218?

[Heron]

v218 se chová následovně:

time ./journalctl -b | wc -l
359191

real    0m26.820s
user    0m22.904s
sys     0m1.348s

hned potom:

time ./journalctl -b -u postfix.service | wc -l
61982

real    0m10.631s
user    0m4.612s
sys     0m0.556s

Takže zrychlení je značné. Pokud je to tvoje práce, tak ti patří velký dík. Tohle už se používat dá.

[michich]

Asi jo, ale ve verzi 218 nejsou ty patche všechny. S verzí z gitu by to mohlo být ještě lepší.

[Heron]

Problém. Když jsem zkompiloval tag v218, tak ./journalctl logy našel.

Teď po kompilaci dab2bce81ed3e97d059d56e66f560aa25d9c2d63 to píše

./journalctl
No journal files were found.

a to ani když jsem mu nastavil cestu (-D).

Já už se tomu dál nechci věnovat, už tak jsem tomu dal víc času než jsem chtěl. Podstatné je, že už 218 vypadá docela použitelně a jestli se to bude ještě zlepšovat, tak je to jen dobře.

[Adam Pribyl]

Muj vypis journalctl k dnesnimu datu zobrazuje zaznamy od 27.9. do 4.12. a smytec.. journal se mi nekolikrat poskodil. V textovoych log souborech kam se snazim vse presmerovavat vse neni. Tail /var/log/message je vyrazne rychlejsi nez journactl -r.

Posledni aktualizace systemd za chodu systemu skoncila po desitkach radek systemd-sysv-generator blabla Could not find init script for blabla.servis chybou: systemd[1]: segfault at 55d4a80 ip 00007f1b99909416 sp 00007fffb41c2580 error 4 in systemd[7f1b998a8000+138000] od te doby byl system v metastavu - sice fungoval, ale nic nefungovalo, protoze systemd... Jedine reseni byl trvdy restart.

Tolik k tomu jak se na systemd da spolehnout.

[Heron]

Ano, mě se journal binární soubory také poškodily, jako jediná věc na zcela zdravém kompu. Lennartovo řešení: smazat. Jako, nejsou snad logy od toho, aby se zjistilo, co se stalo, že se to poškodilo? Neměly by se mazat jako poslední? Už jen tohle ukazuje na jeho přístup k systému, jak něco, co se prostě může zahodit na vytvořit znovu.

[omg]

ted je v mode zahazovani a znovy vytvareni... virtualu, kontejneru, hardware i administratoru. skoda, ze se zatim nedostalo i na blondate vyvojare.

[lnykryn]

Která verze systemd? 208, která je v rhel7, chybí pár výkonnostních patchů.

[lnykryn]

Na vyzkoušení pro rhel/centos7 tady je balíček poslední verze. Bohužel moc nespolupracuje se selinuxem a auditem. https://copr.fedoraproject.org/coprs/lnykryn/systemd/

[sonma]

Jako že by je zajímalo použití Linuxu v širším kontextu ? Jako i u neplatících zákazníků ? To snad ne ;)

Chtělo by to opustit bláznivou myšlenku, že jde o nějaké altruisty, kterým jde o nějaké obecné blaho v oblasti Open source a že svoje investice nechtějí a nebudou chtít kapitalizovat.

Až budeš mít neřešitelný komplikace s provozem serverů, se kterými sis dřív dokázal poradit než sis zavlík systemd, tak budeš nucenej platit si jejich support nebo si to komplet pronajmš. A plať.Těch věcí za co se začne platit a který byly doteď zadarmo asi bude přibejvat.

[pavlix]

Nesoulad mezi sysadminy a vývojáři je všudypřítomný :).

[sonma]

Jen do chvíle než to musí sami v praxi používat :)

[pavlix]

Jenže oni nemusejí, v tom je právě ten vtip. Jeden vývojář mi před časem, že dostal nabídku od Googlu dělat sysadmina a smál se tomu, jak jsou u Googlu blbí, že mu tu práci nabízí, když nikdy nic takového nedělal. Většina těch lidí z jedné skupiny nejspíš vůbec neuvažuje o tom, že by mohli dělat to druhé.

[sonma]

Vtipnejsi je, pokud se tomu tak opravdu stane :) Mohl bych vytahnout jeden priklad nejmenovaneho nadnarodniho SW-house, kde z duvodu reorganizace par vyvojaru skutecne slo delat spravce IS, ktery sami spoluvyvijeli. Nez aby skoncili na pracaku.

[pavlix]

Tohle většinou bývá věc rozhodnutí, pokud člověk není pevně vázaný na město, kde působí jediný zaměstnavatel. Mně osobně by nevadilo po sobě něco spravovat, ale já jsem asi trochu jiný typ vývojáře. Kolegům jsem často říkal, co bychom měli udělat, a dělalo se to až se zpožděním, když přišel stejný požadavek z praxe.

[Ivan]

Jsou admini, vyvojari a vyzionari. A jak rekl pred mnoha lety muj byvaly kolega: "Nejlepsi obrana pred vizionari, je dat jim moznost svoje vize naplnit". V tomhle pripade to ale nejak neplati.

[Sid]

To ano len akurat ta jedna skupina si mysli, ze je medzi nimi rovnatko co povacsine nie je.

[pavlix]

Nevím, do které skupiny patříš, ale v každém případě předpokládám, že tenhle názor přisuzuješ té druhé.

[sonma]

Jedna z dalších novinek systemd:

read ahead implementation dropped: in the age of SSDs the benefit is not big enough to have this. All systemd developers have SSDs and no more spinning disks, nobody could/wanted to support this anymore. The idea was to read-ahead the bits needed during the boot process and remember it next time, for faster boots. But with SSDs, this support is dropped

Soudruzi z Red Hat jedou na SSD a tak jsou rotační HDD pasé. To už ani není vtipný

[kozzi]

Tak ja jsem to pouzival a opravdu to ten boot (v mem pripade) trochu zrychlilo. Nadruhou stranu je to jedna z funkcionalit, kterou klidne ozelim. Ono to hlavne nemuselo pomoct vzdy. Takze udrzovat neco takoveho opravdu v dnesni dobe nedava moc smysl. Nehlede na to ze i ja uz mam skoro vsude SSD pro system.

[pavlix]

Sami zjistili, že je read ahead slepá ulička, tak proč se s tím trápit dál.

[sonma]

Jak "slepá ulička" ? Tam není zdůvodnění že by to bylo neefektivní, neudržovatelné nebo jiná technická příčina. Jasně píšou že "o věku SSD" a že "všichni systemd vývojáři mají SSD". Tak že politikum, navzdory realitě kolik se ještě prodává počítačů s HDD a na jakém HW se už používá.

[pavlix]

Tak funguje open source. Jestliže ve vývojářské komunitě není o nějakou funkcionalitu zájem, tak se buď nechá vyhnívat, nebo se odstraní jako nadbytečná. Jestliže někoho zajímaly vteřinové rozdíly v bootování systému, tak si SSD už pořídil. Ostatní se postarali o to, aby bootovali co nejméně. Jestliže se jimi chce někdo zabývat na HDD, kód je k dispozici. Jestliže si někdo přeje, aby kód byl nadále součástí upstreamového systemd, smůla. Nevidím důvod se pozastavovat nad takovými prkotinami, ten projekt má mnohem zajímavější a dalekosáhlejší důsledky.

[sonma]

Nevím proč tak obšírná obhajoba. Tady nejsi u soudu a ani advokát.

Jen jsem poukázal s jakým (dis)respektem ke skutečným i potenciálním uživatelům uvažují. Pokud si to někdo nedokáže přebrat nebo vědomě ignoruje, jeho věc že padá do pasti.

[pavlix]

Nevím proč tak obšírná obhajoba.

To ale vůbec není obhajoba, i když to tak z vnějšího pohledu může vypadat. Jsou to jen moje zkušenosti s tím, jak open source vývoj obecně funguje.

Jen jsem poukázal s jakým (dis)respektem ke skutečným i potenciálním uživatelům uvažují.

Můj názor je, že sis na to vybral špatný příklad. Jednak se jedná o naprostou prkotinu, jednak je v podstatě celkem dobře zdůvodněná a jednak zrušili podprojekt, který byl podle mě od začátku omyl a vůbec neměl vzniknout.

Pokud si to někdo nedokáže přebrat nebo vědomě ignoruje, jeho věc že padá do pasti.

Obecně bych s tebou i souhlasil, ale v tomhle případě se obávám, že jsi se vyhnul pasti jen proto, abys spadl do té o kousek vedle a ještě stáhl další s sebou. Slabá kritika je jedna z věcí, na které je úspěch systemd kabal vystavěn. Stačí si zajít na pár přednášek nebo sledovat propagandu šířenou po internetu. Jednou z možností jak se vyhnout reakci na kvalitní kritiku je neustále reagovat na tu nekvalitní.

[Sid]

Ty sa na to pozeras uplne zle. Oni nemaju neobmedzene moznosti a cas na podporu vsetkeho. Takze ked to naozaj potrebujes mas niekolko moznosti. Bud sa toho chytis a budes to udrziavat, alebo ich ty a vela dalsich ludi presvedci, ze naozaj to chceme a posledna moznost je, ze si to zaplatis. Co je na tom nerespektovanie? Myslim, ze viacero ludi tu by ti vedelo dat priklad ako sa "optimalizuju" ludske zdroje v programovani a naraz by si videl, ze ten clovek obcas skace medzi vecami ako kon po sachovnici a nema sancu (moznost,chut) niektore veci robit. Nie ze by nevedel, nechcel ale medzi x kritickymi vecami musis tie menej kriticke zahodit. Staci si pozriet obcas JIRU na projektoch a hned vidis co a ako.

[xm]

No nechci se zastávat takovéhleho arogantního přístupu, ale na druhou stranu zrovna read-ahead při bootu považuju za naprostou zbytečnou složitost, jen kvůli tomu aby se o pár sekund urychlil boot (který navíc stejně člověk dělá jen jednou za uherák ). Prostě zbytečný bloat...

[Heron]

Ano a já pravidelně na pivku s redhatáky poslouchám, jak dostali nové ntb a že budou testovat nějaké další serverové appky. Nevím, do jaké míry je to provokace vůči mě (jednak nesnáším ntb, když mi v práci nutili celkově už šestý za 7 let, tak jsem ho dal kolegovi a hlavně dělám na serverech), každopádně kdejaký test serverového něčeho, typicky moderního multidevice fs (kterému je nejlépe na hromadě disků) se zásadně provádí na ntb a na jednom disku.

Readahead mi nijak nechybí, to jsem nikdy nezapínal, ale arogance je to bezbřehá.

[sonma]

Na slabším notebooku s HDD ≤ 5200rpm je ale readahead fajn, start náročnějších aplikací jako LibreOffice se o hodně urychlí. Dost citelný když se spouští jako asociovaná aplikace třeba při otvírání příloh mailů.

Komentář nebyl ale ani tak read ahead ale o jejich přístupu a sebestřednosti.

[xm]

Notebook se nevypíná, ale uspává Momentálně mam na svém notebooku uptime asi 14 dní A i kdybych ho vypínal o něco častěji, pořád těch pár sekund neospravedlní takový zbytečný bloat jako je read-ahead v initu...

[sonma]

Nejsem si jistý jestli chápeš o čem readahead je. Pokud ti aplikace jako Libreoffice se spoustou rozlezlých sdílených knihoven trvale neběží, tak ti dřív nebo pozděj zmizí z cache i swapu a bude se zase startovat dlouho jak raketoplán Endeavour. Nemá s problémem suspend vs shutdown nic společného.

[xm]

He? A od kdy jako readahead v init systému řešil cokoliv jiného než jen služby spouštěné při bootu init systémem? Spuštění LibreOffice ti systemd s readahead fakt nikdy neurychlovalo (pokud si tedy LibreOffice nespouštěl rovnou při bootu pomocí systemd), zjevně si tedy žil v bludu a nechal se oblbnout placebo efektem

Z manuálové stránky:

systemd-readahead-collect.service is a service that collects disk usage patterns at boot time. systemd-readahead-replay.service is a service that replays this access data collected at the subsequent boot.

[sonma]

Dobře, tenhle readahead kešoval systémové služby a příklad s Libreoffice se spíš týkal readahead daemona jako preload, ale to na tom snad nic nemění ? Pořád jde o to, že se odebrala tahle možnost jak urychlit čas startu programu-služby a to z důvodů výše uvedených. Zvlášť když většina je ve výchozí konfiguraci ondemand.

[Michal Kubeček]

No, kombinace "read ahead" a "on demand" mi přijde skoro tak uhozená jako čísi nápad, že se cups démon nebude spouštět normálně při bootu ale přes socket based activation, ale aby bylo možné vylistovat tiskárny, spustí se při přihlášení uživatele automaticky příkaz, který vynutí jeho spuštění.

[pavlix]

+1

[Jakub Galgonek]

Ale to s tím cups snad není problém systemd, ne?

[Michal Kubeček]

Ne přímo systemd jako takového, ale je to IMHO názorný příklad, proč je socket based activation velmi pochybný koncept, který by se neměl slepě používat všude, kde to jde, jen proto, že to jde a že je to cool. Pokud se nebojíte ukroucení hlavy, doporučuji podívat se na tento bug.

[Lol Phirae]

Pokud se nebojíte ukroucení hlavy, doporučuji podívat se na tento bug.

Vzdal jsem to. Pokud někdo diskutuje ve 150 komentářích bug, který existuje jen díky "Lennartware" vylepšení "koncepce", je to prostě ztracené. Nějak jsem si nevšiml, že by před existencí Lennartova clusterfucku někdo masivně volal po tom, aby se cups spouštěl přes (x)initd, protože jinak běží zbytečně. Čím to asi tak bude.

[pavlix]

Stejný problém mohl nastat s xinetd a podobnými.

[Lol Phirae]

Ano. A proto takovou píčovinu nikdo nedělal, že. Ale je nová doba, a co nepoužívá Lennartware, tak je špatné.

[pavlix]

Teorie zajímavé, nicméně pak stojí za úvahu, jestli náhodou takových lennartů už nebyla spousta a neměli jen prostě tu smůlu, že nepřišli do té správné doby.

[Lol Phirae]

Ano. Až dnešní doba je nakloněna nejrůznějším debilitám. Asi to bude i nebývalým nárůstem debilů v populaci.

[Michal Kubeček]

Spíš my štěstí… Ale musím přiznat, že mnohem víc než Lennart a jeho klika mi v žaludku leží ti, kdo místo aby včas řekli "Sorry, kamaráde, ale dokud tvůj projekt nebude schopen/ochoten rozumně koexistovat s ostatními, do distribuce nepůjde.", přivítali to kukaččí mládě s otevřenou náručí a naopak vyházeli všechno, s čím si systemd nerozuměl.

[pavlix]

Taky si myslím, že úspěch software se odvíjí od jeho přijetí a nikoli od jeho naprogramování a házet všechnu vinu na vývojáře je nesmysl.

[lima]

+1

vidím to podobně

[j]

Ja si porad jeste myslim, ze se jim to vrati i s urokama. Specielne tem, co se tim zivi = chteji za to prachy. Ono az nebudou schopni zakaznikovi rict, proc to pada, protoze jim to pozere i logy, az se s "prekvapenim" zjisti, ze stroje maji hromady a hromady otevrenych portu do sveta - proste proto, ze se nekde zalatala nejaka dira a zaroven se zmenilo chovani neceho ...

Prvni kdo zacne rvat budou pochopitelne sysadmini, to az jim skonci support a budou muset jid do upgrade. A kratko na to zacnou rvat managori (samo na ty adminy). A pak budou spolecne rvat na dodavatele.

[Heron]

+1

Tohle půjde cestou Windows. Nakonec to bude takový moloch, který neudrží pohromadě ani sám sebe. Vzhledem k tomu, že ti lidi nemají ani páru, proč unix 40 let funguje a opakujou stejný chyby jako třeba zmíněné windows, tak to musí dopadnout úplně stejně.

[Jakub Galgonek]

Tak pokud bych chtěl cups spouštět vždy při startu, tak prostě udělám:

systemctl disable cups.socket
systemctl enable cups.service

Já mám cups nastaven na socket activation, loguji se do KDE a dokud nechci tisknout, tak se mi cups nespouští.

Co se týče té chyby, tak jsem ji letmo prolítnul a jestli jsem to správně pochopil, je to chyba v konfiguraci cups a nejde o chybu systemd.

[Michal Kubeček]

Tuhle logiku miluju: jako úžasná výhoda systemd se prezentuje, že se systemd všichni dostanou prefabrikované unit files perfektně se hodící do všech distribucí. Jakmile je s nimi ale sebemenší problém, hned je to "chyba v konfiguraci cupsu". (Když budou fungovat dobře, bude to zásluha systemd.)

Ale abych stručně shrnul ten bug. Původní problém byl v tom, že při socket based activation ten socket musí vytvořit a nabindovat už systemd, který nečte konfiguraci cupsu, takže vždy poslouchá na wildcard adrese, což není ani zdaleka žádoucí. První pokus o řešení bylo, že tedy ten socket necháme defaultně poslouchat jen na 127.0.0.1, jenže, ouha, pak nefunguje announcing, protože ten potřebuje broadcast. V tu chvíli Johannes došel k tomu, že nejlepší řešení je se na celou slavnou socket based activation vykašlat, protože víc problémů přináší než řeší a pro tento typ služby se prostě nehodí; tak se prostě cupsd spustí normálně jako vždycky a bude klid. To neprošlo, protože socket based activation je killer feature, která se prostě použít musí, to by tak hrálo, aby se cupsd spustil dřív, než někdo bude tisknout. Tenhle problém se nakonec podařilo obejít pomocí nějakých generátorů, které z konfigurace cupsu vygenerují konfiguraci pro systemd (super, hlavně že jsme se před časem s velkou slávou zbavili SuSEconfigu, protože jsme přišli na to, že generovat z jednoho konfiguráku druhý není nejšťastnější řešení).

Pak ale vyvstal další problém: dokud se cupsd nespustí, nejdou v KDE vylistovat tiskárny. Hm, co s tím? Ne, opět nebudeme spouštět démona normálně, to by bylo moc oldschool. Takže se dostáváme k tomu "geniálnímu" nápadu, o kterém jsem se zmínil výše: démona budeme sice spouštět přes socket based activation, ale jakmile se někdo naloguje, spustíme "lpstat -a", který zařídí, že… ano, modří už vědí… Že bych byl jediný, kdo z toho celého má pocit, že v Kocourkově byli žabaři?

[Jakub Galgonek]

No, já na to mám trochu jiný pohled. Pokud se používá socket aktivace, pak to, na čem se poslouchá, se nastavuje v .socket souboru. Pokud zdrojem těchto informací má být konfigurační soubor cupsu, pak se prostě musí napsat generátor, který podle něj vygeneruje správný .socket file. Bohatě by ale snad stačilo si správně (ručně) nastavit ten socket file. Na druhou stranu, pokud ten generátor bude generovat konfiguraci do /run/systemd/generator/, pak není problém s tím, že by v systému byly dvě konfigurace (jako se SuSEconfigem), protože perzistentní bude stejně jen ta jedna. Ale musel bych se podívat na detaily, tak moc do toho zase nevidím.

Jinak jak je to s s tou aktivací cupsu při loginu, nevím. Mně se cups při loginu nespouští, spustí se mi až ve chvíli, kdy dám v něčem "soubor->tisk".

[Lol Phirae]

Jinak jak je to s s tou aktivací cupsu při loginu, nevím. Mně se cups při loginu nespouští, spustí se mi až ve chvíli, kdy dám v něčem "soubor->tisk".

Můžu se zeptat, na kterou tiskárnu tiskneš, když není žádná vidět, protože holt jaksi cups neběží? (Bavím se o prinserveru a tisku přes síť. To je něco, co desítky let fungoval, než přišel Lennartware s NIH syndromem a jeho socket kokotinama.)

[Jakub Galgonek]

Tisknu pouze na síťové tiskárny. Ve chvíli, kdy otevřu print dialog, tak se spustí cups a zobrazí se mi seznam tiskáren.

[Josef Kufner]

A jak ti funguje autodetekce tiskáren na síti? Nebo to máš nakonfigurované vše ručně?

[Jakub Galgonek]

Ručně.

[Lol Phirae]

Bezva pokrok.

[Jakub Galgonek]

Chápu to správně, že cups při startu detekuje tiskárny, zapíše je do nějakého souboru a odtud jejich seznam načítají klienti?

[Josef Kufner]

Cups poslouchá broadcast oznámení od okolních tiskáren a pamatuje si je (démon, žádný soubor), takže když pak chceš tisknout, automaticky ti dokáže nabídnout všechny tiskárny na místní síti.

Tedy v praxi to vypadá tak, že připojíš v kanceláři nové PC a okamžitě můžeš tisknout na vedle připojené síťové tiskárně bez jakékoliv konfigurace. Prostě ji uvidíš a bude to tisknout.

Pak také respektuje, když nějaká tiskárna o sobě tvrdí, že je defaultní. Tedy když přeneseš notebook domů, budeš automaticky tisknout na domácí tiskárně.

Současně také můžeš jediným zaškrtávátkem vybranou tiskárnu zveřejnit ostatním na síti.

Proto je žádoucí, aby Cups nastartoval okamžitě při bootu. Socket activation může být použita jen pro ostatní démony, aby chvilku počkaly než Cups naběhne, ale jinak to je na nic.

[Jakub Galgonek]

Díky, v tomhle use case je socket aktivace opravdu na škodu.

[Lol Phirae]

https://www.cups.org/documentation.php/doc-1.5/sharing.html

CUPS browsing works by periodically broadcasting information about printers that are being shared to client systems on the same subnet. Each client maintains its own list of shared printers, and when more than one server shares the same printer (or the same kind of printer) the client uses all of the servers and printers to provide high-availability and failsafe printing.

To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.

[j]

Pokud by ses podival aspon na prvnich 10 postu v ty sileny diskusi, tak slo mimo jine a predevsim o vychozi konfiguraci. A pokud je vychozi konfigurace ze se vse otevre do sveta, tak ten, kdo to takhle napsal je proste magor.

"Mně se cups při loginu nespouští, " => nemuzes videt tiskarny.

[Heron]

Pokud zdrojem těchto informací má být konfigurační soubor cupsu, pak se prostě musí napsat generátor

A tohle má být ta výhoda systemd? Že místo "zastaralých, složitých, těžkopádných" (a já nevím jak se ještě nálepkujou původní RC scripty) se vyrobí generátory (na každou službu zvlášť), které to potom naservírují systemd? Opravdu máš pocit, že tohle je vylepšení?

[pavlix]

To mě hodně pobavilo. Je jasné, že ty složité a těžkopádné initskripty měly vždy svůj důvod, ať už to bylo lajdáctví jejich autora, obcházení nepříjemností způsobených samotným software nebo potřeba řešení nějakých věcí okolo, tedy že složitost není vlastnost initskriptů jako konceptu, ale jen jednotlivých kusů, i kdyby těch složitých bylo velké množství.

Na druhou stranu tohle celé není ani tak o formátu jako o socketové aktivaci. Celá ta věc s aktivací za pomoci TCP/IP socketů je o tom, že se zodpovědnost za poslouchání na síti přenáší z jednotlivých služeb na supervizor (ať už je to inetd, xinetd, systemd nebo cokoli jiného) a tedy je nutné přenést i informaci o tom, jak má být socket nakonfigurovaný.

Administrátor ví, že používá socketovou aktivaci a tudíž může nakonfigurovat přímo ten supervizor, to je jedna možnost, jak to řešit. Možnost generování konfigurace z konfigurace samotné služby mi přijde dost divoká a bude to mít spoustu problémů. Samozřejmě je vždycky možnost socketovou aktivaci nepoužít. Pokud by se to mělo stát pravidlem, pak ovšem systemd ztrácí kus svého kouzla, že.

se vyrobí generátory (na každou službu zvlášť), které to potom naservírují systemd

A ještě se musí systemd říct, že se má reloadovat, aby si vůbec ty generované konfiguráky vzalo.

[Lol Phirae]

Samozřejmě je vždycky možnost socketovou aktivaci nepoužít. Pokud by se to mělo stát pravidlem, pak ovšem systemd ztrácí kus svého kouzla, že.

Já v tom žádné kouzlo nespatřuji. Prostě jsou služby, které musejí stále běžet a spustit se při startu systému, aby plnily svou funkci. Mailserver taky nikdo příčetný nespouští on-demand, aby přijal přes SMTP mail, že. No a pak přijde systemd blb, který k tomu sdělí, že to je insane, že stále běžící služba je hrozná pitomost a pokud to správce balíčku nechápe, tak je nutné ho vyrazit, protože v 21. století používáme sockety a přes to nejede vlak.

[Jakub Galgonek]

V tom případě prostě použijete cups.service.

[Lol Phirae]

To už jsme si probrali výše, že (lpstat -a).

[Jakub Galgonek]

Na co přesně narážíš?

[Lol Phirae]

Že kuafix nejsou vidět ty tiskárny... Chjó, to jsme si psali s nějakým tvým dvojníkem, nebo co?

[Jakub Galgonek]

Ne, jen jsi mne nepochopil. Když použiješ cups.service, tak cups se spustí hned při startu a tiskárny pak vidět jsou.

[Lol Phirae]

Něrabótajet. Abych to tak nějak shrnul, "díky" Lennartovi a jeho kundovinám je již přes rok v Suse rozbitý tisk. Skvělá práce, Bill Gates musí mít radost.

[Jakub Galgonek]

Neházel bych na Lennarta, že v Suse blbě použili socket aktivaci.

[Lol Phirae]

Boha mojho, o socket aktivaci není řeč, ta je v daném případě zcela nepoužitelná, na čemž jsme se ostatně shodli. (Schíza?!) Ona nefunguje správně ani ta služba, stejně se to při startu nespouští, protože to celé je to celé tak úžasně zjednodušené pro 21. století, že už se v tom sajrajtu nevyzná ani prase. (A když se to náhodou spustí, tak pro změnu nefungují lokální tiskárny. No prostě paráda, ježíííš já su tak šťastné že tu máme ten pokrok!)

[Jakub Galgonek]

Ano, socket aktivace je v tomto případě nepoužitelná. A Lennart jako může za to, že ji v Suse přesto použili?

Za jakých okolností že se to nespustí cups.service, pokud je enabled (a cups.socket je disabled)?

[Lol Phirae]

Za jakých okolností že se to nespustí cups.service, pokud je enabled (a cups.socket je disabled)?

Nespustí to, pokud to není navázáno na jakousi multi-user.target vopičárnu. Po opravě to pro změnu nedetekuje lokální tiskárny. Ne, vopravdu, není nad to rozmrdat naprosto triviální léta funkční věc Lennartovým clusterfuckem a nadšeně hýkat o pokroku 21. století.

[pita]

Ne ne, chyba je na tvojí straně.
Za prvé systemd nevhodně používáš. Chtít automatický seznam dostupných tiskáren je přežitek. Reagovat na UDP broadcasty je ideový negativismus. Naopak jako soudružský projev vstřícnosti je naslouchání na služby namapovaných portech, i těch které jsi explicitně nepovolil. Když budeš chtít poslat tisk o tři patra vejš, tak zvedni telefon a obvolej místní adminy, stejně nemaj do čeho píchnout. Nebo zvedni zadek a pořádně se proběhni, posílíš zdraví (a světový mír).
Za druhé používáš špatnou distribuci. Jejich správci balíčků jsou obyčejný ignoranti, kteří jen správně nepochopili genialitu díla našeho Padre a sabotují jeho Velký plán. Jen požehnané distribuce ze Svaté země jsou hodny užívání a uctívání.
Pokud selžou předchozí body, máš k dispozici zdrojáky, tak si to kurva fixni. Ale zapomeň, že svým patchem zohyzdíš upstream ! A jestli ti to před tím dobře fungovalo, tak to se ti asi jenom něco zdálo. Jestli na tom přesto trváš, tak jsi jen obyčejný hater nebo zakuklený terorista.

[kralyk z abclinuxu]

O cups-browsed v tomhle vlákně asi zjevně nikdo neslyšel...

[Lol Phirae]

To bych snad vůbec nekomentovat. Rozbít a následně zrušit fungující věc a protože je zjevně stále potřeba a lidi, kteří ji léta používali, najednou řvou, tak tuto poté reimplementovat tím, že do toho vzniklého bordelu narvu další mezivrstvu (Avahi/mDNS/DNS-SD), to je prostě tak boží nápad, že z toho člověk dostává okamžitý orgasmus.

[pavlix]

že do toho vzniklého bordelu narvu další mezivrstvu (Avahi/mDNS/DNS-SD)

Až na to, že mDNS/DNS-SD nejsou žádné mezivrstvy, ale protokoly pro objevování služeb na síti, pomocí kterých se dají mnohé tiskárny najít. Avahi je jedna z implementací. On měl někdy CUPS implementaci vlastní?

[Lol Phirae]

On měl někdy CUPS implementaci vlastní?

https://www.cups.org/documentation.php/doc-1.5/spec-browsing.html

Tahle zprzněnina, používající bonjour křáp od Applu, je novinkou od verze 1.6. Samozřejmě to funguje nahovno jako všechno, co vylezlo z dílny nakousnutého jablka.

[pavlix]

Jak bys to řešil ty?

[Lol Phirae]

Tak nějak bych řekl, že nejlepší by bylo nerozbíjet funkční věc. Pak by nebylo třeba řešit neexistující problémy.

[pavlix]

Já se ptal konkrétně jak bys řešil objevování tiskáren.

[Lol Phirae]

Na to už jsem odpověděl.

[pavlix]

Jistě.

[kralyk z abclinuxu]

On na to fakt odpověděl - viz ten odkaz výše na doc CUPS 1.5 - akorát je to v zásadě to samý jako Avahi

[pavlix]

To si nejsem vůbec jistý. Umí vůbec všechny tiskárny, co jsou vidět přes multicast DNS, ten starší protokol?

[Heron]

Opravdu bych někdy chtěl vidět tyhle věci fungovat. V podstatě jediná autokonfigurace, která mi kdy fungovala, je v IPv6 a to jsem si fakt sednul na prdel a to používám kdykoliv potřebuju rychle nastavit síť, aby se to navzájem vidělo. Zbytek, ať již dřív NetBIOS u widlí, nebo různý zeroconfy, multicasty, upnp srajdy prostě nikdy. Mě to až tak netankuje, já si rád všechno nastavím staticky (nakonec i tu IPv6 síť taky), ale překvapuje mě, kolik úsilí do toho lidi vkládali a pořád to prostě nefunguje.

[pavlix]

Zrovna na IPv6 se mi celkem líbí LL adresy, ale autokonfigurace ostatních adres mi přijde ve srovnání s DHCP debilní a to ani na návrh DHCP nemám zrovna pozitivní názor. Jinak souhlasím, že je zvláštní, že je tolik zabugovaných protokolů, když není až takový problém navrhnout protokol dobře. Horší je ho pak prosadit.

Největší problém s Avahi vidím v chybné detekci duplicitních jmen, kdy člověk zcela běžně vidí jediné stroj svého jména svévolně měnit jméno přidáním a inkrementací číselného suffixu. Přitom by bohatě stačilo použít jeden unikátní identifikátor, třeba úplně pro všechny podobné protokoly včetně DHCP apod. Ještě by mohlo být fajn mít kryptografickou variantu, kde by nebylo možné zdroj informací lehce nahradit.

[Heron]

Spojení na link local používám vyloženě nouzově, to raději vyšlu RA a celá síť je nastavená. Takhle fungovat všechno ...

[kralyk z abclinuxu]

A to můžeš vyslat i z linux desktopu? Pokud jo, přiblížil bys, jak se to dělá?

[pavlix]

Nechápu, proč bys nemohl, když chceš. Kdyby nic jiného, tak můžeš pustit radvd s odpovídající konfigurací.

[Heron]

Tak ideální je to vyslat ze stroje, který bude tvořit gateway sítě. Protože po RA si všechny stroje nastaví jednak IPv6 adresy (autokonfigurací) a také default gateway právě na link local adresu stroje, který RA vyslal.

Jinak to samozřejmě jde poslat odkudkoliv.

Já používám radvd, je to asi v kažým distru, minimální konfigurace je pak:

interface eth0
{
        AdvSendAdvert on;
        prefix 2001:xxxx:xxx:xxx::/64;
};

(prefix samozřejmně podle ISP)

Potom normálně start služby nebo prostě jen radvd -n.

[kralyk z abclinuxu]

Ok, supr, dík...

[kralyk z abclinuxu]

Zajímavý, mně to (Avahi) zas fungovalo jen na IPv4, na IPv6 jsem měl problém s link-local...

[pavlix]

Mně avahi na IPv6LL fungovalo, ale glibc to neumí, ale o tom už jsme se bavili.

[kralyk z abclinuxu]

Jo, to bude ono...

[kralyk z abclinuxu]

Samozřejmě to funguje nahovno ...

Co přesně ti na tom nefunguje? Zkoušels to?

... jako všechno, co vylezlo z dílny nakousnutého jablka.

V tom případě nevim, proč se vůbec zabýváš CUPSem jako takovým, ten vůbec nevyvíjí už řadu lez Apple, že

[Lol Phirae]

Samozřejmě to funguje nahovno ...

Co přesně ti na tom nefunguje? Zkoušels to?

Ano. Přesně mi na tom s výjimkou produktů nakousnutého jablka nefunguje vůbec nic. (Používám Xfce, kde tyhle krávoviny nejsou zadrátovaný.) Pod Windows je to rovněž zcela na <|>. Je to věc, kterou naprosto na nic nepotřebuju a nehodlám ztrácet čas jakýmkoliv jejím nastavováním. Ostatně, co se týče konkrétně Avahi, určitě není náhodou, že v tom je opět namočenej ten pošuk Lennart.

[pavlix]

emerge --ask --verbose sarcasm

[Lol Phirae]

V případě Lennartwaru a podobných magořin sarkasmus bohužel nefunguje.

[pavlix]

Jsi přecitlivělý, fungoval i za války, teda ne že bych to pamatoval :).

[Josef Kufner]

Ono jde o to, že soketová aktivace se používá k řešení závislostí mezi službami při bootu. Takže nastavit cups, aby se spustil přes aktivaci socketu a pak na konci bootu do něj explicitně kopnout, aby se vždy spustil je vlastně celkem rozumné řešení. Ale mnohem lepší by bylo, kdyby systemd uměl službu spustit na konci bootu, i když nebude socket aktivován, ale mechanismus socketové aktivace pořád pohlídá závislosti.

[Jakub Galgonek]

A nefunguje to právě takto, pokud se nastaví jako enabled .socket i .service?

[Jakub Galgonek]

Ten generátor není vůbec potřeba, pokud se na soubor cups.socket koukáte jako na konfigurační, který si prostě musíte nastavit podle svého uvážení. Pokud z nějakého důvodu trváte na tom, že si ten soubor ručně nastavovat nechcete, pak holt musí někdo napsat ten generátor.

[Michal Kubeček]

Abych se na něj mohl dívat jako na konfigurační, tak by (1) měl být pod /etc a (2) označen jako %config(noreplace). Konfigurační soubor, který po každém updatu budu muset znovu upravit a který nebude v zazálohovaném /etc, je poněkud na draka.

[Jakub Galgonek]

To by neměl být problém, ten soubor může být i pod /etc/systemd/system.

[pavlix]

No je vidět, jak se to celé sype, život už nikdy nebude jako dřív. Je vůbec legrační, že sysadmin ztratil i tak základní funkci jako pustit/zastavit službu a naplánovat/nenaplánovat službu pro spuštění při startu. Teď musí i pro tuto základní úlohu zjišťovat, jestli chce používat službu nebo socket, jestli obojí skutečně funguje (viz ten tisk), a zjistit, zda je služba spuštěná je ještě komplikovanější.

[Michal Kubeček]

To mi připomíná, jak jsem nevěřícně zíral na hlášku (volně převyprávěno): "OK, tak já to teda stopnu, ale počítej s tím, že to stejně za chvíli stejně zase spustím přes socket."

[pavlix]

V případě dbusových služeb to bylo bez hlášky :D.

[Jakub Galgonek]

Tím ti systemd naznačuje, že možná chceš stopnout i ten socket.

[pavlix]

Byly doby, kdy vypínání a zapínání služeb patřilo mezi jednoduché a jednoznačné úkoly.

[pavlix]

Teď mám pocit, že by mi tam spíš sedělo s/úkoly/úkony/.

[Lol Phirae]

Tak ať systemd nenaznačuje a ten dopíčenej socket, o kterej se nikdo neprosil, laskavě stopne samo. Skutečně nevím absolutně o nikom, kdo by toužil "vypnout" službu s tím, že se kdykoliv může sama znova spustit, až sama uzná za vhodné.

[Jakub Galgonek]

Nezapíná se, když sama uzná za vhodné, ale když o ni někdo opět požádá!

[Lol Phirae]

Sorry, u služby, kterou admin zastavil, nemá nikdo jiný o co žádat. Služba prostě neběží, protože ji admin úmyslně vypnul. Tečka. Když ji chceš zapnout, tak běž za adminem a ne za Lennartem, kterej adminovi ukáže "jedničku" a sdělí mu, že se nic vypínat nebude, že už to není v módě.

[Jakub Galgonek]

Pokud admin nechce, aby měl někdo možnost ji opět zapnout, má vypnout aktivátor.

[pavlix]

Jak se vypíná aktivátor dbusových služeb?

[Jakub Galgonek]

S tím jsem si nikdy nehrál.

[pavlix]

To jsem si myslel.

[Jakub Galgonek]

http://fedoraproject.org/wiki/Packaging:Systemd#DBus_activation

Zde se popisuje, jak se to dá udělat.

[Lol Phirae]

No to je báječné! "You can easily implement disabling", načež následuje odstavec plný nepochopitelných systemd technoblábolů a odporných hacků, načež přichází ta největši perla:

# This service should not be bus activated if systemd isn't running,
# so that activation won't conflict with the init script startup.
Exec=/bin/false

Ach ta elegance 21. století! Nádhera! Děkujeme, Lennarte, za ten moderní init!

[Jakub Galgonek]

No, mně teda nedělalo problém ten princip hned pochopit.

Mimochodem, není náhodou dbus aktivace starší než systemd?

[kralyk z abclinuxu]

Mám z tebe pocit, že, narozdíl třeba od Herona, který má konzistentní požadavky, ty hledáš, na co se kde dá zanadávat... Nejdřív chceš CUPS, pak si stěžuješ, že věci od Applu jsou nahovno. Pak si stěžuješ, že nefunguje CUPS discovery tiskáren, následně napíšeš, to naprosto na nic nepotřebuješ. A teď si stěžuješ na D-Bus aktivaci, která se afaik CUPSu netýká už vůbec.

Takže jenom pro pořádek, ačkoli se nejspíš dozvim podobně jako minule že "to prostě nefunguje, protože je to nahovno", kteréže služby se aktivují přes D-Bus a nejdou vypnout?

[pavlix]

Přes dbus se aktivuje NetworkManager a ještě špatně, přesněji řečeno tak, že to nutně nezajišťuje správné pořadí služeb při bootu, což je ovšem jediný důvod, proč se NetworkManager aktivuje přes dbus. Vypnout NetworkManager jde, ale je potřeba použít před zastavením ještě maskování. Maskovat se dá i dočasně do příštího rebootu. Co ovšem striktně vzato nejde, je zastavit ten aktivátor, jak píše Jakub. Nic proti němu, ale vždycky mě u skalních zastánců (a někdy i u skalních odpůrců) zajímá, jestli skutečně rozumějí tomu, k čemu se s takovou vervou vyjadřují.

Problém systemd service manageru je v tom, že nejen že spoléhá na socketovou aktivaci pro synchronizaci spouštění služeb při bootu a při jiných příležitostech, a nejen v tom, že neposkytuje prostředky k tomu tu synchronizaci správně provést, ale i v tom, že leakuje tyhle implementační detaily do konfigurace těch služeb a do ovládacího prostředí.

Tomu prvnímu se bohužel nedá z principu úplně vyhnout. Pokud chce nějaká služba připravovat sockety pro jinou službu, musí znát informace o tom, jak je má připravit a tak je nutné přinejmenším tuhle část konfigurace do správce služeb přesunout. Tomu druhému se ale vyhnout dalo a z mého pohledu je to ukázka toho, že systemd je navrhován programátory pro programátory a že naprosto ignoruje pohled jak běžného uživatele, který by chtěl alespoň vědět, jaké služby běží, tak administrátora, který by se především chtěl zvlášť starat o to jestli služba běží a zvlášť o to jak běží.

Jestli služba používá socketovou aktivaci je pro něj imlementační detail do doby než zjistí, že mu to tak nevyhovuje. Za normálních okolností je pro něj zajímavé, zda služba běží nebo ne, a na to se chce taky systému zeptat a to chce taky v systému měnit, nikoli ho analyzovat a na základě toho sám vyhodnocovat, zda služba běží. Takové rozhraní by bylo možné nad logikou systemd postavit, ale to, co tam je, je z hlediska ovládání úplně špatně.

[kralyk z abclinuxu]

Ok, ok. Teď si vzpomínám, žes už o tom psal před časem. Z mého pohledu tohle jsou v podstatě blbě napsané výchozí service files, protože pokud vim, když se ze service file vyhodí ten D-Bus alias, tak to funguje jako normální démon, ne?

Jinak to byla otázka hlavně na Lola, jestli vyhrabe nějakou svoji D-Busem aktivovatnou službu, nebo jestli jen kopíruje, co píšeš ty, aby měl střelivo

[pavlix]

Z mého pohledu tohle jsou v podstatě blbě napsané výchozí service files, protože pokud vim, když se ze service file vyhodí ten D-Bus alias, tak to funguje jako normální démon, ne?

A přestane se to při startu synchronizovat a vyběhne na nás Lennart. Nemysli si, že jsem tento postup nezkoušel v kombinaci s tím, že bych zavedl onboot connections a že by NM ohlásil, že je hotový až po jejich dokončení.

[Lol Phirae]

SAkra, CUPS discovery mi fungovalo, dokud to Lennart nerozmrdal. Normálně přes broadcasty v CUPSu. Nebylo k tomu potřeba žádné přiblblé Avahi, systemd, sockety ani jiné činčurády. Psal jsem, že na nic nepotřebuju Avahi/mDNS, tak to proto nehodlám nastavovat a vrtat se v tom jen proto, aby fungovalo opět to, co léta před tím chodilo out of the box.

[pavlix]

Exec=/bin/false

Pokud si dobře pamatuju, tak nic podobného nefungovalo.

[Lol Phirae]

To je docela možné, že to nefungovalo. Ono se samotného popisu výroby rovnáku na vohejbák a téhle bezva "elegantní" finty je zjevné, že to je příšerný hack.

[Jakub Galgonek]

A jak tohle řešíš v distribucích bez systemd ty ?

[pavlix]

Už jsem někde psal, že to v distribucích bez systemd není třeba řešit :), k čemu je ptát se dalšího člověka jak řeší problém specifický pro systemd.

[Jakub Galgonek]

Tohle nechápu, na distribucích se systemd vám vadí, že DBus sám spouští služby a vy to nemůžete (snadno) zakázat. Ale na distribucích bez systemd vám to nevadí? Chtít vypnout automaticky aktivovanou službu snad není problém specifický pro systemd, ne?

[Lol Phirae]

Chtít vypnout automaticky aktivovanou službu snad není problém specifický pro systemd, ne?

Evidentně je.

[Jakub Galgonek]

Promiň, ale to nedokazuje, že vypnutí automatické aktivace je problém specifický pro systemd.

[Lol Phirae]

Už mě ta debata přestává bavit. Když to bez systemd funguje a vypnout jde a se systemd ne, tak bude patrně chyba v bagru, že...

[Jakub Galgonek]

No a já chci vědět, jak konkrétně to bez systemd vypínáš? Pomocí toho triku s Exec=/bin/false anebo jinak?

[pavlix]

Bez systemd problém neexistuje, tudíž není potřeba nic dělat. Upstream dodává dbus service file s Exec=/bin/false, služba se sama od sebe nikdy nespustí a administrátor tedy nemusí dělat vůbec nic.

[Jakub Galgonek]

Ale já se neptám, jak vypnout automatické zapínání služby, která se automaticky nezapíná!

[pavlix]

Ty se ptáš na hovadiny, že :).

[pavlix]

Chtít vypnout automaticky aktivovanou službu snad není problém specifický pro systemd, ne?

Samozřejmě, že je, jestliže je ta služba automaticky aktivovaná pouze kvůli systemd.

[Jakub Galgonek]

Ale já mluvím obecně o libovolné službě.

[pavlix]

Jenže tady nejsme mateřská školka. Pokud máš konkrétní dotaz, tak ho polož. A to úplně nejlépe v poradně. Korektní zastavování služeb bylo do nedávna samozřejmostí. Pravda, občas se některý démon pouštěl volně přes fork+exec, pak přišel dbus s nepřímým spouštěním přes dbus démona, ale to nelze moc nazývat systémovými službami.

Trochu mi přijde, že se jen snažíš zakecávat to nekritické oslavování systemd, které se obhaujuje ještě hůře než střílení na slepo ve stylu Lol Phirae.

[pavlix]

Jenže tady nejsme mateřská školka.

I když to tak může někdy vypadat :).

[Jakub Galgonek]

Tak tedy konkrétně: Jakým příkazem (na systému bez systemd) zastavíš polkit a jeho automatické spouštění? Protože z upstreamu je nastaven tak, aby se spouštěl automaticky.

Diskuze začala tím, že když v systemd vypínáš službu, která může být znovu spuštěna přes socket aktivaci, tak tě na to systemd upozorní, že bys možná měl vypnout i tu socket aktivaci. Tys kontroval tím, že v případě, že služba může být spuštěna přes DBus aktivaci, tak upozornění nedostaneš. A já se snažím zjistit, proč ti automatické spouštění přes DBus vadí u systémů se systemd, ale vůbec ti nevadí u systémů bez systemd. Přestože v obou případdech se to v podstatě vypíná zásahem do stejného souboru.

[pavlix]

Tak tedy konkrétně: Jakým příkazem (na systému bez systemd) zastavíš polkit a jeho automatické spouštění? Protože z upstreamu je nastaven tak, aby se spouštěl automaticky.

Mám Gentoo, které je stavěné na to aby fungovalo se systemd i s openrc. Když se podívám do seznamu souborů, které se s tímto balíkem nainstalují, není tam ani systemd služba ani initskript. Balík tedy neinstaluje standardní systémovou službu (systemd unit, initscript, ...), ale pouze službu aktivovanou dbusem, což zajišťuje následující soubor.

/usr/share/dbus-1/system-services/org.freedesktop.PolicyKit1.service:

[D-BUS Service]
Name=org.freedesktop.PolicyKit1
Exec=/usr/lib/polkit-1/polkitd --no-debug
User=root
SystemdService=polkit.service

Mimochodem dbusovou aktivaci považuju za takový první krok k nadělání bordelu ve startování služeb, systemd na to pouze navazuje. Příkaz na zastavení služby pokud vím dbus nenabízí a tak je víceméně nutné systém překonfigurovat (smazat, přejmenovat či přebít soubor, který ji definuje, případně sebrat execute práva příslušné binárce) a službu sestřelit, bez ohledu na to, zda se používá systemd nebo ne.

Naštěstí to u polkitu není tak zásadní jako u toho NetworkManageru, a to z následujících důvodů.

1) Dočasné zastavení polkitu za běhu systému mi nic nepřináší a tedy nevidím důvod ho provádět. Oproti tomu zastavení NetworkManageru považuju za klíčovou funkcionalitu, které mi umožňuje dočasně konfigurovat síť ručně v případě, že potřebuju konfiguraci, která se s NetworkManagerem neslučuje. To se stává každému, kdo si trochu víc hraje se sítěmi.

2) Ještě by bylo dobré zmínit, že polkit je čistě dbusovou službou zjevně z vůle upstreamu a ani distributor na tom v mém případě nic nemění. Oproti tom NetworkManager je dle upstreamu klasická systémová služba a jediný důvod pro dbusovou aktivaci jsou požadavky systemd.

Jinak řečeno, polkit je v tomto ohledu problematický i bez systemd, ale s minimálními důsledky. Oproti tomu NetworkManager je v tomto ohledu problematický kvůli systemd a především na žádost vývojářů systemd.

Problém by ovšem nastal, kdyby se upstream rozhodl polkit opravit a udělat z něj standardní systémovou službu, ovšem opět kvůli systemd nadále aktivovanou dbusem. Narazili by na ten stejný problém jako u networkmanageru, tedy na špatnou integraci systemd a dbusu, tedy by nakonec k řešení nedošlo, tentokrát ovšem kvůli systemd.

[Jakub Galgonek]

Jinak řečeno, žadné z těch dvou prostředí neposkytuje elegantní způsob, jak DBus aktivaci konkrétní služby zakázat. O jaký problém šlo v souvislosti s tím NetworkManagerem?

[pavlix]

Jinak řečeno, žadné z těch dvou prostředí neposkytuje elegantní způsob, jak DBus aktivaci konkrétní služby zakázat.

Těmi dvěma prostředími máš doufám namysli systemd a dbus. OpenRC se žádnou integrací s dbusem nechlubí a jeho vývojáři pokud vím nikoho nežádají, aby dbusovou aktivaci používal.

O jaký problém šlo v souvislosti s tím NetworkManagerem?

Ten, že se na systemd po systemctl stop NetworkManager nebo service NetworkManager stop znovu samovolně spouštěl jen na základě pokusu o přístup k jeho API ze strany jiných (dokonce neprivilegovaných) procesů.

[Jakub Galgonek]

Těmi dvěma prostředími máš doufám namysli systemd a dbus.

Ne, ale to teď nechme asi plavat.

Ten, že se na systemd po systemctl stop NetworkManager nebo service NetworkManager stop znovu samovolně spouštěl jen na základě pokusu o přístup k jeho API ze strany jiných (dokonce neprivilegovaných) procesů.

Ano, musí se zadat ještě systemctl disable NetworkManager, aby se přestal samovolně spouštět před DBus. Což souvisí s tím, že nejde DBusu říct, aby tu službu teď (dočasně) automaticky nespouštěl a řeší se to tím workaroundem s aliasy. Myslím, že by bylo fajn, kdyby bylo v moci systemd zastavovat DBus aktivaci stejným způsobem, jako může manipulovat se socket aktivací. Protože tak, jak je to teď, to opravdu není moc pěkné řešení.

[pavlix]

Ano, musí se zadat ještě systemctl disable NetworkManager

Zkus si přečíst dokumentaci systemd a zkus trochu pogooglit po internetu, případně si znovu přečti diskuzi, ať nemusíš dokola opakovat stejné nesmysly.

1) Příkaz disable ruší startování NM při bootu.

2) K zastavení služeb slouží příkaz stop, jen už nefunguje na 100%.

3) Workaround k tomu, že stop už nefunguje na 100% byl známý už před započetím diskuze.

systemctl --runtime mask NetworkManager
systemctl stop NetworkManager

Takže zkus prosím přestat plácat nesmysly. Je možné, že tebou navrhovaný příkaz zablokuje start NetworkManageru (nechce se mi to testovat ani dolovat, zda tomu tak bylo vždycky), ale má velmi nepříjemný vedlejší efekt na konfiguraci systému.

Což souvisí s tím, že nejde DBusu říct, aby tu službu teď (dočasně) automaticky nespouštěl a řeší se to tím workaroundem s aliasy.

Který pokud vím nikdy nefungoval a nejsem si vědom toho, že by někdo posílal patch, který by to opravoval.

Myslím, že by bylo fajn, kdyby bylo v moci systemd zastavovat DBus aktivaci stejným způsobem, jako může manipulovat se socket aktivací.

Pokud vím, tak se s tím čekalo na kdbus.

Protože tak, jak je to teď, to opravdu není moc pěkné řešení.

Je to jen jeden střípek z rozbitého zrcadla, jak je vidět i v dalších komentářích a diskuzích.

[Jakub Galgonek]

Nesmysly? Příkaz disable ruší startování NetworkManageru při bootu, ale taktéž ruší alias dbus-org.freedesktop.NetworkManager.service, skrz který startuje DBus ten NetworkManager. Takže po systemctl disable NetworkManager už NetworkManager nemůže být přes DBus startován.

#systemctl disable NetworkManager
Removed symlink /etc/systemd/system/multi-user.target.wants/NetworkManager.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service.

[Jakub Galgonek]

Hmm, leda by systemd postřehl zmizení toho aliasu až po rebootu, pak opravdu zbává jen to maskování. Škoda, že systemd neumí něco jako systemd stop NetworkManager.dbus, podobně jako to umí u socketů.

[pavlix]

Je mi upřímně jedno, jestli stačí nebo nestačí disablovat, a to z následujících důvodů.

1) Samotné použití disable na tento účel je výsledkem chybné úvahy, mask je naopak logicky správný způsob, jak docílit toho, že služba nebude moci naběhnout.

2) Fungování disable závisí na konfiguraci služby, mask funguje bezpodmínečně.

Nicméně tvoje analýza má jednu zásadní chybu a to, že vůbec nezohledňuje, že systemctl disable (stejně jako systemctl mask) má vedlejší efekt a zasahuje do uložené systémové konfigurace, což jde zcela proti sysmu systemctl stop, který do uložené konfigurace vůbec nezasahuje. Obávám se, že ti vůbec nedochází, jak špatné je zasahovat do uložené konfigurace, zvláště když se jedná o vedlejší efekt. Ale to je asi otázka zkušeností a ty jsou bohužel nepřenositelné.

Zatím nejlepší workaround je ten, který jsem uvedl výše. Nemá smysl vymýšlet horší.

[pavlix]

Příkaz disable ruší startování NetworkManageru při bootu

Tudíž to má nepříjemný vedlejší efekt, který působí destruktivně vůči systémové konfiguraci. Tudíž to rozhodně není korektní workaround na nefunkční systemctl stop. Navíc je korektní workaround (bez toho vedlejšího efektu) už delší dobu známý. Navrhovat tento workaround tudíž považuju za nesmysl. Navrhovat ho opakovaně i po upozornění považuju za donebevolající nesmysl. Na tom bohužel musím trvat.

[Jakub Galgonek]

Tím upozorněním myslíš tento příspěvěk anebo jiný?

Ale abychom to nějak shrnuli a uzavřeli. DBus si sám spouští "služby" jak pod OpenRC tak pod systemd. U OpenRC ti to nevadí, u systemd ti to vadí, protože přidal automatickou aktivaci i ke službě/službám, která/é se automaticky pod OpenRC nespouští. V podstatě je tu sice pořád stejný problém, že se něco spouští samo a není tu příkaz, jak to (dočasně) zakázat, ale pod OpenRC ti to zatím nespouštělo nic, co bys nechtěl.

Čili tvá kritika se točí kolem "kvůli nastavení pro systemd mi DBus spouští něco, co nechci" a má námitka zní "i bez systemd ti DBus může spouštět něco, co nechceš". Což ale nepovažuješ za problém, protože ti v praxi zatím nezpůsobil potíže. Podle mne je to naopak problém jak pod OpenRC tak pod systemd - obojí to prostě neumí.

Tak mne napadá, že u systemd máš alespoň ten mask, ale u OpenRC ne, tam se prostě řídí tou Exec direktivou. Osobně si myslím, že by systemd prostělo, kdyby zde byla možnost dávat stop i na service soubory dbusu.

[Jakub Galgonek]

Stručně: Automatická aktivace služeb DBusem bez možnosti dočasného zákazu je problém, který existuje i pod OpenRC a který systemd podědil/neřeší. U systemd to však může častěji způsobovat problémy, protože automaticky přes DBus spouští i služby, které OpenRC spouští pouze přímo (anebo vůbec). Takže je chybou systemd, že se hodně spoléhá na aktivaci DBusem, ale nedořešil vypínání tohoto způsobu aktivace. Souhlas?

[pavlix]

Automatická aktivace služeb DBusem bez možnosti dočasného zákazu je problém, který existuje i pod OpenRC a který systemd podědil/neřeší.

Ve skutečnosti dbusová aktivace s OpenRC nesouvisí, zatímco se systemd ano, ale to v podstatě popisuješ níže. Ten problém podědil systemd od dbusu, nikoli od jakéhokoli RC řešení a už vůbec ne od OpenRC. Nepřímo se dá říct, že ho podědil od Gnome.

U systemd to však může častěji způsobovat problémy, protože automaticky přes DBus spouští i služby, které OpenRC spouští pouze přímo (anebo vůbec).

Není to přesné, ale podstatu problému to celkem vystihuje.

Takže je chybou systemd, že se hodně spoléhá na aktivaci DBusem, ale nedořešil vypínání tohoto způsobu aktivace. Souhlas?

Dá se to tak říct. Ovšem ta vlastnost se netýká jen systemd jako kódu, ale i jako ekosystému a komunity. Nicméně se na ten problém nejspíš za chvilku zapomene a budou se řešit jenom stovky jiných :).

[Jakub Galgonek]

Ok, na tom se asi shodneme ...

[pavlix]

Obávám se, že jsem popsal jen fakta.

[Jakub Galgonek]

Fakta jsou jedna věc, pohled na ně (jejich interpretace) je věc jiná

Moje interpretace byla: "automatické spouštění dělá DBus, nejde mu říct, aby to dočasně nedělal, viníkem je DBus." A tvá, jak jsem pochopil, byla asi tato: "Systemd vyžaduje u dbus služeb automatickou aktivaci, ty pak mohou být automaticky startovány, i když byly stopnuty, viníkem je systemd". Škoda, že dbus aktivace není řešena jako dbus aktivace, bylo by to čistější. Takhle to je, uznávím, děs běs.

[pavlix]

Tvůj popis není úplně stoprocentně správný, ale už asi nemám čas a sílu ho uvádět na pravou míru.

[Jakub Galgonek]

Škoda, zajímalo by mne, co na něm není správně.

[pavlix]

Viz komentář ke stručné verzi.

[pavlix]

systemctl --runtime mask NetworkManager
systemctl stop NetworkManager

Mimochodem jsem jen tak z legrace zkusil následující, protože se jedná o hybrid mezi oběma přístupy a to selhává na plné čáře.

systemctl --runtime disable NetworkManager

Tenhle příkaz totiž nedělá v dané situaci vůbec nic. On se jenom podívá, zda není služba runtime enabled a v případě toto zruší. Nejspíš to ani není bug, jen chování, které potvrzuje, že je mask ten správný přístup, protože služba jde maskovat jak trvale (v uložené konfiguraci), tak runtime (v /run), podle potřeby administrátora.

[kralyk z abclinuxu]

Na Arch fóru radí odendat D-Bus alias z toho service fajlu, to mi skoro přijde jistější...

[pavlix]

1) Nic není jistější než masking.

2) Trpí to stejným nebo horším problémem, a totiž že trvale zasahuješ do konfigurace stroje, což je ve většině případů, kdy chceš jen zastavit službu nežádoucí, a u NetworkManageru zvlášť.

[pavlix]

1) Nic není jistější než masking.

Tedy kromě zásahu do samotné binárky, ale tam se opět uplatní bod #2.

[pavlix]

Když už sis dal práci s tím to najít, zkus to ocitovat, já tam žádný rozumný a funkční způsob nevidím.

[pavlix]

Tím netvrdím, že nevím, jak to lze obejít, jen to nevidím popsané zrovna tam, kam se odkazuješ.

[Jakub Galgonek]

Pokud jsem to správně pochopil, tak DBus si to startování dělá sám (i v prostředí bez systemd). V non-systemd prostředí startuje příkaz z Exec=, v systemd prostředí spuští službu uvedenou v SystemdService=. Proto nastavení Exec=/bin/false v distribuci používající systemd nemá efekt, protože DBus se touto direktivou neřídí.

Pokud tedy chceme, aby při nastavení systemd service jako disabled nebylo možné, aby si ji DBbus aktivoval, tak se to dělá (dle toho návodu) tak, že místo skutečného názvu service souboru (avahi-daemon.service) se tam uvede odkaz pouze alias (dbus-org.freedesktop.Avahi.service) a do skutečného service souboru se přidá definice aliasu (Alias=dbus-org.freedesktop.Avahi.service). Pokud je service file disabled, alias není nastaven a DBus by neměl službu sám spouštět.

[pavlix]

Pokud jsem to správně pochopil, tak DBus si to startování dělá sám (i v prostředí bez systemd).

Implementační detail, leč zjevně nezvládnutý.

Pokud tedy chceme, aby při nastavení systemd service jako disabled nebylo možné, aby si ji DBbus aktivoval, tak se to dělá (dle toho návodu) tak, že místo skutečného názvu service souboru (avahi-daemon.service) se tam uvede odkaz pouze alias (dbus-org.freedesktop.Avahi.service) a do skutečného service souboru se přidá definice aliasu (Alias=dbus-org.freedesktop.Avahi.service).

Tak to NetworkManager měl a zjevně to nefungovalo. Dívalo se na to několik systemd expertů a po velmi dlouhé době dokázali přijít s řešením pomocí maskování.

Pokud je service file disabled, alias není nastaven a DBus by neměl službu sám spouštět.

Správná terminologie je stopped neboli zastaven. Nebavíme se o naplánování služby na příští boot, ale o tom, zda služba má nebo nemá běžet teď. A to rozhodně nefunguje a lidi od systemd dosud nepřišli na to, jak to opravit. Takže časem nabídli nějaký ten workaround (michich) a odložili řešení minimálně dokud nebude dbus začleněný do systemd (dokonce ve smyslu pid 1, pokud vím).

[Jakub Galgonek]

Myslím, že ten "implementační detail" je dán tím, že dbus aktivace tu byla ještě před systemd. Proto je ta integrace systemd taková nepěkná.

[pavlix]

Myslím, že ten "implementační detail" je dán tím, že dbus aktivace tu byla ještě před systemd.

Před systemd byla spousta software. Jenže dbus a aktivace dbusem jsou trochu jiná kategorie a byly vždy prezentovány jako preferovaný způsob integrace se systemd.

Proto je ta integrace systemd taková nepěkná.

To ovšem platí obecně, nejen o dbusu.

[pavlix]

Pokud jsem to správně pochopil, tak DBus si to startování dělá sám (i v prostředí bez systemd).

Ještě jedna designová drobnost. Bavíme se o software, který nepotřebuje být aktivován dbusem a v prostředí bez systemd by nikoho nenapadlo, že bude. Jediný důvod pro aktivaci dbusem je systemd a jediná chvíle, kdy se ta aktivace má uplatnit je při startu NetworkManageru a jiných služeb, kdy se tím zajistí, že ty služby se na tom dbusu zablokují a počkají, až bude NetworkManager připravený.

[Heron]

Ale hlavně že máte plné kecy o tom, jak se všichni hateři bojí novinek. Přitom ti hateři toho o systemd vědí víc jak vy a na rozdíl od vás to taky musí v praxi spravovat.

[Jakub Galgonek]

Jo? A v kterém příspěvku jsem to tvrdil?

[Heron]

Ježiš sorry

Spletl jsem si Golis a Galonek. Omlouvám se.

To je tak, když člověk čeká na to, jestli se ty servery u Masterů opravdu vypnou.

[Jakub Galgonek]

[Michal Kubeček]

No, já taky, když chci stopnout službu, tak to obvykle dělám proto, že z nějakého důvodu nechci, aby běžela. Ale já jsem holt zpátečník…

[Jakub Galgonek]

To je takový problém pochopit, že když stále beží "aktivátor", tak může dělat to, kvůli čemu běží, tj. aktivovat?

[Lol Phirae]

To je takový problém pochopit, že vypnout znamená vypnout?

[Jakub Galgonek]

Pokud admin nechce aktivátory, má je vypnout.

[pavlix]

Podobný komentář už jsem v diskuzi viděl a reagoval jsem, že ani to systemd nezvládá na 100%, sorry.

[Jakub Galgonek]

Tím narážíš na ten DBus?

[pavlix]

Ano. Samozřejmě jsou tu i jiné věci. Třeba si nemyslím, že by Michal nechápal, spíš mám pocit, že s tím designem nesouhlasí, a v tom mu bohužel musím dát za pravdu. Ve skutečnosti totiž běžný sysadmin vůbec žádné aktivátory nechce a nepotřebuje, jinými slovy vždy když se jimi musí speciálně zabývat, znamená to, že mu někdo přidělává práci.

[Jakub Galgonek]

A jak dbus aktivaci (její zakázání) řešíš na systémech bez systemd?

[pavlix]

To je trochu hloupá otázka, ne? Když bylo možné dbusovou aktivaci u dané služby nakonfigurovat, tak asi nebude problém ji zrušit, že? V první řadě bych ale nemusel dělat vůbec nic, protože u systémových služeb jako je NetworkManager se pokud vm zaváděla až kvůli systemd. A potom ten trik s Exec=/bin/false bez systemd funguje bez problémů.

[Jakub Galgonek]

Tak já to nikdy nedělal, tak se ptám. A co brání možnosti zrušit tu konfiguraci i v případě, že se používá systemd? A u systemd by nepomohl trik SystemdService=nic.service?

[pavlix]

Řešil jsem to tehdy s Danem Williamsem a šlo o tom, že tenhle setup doporučil Lennart a SystemdService prý muselo být nastavené správně, jinak to nechodilo jak mělo v systemd. Nepamatuju si už, jestli jsem to sám testoval nebo jsem to nechal být, když to neumějí ani v systemd kabal.

[Jakub Galgonek]

A je ta komunikace někde veřejně vidět?

[pavlix]

Netuším, možné to je.

[pavlix]

Ten generátor není vůbec potřeba

Kdo ho tedy v diskuzi navrhoval?

[Jakub Galgonek]

Je potřeba, pokud chceš cups.socket nastavovat automaticky. Je ale potřeba nastavovat cups.socket automaticky?

[pavlix]

Mně se nejvíc na tom líbí to, že řešíme problémy, které by bez socketové aktivace a její aplikace na cups vůbec nevznikly. Ale ať nejsem tak tvrdý, správné řešení je zřejmě kopírovat systemd konfigurák /usr/lib do /etc a považovat ho za součást konfigurace CUPS. Na to ovšem zase chybí sysadmin-friendly tooling.

[j]

V kocourkove zili a ziji odjakziva velice inteligenni lide, kteri pilne pracuji na tom, aby se meli dobre a jeste lepe. Mr lennart by v kocourkove byl povazovan za magora/saska/obecniho blazna.

BTW: sluzeb jako cups bude pomerne slusna hromadka, zeano, takze budem opet vyrabe narovnavak na vohejbak, a budeme mit sadu scriptu, ktery budou z konfiguragu jednotlivych sluzeb (a kazda to ma zcela jinak) sosat, jak maji byt nakonfigurovany, a predkladat to systemd. Alternativne systemd casem cups, myslq, postfix, courier, ... zaintegruje a aby to bylo khuul a startovalo to rychle bude konfigurace kompilovana primo do jedne velke binarky.

A co kdyz se ty scripty podelaj, a kdo je bude udrzovat? Jo aha, systemd nam zjednodusi praci jednotnou konfiguraci.

BTW2: probeh sem prvnich par postu toho bugreportu, a pak sem dosel k zaveru, ze nekdo otevrel bohnice a pustil vsechny chovance.

[pavlix]

V kocourkove zili a ziji odjakziva velice inteligenni lide, kteri pilne pracuji na tom, aby se meli dobre a jeste lepe.

To se pokud vím Lennartovi daří. Je významným členem linuxové komunity, nemá problém si kdykoli sehnat zaměstnání u kterékoli větší firmy z oblasti a tedy si pravděpodobně může dost diktovat ohledně platu. To stejné bude zjevně platit pro kohokoli, kdo si v této oblasti udělá jméno, takže přinejmenším zbytek systemd kabal a v omezenější míře i další významní přispěvatelé do systemd.

Mr lennart by v kocourkove byl povazovan za magora/saska/obecniho blazna.

Stejně dobře jako šaškem by mohl být třeba králem :).

[mankind_boost]

...nebo vývojářem.

[Jiří J.]

Hlavně readahead v systemd je v podstatě klon "preload" daemona, který jsem zkoušel na Debianu Lennym několik let zpátky. Nakonec šel do háje, protože svým těžkým I/O mi blokoval getty / textový login na pár sekund.

(a taky ne vždy jsem startoval X, firefox, ...)

[HonzaRez]

Lennartix - spusťte na Kickstarteru projekt na milión bitkojnů, to se vybere během 5 sekund (latence) a máte od něj pokoj. Za tuto myšlenku nic nechci, uvolňuju ji pod licencí GPLv2...

[little.owl]

A ja se ptam: Kde je Kavol?

[pavlix]

Jen počkej, až se jednou budeš ptát na mě :).

[little.owl]

Musim si te odchytit, az budu zase v Praze.

[pavlix]

To rozhodně.