Osobně třeba nesnáším "systemd-resolved". Do /etc/resolv.conf strčí nějakou capinu jako: nameserver 127.0.0.53. A změnit to je vopruz. V momentě, kdy nameserver nefunguje se to dá dočasně zeditovat, ale za chvíli to opět přeplácne tou nefunkční konfigurací. Něco jsem našel tady: "/etc/systemd/resolved.conf", ale nejsem si jist, jestli to vždy zafungovalo. Mám pocit, že ne, že tu ruční editaci ignoroval.
> Do /etc/resolv.conf strčí nějakou capinu jako: nameserver 127.0.0.53.
Ta capina je tam kvůli tomu, že standardní resolver v libc je „úplně blbej“ a jediný způsob jak mu vnutit DNSSEC, DoT nebo překládání různých TLD u různých serverů je spustit si lokálně vlastní DNS server, který tohle bude dělat. A jeden z takových serverů je právě systemd-resolved (předtím lidi třeba měli lokální dnsmasq, unbound nebo bind). Pokud uvedené nepotřebuješ, tak ho prostě odinstaluj, respektive neinstaluj (to ti vnutila distribuce?).
> Něco jsem našel tady: "/etc/systemd/resolved.conf", ale nejsem si jist, jestli to vždy zafungovalo. Mám pocit, že ne, že tu ruční editaci ignoroval.
A jak jinak by se to mělo konfigurovat? Restartoval jsi ho po editaci?
To, ze nejaka soucast generuje nejaky konfigurak a prepisuje mi ho, je z meho pohledu zasadni problem dnesniho Linuxu, byt asi ne ten nejzasadnejsi.
Reseni je urcite upravit primarne glibc, aby nebylo nutne resolv.conf rucne menit.
Pridal bych treba to, ze (napr.) systemy typu Bubuntu prepisuji konfiguraky GRUBu (obecne vlastne cehokoliv). Jako daleko lepsi bych videl, ze v hlavnim konfiguraku (na ktery mi zadny skript uz nesahne) bude nejaky 'include' toho generovaneho, abych nad tim neztratil kontrolu. Kdyz si ten include smazu nebo ho nejak znefunkcnim, je to muj problem.
Jako cloveka, ktery umel pouzivat Unix koncem devadesatek se dneska uz naprosto ztracim v tech "novinkach". A popravde se je ani nechci ucit - je to jak ve svete Windows, veci se neustale meni, ackoliv mi v dusledku neprinasi pridanou hodnotu.
V moji realite to je tak, ze se nechci ucit veci, ktere mi neprinasi nic noveho. Vnasite tam myslenku "vse nove je lepsi" (ne, neni, v mem zivote urcite ne).
Tedy napriklad se velmi rad naucim rad AArch64, pripadne nejake R-V veci, protoze v tom vidim smysl, k necemu to pouziju, muj zivot to zlepsi. Nemam zajem ale zjistovat jak aktualne funguje (napr.) nejaka systemd vec, kdyz to za rok bude uplne jine (nekdo opet dostane napad jak to udelat "lepe", ale to je spis demonstrace vnitrniho pocitu "ja to umim nejlepe").
Treba to mate uplne jinak, a takovehle hrani si s Linuxem Vam plni nejakou potrebu. Mne ne.
Jenže problém je že to vidíte za sebe -- když to nepřínáší užitek vám (nebo ten užitek za sebe nevidíte), nepřináší to užitek nikomu. Ale to není pravda, třeba takové systemd-resolved např. přináší možnost resolvování tld o specifický ns, což je věc kterou třeba já využiji (vy asi ne).
Mě to připadá že jste se prostě jednou "naučil" v 90kách unix a představujete si že to bude na celý život. Takhle to ale ve světě nefunguje, veškeré věci procházejí evolucí (os, software, programovací jazyky i nakonec takové věci jako (ať se nedržíme výhradně software) vozidla, letadla, řemesla... prostě všechno). A to co platilo před 10, 20 lety opravdu dnes neplatí a popravdě ani většině uživatelů(programátorů, řemeslníků, řidčů...) by to nevyhovovalo.
Ano, kazdy to mame jinak. Pisu jak to mam ja.
Ano, souhlasim s tim, ze svet prinasi nove problemy, v 90tkach DNSSEC nebyl, a je to vec, ktera resi urcity problem, byt ne zcela dokonale, ale je to myslim good enough reseni.
Ale uz nesouhlasim s tim, ze vetsina novych reseni (ala koncepty v systemd-resolved) skutecne prida takovy uzitek, aby stalo za to domrvit stavajici reseni. To co vlastne popisujete pokud jde o nutne zmeny (cache atd.) tak by do (g)libc zcela urcite slo zapojit vic po vzoru paradigmatu Unixu (sada malych komponent delajicich svoji praci dobre).
Treba nakonec skoncim u OpenBSD :).
> To co vlastne popisujete pokud jde o nutne zmeny (cache atd.) tak by do (g)libc zcela urcite slo zapojit vic po vzoru paradigmatu Unixu (sada malych komponent delajicich svoji praci dobre).
Nechápu co není unixového na přístupu „spustím lokální DNS démon který všechny ty komplikace bude řešit, nechám ho poslouchat na 127.0.0.53, tohle napíšu do resolv.conf a všichni se ho budou ptát stávajícím jednoduchým způsobem a on jim bude vracet jednoduché odpovědi“. Jakmile máš cache, DNSSEC klíče a já nevím co dalšího, tak se všechny programy co dělají resolving budou přetahovat o nějaký soubor ve /var/cache/bleble a nedejbože bude muset být něco SETUID nebo +t aby to tam mohlo zapisovat.
Posílat systémovou poštu přes lokálně běžící postfix/exim4 ti taky přijde neunixové?
To co vlastne popisujete pokud jde o nutne zmeny (cache atd.) tak by do (g)libc zcela urcite slo zapojit vic po vzoru paradigmatu Unixu (sada malych komponent delajicich svoji praci dobre).
Nevím, jak ještě víc unixově byste si službu pro překlad DNS záznamů představoval, než že záznamy překládá, validuje a kešuje. Nenajdete žádnou jinou službu, která by dělala třeba jenom cache pro DNS záznamy a počítala by s tím, že překládat to bude jiná služba.
Naopak tady někdo jako alternativu zmínil DNSmasq, který kromě překladu a cache dělá také autoritativní DNS server a DHCP server.
Tak si vzpomente na init systemy z te doby :-) To byl jeden velky bastl. Clovek si vesmes vystacil s tim, ze sluzby nastartovaly v nejakem poradi... Kdyz chcel hlidat beh sluzeb, musel to nejak zrovnatak bastlit okolo, zrovnatak byly dost velkym bastlem i ruzne pokusy o paralelizaci startu sluzeb... a cela bezpecnost stala a padala s tim, co vytvoril autor init scriptu.
No a Vam to mozna staci dodnes... a tak proc ne. Ale od moderniho init systemu se toho chce ponekud vic. To ze moznosti systemd (treba omezit prava, systemove zdroje, izolovat tmp) vyuzit nedokazate opravdu jen dokazuje neochotu se neco noveho naucit a treba to delat lip nez pred ctvrt stoletim ;-)
Motame se v kruhu, tak uz jen strucne: Nemyslim, ze sysV init byl spravny a nahradit je ho urcite dobre, ale vsechny koncepty, ktere prinasi systemd za to myslim nestoji.
Mam-li si vybrat predvidatelny system se SysV initem, nebo neco co mi prepisuje konfiguraky, tak volim radsi neco na zpusob toho SysV initu, protoze udrzet to funkcni mne myslim bude stat mene casu.
Na druhou stranu to, ze Ubuntu prinasi celkem dobry komfort pokud jde o snadnost instalace a updatovani zatim stale prebiji nevyhody, ktere mi to prinasi, takze ho pouzivam. A tohle pisu z Windows, protoze v Linuxu mi zase nefunguji nejake pracovni veci, takze Win vyhraly na tomto stroji nad Linuxem.
Abych dodal posledni vec, vystupovani Lennarta celkem jasne ukazuje jeho osobnost a zapada to do meho modelu "vim nejlepe jak to maji ostatni delat".
Jenze samotny init (systemd) zadny konfigurak v etc neprepisuje, to je proste FUD... z neznalosti. A flame kolem /etc/resolv.conf - ehm, ten prepisuje treba i network manager, ktery se systemd vubec nic spolecneho nema. A naopak samotny systemd-resolved daemon na /etc/resolv.conf nesaha - to je prace, co udela postinstall script samostatneho balicku (minimalne v pripade Debianu/Ubuntu) - ktery zmineny soubor nahradi symlinkem na soubor umisteny v /run/systemd/resolve/... ale samotny daemon do /etc/resolv.conf fakt nehrabe. Kdyz nevite a viditelne si ani nedokazete zjistit, jak to doopravdy funguje, tak radsi pomlcte :-)
> A flame kolem /etc/resolv.conf - ehm, ten prepisuje treba i network manager
NetworkManager (s velkými písmeny) je taky „kontroverzní“ technologie. Spíš bych jako příklad dal dhclient - a ten dokonce kašle na symlinky…
Mě by zajímalo jestli mu to fakt přepisovalo soubor v /etc, myslím si že tam měl symlink a nevšiml si toho (a symlink stačilo smazat -- a nebo resolved odinstalovat, když ho nechce - otázka je proč ho vůbec instaloval, například na Debianu se automaticky neinstaluje).
Proc kontroverzni? Jasne, na server si to clovek nestrci, ale proc ne notebook, se kterym clovek porad nekde lita? Nektere use-case to vyresi naopak elegantne (priority LAN/WLAN/WWAN + ev. i VPN) a to vc. spravneho poskladani toho resolv.conf. Dynamicky... jasne, s ifupdown to jde vykouzlit taky, ale je to desnej os*r :D
Protože je potřeba nastudovat jadernou elektrárnu aby to člověk dokázal používat pro všechny své use-casy (připoj se a nenastavuj adresu; nastav statickou; až teď si řekni o DHCP ale nenastavuj z toho default routu; na jedné wifi kartě spusť hostapd a druhou používej pro připojení a NATuj…) a viděl jsem příliš mnoho lidí v tom failovat (populární je třeba zapomenutí ručně nastavené adresy na ethernetovém rozhraní když na chvilku spadne link). Nepochybuji že všechno z toho lze nastavit i s NM, ale pro mě bylo jednodušší si napsat těch pár shellových skriptů co to připojení zařídí. mhi to může mít stejně a odkloní se tím diskuze uvedením nevhodného příkladu.
A tak kdyz notebook pouzivate jako substitut za router :-) Na vetsinu beznych ale i pokrocilych (klientskych) use-case ale zadnou elektrarnu studovat netreba, to clovek proste naklika. A samozrejme kdyz mam na chvili echt specificky pozadavek, nic mi nebrani v tom GUI cely NM vypnout/nenechat klidne i jen jedno rozhrani NM spravovat a udelat to bokem rucne dle libosti. Za posledni tri roky jsem to udelal... mozna jednou?
Mam-li si vybrat predvidatelny system se SysV initem, nebo neco co mi prepisuje konfiguraky, tak volim radsi neco na zpusob toho SysV initu, protoze udrzet to funkcni mne myslim bude stat mene casu.
systemd je mnohem předvídatelnější, než SysVinit. A přepisování konfiguráků dělají distribuce odjakživa. Třeba když jste uměl nakonfigurovat síť (tehdy ještě) pomocí ifconfig nebo později ip, nakonfigurovat firewall pomocí iptables nebo dříve ipchains, bylo vám to ve většině distribucí k ničemu, protože konfigurovaly síť vlastními skripty z vlastních konfiguračních souborů. Nadával jste tehdy na to, že je to špatně a nerozumíte tomu – nebo jste se prostě naučil používat ty distribuční konfigurační soubory?
To jak distribuce prepisuji/generuji konfiguracni soubory mi prijde jednoduse uplne spatne.
Moje cesta byla tehdy primet nejak distribuci, aby mi moc nekladla prekazky a upravit si to k obrazu svemu v necem *typu* rc.local :). A nenadaval jsem, ani jsem myslim do nikoho neprojikoval odstepene casti sveho JA ;).
Mate ze mne radost, ze?
To jak distribuce prepisuji/generuji konfiguracni soubory mi prijde jednoduse uplne spatne.
Za prvé, když musíte znásilňovat nějaký nástroj k obrazu svému, měl byste přemýšlet o tom, zda používáte správný nástroj a zda ho používáte správně. Případy, kdy opravdu není jiná možnost, jsou výjimečné. Častější je, že si tím přiděláte práci.
Za druhé si tím budete práce přidělávat čím dál víc, protože software je čím dál komplexnější, aby pokryl čím dál víc situací. Na úrovni předem připravené konfigurace se to řeší tak, aby nejčastější případy byly stále stejně jednoduché – ale když si to předěláte po svém, komplikujete si to, a komplikujete si to čím dál víc.
Za třetí, když jste nenadával tenkrát, proč na to samé dnes nadáváte?
To, ze nejaka soucast generuje nejaky konfigurak a prepisuje mi ho, je z meho pohledu zasadni problem dnesniho Linuxu, byt asi ne ten nejzasadnejsi.
To není žádný novinka, tohle dělají linuxové distribuce odnepaměti.
Reseni je urcite upravit primarne glibc, aby nebylo nutne resolv.conf rucne menit.
Jak byste glibc chtěl změnit? Třeba pro validaci DNSSEC je rozumné mít keš, kterou je rozumné mít sdílenou napříč procesy. To znamená mít systémovou službu, která bude pro ostatní procesy provádět překlad a validaci DNS. (Jako je to ostatně v mnoha jiných případech, kdy si každý proces neřeší všechno sám, ale nechává to na jádru OS nebo jiných procesech.) No a překlad DNS a kešování už dělá kešující DNS resolver, tak proč takovou službu nepoužít i pro lokální počítač?
Jako cloveka, ktery umel pouzivat Unix koncem devadesatek se dneska uz naprosto ztracim v tech "novinkach". A popravde se je ani nechci ucit - je to jak ve svete Windows, veci se neustale meni, ackoliv mi v dusledku neprinasi pridanou hodnotu.
Jenže ono to koncem devadesátek nebylo principiálně jiné a tehdy stejně brlali ti, co se něco naučili v sedmdesátkách. Rozdíl pro vás je jenom v tom, že vy jste se to tenkrát naučil a nechcete se už naučit nic nového. Máte na to samozřejmě plné právo – akorát teda já teda až zjistím, že už se nechci učit nic nového, budu vědět, že už jsem definitivně starej dědek. A děsím se toho, až to přijde.
To, že vám to nepřináší přidanou hodnotu, je právě tím, že se to nechcete naučit. Takže si jenom najdete nějakou kličku, jak to používat postaru – takže logicky nemůžete využít ty nové věci. Když před auto zapřáhnete koně, aby to bylo jak jste zvyklý, také nevyužijete výhod auta.
29. 12. 2022, 16:59 editováno autorem komentáře
> To, ze nejaka soucast generuje nejaky konfigurak a prepisuje mi ho, je z meho pohledu zasadni problem dnesniho Linuxu, byt asi ne ten nejzasadnejsi.
Já to teda nepoužívám, ale u jiných řešení jsem viděl, že to nepřepisuje konfigurák v /etc (to by bylo opravdu divné), ale při instalaci se (způsobem podobným jako když si vybíráš který program bude netcat - takové to update-alternatives, nikdy jsem to nezkoumal) udělá symlink /etc/resolv.conf /run/resolv.conf a ten soubor se generuje a přepisuje tam. A když ten symlink smažeš, tak si můžeš vytvořit vlastní soubor a ten už ti nikdo nepřepíše (teda… klasický dhclient v defaultní konfiguraci ano, tomu je nutné to taky zakázat, ale to nesouvisí se systemd).
> Reseni je urcite upravit primarne glibc, aby nebylo nutne resolv.conf rucne menit.
Jak se píše ve vedlejším komentáři, tohle je dnes považováno za „legacy“ a viděl jsem že se dneska resolving snad dělá přes dbus nebo co. Ale co chceš dělat s těmi všemi programy, které /etc/resolv.conf stále používají?
Navíc co to jako řeší? Místo /etc/resolv.conf si budeš stěžovat že se to dělá nějak jinak a že neumíš nastavit ten nový způsob.
A to si tedy bude každý program (skrze systémovou libc, nebo nedej bože vlastní) sám pro sebe řešit DoT, DNSSEC, překlady různých domén u různých serverů atd.? To zní děsivě.
Tvůj problém doslova je že sis nainstaloval lokální DNS server, ten se ti nastavil v /etc/resolv.conf a ty jsi z toho pak byl kyselej.
> Pridal bych treba to, ze (napr.) systemy typu Bubuntu prepisuji konfiguraky GRUBu (obecne vlastne cehokoliv).
Achich ouvej, hlavně že jsem před chvíli odkazoval ten debunkovací článek. FYI konfigurák grubu přepisoval třeba i Arch Linux, chtěl bych vidět distribuci která to nedělá/nedělala (možná slackware a gentoo?) a především mi zkus naznačit, jak se zařídí, když si nainstaluješ nový kernel a/nebo vygeneruješ initramfs, aby se přidal do menu, ale současně šlo spustit i ten starší -- nebo tebou požadované defaultní chování je vždycky bootovat poslední kernel a když to selže, tak si starý kernel a initramdisk najít ručně v konzoli?
> Jako daleko lepsi bych videl, ze v hlavnim konfiguraku (na ktery mi zadny skript uz nesahne) bude nejaky 'include' toho generovaneho, abych nad tim neztratil kontrolu.
Jednak některé věci (moduly) asi potřebuješ načíst hned na začátku a některé příkazy provést na konci potřebuješ těch souborů více, a hele, právě jsme objevili /etc/grub.d, jednak ti nikdo nebrání si v podstatě tohle udělat. Jaký je tvůj use-case pro takovou věc a proč ti nestačí to buď napsat do /etc/grub.d/00_moje, nebo celou tu update-grub věc vypnout, nebo ji přesměrovat do jiného souboru a ten si includovat jak si přeješ? (nebude ti to úplně na první pokus fungovat, viz moduly a pořadí) (skutečná otázka, jak píšu v tom článku, ještě jsem nepotkal use-case kdy bych potřeboval mít plně ručně psaný konfigurák)
> A popravde se je ani nechci ucit - je to jak ve svete Windows, veci se neustale meni, ackoliv mi v dusledku neprinasi pridanou hodnotu.
Přinášené hodnoty DNS jsem popsal, GRUBu taky.