Vlákno názorů k článku
Dělá systemd Linux více složitým, náchylným k chybám a nestabilním?
od Me - systemd na serveru je nebezpecna vec. Moj problem...
-
Me (neregistrovaný)
systemd na serveru je nebezpecna vec. Moj problem s nim je, ze nikto netusi, aku dalsiu sluzbu sa rozhodnu pani experti zo systemd pribalit do balicka systemd a co vsetko tym pokazia.
Pri jednom dist-upgrade stable debianu, sa takto na moj secondary DNS dostal systemd-resolved, ktory samozrejme obsadil port a vdaka tomu PowerDNS nefungoval. Predtym to islo x rokov bez problemov, nikto sa mi na serveri nesnazil spustat sluzby, ktore som neziadal.Preto moja otazka pri systemd znie, co dalsie si systemd nainstaluje - systemd-httpd, systemd-ldapd, systemd-smtpd ? Ktora dalsia sluzba pojde vdaka upgradu do kytek, pretoze sa niekto rozhodne, ze toto by sa nam hodilo do 'architektury' a doteraz to vsetci robili zle, tak to spravime lepsie....
-
Filip JirsákStříbrný podporovatelPreto moja otazka pri systemd znie, co dalsie si systemd nainstaluje
Nic, stejně jako si nenainstalovalsystemd-resolved. Balíčky neinstalujesystemd, ale správce systému prostřednictvím distribučního správce balíčků. -
Opět vedle, po stažení oficiálního tarballu systemd je uvnitř komponenta systemd-resolved = je přímou součástí systemd není zvlášť. Nedá se to stáhnout zvlášť, nedá se to používat bez systemd, není to samostatná věc ani projekt. Je to komponenta, žádná samostatná věc. Není se pak čemu divit, že to v distribuci také nerozpitvávají na více částí a tak jako to udělali autoři tohoto software tak to je nakonec i balíčku distribuce. Jediné co se dá udělat je zakázat tuto komponentu při kompilaci systemd, pak ta komponenta není, ale zkompilovat ji zvlášť nespíš ani nejde.
PS: Vy znáte distro, které má systemd-resolved zvlášť, že říkáte, že to je problém dister nikoli autora(ů) tohoto software, který to udělal jako nedílnou součást zdrojáků systemd?
-
Filip JirsákStříbrný podporovatel
Ano, je to komponenta, dá se to distribuovat zvlášť, dá se to spouštět zvlášť, nebo se to spouštět vůbec nemusí. Pokud se to v Debianu nainstaluje a a aktivuje samo, přestože je nainstalovaný jiný DNS resolver, je to problém Debianu. Co by s tím asi tak autoři systemd mohli dělat? To už od teď nikdo nesmí naprogramovat DNS resolver, protože jinak ho někdo v Debianu hned nainstaluje a spustí při startu (pokud to opravdu dělá)? Já používám
systemdna různých distribucích, a nikde jsem neměl problém s tím, že by se misystemd-resolverpouštěl, když nechci. -
KateStříbrný podporovatelJá spíš doteď nechápu, proč Debian každou nainstalovanou službu hned aktivuje a spustí. Nebýt toho, tak si nejspíš toho přibaleného resolved ani nevšimne…
-
To že systém aktivuje a spustí nového démona je chyba systemd... Aha.
Jestli to spíš nebude to, že se systemd během upgrade nerozhodl enablovat službu, protože usoudil, že ji nějaká jiná potřebuje a "nechápal", že už jiná konkurenční je/bude enabled během upgrade, ale Lennart s tím, že by někdo mohl upgradovat z jiného initu, takže ta konkurenční se dostane konfigurace systemd až v nějakém dalším kroku upgrade jaksi nepočítá a zapne si svůj dle něj správný "výchozí" stav.
Z toho bych OS nevinil :). -
Petr M (neregistrovaný)
Systemd dělá to, co dostane befelem. Spusť X, postup je napřed Y a Z, potom teprve X. A dej vědět, když se X nerozběhne do 20s po startu závislostí.
Někdo mu musí dát ten befel, kdy a jak tu součást spustí. Sám si nezjistí, že má nějaký modul v systému navíc, ani závislosti. Kdyby byl tak moc vševědoucí, tak nepotřebuje skripty s nastavením.
Takže otázka je, kdo a proč mu dal ten befel? A odověď je, že autoři distra, aby tě vytočili.
-
KateStříbrný podporovatel
A tohle není?
„Jestli to spíš nebude to, že se systemd během upgrade nerozhodl enablovat službu, protože usoudil, že ji nějaká jiná potřebuje a "nechápal", že už jiná konkurenční je/bude enabled během upgrade, ale Lennart s tím, že by někdo mohl upgradovat z jiného initu, takže ta konkurenční se dostane konfigurace systemd až v nějakém dalším kroku upgrade jaksi nepočítá a zapne si svůj dle něj správný "výchozí" stav.
Z toho bych OS nevinil :).“ -
A tohle není?
Určitě je (tedy kromě zkušenosti, že tyhle podivnosti systemd také umí), ale snažím mu to naznačit už chvíli a nějak to nechápe, tak jsem si myslel, že by to mohl pochopit, když to dostane stejně zpátky.
PS: A klasika, Kate to pochopila hned a s přehledem, to zas bude mít někdo ostudu ;-), takže děkuji za nahrávku :-)
-
Sten (neregistrovaný)
To (ne)spouštění lze řešit přes policy-rc.d, akorát některé postinst skripty nezvládnou, pokud se služba nespustí.
Debianní policy je, že služby ve výchozí konfiguraci nesmí naslouchat na síti ani umožňovat měnit systém, tak by automatický start neměl mít bezpečnostní implikace, a protože některé balíčky nejdou nastavit, aniž by běžely služby, na kterých závisí (třeba D-Bus), je lepší spouštět ty služby automaticky, než aby selhala instalace.
-
dw (neregistrovaný)
Akurat ze v centos, fedore je systemd-resoved v stave vendor disabled, tym padom predpokladam ze bude aj v redhate... Cize to aky je systemd v debiane rozd... pokazeny nie je problem autorov systemd ale je to problem diletantov co dali distro do kopy v sucinnosti s diletantmi co to distro pouzivaju...
ČLÁNKY DO MAILU