Názory k článku Nebojte se systemd: jednotky
-
j (neregistrovaný)
Jo, ono se to nejak samo a mozna to i dela to, co autor pise ... a mozna (spis urcite) taky ne ...
Kdyz budu ja chtit na vzdalenym stroji neco pustit, tak to udelam ssh stroj 'command' a je naprosto jasny co se stane. A dokonce tak umim zadat heslo ( k tomu klici) a umim samosebou spustit i interaktivni appku, ktera se treba na neco zepta. Naprosto univerzalni.
Jinak nevim nic o tom, ze by start ntpd neco jednorazove syncnul, na to se pouziva ntpdate. A vi vlastne buh, jestli by to ntpd (nebo i ntpdate) nastartovalo ... kdyz to pustim normalne, tak je to jisty.
-
MP (neregistrovaný)
Pravdepodopne proto, ze jak ntpd, tak i systemd-timesyncd.service maji sva omezeni:
ntpd: neumi sync, pokud se rozjede cas o vice nez urcenou hodnotu (1000s default) a neumi to opakovane (viz -g), pro pouziti ntpdate je nutne navic ntpd stopnout
systemd: nema tak jemny drift jako ntpd, nelze pouzit jako ntp server -
Kolemjdouci (neregistrovaný)
No ja se ted doma bavil s Rpi, ktere pouzivam jako lokalni DNS.
Potreboval jsem delat na rozvodech elektriky, tak jsem ho na par hodin vypnul.
A najednou krasna hlava 22.
Rpi melo pri bootu ujety cas, tak se podivalo do ntp.conf a zkusilo resolvnout vychozi NTP servery z debianiho poolu. Jenze tam je zapnuty DNSSEC, takze resolv neprosel. A DNSSEC nezacne fungovat, dokud se nesyncne cas podle NTP. -
Karbous (neregistrovaný)
Tak mozna staci dat jen -h a usetri se jedno zmacknuti klavesnice. Funguje spolehlive.
Takto maji napriklad vytunenou Jeos verzi oblibene chameleoni distribuce - man neni nainstalovany.
Je to vyborne zvlast pro takove neznalky prikazove radky jako ja, treba pri hledani detailu ohledne prikazu shutdown... -
Filip JirsákStříbrný podporovatelA proto je právě ta možnost zadat to do konfiguračního souboru jednotky – pak to nemusíte vědět ani zjišťovat, a prostě se vám jako help otevře správná manuálová stránka.
-
dustin (neregistrovaný)
Donedávna jsem se systemd přicházel do styku jen na pracovních stanicích, kde mi nijak nepřekážel. Tudíž jsem se k němu v diskusích nijak nevyjadřoval. Minulý týden jsem však konsolidoval firemní servery do LXC kontejnerů s hostitelem debian jessie se systemd a tolik sprostých slov....
Nejvíc mě dostal nekonečný start i stop timeout při změně síťovek. Dříve stačilo přehodit disky do jiného stroje, po nabootování opravit udev pravidlo pojmenování síťovek na novém mac adresy a udevadm trigger nebo reboot. Dnes takový stroj vůbec nenabootuje, nebo po obrovském zpoždění. A hlavně se ani nevypne, takže pole, filesystémy - vše pohlazeno tvrdým bootem. Řešení poskytla dobrá duše v http://unix.stackexchange.com/a/264286 . Nastavit defaultní nekonečný timeout je idiocie nejhrubšího zrna.
-
j (neregistrovaný)
Estli se nechces zblaznit, tak rychle vymen distro, protoze s kazdym dalsim patchem ti to bude fungovat jinak. Viz http://www.root.cz/zpravicky/systemd-po-odhlaseni-zabije-vsechny-procesy-na-pozadi/.
-
Rhinox (neregistrovaný)
Ono obecne ty defaultni hodnoty a defaultni nastaveni co presazuje systemd je v mnohych pripadech totalni blbost...
Ja neverim, ze kdyby tohle pred rokem vedeli lidi z Debianu, ze by souhlasili s prechodem na systemd. Opravdu neverim! Spis mam takovej dojem, ze systemd dev-team drzel tyhle "killer featury" v zaloze na dobu, kdy uz bude systemd pekne zadratovanej ve vetsine distribuci. A ted chces-nechces, musis ze pristusobit. Jina moznost jiz neni...
-
Přesně tak, je to SW omezení na desktopových edicích. Lze to obejít tímto: https://github.com/stascorp/rdpwrap/ :-)
-
Volam nadsene: "Slava"! Systemd uz umi ssh, ted uz fakt schazi jen par detailu, treba Tetris, textovy a graficky editor, IM, vlastni VPN, vlastni SQL databaze, vlastni sitovy stack, ktery pouziva vlastni protokol odlisny od ipvX, a hlavne vlastni jadro, ktere ucini soucasne jadro zastaralym a nepotrebnym.
-
dustin (neregistrovaný)
S ssh používám pro různé servery různé parametry (jiné porty, klíče, občas forwardování portů atd). Takže další vrstva komplikovanosti - musím si to nejdříve nakonfigurovat pro jednotlivé servery v konfigech systemd (předpokládám, že to jde). Kde uvidím logy ssh, kde logy spouštěné aplikace na druhé straně? To jsou všechno zásadní věci, jejich skrývání pod dalšími vrstvami znepříjemňuje život.
-
Filip JirsákStříbrný podporovatel
Proč byste si to konfiguroval extra pro
systemd? Vy nemáte nakonfigurovaného ssh klienta tak, abyste se na ty vzdálené servery připojil?systemctl start ntpd --host root@example.commůžete chápat jako alias prossh root@example.com systemctl start ntpd. Nic jiného komplikovanějšího v tom nehledejte. -
Filip JirsákStříbrný podporovatel
Zatímco v případě použití
systemctlse SSH případně zeptá na heslo. Ano, ve vašem anti-světě to určitě nefunguje, protože tady u nás v reálném světě to funguje.Mimochodem, gratuluji ke zlepšení SLA. Dříve jste zaručoval, že 99,9 % vašich komentářů budou nesmysly popisující pravý opak, než je realita. Ale těch 0,1 % vám občas přeci jen ujelo a občas bylo možné narazit na váš komentář, který se shodoval s realitou – z čehož pak byli všichni okolo zmatení a znovu si všechny informace ověřovali. Už hodně dlouho jsem na takový váš komentář nenarazil a myslím, že se vám k vašemu SLA podařilo přidat alespoň jednu další devítku.
-
je to velmi jednoduché, napřed vygenerujeme jednoduchým příkazem speciální profil:
systemctl --create_new_custom_easy_configuration_profile --new_cool_ssh_profile_name "sshport2222" --new_cooool_ssh_profile_surname "nevimproctochce" --stupid_useless_parameter_just_for_LP_fun "I <3 LP" --easy_online_generated_systemd_key_for_nonstandard_modification "a457445c77d8e894a75754b547c5" --ssh_profile_nonstandard_append_parameters_string "-p 2222"
a potom už jen velmi jednoduše použiješ u systemctl parametr
--I_am_fucking_idiot_and_need_this_nonstandard_profile_but_I_promisse_I_will_not_blame_LP_for_this_shit "sshport2222"
-
Filip JirsákStříbrný podporovatel
Předpokládám, že jste myslel, že máte na nestandardním portu
sshd. V takovém případě ten port asi máte vssh_config, ne? No a pokud nemáte, pak to asi rád píšete ručně, ta zkratka sesystemctl --hostvám nebude fungovat a musíte i tam psát celý příkaz ssshručně. V případě virtuálních strojů ta ruční metoda bude samozřejmě ještě komplikovanější. Ale nic vám nebrání vytvořit patch a prosystemctlimplementovat také tu možnost předat kompletnísshpříkaz. -
dustin (neregistrovaný)
Nejen na heslo, ale typicky si stěžuje na změněný hash při přesunu na jiný stroj. Proto se u služeb využívajících ssh (např. zálohování) nejdříve testuje ručně, že se ssh s klíčem bezproblémově připojí, až pak se to spouští přes aplikace. Každá vrstva navíc je prostě komplikace, a pokud se jí lze vyhnout, je to technicky správné řešení.
-
Sten (neregistrovaný)
Vzhledem k tomu, že systemd pouze spustí ssh, tak si to stěžuje na to samé. Stejně tak můžete použít
.ssh/configpro nastavení čehokoliv, co potřebujete, včetně server aliasů.U té druhé věty nechápu, co to je za výhodu. Každá normální aplikace si umí poradit s tím, když se nepodaří spustit přenosový kanál, ať již protože selže DNS, nefunguje síť nebo nesedí hashe.
-
Měl bych dotaz zrovna k tomu mpd. Zjistil jsem, že po startu systému mi začne mpd naslouchat na 6600, ale už nevím, pod jakým uživatelem (snad dokonce root).
Nevím, jak mu to vymluvit, protože si startuji mpd pod svým uživatelem a klasické "autostart disable" skripty nezávisle od distribuce nefungují. Zatím se mi žádným způsobem nepovedlo ten autostart vypnout (třeba Ubuntu 16.04 nebo CentOS 7). Jaká magie na systemd platí v tomto případě?
-
-
Momentálně mi běží práve ten mpd pod non-root účtem, který jsem spustil ručně. "systemctl status mpd" hlásí "inactive".
Tipnul bych si, že to, co se spouští po startu systému a nevím, jak to vypnout, je v
/usr/lib/systemd/system/mpd.socket:[Socket] ListenStream=/run/mpd/socket ListenStream=6600 Backlog=5 KeepAlive=true PassCredentials=true [Install] WantedBy=sockets.target
Dokud totiž to "něco" poslouchá, odmítá se mpd pod non-root uživatelem spustit, protože port je obsazen (ale ani mpd klient se k tomu nepřipojí, což bych očekával, že tato magie má nějak zaručit autostart reálného daemona).
-
Ondra Satai NekolaZlatý podporovatela obsah te druhe unity?
A _cely_ vystup statusu i na ten socket?
-
Výstup z
systemctl status mpdpo restartu:● mpd.service - Music Player Daemon Loaded: loaded (/lib/systemd/system/mpd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2016-05-30 10:43:32 CEST; 13h ago Main PID: 1175 (mpd) CGroup: /system.slice/mpd.service └─1175 /usr/bin/mpd --no-daemon May 30 10:43:32 sylvan systemd[1]: Started Music Player Daemon. May 30 10:44:13 sylvan pulseaudio[2656]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 May 30 10:44:13 sylvan pulseaudio[2656]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 May 30 10:44:13 sylvan pulseaudio[2656]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.91"Výstup z
systemctl status mpd.socket:
● mpd.socket Loaded: loaded (/lib/systemd/system/mpd.socket; enabled; vendor preset: enabled) Active: active (running) since Mon 2016-05-30 10:43:32 CEST; 13h ago Listen: /run/mpd/socket (Stream) [::]:6600 (Stream) May 30 10:43:32 sylvan systemd[1]: Listening on mpd.socket.BTW takhle vypadá
mpd.servicesoubor:
[Unit] Description=Music Player Daemon After=network.target sound.target [Service] EnvironmentFile=/etc/default/mpd ExecStart=/usr/bin/mpd --no-daemon $MPDCONF # allow MPD to use real-time priority 50 LimitRTPRIO=50 LimitRTTIME=infinity # disallow writing to /usr, /bin, /sbin, ... ProtectSystem=yes [Install] WantedBy=multi-user.target Also=mpd.socket
-
(Sorry za ty zbalený výpisy z code tagů, takhle to dělá root.)
Pokud chci pustit po tomto mpd jako uživatel, musím dát "service mpd stop" jako root ("systemctl stop mpd" nestačí) a pustit "mpd" pod uživatelským non-root účtem.
Se "systemctl stop mpd" ukazuje netstat, že pak na portu 6600 poslouchá init process.
-
Filip JirsákStříbrný podporovatel
Tak příště nemyslete a radši si o tom něco zjistěte.
systemctlneníinit, je to program na ovládánísystemd. To, že nějaký program komunikuje skrze SSH kanál, není nic převratného, dělá to tak například irsync. -
Filip JirsákStříbrný podporovatel
Ano, to je dobrá otázka. Ale je zajímavé, že někteří na tu otázku nepotřebují znát odpověď, protože „vědí“, že systemd implementuje SSH, nebo dokonce vědí, že systemd PID=1 implementuje SSHD. Jak je to doopravdy už napsal Sten.
-
Petr M (neregistrovaný)
"akoze aky je v tom problem? dany skript riesi maintainer daneho distribucneho balika. btw tak isto musi napisat aj unit file pre systemd..."
Jasně, a když v distru bude k dispozici 500 služeb, každou ti někdo bude ladit ručně, že... A u každé bude znát závislosti, konfiguraci,.. A vůbec to nesežere čas, který by šel využít líp. A on to vlastně je nějakej dobrovolník, tak na něho není třeba brát ohled. Přece ho to baví, tak bude 24/7 čekat, až začneš pyskovat, že něco nefunguje.
*Čistý řešení* je, když si autor služby řekne, co potřebuje k jejímu běhu, nejlíp nějakou deklarací, a systém mu to hodí pod nos - instalace závislostí, spuštění služeb, který potřebuje,... A není potřeba nikdo, kdo by se v tom ručně vrtal.
-
Palo M. (neregistrovaný)
"Jasně, a když v distru bude k dispozici..." bla-bla-bla, znoska kydov.
Forma zapisu je adminovi uplne jedno. Ci unit file, skript, alebo cokolvek.
Nakoniec, konfiguraky su aj tak uplne ine pre kazdu jednu sluzbu a admin si toho musi nastudovat omnoho viac.
samalama ma pravdu: to, co je autorom clanku prezentovane ako nejaka vyhoda, v praxi ziadnou vyhodou nie je. -
higgsuv boson (neregistrovaný)
Článek jsem ještě nečetl, ale ten titulek mě zaujal:
„Nebojte se systemd“
Ale on je tu důvod.
systemd ukončuje procesy uživatelů po jejich odhlášení
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394)
↓↓↓↓
vývojář systemd navrhuje jako řešení do tmuxu implementovat dbus a přes něj volat nějakou metodu
(https://github.com/tmux/tmux/issues/428)*When one facepalm is not enough*
-
No, bez legrace ... skoncil jsem u debianu, protoze si clovek mohl byt jist, ze se po dobu jeho sluzby nic zvlastniho nestane, vyjma pozaru v HW. Skousnul jsem grub2 (dobre, nemusim se v tom tedy hrabat, ale at to funguje), systemd (ok, nerozumim co delas, ale hlavne startuj).
A jestli jsme ted prekrocili rubikon tim, ze jedna aktualizace zlikviduje moje legie bezicich screenu a ukonci funkci nekolika mych stroju ... predvidali to, kdyz prijimali systemd? ... Ne, tomu nemohu uverit. -
Sten (neregistrovaný)
Nebojte se, v Debianu tahle nová vlasnost nebude zapnutá, dokud nebude fungovat se screenem a tmuxem. Viz bug 825394.
-
dustin (neregistrovaný)
Těch dotčených aplikací je mnohem víc, přímo v tom bug reportu jsou zmiňované další. Je nesmysl je všechny měnit, navíc lidi třeba používají i své vlastní. Tenhle přístup je prostě hovadina, není o čem diskutovat.
Sleduji mailinglist alsy (nerovná se pulstaudio :) ) a tam platí zásadní pravidlo - neměníme legacy funkcionalitu, jen opravujeme chyby a přidáváme další API, jak vzniká potřeba u nových zařízení. Hlavní správce si to sakra hlídá a neakceptuje patche, které by mohly rozhodit stávající správně napsané user-space aplikace.
-
dustin (neregistrovaný)
=====
ALSA je část jádra. Tam platí jiná pravidla.
=====Naopak, v tomto případě se jedná o user-space API knihoven kolem alsa-lib. User-space programy nevolají služby alsích modulů napřímo.
Tato pravidla vycházejí ze zdravého rozumu a měla by platit v mezích možností vždy a všude. Pokud ke změně rozbíjející legacy kód není opravdu zásadní důvod, pak by se dělat neměla.
Protože to má spoustu dopadů. Provozujeme několik serverů na netu. Sami i klienti kontrolujeme jejich zabezpečení. Takže musíme samozřejmě upgradovat v případě bezp. problémů. Co myslíš, chce se nám upgradovat servery z wheezy na jessie? Dosud to bylo vždy docela bez problémů (upgradů už proběhla celá řada). Nyní budeme wheezy držet, co to půjde, protože můžeme čekat mraky problémů se systemd v jessie. I když si to vyzkoušíme bokem, stejně lze očekávat nějakou neotestovanou situaci. Máme tam některé klíčové systémy v legacy chrootu (bez LXC), spouštěné Jak se to podepíše na bezpečnosti těch serverů? A takhle se bude chovat mraky správců. Tyhle zbytečné změny povedou akorát ke snížení bezpečnosti internetu jako celku.
Donedávna jsem byl optimistou a věřil, že správci debianu udrží systemd v jessie pod kontrolou. K systemd jsem se nevyjadřoval, protože se mě defacto nijak netýkal. Poslední dobou (po pár setkáních s jessie na serverech) začínám mít obavy, co dál.
-
Sten (neregistrovaný)
A když ten legacy kód používá nedokumentované chování?
Několik serverů jsem aktualizoval. Problém jsem se systemd měl jen ten, že jsem se musel naučit s ním pracovat.
Pokud se přesto obáváte, tak Debian nikoho nenutí používat systemd. Bylo o tom i hlasování. Klidně můžete zůstat u sysvinitu, upstartu nebo něčeho jiného, co jste používal dřív, v Jessie, Stretchi, Sidu i Experimental pořád jsou.
-
dustin (neregistrovaný)
====
A když ten legacy kód používá nedokumentované chování?
====Nevím, zda např. nohup používá nedokumentované chování, ale používá se takto desítky let, je popisován ve všech knížkách o správě linuxu. To je pro mě dokumentované chování.
====
Několik serverů jsem aktualizoval. Problém jsem se systemd měl jen ten, že jsem se musel naučit s ním pracovat.
====Asi to byly jen jednoduché věci. Hned při první příležitosti jsem narazil na velice nepříjemnou a zcela nelogickou změnu chování http://www.root.cz/clanky/nebojte-se-systemd-jednotky/nazory/876735/
Všechny aktualizace debianů na serverech jsme vždy dělali vzdáleně, přes ssh. Sice v noci, ale za provozu. Na tohle si v případě upgradu na jessie se systemd ani náhodou netroufnu.
-
Nevím, zda např. nohup používá nedokumentované chování, ale používá se takto desítky let, je popisován ve všech knížkách o správě linuxu. To je pro mě dokumentované chování.
Kdyby jen Linuxu, ale nejspis i v kazde knizce o libovolnem *NIXu. Nohup je definovan v POSIXu. Ale POSIX patrne dnes znamena Poettering's Operating System Interface, takze je vse v poradku.
-
Sten (neregistrovaný)
POSIX nikde neuvádí, že by nohup měl přežít konec sezení. Pouze že přežije poslání SIGHUP. Což nemusí a často ani není totéž, třeba pokud po přihlášení spustíte MC, pak všechny další příkazy jsou spuštěné v novém shellu a ukončením MC by je to postřílelo SIGHUP. Sezení ale neskončí, dokud neskončí ten původní shell.
-
ebik (neregistrovaný)
No to neni uplne pravda. Grub2 se jen prestal spolehat na to, ze mu filesystem nepresune bloky kde je ulozen. Takze mu muzete vytvorit specialni partisnu s par jednotkama mega, nebo pouzit filesystem, ktery ma na zacatku partitiony dostatecne rezervovaneho mista (bohuzel z hlavy zadny takovy neznam). Kazdopadne to asi ale bude chtit priohnout jeho install skripty (to uz je peknejch par let co jsem to delal). A obavam se, ze bude grub vytlacen nahravanim jadra do EFI, nebo tak neco.
-
BS (neregistrovaný)
Zdravím,
Problém je, že skript /etc/init.d/jmeno se musel pro každého démona vytvářet znovu.
Tohle mi stále uniká. Za prvé snad stále musím napsat unit file a to pro každého daemona znovu, což je naprostá maličkost, ale za druhé v jakémkoli složitějším (čti produkčním) případě stejně bude nevyhnutelně třeba samotné daemony owrappovat nějakým skriptem, který doladí detaily.
Napíši tedy skript, který bude mít třeba argument start a stop a ten pak uvedu do příslušných parametrů unit file, kam přidám ještě závislosti, podobně jako v LSB hlavičce init skriptu. Dohromady tedy napíši klasický init skript, ale místo jeho hlavičky někde bokem vytvořím unit file. To ale přece znamená, že jsem si nijak nepomohl, práce mi to tedy připadá úplně stejně.
Samozřejmě po nějaké mpd to bez wrapperu asi půjde, ale to je jednoznačně desktopová věc a na desktopu uživatel běžně init řešit nemusí, ať má ten, či onen, já jsem až na naprosté výjimky nikdy nic takového dělat nemusel. Z druhého pohledu, mé zkušenosti s vývojem jak embed zařízení, tak serverových aplikací (skutečně daemonů, žádný web) naznačují, že skriptování se vývojář (jistě nikoli uživatel) nikdy nevyhne.
Možná, že systemd má nějaké výhody proti sysv-init, ale výše uvedené tvrzení je podle mě skutečně nesmysl.
-
Filip JirsákStříbrný podporovatel
Za prvé snad stále musím napsat unit file a to pro každého daemona znovu
Je rozdíl mezi tím napsat skript v turingovsky úplném jazyce, který může dělat cokoli – a napsat konfigurační soubor.stejně bude nevyhnutelně třeba samotné daemony owrappovat nějakým skriptem
Proč? Co by ten skript dělal? -
Kiwi (neregistrovaný)
No právě. Že mám k disposici turingovsky úplný jazyk považuji za obrovskou výhodu. Občas se to totiž může hodit a v takovém případě se díky tomu dá elegantně vyřešit problém, který by byl jinak obtížně řešitelný nebo neřešitelný.
Ale to je problém celého systemd a všech jeho zastánců - příliš mnoho toho ještě nepochopili, ale mají pocit, že vše dokonale chápou. Opravdu nechápu, co je vede směrem, kterým se kdysi vydaly Windows, když je evidentní, že to byla slepá ulička.
Někteří lidé by asi opravdu měli zůstat u Windows a nepokoušet se programovat Linux, nebo ještě lépe - nepokoušet se programovat vůbec.Když Poettering zkouší vylepšovat Unix, je to podobné, jako by se Justin Bieber pokoušel vylepšovat Mozarta.
-
Filip JirsákStříbrný podporovatel
Že mám k disposici turingovsky úplný jazyk považuji za obrovskou výhodu.
Ne, vy ho nemáte k dispozici. Vám nezbývá nic jiného, než ho použít. K dispozici ho máte v systemd – ale ve většině případů ho použít nepotřebujete.Ale to je problém celého systemd a všech jeho zastánců - příliš mnoho toho ještě nepochopili, ale mají pocit, že vše dokonale chápou.
No já nevím. Váš komentář v části týkající se porovnání systemd s jinými inity obsahuje dvě chyby. Odpůrci systemd jeho neznalost prezentují v každém druhém komentáři. Byl bych opatrný v hodnocení toho, kdo co nepochopil. -
Vám nezbývá nic jiného, než ho použít.
Ano, přičemž celý ten turingovsky úplný aparát musíte nutně použít, v žádném případě v bash skriptu nelze přiřadit jen hodnotu do proměnné. Jasně. Prostě se to musí nutně používat v celé turingovské komplexnosti...
Mě se "líbí" (kdyby někdo nepoznal: ironie), jak se to dostalo do roviny urážek.
Název článku projistotu rovnou obsahuje slovo "nebojte", aby se toto vyřídilo hned v nadpisu a v diskusi padají slova jako nechápou, nepořádek apod.
Takže NetworkManager (viz minulá diskuse) nefunguje nikoliv proto, že jeho autoři jsou neschopní, případně nevěděli, do jak velkého úkolu se pouští, ale proto, že starý způsob nastavení sítě je nepořádek (nepořádek pro koho? Možná pro autory NM, ti se v tom nevyznají.). Aha. Takže starý způsob, který roky fungoval se označí slovem nepořádek jen proto, že někdo nedokáže napsat jeho náhradu. Super.
Teď se tady opakuje slovo neznalost a nepochopení. Problém je, a bylo to vidět i v bugreportech ohledně zavedení KillUserProcess=yes, že systemd nelze znát. Někdo to tam napsal správně. Nikdo nečte všechny changelogy i kdyby ano, i kdyby znal intimně verzi 229 a měl naučené všechny man stránky z paměti, tak je mu to stejně na nic, protože ve verzi 230 mu to stejně přestane fungovat. Při tomto způsobu vývoje ani není možné systemd znát.
Mimochodem doteď jsem se nedozvěděl od lidí,kteří systemd chápou, rozumí mu a nebojí se ho, žádné řešení (já jsem navrhl 3).
-
Filip JirsákStříbrný podporovatel
Ano, přičemž celý ten turingovsky úplný aparát musíte nutně použít, v žádném případě v bash skriptu nelze přiřadit jen hodnotu do proměnné. Jasně. Prostě se to musí nutně používat v celé turingovské komplexnosti...
Zdá se, že nechápete, v čem je ten problém. Problém není v tom, že nějaké konstrukce bashe můžete použít. Problém je v tom, že nedokážete zabránit tomu, aby je někdo použil, problém je v tom, že to, zda jsou nebo nejsou použité, zjistíte jedině tak, že ten skript otevřete a celý ho přečtete.Takže starý způsob, který roky fungoval se označí slovem nepořádek jen proto, že někdo nedokáže napsat jeho náhradu.
To někomu podsouváte svůj vlastí argument a zaměňujete příčinu a následek. Někdo nechce psát plnohodnotnou náhradu nepořádku, protože plnohodnotná náhrada nepořádku je zase jen nepořádek.systemd nelze znát
Porovnáváte jeden systém, který je ve vývoji, se systémem, který se v základu nezměnil už hodně dlouho, a na něm je zbastleno spousta individuálních řešení. Výsledek je v současné době stejný – konkrétní řešení nelze znát. Výhoda systemd je v tom, že směřuje ke stavu, kdy ho bude možné znát, a jeho znalost použijete na kterémkoli systému. Na rozdíl od těch současných „řešení“, kdy sice můžete znát jednu konkrétní (nejlépe svou) instalaci, ale když přijdete jinam, můžete akorát hádat. -
Problém je v tom, že nedokážete zabránit tomu, aby je někdo použil, problém je v tom, že to, zda jsou nebo nejsou použité, zjistíte jedině tak, že ten skript otevřete a celý ho přečtete.
Já to za problém nepovažuji. Navíc historie ukazuje, že ty skripty jsou mnohem stabilnější co do chování, než systemd. Takže ano, v bashi může kdokoliv napsat cokoliv, to je pravda, ale v praxi se ukázalo, že tam píše jen to, co je nutné pro běh jeho služby (tzn daemonizace nějakého programu).
Někdo nechce psát plnohodnotnou náhradu nepořádku, protože plnohodnotná náhrada nepořádku je zase jen nepořádek.
Pokud někdo nechce psát plnohodnotnou náhradu něčeho staršího, tak to nutně skončí tak, že napíše neplnohodnotnou náhradu a pro stavy, kde tato náhrada nepůjde použít (na rozdíl od staršího řešení), to zase někdo bude muset nabastlit nějakým skriptem nebo něčím. Takže opět vznikne nepořádek.
Potom klasicky opět přijde někdo, kdo to označí za nepořádek a protože opět nepochopí, v čem je problém, tak napíše ještě méně kompletní verzi a bude se to bastlit ještě víc. Takže zatímco na začátku jsou utilitky slepené turingovsky úplným lepidlem, tak na konci jsou utilitky, které toho umí ještě míň, jsou opět spojeny tu lepidlem. Gratulujeme.
Porovnáváte jeden systém, který je ve vývoji, se systémem, který se v základu nezměnil už hodně dlouho, a na něm je zbastleno spousta individuálních řešení.
Ne neporovnávám. Jestli něco porovnávám, tak je to systemd verze 229 a systemd verze 230, kde proběhla zcela zásadní změna koncepce formou jednoho odstavce v changelogu. I kdyby někdo měl krásně funkční systém postavený na 229, tak mu to ve 230 prostě nebude fungovat.
Takové změny se obvykle řeší tak, že se nějaké staré řešení označí za deprecated, do logu, nebo na stderr, nebo při spuštění, nebo na jiné vhodné místo se dá upozornění, a po nějaké době se to přepne. Chovají se tak všechny příčetné systémy. Ne, že se to změní z verze na verzi a do bugzilly kompletně nesouvisejících projektů se napíše bug opravte si, co jsme my rozbili.
-
Filip JirsákStříbrný podporovatel
Pokud někdo nechce psát plnohodnotnou náhradu něčeho staršího, tak to nutně skončí tak, že napíše neplnohodnotnou náhradu a pro stavy, kde tato náhrada nepůjde použít (na rozdíl od staršího řešení), to zase někdo bude muset nabastlit nějakým skriptem nebo něčím. Takže opět vznikne nepořádek.
Nikoli. Ta náhrada obvykle poskytuje nové funkce. Stavy, kde náhrada nejde bezezměny použít, jsou (pokud ta náhrada je rozumná) hacky hacků – a náhrada pro danou věc poskytuje čisté řešení, bez hacků. Takže jediný „problém“ je ten, že je potřeba ty původní hacky zahodit a udělat to novým způsobem a pořádně. Skutečným problémem je pak to, že někdo trvá na použití těch hacků, pokouší se vyrobit hack hacku hacku a rozčiluje se, že mu to nejde. V jiné oblasti to vidíme třeba při přechodu na IPv6, kdy je taky spousta „administrátorů“ celá nesvá z toho, že najednou mají veřejných IP adres, kolik chtějí, a pořád se snaží někam naroubovat NAT a šetřit IP adresy, protože jsou na tyhle hacky zvyklí.staré řešení označí za deprecated
To by mne zajímalo, jak chcete označit jako deprecated defaultní hodnotu konfigurační volby. -
a udělat to novým způsobem a pořádně
Fajn, zpět k systemd, je někde popis, jak to udělat novým způsobem a pořádně a tak, aby to přežilo změnu verze 229 a 230?
Když přijde junior, chytrý, inteligentní člověk světem serverů nepolíbený, odkud podle tebe má začít?
Tohle totiž nikde není. systemd jede změnu za změnou salámovou metodou a není možné se připravit na budoucí verze. Celé to působí dojmem, že ani autoři nevědí, kam jedou.
To by mne zajímalo, jak chcete označit jako deprecated defaultní hodnotu konfigurační volby.
Tak především se ta defaultní hodnota změnila. V 229 byla no, v 230 je nově yes.
Tohle na první pohled nevinné přepnutí způsobuje to, že věci, které fungovaly 30 let náhle fungovat přestávají. Ano, jedno ze 3 řešení je přepnout si to zpět na no. Ale asi to není ta správná systemd way, protože jinak by ten default neměnili. Jen vůbec není jasné, jaké je to správné nové řešení.
Za druhé, to si z nás opět děláš srandu, že? Za těch 15 let jsem mnohokrát na různých místech (při update balíčku, při bootu, při spuštění služby, v logu, na stderr, prostě všude) viděl různá varování: pozor, toto je deprecated a změní se to, upravte si to. Je to zcela běžné.
-
Filip JirsákStříbrný podporovatel
Tak především se ta defaultní hodnota změnila. V 229 byla no, v 230 je nově yes.
Ano. A vy jste psal, že ve verzi 230 měla být výchozí hodnotanooznačena jako deprecated, a někdy později teprve změněna nayes. A já se ptám, jak konkrétně se to mělo udělat. Měla se do systemd přidat funkcionalita, že se u každé volby bude sledovat, odkud pochází, a pokud pochází z v výchozí konfigurace a jeno, mělo se vypsat varování? Nebo se varování mělo vypisovat pořád, bez ohledu na nějakou konfiguraci? Srandu si nedělám, zcela vážně jsem se ptal na to, kdy přesně by se to varování mělo zobrazovat, a svůj dotaz tímto opakuju. -
A vy jste psal, že ve verzi 230 měla být výchozí hodnota no označena jako deprecated
Nic takového jsem nepsal.
Srandu si nedělám, zcela vážně jsem se ptal na to, kdy přesně by se to varování mělo zobrazovat, a svůj dotaz tímto opakuju.
Můj návrh: od verze 200, nebo lépe 150, se mělo zobrazovat upozornění: pozor, chystáme se na velkou změnu koncepce, je možné, že vám některé věci přestanou fungovat. Popis změny a doporučený postup naleznete v
man systemd_future, případně na webu. -
BS (neregistrovaný)
Napsání unit file je samozřejmě naprostá maličkost, to nikdo nezpochybňuje. A co by ten skript dělal? Tak třeba primitivní příklad ze života. Představte si službu, která běží na na embed zařízení v rámci své inicializace potřebuje přečíst několik parametrů z integrované EEPROM. A teď si představte, že máte více typů těchto zařízení, ale ty mají různé procesory a EEPROM je na každém připojena trochu jinak.
Takže mám tři možnosti, buď do služby přímo implementuji schopnost číst všechny typy, nebo vytvořím pro každý HW vlastní verzi, což je dost neudržovatelné a nebo pro každý HW napíšu skript, který údaje přečte a službě předá jako argument. Třetí varianta je nejsnazší, je sice třeba udržovat skripty, ale není potřeba nepřetržitě modifikovat zdrojové kódy (třeba C) služby. Navíc je také možné, že služba je nějaký OSS, který se vyvíjí a bylo by nutné vždy novou verzi patchovat, takže přímá modifikace služby je dost komplikované řešení, proti eleganci skriptu.
Ty skripty slouží jako glue, který lepí danou službu s konkrétním nasazením, svět Linuxu není jen x86/amd64 s Gnome/KDE. Naopak ty desktopy jejichž HW má ve srovnání se zbytkem zařízení v podstatě normované chování jsou naprostá minorita. Také je naprosto správně, že programátoři neimplementují každou možnou nuanci do binárky nebo do konfigurace, ale očekávají, že tyto nuance se vyřeší skriptem. Není ani nic nezvyklého, že konfigurace daemona se vytvoří až ve skriptu, podle nějakého templatu.
-
Filip JirsákStříbrný podporovatel
Aha, takže ve skutečností žádný wrapper pro spuštění nepotřebujete. Potřebujete buď nástroj, kterým vytvoříte předem konfiguraci pro dané zařízení (pokud se nemůže měnit), a nebo potřebujete nástroj, který spustíte před vlastní službou, který zjistí příslušné parametry a službu před jejím spuštěním nakonfiguruje.
Vidíte, ve vašem řešení se obalujícím skriptem byste to slepil všechno dohromady a následně by se to špatně udržovalo. Systemd vás vede k tomu, abyste oddělil službu a její konfiguraci, takže to pak můžete spravovat i aktualizovat každé zvlášť.
-
BS (neregistrovaný)
Pokud jde o udržování rozdíl nevidím, v obou případech je někde nějaký skript, který je potřeba udržovat. Pokud jde čistě o vygenerování konfigurace, máte pravdu, že je velmi elegantní použít samostatnou službu, které se o to postará (ta služba je skript), toto často při vývoji používám bez ohledu na init systém. Pokud, jde ale pouze o to předat dva argumenty začne to dle mého ztrácet přehlednost.
Konfigurační služba by vytvořila předpis pro spuštění druhé. Tento předpis by mohl být buď přímo unit file, nebo jednořádkový skript, který by předem udělaný unit file spustil, což mi připadá ekvivalentní, ale zdá se mi to jako jít kanónem na vrabce.
Nicméně mě neberte jako apriorního odpůrce systemd, já si více méně myslím, že za pár let, až se stabilizuje API, bude mít linuxovému světu hodně co nabídnou. Poukazuji pouze na to, že absence skriptování je utopie. Jak vidíte, tak jak v mém tak ve vašem řešení se ten skript objevuje, jde jen o to kdy a kde se spustí, což je konec konců kosmetické, někdo ho totiž stejně musí napsat.
Sys-V init má spoustu nedostatků, o tom není pochyb, ale skriptování k nim nepatří, to je naopak největší přednost, právě díky univerzalitě, kterou tento přístup nabízí, se udržel tak dlouho i přes své nedostatky. Konec konců, třeba ten Debian také používá systemd převážně jako spouštěč LSB init skriptů a řekl bych, že jiné distribuce jsou na to podobně.
-
Filip JirsákStříbrný podporovatel
Univerzálnost je dobrý sluha, ale zlý pán :-) Systemd umožňuje použít skripty, pokud je to potřeba – ale pro většinu věcí to potřeba není, a nakonec dosáhnete lepšího výsledku jednodušším konfiguračním souborem. všechno, co můžete udělat v systemd, můžete udělat i v univerzálním skriptu – akorát zkušenost ukazuje, že se tak neděje.
