Vlákno názorů k článku
Bizarní chyba v systemd od rcs-34 - Takže podle toho ... mmm ... frajera: Když...

Systemd nevidí do hlavy správci, aby mohl rozpoznat každou nesprávnou konfiguraci. Nejde jen o zpětnou kompatibilitu se staršími verzemi systemd, jde i o kompatibilitu s jinými aplikacemi, které používají unit soubory. Při rozpoznání pravděpodobně nesprávné konfigurace vypíše varování do logu.

Tady se ukazuje rozdíl mezi správci, kteří po napsání jednotky otestují, zda funguje, a zkontrolují logy, a správci, které nějaké varování nezajímá a řeší až případ, kdy jim služba vůbec nenastartuje (a nejspíš je pak na to stejně musí upozornit někdo jiný).

To není proto, že jméno začíná nulou.

Ano, při kontrole logů může být pozdě, proto má správce jednotku napsat správně a spustit ji teprve po kontrole. Když do ExecStartPre zadá rm -r /*, tak mu to smaže celý systém. To je také chyba systemd?Když zadá Usr=nobody, spustí se jednotka pod rootem. Taky chyba systemd?

Sorry, ale samotný systemd s tebou nesouhlasí:


systemd[1]: /etc/systemd/sys­tem/t.service:3: Invalid user/group name or numeric ID, ignoring: 0tomasxxx
systemd[1]: /etc/systemd/sys­tem/t.service:5: Unknown lvalue 'Usr' in section 'Service'


Evidentně to dělá rozdíl mezi neznámou lvalue a mezi vadnou hodnotou známé lvalue.

Ano, oba řádky se to rozhodne ignorovat. To je asi to jediné, co mají společného. Pokud se do User dá jméno, které systemd považuje za validní, tak už to položku User neignoruje a začne se to podle ní řídit.

Což mimochodem taky znamená, že pokud v budoucnu se systemd změní a jméno "0tomasxxx" to bude považoval za validní uživatelské jméno, tak ta unita selže na neznámého uživatele. Unita, která do té doby "zpětně kompatibilně" fungovala.

Nechápu, jak tohle může někdo obhajovat.

Vždyť popisuješ přesně to, co jsem napsal. Neznámá volba nebo neznámý formát volby znamená varování do logu a přeskočení dané volby. Obojí je logické kvůli kompatibilitě s jinými programy. Teprve pokud je volba známá a má známý formát, systemd se ji pokusí zpracovat. V případě uživatelského jména tedy vyhledá uživatele s daným jménem – a pokud neexistuje, je to jednoznačně chyba, proto také systemd danou jednotku nespustí.

Pokud se systemd v budoucnosti změní, může se změnit různými způsoby. Číslice na začátku může být chápána jako prefix – podobně, jako např. spuštění příkazu může mít prefix +. A nebo by číslice na začátku mohla být považována za validní uživatelské jméno, teprve pak platilo to, co jsi napsal – že by jednotka při startu selhala, pokud by ten uživatel neexistoval.

Pokud nechápeš, jak to někdo může obhajovat, měl bys nejprve napsat, co ti vlastně vadí. To, že je volba s neznámou syntaxí ignorována? Nebo obecně princip kompatibility formátu, kdy je ignorována neznámá volba nebo volba s neznámou syntaxí? Nebo ti to vadí jen u volby User a ta by se měla chovat jinak, než ostatní volby?

Já chápu, že to chování je na první pohled divné. Ale to zacházení s neznámými volbami a neznámými formáty voleb je logické, a je logické, že se systemd ke všem volbám chová stejně.

Pokud nechápeš, jak to někdo může obhajovat, měl bys nejprve napsat, co ti vlastně vadí.

Pokud napíšu lvalue= tak očekávám:

* Pokud lvalue nezná, tak mě na to upozorní. Ocenil bych možnost, kdyby to nebylo jen upozornění, ale kdyby to s neznámým atributem vůbec nejelo (prostě tato unita nebude provedena, dokud jsou v ní chyby nebo neznámé atributy).

* Pokud lvalue zná, tak očekávám, že se to pokusí zpracovat hodnotu a pokud toto zpracování selže, unita nebude provedena a systemd ohlásí chybu (tak jak se děje, pokud dám do User neexistujícího uživatele).

Prostě tak jak se chovají jiné programy. Pokud jinému programu dám lvalue=nesmysl, tak typicky ani nenastartuje.

Pokud jinému programu dám neznámou lvalue, tak většina z nich mě na to upozorní (systemd taky, v logu).

Co ovšem nechci je to, aby chování záleželo syntaxe hodnot. Tady, syntax error znamená, že se to bude celé ignorovat. Tohle je chyba o které se tady diskutuje.

Pokud se systemd v budoucnosti změní, může se změnit různými způsoby. Číslice na začátku může být chápána jako prefix – podobně, jako např. spuštění příkazu může mít prefix +. A nebo by číslice na začátku mohla být považována za validní uživatelské jméno, teprve pak platilo to, co jsi napsal – že by jednotka při startu selhala, pokud by ten uživatel neexistoval.

Aha, takže máme bezpečnostní problém (spouštění unit za roota, pokud správce nastavil attibut User, považuji za vážný bezpečnostní problém), ale budeme ho ignorovat, protože větší výhodu má budoucí změna syntaxe.

Takhle se systémový software opravdu nepíše.

Ale asi je to fakt o těch správcích, jak jsi psal. Já mám rád software, který svou práci bere vážně. Kdysi jsem psal o jednom příběhu s MySQL, který se taky rozhodl ignorovat to, že innodb (po změně konfigu) nenajelo, ignorovalo to create table ... engine=innodb a vytvořilo to typ mysiam, ignorovalo to begin tranaction a rollack (myisam nepodporuje). Však co na tom, že někdo přišel o data, sere pes...

Jestli tímto způsobem autoři software přemýšlí (a u Lennarta na to máme důkazů už dost), tak je celkem dobré ten software nepoužívat. U normálního softu mě to na nestandardní konfiguraci upozorní. Pokud hodnota neodpovídá typu konfigurační volby, tak to nenajede. Apod. Je soft, kde to jeho autoři berou vážně. A potom je ten zbytek.

Oba požadavky znamenají, že syntaxe jednotkového souboru je striktně vázána na jednu verzi systemd. Předpokládám, že jednotkový soubor má ambici být univerzálním formátem, který budou používat i jiné nástroje spravující služby. Dovedu si třeba představit, že v jednotkovém souboru bude i popis toho, na kolika a jakých strojích v clusteru se má jednotka spustit.

To, že program ignoruje neznámé hodnoty, je běžná situace – zejména v případech, kdy nepoužívá formát souboru určený jenom pro daný program.

To, že se ignorují neznámé formáty (ty píšeš „syntax error“) je nedílná součást té otevřené definice formátu, která umožňuje budoucí úpravy. Třeba v HTML prohlížeče ignorují jak neznámé tagy (což by odpovídalo těm neznámým volbám), tak neznámé atributy na známém tagu (což by odpovídalo tomu neznámému formátu). Jenom díky tomu se HTML může vůbec vyvíjet – kdyby to tak nebylo, HTML už dávno zemřelo ve verzi 1.0.

Mně se ten formát jednotkových souborů vůbec nelíbí, ale když už byl zvolen takhle, zachází se s ním logicky, konzistentně, a je možné, aby se programy používající ten formát rozvíjely. Ostatně i samotné systemd už několikrát využilo toho, že přidalo nový formát volby.

Pokud správce nastavil User na neplatnou hodnotu a pokusí se to spustit, je to jeho chyba, ne bezpečnostní chyba systemd. root má milion způsobů, jak omylem něco spustit jako root – a musí si to pohlídat, od toho je root.

Systemd na nestandardní konfiguraci upozorňuje. Ale změnit to na tvrdou chybu by znamenalo úplně rezignovat na kompatibilitu formátu jednotkových souborů. Může se ti to nelíbit, třeba bys dal přednost formátu souboru svázaného s konkrétní verzí systemd (což by byl krok i proti modulárnosti systemd). Ale autoři systemd se rozhodli pro kompatibilní formát, což má tenhle důsledek. To ale neznamená, že to autoři systemd neberou vážně.

Neregistrovaný, 14:15: Vynucené automatické aktualizace Windows se týkají domácích Windows, které žádného správce nemají.

Neregistrovaný 15:11: Čemu na tom nerozumíte? Windows, které mají správce, používají pro distribuci aktualizací WSUS.

Souhlas, WSUS jde používat i bez active directory a je to takový základ.

Pane J:

To co popisujete je důsledkem toho, že jste ve WSUS konzoli zaškrtl že chcete dostávat přes WSUS Windows 10 language packy.
Když jste je potřeboval, nevím proč si zde stěžujete.

A za druhé - tajemné kouzlo WSUSu je v tom, že si můžete aktualizace o které nemáte zájem odmítnout. Klienti pak nebudou hlásit že je potřebují.

Přeji pěkný den.

Všiml jste si, že čím slušněji Vás oslovuji, tím hruběji píšete?

To vaše "MOZNA NEKDY NECO " řeší on-demand aktualizace které nejsou needed. Např pro novější desítky .net framework 3.5. Ale máte pravdu, že se to zatím používá méně než by mohlo.

Needed u jazykového balíčku dává docela smysl, když chcete mít na WSUS jazykové balíčky (já tedy ne). A chcete tam mít téměř všechny větové jazyky, tak WSUS jasně hlásí, že má v databází něco co klient nemá nainstalované. Můžete je tedy bud odmítnout, nainstalovat, nebo ignorovat.

Nenapadá mě které aktualizace pro Windows 10 nejsou na WSUS, ale pro ostatní systémy občas vycházejí hotfixy které jsou dostupné na update catalogu. Z catalogu je můžete imporotvat do wsusu. Například SMB patch pro XP/2003 naposledy.

Petr M: To ale pořád počítáte jen s jednou jedinou aplikací. Zkuste si představit, že takhle přidáváte nový atribut pro nějaký tag v HTML.

Očividně o té chybě ví, když ji zaloguje jako warning.
Systemd očividně rozlišuje mezi chybou a varováním.

Máš nějaký konkrétní příklad? Tomu argumentu nerozumím. Proč by měl systemd akceptovat formát svého vlastní direktivy, kterému nerozumí (a jen to přejít logem), jenom proto, že jej může používat jiná aplikace? Ta si přece může použít jiný název direktivy.
To není direktiva systemd, je to direktiva jednotky (unit file). Jiná aplikace je třeba budoucí verze systemd. Váš přístup by znamenal, že s každou změnou formátu by se musel změnit i název volby. Já osobně považuju formát jednotkových souborů za to nejhorší na celém systemd, ale prostě zvolili takovýhle formát a to, že různé formáty hodnot voleb budou označovat různé chování, tak to respektuju.

Pokud se mi služba i jen pro otestování spustí pod rootem, může to nadělat pěknou paseku třeba na filesystému - vyrobí mi klíčové soubory pod rootem a budu pak pěkně dlouho dohledávat a měnit práva souborů, aby mi zase běžela pod neprivilegovaným userem.
Taky si má nejdřív správce zkontrolovat, co spouští. Když takhle spustí přímo MySQL nebo nějaký skript, může napáchat úplně stejné škody.

V případě jednotky ale správce tu službu nemusí hned spouštět, může nejprve na jednotku spustit systemd-analyze verify, která mu ta varování vypíše bez nutnosti jednotku spouštět.

To, že se přidal formát, neznamená nutně, že nová jednotka se starým systemd nefunguje správně. Když se k volbě Description přidá možnost prefixem @lang= zadat jazyk popisku jednotky, start služby to nijak neovlivní.

Vy to pořád popisujete, jako kdyby to byl formát jen pro systemd – jenže tak evidentně nebyl zamýšlen.

Mně se ten formát nelíbí, radši bych formát, kde se příznaky nebudou zapínat tím, že se použije nový formát zápisu hodnoty, radši bych formát, kde bude možné udělat podmínku na zpracovávající aplikaci nebo její verzi. Ale autoři systemd zvolili tenhle formát, a v rámci toho formátu je to chování logické a konzistentní.

Já osobně považuju formát jednotkových souborů za to nejhorší na celém systemd, ale prostě zvolili takovýhle formát a to, že různé formáty hodnot voleb budou označovat různé chování, tak to respektuju.

Já osobně považuji tento formát za velmi vhodný.

Prostě ini-like, [sekce] klíč=hodnota

Stejný formát napříč vším, logind.conf vypadá stejně jako .network nebo .mount. Tohle mi vyhovuje.

Co mi nevyhovuje je, že někdo obhajuje, že klíč=hodnota vlastně není klíč=hodnota, ale že to ještě navíc záleží na syntaxi té hodnoty a vlastně to může znamenat něco úplně jiného.

Váš přístup by znamenal, že s každou změnou formátu by se musel změnit i název volby.

Což by bylo správné řešení. Pokud by si někdo vymyslel seznam uživatelů, klidně může vzniknout UserList=. Nevidím na tom nic špatného, právě naopak, protože seznam uživatelů je evidentně něco jiného, než jeden uživatel.

Co mi nevyhovuje je, že někdo obhajuje, že klíč=hodnota vlastně není klíč=hodnota, ale že to ještě navíc záleží na syntaxi té hodnoty a vlastně to může znamenat něco úplně jiného.
To je přesně to, co mi na tom formátu nejvíc vadí. Jenže pokud by to mělo být jinak, s tím postupem [sekce] klíč=hodnota by to nejspíš nešlo. Stačí se podívat jenom na ExecStart, který se může opakovat a může obsahovat prefix @, + a -. Rozepsat do klíč=hodnota by šlo, ale jak by to vypadalo…

Stačí se podívat jenom na ExecStart, který se může opakovat a může obsahovat prefix @, + a -. Rozepsat do klíč=hodnota by šlo, ale jak by to vypadalo…

Vypadalo by to úplně normálně a hlavně by to nerozbilo zpětnou kompatibilitu. Prostě ExecStart je plná cesta k binárce a její parametry. Pokud si někdo později vymyslel @+-, stačilo zavést třeba ExecMod, do kterého by šlo zadat mod spouštění (třeba jako bitmapu, nebo pomocí symbolů @+-). Vůbec to není potřeba cpát do hodnoty parametru ExecStart a porušit tím předchozí kompatibilitu (@/bin/bash evidentně není validní cesta k souboru).

Jenže ExecStart se může opakovat a ty prefix se týkají každého příkazu zvlášť. Navíc ty modifikátory nemusely být zavedeny najednou, takže pak by pro ně nestačil jeden ExecMod, ale podle pravidla „při každé změně novou volbu“ by těch voleb muselo být několik. Takže ze současného

ExecStart=@+-/opt/backup/run-backup.sh backup-home
ExecStart=@+-/opt/backup/run-backup.sh backup-var
ExecStart=/opt/backup/upload-backup.sh

by se stalo

ExecStartArgv0=backup-home
ExecStartFullPrivileges=yes
ExecStartIgnoreError=yes
ExecStart=/opt/backup/run-backup.sh
ExecStartArgv0=backup-var
ExecStartFullPrivileges=yes
ExecStartIgnoreError=yes
ExecStart=/opt/backup/run-backup.sh
ExecStart=/opt/backup/upload-backup.sh

Ten první zápis je hrozný, ten druhý je ještě horší.

Ten první zápis je hrozný, ten druhý je ještě horší.

Tak to je otázka vkusu. Asi jako všechny flamy v historii o tom, která syntaxe je lepší, která horší, která je úsporná a která je readonly.

Mě osobně druhý zápis nijak nevadí. Pokud by se to naformátovalo pěkně, tj mezi každou skupinu ExecStart dala třeba mezera, tak osobně nemám problém s čitelností.

Ale to je věc vkusu.

Systemd neignoruje jen volby, které nezná, ale také volby, které mají neznámou syntaxi. Což umožňuje syntaxi volby rozšířit – třeba se později někdo rozhodne, že bude možné uvést seznam uživatelů oddělených čárkou, a použije se první, který v systému existuje. Jiná věc je, jestli je vhodný tenhle způsob konfigurace, kdy se různé nové volby zavádějí třeba tak, že se před hodnotu zadá nějaký prefix (plus, zavináč apod.).

Z hlediska syntaxe unit souboru zkrátka není rozdíl mezi tím, zda uvedu UserXXX=nobody nebo User=@"#!, v obou případech je to pro aktuální systemd neznámá volba (a v obou případech to něco může znamenat pro jinou aplikaci nebo pro budoucí verze systemd).

Proč pořád řešíte špatně zadanou volbu? Tady jde o případ, kdy správce zadal tu volbu zcela správně a s platnou hodnotou. Je tam prostě User=0day, což je normální platný uživatel.
Neznámá volba a neznámý formát hodnoty volby jsou pro systemd to samé. Obojí umožňuje kompatibilitu jednotek s jiným softwarem (např. budoucími verzemi systemd).

0day pro systemd není platný uživatel.

To vypadá že v zájmu kompatibility s něčím budoucím, co neexistuje ani není naplánováno, už nyní není kompatibilita s něčím co funguje.

Pokud neni uvedena, pouzije se defaultni hodnota a pokud ma chybny format, sluzba se nespusti s chybovym hlasenim!
Čímž zabijete jakoukoli kompatibilitu jednotkových souborů.