Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: kamen 27. 10. 2018, 11:07:09
-
Proc SystemD-resolved ignoruje DNS cache bezici na routeru?
Ve sve domaci siti mam na routeru napojenem na Internet DNS split horizon (ruzne DNS response podle toho z jake site se hlasite).
Az do Ubuntu 16.04 LTS vse fungovalo jak by bezny negr ocekaval. Dnsmasq bezici na Network-manager managed klientech pouzil routerem nabizeny DNS server a vsichni byli stastni.
Po upgrade na Ubuntu 18.04 vse vypadatlo vicemene funkcne az na dulezity detail. Nejaky Systemd-resolved na portu localhost:53 (asi nahrada stareho dobreho Dnsmasq), uplne ignoruje DNS nastaveni prijate v DHCP odpovedi.
Prozatim jsem to poresil editaci /etc/resolv.conf a fixnim nastavenim serveru. Ale proc proboha ten novy proces uplne ignoruje zavedena pravidla?!
Napada vas nekoho jak to opravit, tak aby vse fungovalo jak ma?
[odpovedi zrusit DNS horizon nejsou resenim protoze nenaplnuji muj zakaznicky pozadavek]
-
systemd-resolved se chová správně, pokud používá jen resolv.conf. Jestli DNSMasq používal něco jiného, choval se nestandardně a musel jste to tak mít nastavené. Řešení je doinstalovat resolvconf, který aktualizuje resolv.conf z DHCP.
-
Ignoruj zcestné odpovědi Lennartova fanklubu a tu sračku vypni.
sudo systemctl mask systemd-resolved
-
pokud používá jen resolv.conf.
Vy mi asi nerozumite. Ten proces uplne ignoruje to co mu DHCP odpoved posle jako nejblizsi/preferovany DNS server pro danou sit.
Zkusil bych to nejak zadebugovat, ale neni zrejme, kde tento proces loguje. V /var/log/syslog nic neni a neni zrejme jak ho prepnout do 'verbose' rezimu.
Rekneme ze lokalni sit je 192.168.123.0/24 a DNS pro tu sit je 192.168.123.1. Na te lokalni siti je pocitac co ma jmeno SuperCooolServer.
Ten proces pak uplne ignoruje dotazovani na ten 192.168.123.1 (vypozorovano z logu toho routeru, ze tam zadny takovy dotaz nedojde).
Kdyz dam 'host SuperCooolServer' tak to vrati servfail (coz muze byt cokoliv). Ale s jistotou je to odpoved od toho procesu co nasloucha na localhost:53 (tedy Systemd-resolved), protoze dnsmasq na routeru by napraskal jakoukoliv aktivitu (pro ladeni jsem si zapnul max. verbosity).
Me jde vlastne jen o to, jak spravne ten proces nastavit, protoze je mi jasne, ze pokud chci Ubuntu 18.04 tak mi proste nic jineho nezbyva nez strpet tento novej proces. Kdyby byla lepsi distribuce s KDE Neon co to nema, tak bych klidne zvazil s klientama prejit jinam. Jen to Ubuntu LTS je takova jakasi jistota (prosim zadny flame, je to proste ma preference).
-
Ignoruj zcestné odpovědi Lennartova fanklubu a tu sračku vypni.
sudo systemctl mask systemd-resolved
To zni dobre, nebude to mit vliv na jinou funkcionalitu? Myslim tim, ze jedine co po lokalni DNNS cache na localhost:53 chci je DNS preklad. Ciste pragrmaticky: Neni mozne ze ten SystemD-resolved ma jeste nejakou dalsi funkcionalitu, pro kterou by se mi neco jineho pokazilo? (treba zavislost nejake desktop funkce na prezentic toho procesu?)
-
Co jste v konfiguraci toho Ubuntu měnil? Normálně totiž systemd-resolved DNS servery dodané přes DHCP používá. Nevypnul jste si náhodou v konfiguraci systemd-network v sekci [DHCP] volbu UseDNS?
-
To zni dobre, nebude to mit vliv na jinou funkcionalitu? Myslim tim, ze jedine co po lokalni DNNS cache na localhost:53 chci je DNS preklad.
Ne, na funkci rostlináře to nemá vliv. ;D Ten Lennartův paskvil dělá totéž, co např. onen dnsmasq + NM (tzn. lokální kešující stub resolver), zato - jak je u Lennartwaru zvykem - neskonale hůře a s tou "výhodou", že konfigurace probíhá naprosto zcestně na X různých místech, z čehož ve výsledku vyleze nefungující paskvil.
-
Co jste v konfiguraci toho Ubuntu měnil? Normálně totiž systemd-resolved DNS servery dodané přes DHCP používá. Nevypnul jste si náhodou v konfiguraci systemd-network v sekci [DHCP] volbu UseDNS?
Zasadne nemenim nic co je deafault. Takze na klientech nic. Protoze zatim mi vse fungovalo. I na tom Ubuntu 16.04 jsem mel vse default.
Jedine co je v otm prostredi jinak nez by bezny negr mel, je ten DNS split horizon. Proste mam na lokalni siti servery, ktere maji z venku jinou IP nez na vnitrni siti. Toto je proste zakaznicky pozadavek, zcela v souladu s internetovymi protokoly.
Lze treba pouzit reseni DNS resolveru (resp. lokalni DNS cache) z toho Ubuntu 16.04? (aniz bych prisel o nejakou speficickou funkci, ktera je predpokladana novym 18.04 LTS)
Osobne nechapu duvod proc se to muselo zmenit. V od zacatku co jsem na Ubuntu to az po tu 16.04 fungovlo bajcne, aniz bych o nejakem DNS musel vedet (vcetne bonjour/avahi a vsemoznych service discoveries).
-
Důvody, proč se to měnilo, jsou např. ve zdejší zprávičce Ubuntu 16.10 bude mít systemd-resolved jako lokální DNS (https://www.root.cz/zpravicky/ubuntu-16-10-bude-mit-systemd-resolved-jako-lokalni-dns/).
Než se pokoušet ohnout systém tak, abyste tam používal stejné programy, jako v 16.04, bylo by lepší zjistit, co máte špatně a to opravit. Protože je také dost možné, že tam pracně zprovozníte dnsmasq, a zjistíte, že se to chová úplně stejně, protože chyba byla někde úplně jinde.
Tu volbu UseDNS tedy máte zapnutou (a nebo je ponechána výchozí hodnota, která je také zapnuto)? V logu něco zajímavého není? Když zkusíte lokálně DHCP klienta, dostane od DHCP serveru správnou odpověď, včetně DNS serveru? Konfigurační soubory systemd-resolv a systemd-network sem dát můžete?
-
Důvody, proč se to měnilo, jsou např. ve zdejší zprávičce Ubuntu 16.10 bude mít systemd-resolved jako lokální DNS (https://www.root.cz/zpravicky/ubuntu-16-10-bude-mit-systemd-resolved-jako-lokalni-dns/).
Ano, tam žádný validní důvod není (viz můj komentář pod odkazovaným blábolem).
-
Tu volbu UseDNS tedy máte zapnutou
..
V logu něco zajímavého není?
..
Když zkusíte lokálně DHCP klienta,
..
dostane od DHCP serveru správnou odpověď, včetně DNS serveru?
Nic jsem nemenil. Uz jsem to psal vyse. Vse je default. Vlastne ani nevim kde bych to mel menit.
Soubor "systemd-resolv" jsem nikde nenasel, ale zkusil jsem najit nejblizsi shodu a odhaduji ze jste asi myslel "/etc/systemd/resolved.conf"
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes
A to stejne pro "systemd-network" jsem vyhodnotil jako "/etc/systemd/systemd-network.conf".
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See systemd-system.conf(5) for details.
[Manager]
#LogLevel=info
#LogTarget=journal-or-kmsg
#LogColor=yes
#LogLocation=no
#DumpCore=yes
#ShowStatus=yes
#CrashChangeVT=no
#CrashShell=no
#CrashReboot=no
#CtrlAltDelBurstAction=reboot-force
#CPUAffinity=1 2
#JoinControllers=cpu,cpuacct net_cls,net_prio
#RuntimeWatchdogSec=0
#ShutdownWatchdogSec=10min
#CapabilityBoundingSet=
#SystemCallArchitectures=
#TimerSlackNSec=
#DefaultTimerAccuracySec=1min
#DefaultStandardOutput=journal
#DefaultStandardError=inherit
#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s
#DefaultRestartSec=100ms
#DefaultStartLimitIntervalSec=10s
#DefaultStartLimitBurst=5
#DefaultEnvironment=
#DefaultCPUAccounting=no
#DefaultIOAccounting=no
#DefaultIPAccounting=no
#DefaultBlockIOAccounting=no
#DefaultMemoryAccounting=no
#DefaultTasksAccounting=yes
#DefaultTasksMax=
#DefaultLimitCPU=
#DefaultLimitFSIZE=
#DefaultLimitDATA=
#DefaultLimitSTACK=
#DefaultLimitCORE=
#DefaultLimitRSS=
#DefaultLimitNOFILE=
#DefaultLimitAS=
#DefaultLimitNPROC=
#DefaultLimitMEMLOCK=
#DefaultLimitLOCKS=
#DefaultLimitSIGPENDING=
#DefaultLimitMSGQUEUE=
#DefaultLimitNICE=
#DefaultLimitRTPRIO=
#DefaultLimitRTTIME=
#IPAddressAllow=
#IPAddressDeny=
Dhclient jsemu musel zabit a kdyz jsem ho pak spustil 'dhclient wlp2s0 -v' tak jsem dostal nasledujici odpoved (mac jsem zmenil):
Listening on LPF/wlp2s0/ab:cd:ef:01:23:45
Sending on LPF/wlp2s0/ab:cd:ef:01:23:45
Sending on Socket/fallback
DHCPREQUEST of 192.168.123.201 on wlp2s0 to 255.255.255.255 port 67 (xid=0x100bfd07)
DHCPACK of 192.168.123.201 from 192.168.123.1
bound to 192.168.123.201 -- renewal in 19489 seconds.
I kdyz ten DNS tu neni videt, starsi klienti co prekladaji pres DNS z toho routeru s prekladem nemaji problem. Vlastne vsechny domaci klienti na ruznych platformach (iPhone, Samsung Android, Windows 10, Ubuntu 16.04, Ubuntu 14.04, Windows 7 a Windows 8.1) s tim nemaji jediny problem. Jen to nove Ubuntu 18.04.
-
Důvody, proč se to měnilo, jsou např. ve zdejší zprávičce Ubuntu 16.10 bude mít systemd-resolved jako lokální DNS (https://www.root.cz/zpravicky/ubuntu-16-10-bude-mit-systemd-resolved-jako-lokalni-dns/).
Je to vzhledem k memu nefunkcnimu Ubuntu 18.04 diky novemu SystemD-resolved off topic, ale uplne nechapu ty duvody. Neberte si to prosim osobne, pokud mate k systemd nejake preference (me osobne je jedno, pokud nebude veci kazit) - naplni-li existujici pozadavky, neprinese-li nove zavislosti a bude mit stejne nebo lepsi kvalitativni a kvantitativni parametry, s chuti ho budu pouzivat.
Cituji z odkazovane zpravicky a opravdu nevidim duvod proc zavadet neco noveho:
Nevýhodou je záznam v /etc/resolv.conf jen nameserver 127.0.0.1, z čehož se nedá usoudit, jaké servery se používají.
Nyni mam v /etc/resolv.conf take 127.0.0.1. Tak nevim, nevidim zmenu.
Na serveru Ubuntu nepoužívá žádný lokální DNS, záznamy z /etc/resolv.conf jsou přímo používány programy přes glibc. To má nevýhodu prodlev, pokud je první server pomalý.
Toto preci resi Dnsmasq. Staci "apt install dnsmaq" na serveru; a nebo lepe se zamyslet nad architekturou a poskytnout serveru lokalni rychlou DNS cache.
V novém Ubuntu 16.10 bude na všech variantách nasazen systemd-resolved, který je malý,
Dnsmasq mi bezi ve vsech routerech s LEDE, dokonce i na tech ultra levnych. Je ultramaly.
podporuje DNSSEC (od verze 230),
Dnsmasq v Ubuntu 16.04 umel DNSSEC (vlastne uz nekdy od Ubuntu 14.10 Dnsmasq 2.69 to umel).
nezávisí na D-Bus jako dnsmasq
Dnsmasq lze uspesne provozovat bez DBUS, ale krome routerovych distribuci jako je LEDE/OpenWRT atp. nechapu proc by to melo vadit. Dbus je nahodou prakticka vec.
Jak vidite vyse, neni tam zadny platny argument nebo tvrzeni podporujici vasi argumentaci.
-
Co vypíše následující příkaz?
cat /var/lib/NetworkManager/dhclient-*.lease
V tom souboru by měly být poslední údaje získané DHCP klientem z netplanu. Případně co vypíše příkaz
netplan ip leases
Asi bude nutné jako poslední parametr přidat jméno síťového rozhraní.
-
Jojo, není nad to jednoduchou funkční konfiguraci znefunkčnít a namísto toho implementovat další Lennartovinu rozšířenou o monstrózní shit typu Netplan s konfigurací v YAMLu.
-
Mě vždycky fascinuje, že když se vyskytne problém související se SystemD, který před SystemD neexistoval, tak jeho obhajci začnou radit jak je špatné cokoli jiného okolo a že je třeba to "opravit" tam, jakoby pracovali s nějakým podivným axiomem "SystemD a jeho komponenty jsou dokonalé, chyby jsou ve všem okolo". A pokud se to okolo nepřizpůsobí, vymyslí se do SystemD nová komponenta, která tu nepřizpůsobivou věc má nahradit, bohužel to dělá tak, že rozbije hromadu dalších věcí.
Řešením je prostě tu komponentu jak radil Lol zakázat. Nikdo se o ni neprosil, takže pokud nevíte o tom, že by jste ji potřeboval, úplně normálně ji vypněte, s vysokou pravděpodobností budou věci fungovat zase normálně jako roky před tim.
SystemD není něco bez čeho se nedá žít, takže pokud zlobí, nemám problém di věci zkonfigurovat bez něj.
-
Mně vždycky fascinuje, jak systemd hateři jakmile někde uvidí „systemd“, hned tam musí naběhnout, nic nečtou a začnou si vymýšlet nesmysly.
Tazatel chce používat lokální DNS cache, takže když jí vypne, s vysokou pravděpodobností mu to fungovat nebude. Zvlášť když má v /etc/resolv.conf jako DNS server nastavený 127.0.0.1.
Vzhledem k tomu, že všude jinde to funguje, např. ve všech instalacích Ubuntu 18.04, tak je naopak velice pravděpodobné, že chyba je někde v konfiguraci a ne v samotném softwaru. On už by si toho totiž nejspíš někdo všiml, že mu nefunguje DNS.
-
Vzdyt spravne reseni pise Lol Phirae uz v druhe odpovedi. Nechapu co resite.
A ze systemd zpusobuje nove problemy je taky bez debat.
-
Mně vždycky fascinuje, jak systemd hateři jakmile někde uvidí „systemd“, hned tam musí naběhnout, nic nečtou a začnou si vymýšlet nesmysly.
Tazatel chce používat lokální DNS cache, takže když jí vypne, s vysokou pravděpodobností mu to fungovat nebude. Zvlášť když má v /etc/resolv.conf jako DNS server nastavený 127.0.0.1.
Vzhledem k tomu, že všude jinde to funguje, např. ve všech instalacích Ubuntu 18.04, tak je naopak velice pravděpodobné, že chyba je někde v konfiguraci a ne v samotném softwaru. On už by si toho totiž nejspíš někdo všiml, že mu nefunguje DNS.
Vy si vubec nectete co pisu.
Ja v Ubuntu 18.04 (KDE Neon) nemam nic nastavene. Proste cista instalace.
V mistni siti mam router, ktery mi dela DNS split horizon. Co je na tom nejasneho? Vsem ostatnim negrum (viz vyse OS ostatnich zarizeni v siti) to funguje.
Takze znovu jeste jednou tucne: Po instalaci jsem nic nenastavoval, pouze heslo do mistni WIFI co jsem zadal do GUI, ktere mne k tomu vyzvalo.
Prosim prectete si cele vlakno, stale totiz ignorujete relevantni informace co jsem vam poskytnul. A dokonce tvrdite neco, co lze z informaci v tomto vlakne vyvratit.
-
cat /var/lib/NetworkManager/dhclient-*.lease
Je tam hodne sokromych informaci, vybral jsem jen relevantni objekt.
lease {
fixed-address 192.168.123.202;
option subnet-mask 255.255.255.0;
option dhcp-lease-time 43200;
option routers 192.168.123.1;
option dhcp-message-type 5;
option dhcp-server-identifier 192.168.123.1;
option dhcp-renewal-time 21600;
option dhcp-rebinding-time 37800;
option host-name "MYHOST.MYDOMAIN.CZ";
option domain-name-servers 192.168.123.1;
renew 1 2018/10/29 12:58:10;
rebind 4 2018/11/01 22:19:20;
expire 5 2018/11/02 19:19:20;
}
[netplan ip leases
root@redcat:~# netplan ip leases wlp2s0
Traceback (most recent call last):
File "/usr/sbin/netplan", line 23, in <module>
netplan.main()
File "/usr/share/netplan/netplan/cli/core.py", line 50, in main
self.run_command()
File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command
self.func()
File "/usr/share/netplan/netplan/cli/commands/ip.py", line 56, in run
self.run_command()
File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command
self.func()
File "/usr/share/netplan/netplan/cli/commands/ip.py", line 75, in run
self.run_command()
File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command
self.func()
File "/usr/share/netplan/netplan/cli/commands/ip.py", line 142, in command_ip_leases
out = subprocess.check_output(argv, universal_newlines=True)
File "/usr/lib/python3.6/subprocess.py", line 336, in check_output
**kwargs).stdout
File "/usr/lib/python3.6/subprocess.py", line 418, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/lib/netplan/generate', '--mapping', 'wlp2s0']' returned non-zero exit status 1.
Error in sys.excepthook:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 145, in apport_excepthook
os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o640), 'wb') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/var/crash/_usr_share_netplan_netplan.script.0.crash'
Original exception was:
Traceback (most recent call last):
File "/usr/sbin/netplan", line 23, in <module>
netplan.main()
File "/usr/share/netplan/netplan/cli/core.py", line 50, in main
self.run_command()
File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command
self.func()
File "/usr/share/netplan/netplan/cli/commands/ip.py", line 56, in run
self.run_command()
File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command
self.func()
File "/usr/share/netplan/netplan/cli/commands/ip.py", line 75, in run
self.run_command()
File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command
self.func()
File "/usr/share/netplan/netplan/cli/commands/ip.py", line 142, in command_ip_leases
out = subprocess.check_output(argv, universal_newlines=True)
File "/usr/lib/python3.6/subprocess.py", line 336, in check_output
**kwargs).stdout
File "/usr/lib/python3.6/subprocess.py", line 418, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/lib/netplan/generate', '--mapping', 'wlp2s0']' returned non-zero exit status 1.
-
Vy si vubec nectete co pisu.
Naopak, asi nečtete vy. Výpis toho, jaké informace dostal netplan z DHCP, tady stále nemáme. Zajímalo by mne, jak chcete opravovat to, že systém nebere v úvahu konfiguraci DNS z DHCP serveru, když nevíte, jestli tu informaci vůbec dostal nebo nedostal.
Ja v Ubuntu 18.04 (KDE Neon) nemam nic nastavene. Proste cista instalace.
Tak nemáte tam nastavené vůbec nic, tedy jste po čisté instalaci veškeré nastavení smazal a teď vám systém nenaběhne, nebo tam máte vše ve výchozí konfiguraci? Hádám, že to druhé.
V mistni siti mam router, ktery mi dela DNS split horizon. Co je na tom nejasneho?
Nejasná je na tom jediná věc – proč to pořád dokola opakujete, když to s problémem s největší pravděpodobností nesouvisí. Když se váš systém neptá toho vašeho DNS serveru, je zatím celkem jedno, jaká data by mu ten server poskytoval.
Vsem ostatnim negrum (viz vyse OS ostatnich zarizeni v siti) to funguje.
Nemají nastavené DNS resolvery ručně? Zjišťují je přes DHCP? Posílá DHCP serveru úplně ty samé údaje, jako to Ubuntu 18.04? To asi těžko, minimálně MAC adresa se bude lišit, nejspíš také jméno a možná i další údaje.
Takze znovu jeste jednou tucne: Po instalaci jsem nic nenastavoval, pouze heslo do mistni WIFI co jsem zadal do GUI, ktere mne k tomu vyzvalo.
NA to jsem se ale neptal. Já jsem se ptal na to, jaké informace netplan obdržel od DHCP serveru.
Prosim prectete si cele vlakno, stale totiz ignorujete relevantni informace co jsem vam poskytnul. A dokonce tvrdite neco, co lze z informaci v tomto vlakne vyvratit.
Nikoli. Vy relevantní informace neposkytujete, přestože jsem se na ně výslovně ptal. To, že jste po instalaci zadal jenom heslo do WiFi, je informace k ničemu (a navíc je nejspíš nepravdivá, protože při instalaci toho zadáváte mnohem víc, než jen heslo k WiFi).
-
No, vida že to jde. Takže DHCP server údaj poslal, ale havaruje netplan – což může být důvod, proč systemd-resolve nemá informaci o tom, jaký DNS server má použít. Zkusil bych postupovat podle Netplan Troubleshooting (https://netplan.io/troubleshooting).
-
No, vida že to jde. Takže DHCP server údaj poslal, ale havaruje netplan – což může být důvod, proč systemd-resolve nemá informaci o tom, jaký DNS server má použít. Zkusil bych postupovat podle Netplan Troubleshooting (https://netplan.io/troubleshooting).
Můžeš mi sdělit jediný dobrý důvod, proč by se měl dotyčný zabývat nějakou monstrózní a evidentně out of the box rozbitou kundovinou typu Netplan?
Ubuntu má vážně neskutečný talent podobnými "vylepšeními" dojebat naprosto základní funkčnost DNS v ostrých releasech. Již asi potřetí za sebou (viz odkaz na debatu o *buntu 16).
-
vyhod netplan (ci ako sa ten bazmek vola). tiez som s tym mal problem, ked diskless klient bootoval po sieti a konfiguraciu siete ziskal cez dhcp este v initramdisku, ale ked uz startoval samotny system, tak mu zrazu prestala fungovat siet (vyhodeny bol aj NM). tiez to bolo najnovsie ubuntu lts, pred tym to fungovalo bez problemov. tak som tu kokotinu vyhodil a zrazu vsetko zacalo fungovat...
-
Řešení I.:
1. vypnout vadný systemd-resolv
2. volitelně instalovat dnsmasq či jinou DNS cache, pokud o ni má zájem, nikde jsem neviděl požadavek, že to musí být systemd-resolv, takže Jirsák nutí tazatele do nutnosti užívat systemd-resolv úplně zbytečně
Užívat si funkční věc
Řešení II.:
1. systemd-resolv je bezchybný, není proto možné aby fungoval špatně, chyba je určitě v dnsmasq
...vyvráceno...
2. v tom případě jste něco měnil v konfiguraci systemd-resolv, špatně tudíž fungujete vy, opravte to
...vyvráceno...
3. důvody změn jsou v linku, cokoli jiného než systemd-resolv by bylo ohýbání systému, zprovozňování dnsmasq je pracné (ha ha) a stejně až to zprovozníte, že chyba je jinde, protože přece systemd-resolv je bezchybný.
...vyvráceno...
4. chyba bude určitě v konfiguracích u vás, ne v systemd-resolv
...vyvráceno...
5. chyba je v komponentě netplan, kterou systemd-resolv používá, protože havaruje - opravte netplan podle linku
Řešení stále v nedohlednu, ale mezitím stačil Jirsák těm, kdo nesdílí jeho názor do tváře a když vidí, že lidi, co tomu rozumí nepřesvědčí, snaží se do nesmyslného řešení vmanipulovat aspoň tazatele.
Jsem zvědavý, které řešení si teda kamen vybere, jestli se bude trápit prokousáváním se problémy se systemd-resolv nebo ho vyhodí a nahradí ho funkčním softem, aby mohl na PC pracovat a neřešit pořád Windows-like troubles :D
PS: Žádné systemd hatery tu nevidím, sám to používám, umím vyřešit hromadu věcí, které to umí přivodit, ale protože si z tohohle kusu často chybně fungujícího softu nedělám modlu, nemám problém věci vyřešit i bez systemd-*, je spousta skvěle funkčních alternativ, které tu byly daleko dříve než systemd-* a jsou prověřeny léty. Není to žádný prohřešek ani ohýbání systému, prostě se mi nehodí určitý kus vadného softu, použiju jiný, žádná křeč. Hatovat systemd nemusím, což ale neznamená, že se k němu musím modlit - tyhle extrémy nechávám psychopatům a jiným podivínům.
-
Proč komentujete věci, kterým vůbec nerozumíte? Víte, co se stane, když má v /etc/resolv.conf jako resolver nakonfigurován jen 127.0.0.1, a lokální resolver vypne? Nebude mu fungovat překlad DNS názvů, protože na tom 127.0.0.1 jaksi nic nepoběží, tudíž nic nemůže odpovědět.
Pokud je rozbitý netplan, který se v Ubuntu 18.04 stará o konfiguraci síťování, je potřeba ho opravit. Protože v důsledku té chyby toho nejspíš nebude fungovat daleko víc, než že se jen nepřebírá konfigurace DNS serverů z DHCP. Vaše geniální rady, že má vyházet půlku věcí, které se v Ubuntu starají o síťování, a vyřešit si to nějak jinak (přičemž pro jistotu nepíšete jak), jsou úplně k ničemu a problém nijak neřeší.
-
Víte, co se stane, když má v /etc/resolv.conf jako resolver nakonfigurován jen 127.0.0.1, a lokální resolver vypne? Nebude mu fungovat překlad DNS názvů, protože na tom 127.0.0.1 jaksi nic nepoběží, tudíž nic nemůže odpovědět.
Ano, tomu říkám objev století... akorát nevím, proč by si asi tak ten resolver vypínal. A jen tak mimochodem, naprosto stejný výsledek nastane i s Lennartware systemd-resolved sračkou, protože tam by default žádný fallback nastaven není. Ono totiž lidi nijak netoužili po tom, aby se to chaoticky připojovalo ke Googlu a navrch rozbíjelo věci (jak je u Lennartwaru tradicí) - viz https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1449001
Pokud je rozbitý netplan, který se v Ubuntu 18.04 stará o konfiguraci síťování, je potřeba ho opravit. Protože v důsledku té chyby toho nejspíš nebude fungovat daleko víc, než že se jen nepřebírá konfigurace DNS serverů z DHCP.
Ano, jasně, tazatel bude opravovat rozbitou věc, kterou k ničemu dodnes nepotřeboval, nadále ji nepotřebuje a jejíž jediným výsledkem je, že mu nefunguje DNS.
Vaše geniální rady, že má vyházet půlku věcí, které se v Ubuntu starají o síťování, a vyřešit si to nějak jinak (přičemž pro jistotu nepíšete jak), jsou úplně k ničemu a problém nijak neřeší.
Ty věci se nestarají o síťování, ty věci síťování naopak rozbíjejí. Síť zcela rozhodně fungovala a nadíle bude fungovat bez nich (a zjevně lépe a bez nekonečného debugování nedebugovatelného Lennartwaru).
-
Ano, tomu říkám objev století... akorát nevím, proč by si asi tak ten resolver vypínal.
Protože mu to vy a ByCzech radíte.
Ty věci se nestarají o síťování, ty věci síťování naopak rozbíjejí. Síť zcela rozhodně fungovala a nadíle bude fungovat bez nich (a zjevně lépe a bez nekonečného debugování nedebugovatelného Lennartwaru).
Proč píšete o věcech, o kterých vůbec nic nevíte? Síť samozřejmě nebude fungovat jen tak sama od sebe. Nějaká aplikace se musí postarat o zapnutí síťových rozhraní, přidělení IP adres, nastavení routovací tabulky, nastavení, které DNS resolvery se mají použít. Nic z toho se neudělá samo. Každá distribuce na to má nějaké nástroje, přičemž na tyto nástroje jsou obvykle navázány další mechanismy distribuce (např. spouštění služeb, které vyžadují síť, GUI konfigurace). Obejít ty distribuční konfigurační nástroje samozřejmě je možné, ale není to jednoduché a hlavně si tím akorát úplně zbytečně přiděláváte práci.
-
Proč komentujete věci, kterým vůbec nerozumíte? Víte, co se stane, když má v /etc/resolv.conf jako resolver nakonfigurován jen 127.0.0.1, a lokální resolver vypne? Nebude mu fungovat překlad DNS názvů, protože na tom 127.0.0.1 jaksi nic nepoběží, tudíž nic nemůže odpovědět.
Pokud je rozbitý netplan, který se v Ubuntu 18.04 stará o konfiguraci síťování, je potřeba ho opravit. Protože v důsledku té chyby toho nejspíš nebude fungovat daleko víc, než že se jen nepřebírá konfigurace DNS serverů z DHCP. Vaše geniální rady, že má vyházet půlku věcí, které se v Ubuntu starají o síťování, a vyřešit si to nějak jinak (přičemž pro jistotu nepíšete jak), jsou úplně k ničemu a problém nijak neřeší.
Když chybí argumenty nastupuje argumentum ad hominem, že?
Nikde jsem neradil nic o vypínání lokální DNS cache resolveru, ale o jeho nahrazení, takže argumentujete úplně mimo téma.
Jedna věc není půlka věcí v systému. Nevím proč by instalace dnsmasq mělo něco rozbíjet, narozdíl od systemd-* se mi u tohohle softu nestalo, že by to něco rozbilo.
Nevadí vám, že působíte jako nějaký člen sekty?
-
Ano, tomu říkám objev století... akorát nevím, proč by si asi tak ten resolver vypínal.
Protože mu to vy a ByCzech radíte.
Lež. Výměna za jiný funkční soft není pouhé vypnutí a znefunkčnění něčeho. To děláte vždycky, když se vám něčí názor nehodí do krámu, že ho manipulujete a ohýbáte do polohy, kterou to není vůbec myšleno?
-
Lež. Výměna za jiný funkční soft není pouhé vypnutí a znefunkčnění něčeho. To děláte vždycky, když se vám něčí názor nehodí do krámu, že ho manipulujete a ohýbáte do polohy, kterou to není vůbec myšleno?
Aha, takže „vypnout“ podle vás znamená „výměna za jiný funkční soft“?
1. vypnout vadný systemd-resolv
2. volitelně instalovat dnsmasq či jinou DNS cache, pokud o ni má zájem, nikde jsem neviděl požadavek, že to musí být systemd-resolv, takže Jirsák nutí tazatele do nutnosti užívat systemd-resolv úplně zbytečně
Užívat si funkční věc
Takže kdo tady lže?
Mimochodem, když si myslíte, že použití dnsmasq by problém vyřešilo – jak podle vás dnsmasq zjistí adresy DNS resolverů, kterých se má dotazovat? Můžete hádat třikrát.
-
Lež. Výměna za jiný funkční soft není pouhé vypnutí a znefunkčnění něčeho. To děláte vždycky, když se vám něčí názor nehodí do krámu, že ho manipulujete a ohýbáte do polohy, kterou to není vůbec myšleno?
Aha, takže „vypnout“ podle vás znamená „výměna za jiný funkční soft“?
1. vypnout vadný systemd-resolv
2. volitelně instalovat dnsmasq či jinou DNS cache, pokud o ni má zájem, nikde jsem neviděl požadavek, že to musí být systemd-resolv, takže Jirsák nutí tazatele do nutnosti užívat systemd-resolv úplně zbytečně
Užívat si funkční věc
Takže kdo tady lže?
Mimochodem, když si myslíte, že použití dnsmasq by problém vyřešilo – jak podle vás dnsmasq zjistí adresy DNS resolverů, kterých se má dotazovat? Můžete hádat třikrát.
Jé Jirsák si nedokáže představit život bez systemd-* věcí :D. Tak to bude pro vás novinka, že věci umějí fungovat i bez nich. Tenhle váš příspěvek je úplná snůška kravin. Vy tvrdíte, že nelze získat DNS servery bez systemd-resolv? Opravdu? No to nemá chybu. Své jsem řekl, je to funkční, vy vymýšlíte scénáře, které vůbec nemyslím, jen proto, že nesnesete, že by někdo mohl mít také pravdu. S tím ale běžte někam jinam, na mě si to léčit nebudete a točit se furt dokola, když už je to dávno vyvrácené nebudu. Až přijdete s něčím novým, možná, zatím se už chvíli opakujete.
-
Mimochodem, když si myslíte, že použití dnsmasq by problém vyřešilo – jak podle vás dnsmasq zjistí adresy DNS resolverů, kterých se má dotazovat? Můžete hádat třikrát.
Stejně jako předtím, než se někdo rozhodl, že NM + dnsmasq není dost cool a in a místo nich při upgradu do systému nacpal Lennartův resolver, systemd-networkd a monstrózní rozbitou sračku jménem Netplan, která se podle dokumentace tváří, že zvládne přinejmenším nakonfigurovat všechny sítě v datacentru NASA, ale zatím místo toho u tazatele v defaultní konfiguraci umí skorát vyhodit backtrace. Zázrak. Fungovalo to bez systemd a Netplanu a může to bez něj fungovat i nadále.. Není možná. Konec světa. Jirsák hledá provaz a odchází k nejbližšímu stromu...
::) ::) ::)
-
Pane Jirsaku nelibi se mi vas zpusob komunikace.
Trochu vsak citim vasi snahu najit reseni, tak se s vami jeste bavim, bohuzel jste mi vlastne neposkytnul zadny navrh reseni.
Ted jsem se dival, ze v tom /etc/resolv.conf jsem vas ve svem omylu mohl neprimo mystifiovat.
V reakci na vami odazovanou zpravicku jsem napsal, ze v /etc/resolv.conf je stejne 127.0.0.1 jako u DNSMASQ. Spravne je 127.0.0.53 (opet, toto neni nic co bych menil).
Tedy /etc/resolv.conf vypada nasledovne (musite uznat, ze na prvni pohled vypada jako ten z 16.04 - to vsak neni dulezite, celou dobu tvrdim, ze jsem v tom Ubuntu 18.04 (KDE Neon) nic nemenil a jen zadal heslo do WIFI):
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
-
Ok, tak uz jsem si nasel pricinu.
Chci zustat konstruktivni proto se vyvaruji adjektiv.
Pan Leonnard P. si mysli (tady https://github.com/systemd/systemd/issues/2514), ze je to tak spravne a mel bych si zmenit svuj business requirement. No nevim, v nasich firmach to resime jinak. A kupodivu muj iPhone, zenina Galaxy, nase Windows 7, 8.1, 10, Ubuntu do 16.04 a staricky noname Android s flashnutym LineageOS si mysli opak.
Navrh reseni je tady https://askubuntu.com/questions/917784/systemd-resolved-does-not-query-dns-server-for-local-domain .
Kvituji i vsechny rady smerem na vypnuti systemd-resolved, zamerne jsem nereagoval, protoze prestoze je to komplikovanejsi cesta, musim volit konzervativni pristup a ten systemd-resolved strpet (no jeste uvidime, zalezi na narocnosti).
Prosim neflamujme, ale radeji pokladejme vecne a nefalesne argumenty a reportujme konstruktivne bugy. Vsimnete si, ze kdyz jsem tu zpravicku a jeji argumentaci rozebral, nezbylo nic nez chtic ukriceneho decka (tady v nadsazce myslim pana LP) udelat neco znovu a po svem.
Protoze za distribuce primo neplatime (neprimo platime svym casem), je to asi nase jedina moznost jak ovlivnit kvalitu pouzitych komponent.
-
Jé Jirsák si nedokáže představit život bez systemd-* věcí :D.
Lžete.
Vy tvrdíte, že nelze získat DNS servery bez systemd-resolv? Opravdu?
Ne, nic takového netvrdím, to jste si vymyslel.
Své jsem řekl, je to funkční
Ne, není to funkční. Vy totiž vůbec netušíte, jak v linuxu věci kolem sítí fungují.
Prozradím vám takový malý detail. dnsmasq nepoužívá žádnou magii, žádnou křišťálovou kouli k tomu, aby zjistil, jaký DNS serverů se má dotazovat. Používá k tomu standardní konfigurační soubor /etc/resolv.conf (stejně jako systemd-resolved), případně je možné to změnit v konfiguraci dnsmasq nebo při startu z příkazové řádky. Takže pokud má dnsmasq (nebo systemd-resolved) používat jako upstream DNS servery inzerované DHCP serverem, musí se někdo postarat o to, aby se o nich dnsmasq (nebo systemd-resolved) dozvěděl. A tohle je právě ta část, která kamenovi nefunguje! Takže těch resolverů si tam může nainstalovat třeba 300, ale fungovat nebude žádný.
DHCP klient standardně zapíše získané DNS servery do /etc/resolv.conf. S tím dnsmasq dobře funguje, pokud běží jako DNS resolver pro síť a poskytuje své služby jiným počítačům v síti. Pokud ale chcete, aby se používal i pro překlad na lokálním počítači (jako to bylo v Ubuntu 16.04), a navíc chcete, aby ho používaly i programy, které nepoužívají libc nebo NSS a čtou přímo /etc/resol.conf, musíte dát do /etc/resolv.conf adresu toho lokálního dnsmasq, tedy např. 127.0.0.1.
No, a tady vzniká jistý konflikt, protože nemůžete mít v /etc/resol.conf zároveň jen adresy upstream DNS resolverů, a zároveň tam mít jen lokální dnsmasq. Řešení je poměrně jednoduché – ty adresy se dnsmasq předají jiným způsobem, než přes /etc/resolv.conf, a naopak se mu řekne, že má tenhle soubor ignorovat. No, a o tohle předání se zase musí postarat nějaký software – a v Ubuntu 18.04 je to řekl bych netplan. A když ten není schopen poskytnout dalším programům adresy DNS serverů z upstreamu, tak nebude tyhle servery používat žádný resolver.
Pravdu vždycky mít nemusím, ale vy evidentně nevíte o tom, jak funguje překlad DNS v linuxu, vůbec nic, takže není tak těžké vědět toho o něco víc.
Stejně jako předtím
Takže taky nevíte, jak to funguje, jenom plácáte nesmysly. Tak to vysvětlení výše je i pro vás.
-
Pane Jirsaku nelibi se mi vas zpusob komunikace.
To mám jako s místními trolly ByCzechem a Lol Phirae zacházet v rukavičkách? Akorát zaplevelují diskusi, o tématu nevědí vůbec nic a jen si vymýšlí a lžou. Rozumnou radu nedali žádnou. A informace, které jsem chtěl po vás, jste napsal také až na několikátý pokus, místo toho pořád dokola opakujete nerelevantní informace.
bohuzel jste mi vlastne neposkytnul zadny navrh reseni.
Poskytl. Psal jsem vám, ať se podíváte do logů a ať postupujete podle návodu na řešení problémů s netplan. Protože ten má v Ubuntu 18.04 na starosti konfiguraci síťování, takže je logické, že pokud je na něm něco rozbité, nebude síť nakonfigurovaná správně. Pak nemá smysl řešit cokoli jiného se sítí, protože nikdy nevíte, zda příslušný problém není způsoben tím netplanem.
opet, toto neni nic co bych menil
Buď můžete chtít opravit problém, a nebo můžete pořád dokola opakovat, že jste nic neměnil a tudíž to musí fungovat správně. Obojí dohromady ale nejde.
Pan Leonnard P. si mysli (tady https://github.com/systemd/systemd/issues/2514), ze je to tak spravne a mel bych si zmenit svuj business requirement.
Nikoli, to issue neříká vůbec nic o tom, že by systemd-resolved nepoužíval DNS servery poskytnuté DHCP serverem. To issue je o tom, že chybně nakonfigurovaný DNS server vrací pro některé DNS CNAME záznamy jenom hostname, ne celé doménové jméno, a spoléhá na to, že si doménu doplní klient sám. Řešení takového problému je jednoduché – opravit konfiguraci toho DNS serveru, aby vracel celý název, tedy ne jen třeba pocitac ale pocitac.example.com.
Navrh reseni je tady https://askubuntu.com/questions/917784/systemd-resolved-does-not-query-dns-server-for-local-domain .
Tohle se týká případu, kdy někdo nepoužívá v místní síti vůbec žádnou doménu, prostě se na počítače odkazuje pomocí samotných názvů jako pocitac1, server apod. Ne že by nechal tyhle názvy doplňovat o místní doménu, jak normálně dělá resolver, ale používá přímo tyhle názvy a žádnou místní doménu nemá.
To není váš případ, vy jste psal, že doménu máte a používáte split horizon, tj. pro název třeba server.example.com vracíte do internetu nějakou veřejnou IP adresu a do vnitřní sítě jinou privátní adresu.
-
To mám jako s místními trolly ByCzechem a Lol Phirae zacházet v rukavičkách? Akorát zaplevelují diskusi, o tématu nevědí vůbec nic a jen si vymýšlí a lžou. ... Prozradím vám takový malý detail. dnsmasq nepoužívá žádnou magii, žádnou křišťálovou kouli k tomu, aby zjistil, jaký DNS serverů se má dotazovat. Používá k tomu standardní konfigurační soubor /etc/resolv.conf
Ne. Opravdu? Vážně? No nekecej! ;D ;D ;D
Hele, je podzim, evidentně bys měl opět zvýšit dávkování léčiv, začíná to být opět kritické, cca na úrovni tvého legendárního diskursu (http://www.abclinuxu.cz/clanky/gimp-2.8-v-jednom-okne-a-s-celou-radou-vylepseni) o exportu v Gimpu.
(https://www.itbiz.cz/images/upload/k/komiks-gimp-2-8.jpg)
P.S. Naposled k Lennartovu "resolveru" - systemd-resolved stops resolving after some time with "DNSSEC validation failed" (https://github.com/systemd/systemd/issues/6490) + tentýž bug v Ubuntu (https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501). Tolik ke smysluplnosti debugování té rozbité sračky.
-
Pomaly zacinam mat pochybnosti o serioznosti tohto fora. A co by ste robili, keby ste mali povedzme 100 klientov ubuntu 18.4, ktorych sa dany problem tyka. Aj tak by ste rekonfigurovali vsetkych miesto toho aby ste prisli na zdroj problemu ? Radu k tomu nemam ziadnu, treba pozriet komunikaciu, nejake debug logy, pripadne strace.Taketo problemy sa tazko riesia na fore, treba si sadnut za klavesnicu, vyuzit skusenosti a nejake to know-how. Riesenie rekonfigurovat sluzby nasadzovat dnsmasq by som bral v pripade, ze mi dany admin zretelne dokaze, ze sa jedna o bug.
-
Pane Jirsaku, nastaveni DNS cache serveru menit nebudu. Ten systemd-resolved ignoruje jak ty s domenou i ty bez domeny.
Argumentace pana LP, ze za zadnou cenu nechce leakovat lokalni query do venkovnich siti je zmatene. Jadro chapu a je relevantni, jenze to lze delat jinak nez menit zakaznicke pozadavky, tak aby mu sedli do toho jak nakodoval jeho software. Na to mu nastesti soudruzi v Apple a Microsoftu prdeji a dik za to. Btw. Dnsmasq ma moznost filtrovat ty lokalni query a myslim, ze je to snad v defaultni konfugiguraci zapnute (no kazdopadne ja to zapnute mam :-) ).
S nekterymi vasimi tvrzenimi vyse nemuzu souhlasit, ale uz se mi to nechce resit, i presto vam dekuji za vas cas, sic jsem pouzil jine reseni.
Proc je pokazeny netplan by default to fakt nevim (a opet zduraznuji, nic jsem nemenil, jen vlozil heslo do WIFI) a celkem mne to desi, upgrade ostatnich 16.04 radeji odlozim a za pul roku uvidime - skoda.
-
Prosim redakci o uzamceni teto diskuze.
Myslim, ze me i ostatnim uz to vice neprinese a jen to bude lakat nerelevantni a off-topic komentare.
-
Ten systemd-resolved ignoruje jak ty s domenou i ty bez domeny.
O žádných názvech bez domény jste dosud nepsal.
Navíc z toho, co jste zatím napsal, plyne to, že systemd-resolved (ani žádná aplikace/knihovna, kterou byste ho nahradil) se nedozví, že byly nějaké DNS servery nakonfigurovány přes DHCP, takže pak ty servery těžko může používat.
Teprve až byste opravil to, aby se lokální resolver dozvěděl o tom, že má používat nějaké DNS servery předané z DHCP, můžete řešit případné problémy s překladem pomocí těchto serverů. A pokud ten váš DNS server opravdu vrací jednolabelové CNAME, na vašem místě bych to opravil, protože je to špatně – nespoléhal bych na to, že to někde možná omylem funguje. Navíc oprava spočívá jenom v tom, že ty záznamy doplníte na plná doménová jména.
Proc je pokazeny netplan by default to fakt nevim (a opet zduraznuji, nic jsem nemenil, jen vlozil heslo do WIFI)
Když si myslíte, že neustálým opakováním „nic jsem neměnil“ se to spraví…
upgrade ostatnich 16.04
Celou dobu jste psal o čisté instalaci, ne o upgradu. Pokud jste dělal upgrade, ten se samozřejmě pokouší zachovat konfigurace z předchozích verzí, takže výsledek vypadá úplně jinak, než čistá instalace. Pokud máte nějakou nestandardní nebo dokonce chybnou konfiguraci, je možné, že si s tím upgrade neporadí. Stávat by se to nemělo, ale software píší jenom lidé a na některé možnosti/kombinace prostě nepřijdou a neošetří je.
-
Při upgrade z 16.04 je netplan skutečně rozbitý - v /etc/netplan chybí jakýkoliv yaml soubor. Systém ale dál používá ifupdown, takže síť funguje.
Oprava je celkem jednoduchá, stačí odinstalovat balíček ifupdown a vytvořit konfigurační soubor třeba podle https://blog.ubuntu.com/2017/07/05/quick-and-easy-network-configuration-with-netplan.
-
Celou dobu jste psal o čisté instalaci, ne o upgradu.
Ty jsi ale dementus maximus, Jirsáku. Cituji prvotní dotaz: "Po upgrade na Ubuntu 18.04"
Chce to silnější prášky.
-
Jé Jirsák si nedokáže představit život bez systemd-* věcí :D.
Lžete.
Jen jsem sdělil své pozorování a sdělil jsem ho pravdivě, tudíž nelžu. Mohl bych se plést ve svém porozování, což ale není to samé jako lhát.
Vy tvrdíte, že nelze získat DNS servery bez systemd-resolv? Opravdu?
Ne, nic takového netvrdím, to jste si vymyslel.
Vyplývá to z toho dotazu co jste položil: "jak podle vás dnsmasq zjistí adresy DNS resolverů, kterých se má dotazovat?"
Prsíte se tu jak jste vy jediný skvělý co tomu rozumí, ostatní označujete přímo či nepřímo za hlupáky a trolly a přitom si ani neumíte přečíst manuál k dnsmasq. Hint: dbus.
Své jsem řekl, je to funkční
Ne, není to funkční. Vy totiž vůbec netušíte, jak v linuxu věci kolem sítí fungují.
Prozradím vám takový malý detail. dnsmasq nepoužívá žádnou magii, žádnou křišťálovou kouli k tomu, aby zjistil, jaký DNS serverů se má dotazovat. Používá k tomu standardní konfigurační soubor /etc/resolv.conf (stejně jako systemd-resolved), případně je možné to změnit v konfiguraci dnsmasq nebo při startu z příkazové řádky.
...
Viz výše a jinak je to snůška blbostí a doměnek. Jen ukazujete, že o tom nic nevíte vy, znáte jednu jedinou možnost, tvrdíte, že je absolutně bezchybná, což vylučuje kromě dalších informací na netu, bugtrackeru systemd i toto vlákno.
Pokud očekáváte v IT magii, doporučuji se přeorientovat na jiný obor nebo alespoň přechod z křišťálové koule k někomu, kdo má skutečný talent :DDD
Stejně jako předtím
Takže taky nevíte, jak to funguje, jenom plácáte nesmysly. Tak to vysvětlení výše je i pro vás.
Naopak, Lol zjevně přesně ví o čem mluví, protože narozdíl od vás to používá a umí to zprovoznit. Protože to očividně narozdíl od vás stejně jako já používá.
PS: Své osobní výpady si můžete nechat od cesty, kromě blbosti, kterou tady dávate na odiv tím předvádíte i své hulvátsví, aroganci a nejspíše nějakou osobnostní poruchu. Chápu, že si neumíte pomoct a dle vašeho vnímání jste jediný chytrý vy a všichni kolem vás jsou hlupáci včetně tazatele, který založil toto vlákno, ale skutečnost je určitě poněkud jiná. Vysoké IQ není všechno, můžete to mít v hlavě zpřeházené i s vysokým IQ ;)
-
Jinak, pokud tazatel skutečně trvá na tom, že nebude vypínat systemd-resolved, tak
/etc/systemd/resolved.conf
DNSStubListener=no
/etc/default/dnsmasq
IGNORE_RESOLVCONF=yes
/etc/dnsmasq.conf
resolv-file=/run/systemd/resolve/resolv.conf
Restart:
systemctl restart systemd-resolved
systemctl restart dnsmasq
Výše uvedené předpokládá, že v systému je nainstalován resolvconf a NENÍ tam žádný nesmysl typu netplan:
apt-get purge nplan netplan.io
-
Ten systemd-resolved ignoruje jak ty s domenou i ty bez domeny.
O žádných názvech bez domény jste dosud nepsal.
Ani nemusel, kdo má dostatek zkušeností, tak tyhle věci, které můžou se systemd-resolv nastat ví.
Navíc z toho, co jste zatím napsal, plyne to, že systemd-resolved (ani žádná aplikace/knihovna, kterou byste ho nahradil) se nedozví, že byly nějaké DNS servery nakonfigurovány přes DHCP, takže pak ty servery těžko může používat.
Nesmysl, to že má problém systemd-resolved neimplikuje, že mají problém i jiné aplikace a knihovny. Zjevná chyba v logice. Aplikace tohle uměly dávno před systemd, tak není důvod si myslet, že když to neumí systemd, protože to dělá jinak než všichni do té doby, že najednou budou mít problém, jen proto, že ho má systemd komponenta.
Teprve až byste opravil to, aby se lokální resolver dozvěděl o tom, že má používat nějaké DNS servery předané z DHCP, můžete řešit případné problémy s překladem pomocí těchto serverů. A pokud ten váš DNS server opravdu vrací jednolabelové CNAME, na vašem místě bych to opravil, protože je to špatně – nespoléhal bych na to, že to někde možná omylem funguje. Navíc oprava spočívá jenom v tom, že ty záznamy doplníte na plná doménová jména.
Proc je pokazeny netplan by default to fakt nevim (a opet zduraznuji, nic jsem nemenil, jen vlozil heslo do WIFI)
Když si myslíte, že neustálým opakováním „nic jsem neměnil“ se to spraví…
Opakuje vám to, protože vy pořád předpokládate, že je blbej a že si to sám rozbil svými zásahy.
upgrade ostatnich 16.04
Celou dobu jste psal o čisté instalaci, ne o upgradu. Pokud jste dělal upgrade, ten se samozřejmě pokouší zachovat konfigurace z předchozích verzí, takže výsledek vypadá úplně jinak, než čistá instalace. Pokud máte nějakou nestandardní nebo dokonce chybnou konfiguraci, je možné, že si s tím upgrade neporadí. Stávat by se to nemělo, ale software píší jenom lidé a na některé možnosti/kombinace prostě nepřijdou a neošetří je.
To jste si vymyslel, nebo neumíte číst. Psal jasně, že to je po upgrade už v dotazu. Shame on you :D
-
Jinak, pokud tazatel skutečně trvá na tom, že nebude vypínat systemd-resolved, tak
...
Neblbni, Jirsákovi tím přivodíš nějakou zdravotní újmu vybalit to na něj takhle celé v úhledném balení, funkční a bezproblémové! ;D
-
Tohle je největší nevýhoda používání systemd. Jakmile se na něco zeptáte, přiběhne banda systemd-haterů trollů jako ByCzech a Lol Phirae, kteří ničemu nerozumí, nic kloudného neporadí, neumí si ani přečíst manuál, nenechají se vykolejit ani přesným popisem příčiny chyby od někoho z diskutujících, a pořád melou ty svoje nesmysly.
ByCzech a Lol Phirae, klidně si dál věřte, že dnsmasq zjistí DNS servery předávané DHCP serverem pomocí křišťálové koule, když je pro vás tak obtížné přečíst si manuálovou stránku. Akorát byste nemuseli zatemňovat fórum těmi vašimi hloupostmi. Protože je dost možné, že teď tazatel přehlédne návod na opravu netplanu, který zmínil Alexander Kuna.
-
Neblbni, Jirsákovi tím přivodíš nějakou zdravotní újmu vybalit to na něj takhle celé v úhledném balení, funkční a bezproblémové! ;D
Ta konfigurace je narychlo zbastlená a testovaná na virtuálním serveru s ifupdown a konfigurací přes DHCP:
/etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 dhcp
*buntu 18 desktop upgradovaný z Ubuntu 16 s NM nemám aktuálně po ruce, instalovat se mi nechce, zejm. protože bych se opět rozčílil ohledně "predictable" jmen rozhraní a dalších Lennartovin. Pokud by se to navzájem mlátilo, tak viz manuál (http://manpages.ubuntu.com/manpages/bionic/man5/NetworkManager.conf.5.html). Základem rozhodně je, že systemd-resolved nebude nic resolvovat a nebude okupovat port 53, jinak jde jen o to, kde je správný konfigurační soubor, odkud si má dnsmasq přebrat upstream DNS servery (pokud je nechci nastavovat ručně v dnsmasq.conf)
ByCzech a Lol Phirae, klidně si dál věřte, že dnsmasq zjistí DNS servery předávané DHCP serverem pomocí křišťálové koule, když je pro vás tak obtížné přečíst si manuálovou stránku.
Nejlepší je pořád dokola podstrkovat někomu něco, co nikdy netvrdil, a pak s tím "polemizovat". Žádnou křišťálovou kouli nepotřebuje, v řešení, které jsem uvedl, si je přežvejká od systemd-resolved, jinak si je naprosto stejně může brát od DHCP klienta, nebo od NM, nebo je můžu nastavit ručně. Určitě k tomu nepotřebuju žádný netplan a nepotřebuju, aby Lennartův rozbitý resolver něco resolvoval a vnucoval se do systému.
-
Nejlepší je pořád dokola podstrkovat někomu něco, co nikdy netvrdil, a pak s tím "polemizovat". Žádnou křišťálovou kouli nepotřebuje, v řešení, které jsem uvedl, si je přežvejká od systemd-resolved, jinak si je naprosto stejně může brát od DHCP klienta, nebo od NM, nebo je můžu nastavit ručně. Určitě k tomu nepotřebuju žádný netplan a nepotřebuju, aby Lennartův rozbitý resolver něco resolvoval a vnucoval se do systému.
A nebo si to může nechat doručovat přes již zmíněný resolvconf (na to opakovaně Jirsák vůbec nezabral, zřejmě vůbec netuší, která bije) nebo si to DNSMasq nechá radit přes dbus... Je to software, který nejenže funguje, ale také je zjevně přizpůsobivý, narozdíl od věcí kolem systemd, které nutí jedinou správnou posvěcenou (a často bohužel nefunkční) cestu.
Hejter systemd nejsem, normálně to používám, ale znám i jeho slabiny a nedostatky, které obhájci systemd nedokážou skousnout a musejí začít hejtovat všechno okolo a všechny ostatní, kteří si dovolí na nějaký nedostatek kolem systemd poukázat.
-
Tohle je největší nevýhoda používání systemd. Jakmile se na něco zeptáte, přiběhne banda systemd-haterů trollů jako ByCzech a Lol Phirae, kteří ničemu nerozumí, nic kloudného neporadí, neumí si ani přečíst manuál, nenechají se vykolejit ani přesným popisem příčiny chyby od někoho z diskutujících, a pořád melou ty svoje nesmysly....
Promiň, ale zrovna Lol a ByCzech mi nepřijdou jako bezmozkovití hateři, ale jako někdo, kdo si s tím bazmekem už svoje užil (a musí zřejmě užívat nadále), a ví, o čem mluví a jak se s tou #$&!%@ popasovat...
-
někdo, kdo si s tím bazmekem už svoje užil (a musí zřejmě užívat nadále), a ví, o čem mluví a jak se s tou #$&!%@ popasovat...
Nejhorší je, že se neustále něco "vylepšuje". Přidáním tisící level of indirection do již tak naprosto neúnosně překomplikovaného bastlu NIC nezlepšuju. Naopak věci rozbíjím, naštvu uživatele, že po roce je už zas něco jinak a zas mi něco přestalo fungovat, zanáším tam další a další zdroje konfliktů a chyb. Je to tam překomplikované, že upgrady nikdo není schopen otestovat, načež následuje tu nefunkční DNS, tu nefunkční síť, tu zcela rozbitý systém (jen kvůli tomu, že se Lennartwaru nelíbí, že něco není symlink a že se někdo rozhodl s něčím nesmyslně šoupat (https://bugzilla.redhat.com/show_bug.cgi?id=1568856).)
Co tohle může zjednodušit? K čemu ten nápad? Kolik lidí ve skutečnosti něco takového potřebuje? A proč už se ZAS u toho mění formát konfigurace? (This is called “version 2”, as current MAAS/curtin already use a different YAML format that is called “version 1”.) WTF?!!!
(https://assets.ubuntu.com/v1/a1a80854-netplan_design_overview.svg)
Krucinál! >:(
-
někdo, kdo si s tím bazmekem už svoje užil (a musí zřejmě užívat nadále), a ví, o čem mluví a jak se s tou #$&!%@ popasovat...
Nejhorší je, že se neustále něco "vylepšuje". Přidáním tisící level of indirection do již tak naprosto neúnosně překomplikovaného bastlu NIC nezlepšuju. Naopak věci rozbíjím, naštvu uživatele, že po roce je už zas něco jinak a zas mi něco přestalo fungovat, zanáším tam další a další zdroje konfliktů a chyb. Je to tam překomplikované, že upgrady nikdo není schopen otestovat, načež následuje tu nefunkční DNS, tu nefunkční síť, tu zcela rozbitý systém (jen kvůli tomu, že se Lennartwaru nelíbí, že něco není symlink a že se někdo rozhodl s něčím nesmyslně šoupat (https://bugzilla.redhat.com/show_bug.cgi?id=1568856).)
Co tohle může zjednodušit? K čemu ten nápad? Kolik lidí ve skutečnosti něco takového potřebuje? A proč už se ZAS u toho mění formát konfigurace? (This is called “version 2”, as current MAAS/curtin already use a different YAML format that is called “version 1”.) WTF?!!!
...schéma...
Krucinál! >:(
A to je to schéma ještě sakra zjednodušené, ve skutečnosti je to výrazně složitější. Prostě úplně proti KISS a nejhorší na tom je, že to nepřináší žádnou killer feature. Dělá to běžné věci, dávno fungující, akorát děsně komplikovaně, stylem "proč to dělat jednoduše, když to jde složitě". Jenže čím složitější, tím snadněji se to může rozbít. Ach jo.
-
...
Krucinál! >:(
Pokrok Nezastavíš!
-
nejhorší na tom je, že to nepřináší žádnou killer feature. Dělá to běžné věci, dávno fungující, akorát děsně komplikovaně, stylem "proč to dělat jednoduše, když to jde složitě". Jenže čím složitější, tím snadněji se to může rozbít. Ach jo.
Já jsem z toho fakt magor. Samozřejmě v tom schématu mraky věcí chybí. Ale ta samotná představa, že když už je tam 999 věcí, co se perou navzájem o to, kdo co bude řídit, tak do toho vnesu ještě jednu další, abych od toho chaosu uživatele zase znova oddělil jako už x-krát předtím (a x-krát to nikam nevedlo), to je vážně úplně praštěné. Na serverech samozřejmě povypínám, co jde, a síť jede buď přes statickou konfiguraci nebo DHCP a klasický ifupdown, poněvadž nehodlám při každé aktualizaci řešit, co se zase kde "vylepšilo" a co to všechno může rozbít.
Proč se na systému, kde už je dnsmasq jako lokální resolver, defaultně nacpe a zapne Lennartův resolver, přičemž výsledkem je, že buď nefunguje nic, nebo (což - jak jsem pochopil, je by design) ten dnsmasq forwarduje dotazy systemd-resolved, který do dál forwarduje serverům nastaveným přes DHCP? Proč sakra takový bastl, který navíc rozbije out-of-the-box fungující DNSSEC na tom dnsmasq? Aby se to nedalo vůbec debugovat a zjistit, kde je problém?
Tohle je vážně "pokrok". Do háje už fakt. Co jde, přesouvám z Linuxu na nějaké BSD, protože už na tohle nemám čas ani náladu ani nervy.
-
Tohle je vážně "pokrok". Do háje už fakt. Co jde, přesouvám z Linuxu na nějaké BSD, protože už na tohle nemám čas ani náladu ani nervy.
Já to zatím řeším tak, že se vyhýbám *buntu distrům jak to jen jde. Dělali to od prvopočátku, že dělali věci složitější a oproti dřívějšku hůře funkční, pokud to jen trochu nezapadlo do toho, co nalajnovali jako jediné možné. Mám raději univerzální a přizpůsobivější distra a zatím to funguje kdekoli potřebuji. Ale chápu i ten přesun jinam, jenže mám obavu, že nakonec to přijde i tam, takže útěk to asi stejně neřeší, jen odsouvá.
-
Lol Phirae, ByCzech: Takže jste oba dva konečně přišli na to, že nejlepší bude spravit konfiguraci systém, aby se informace od DHCP klienta o DNS serverech předala dál. Výborně, to tvrdím od začátku. Teď už zbývá jenom to, aby vám docvaklo, že když tohle bude fungovat, bude se správně těch DNS serverů předaných přes DHCP dotazovat i systemd-resolved, a je tudíž možné odpustit si ty rozcvičky se zbytečnou instalací dnsmasq.
No a k tomu jestli používat netplan nebo si to nějak bastlit sám - v Ubuntu 18.04 je netplan distribuční nástroj pro konfiguraci sítě, takže je rozumné ho použít, protože s jeho použitím jaksi počítají ostatní distribuční nástroje. Zvládnoutnakonfigurovat netplan tak, aby bral nastavení z DHCP serveru, byste mohli zvládnout i vy dva.
Že zrovna vy dva kritizujete, že je něco komplikované, je vtipné. Místo abyste do konfiguračního souboru netplanu zkopírovali pět řádků konfigurace z internetu, budete odinstalovávat balíčky a instalovat jiné a komplikovaně ručně řešit to, co už má dsitribuce dávno vyřešené. Opravdu jednoduchost sama.
-
Proč se na systému, kde už je dnsmasq jako lokální resolver, defaultně nacpe a zapne Lennartův resolver, přičemž výsledkem je, že buď nefunguje nic, nebo (což - jak jsem pochopil, je by design) ten dnsmasq forwarduje dotazy systemd-resolved, který do dál forwarduje serverům nastaveným přes DHCP? Proč sakra takový bastl, který navíc rozbije out-of-the-box fungující DNSSEC na tom dnsmasq?
<ironie>Protože přece systemd-*cokoli* dělá věci přece lépe a dokonaleji než cokoli jiného. Tuhle premisu vidím u tvůrců i obhájců ve všem okolo systemd. Takže pak jim přijde přirozené, že to musí procházet přes systemd-*něco*, protože nikdo jiný to přece lépe neumí, takže je špatně, když si to dělá samo, bez mezikusu. </ironie>
No třeba jim to taky dojde.
-
Lol Phirae, ByCzech: Takže jste oba dva konečně přišli na to, že nejlepší bude spravit konfiguraci systém, aby se informace od DHCP klienta o DNS serverech předala dál. Výborně, to tvrdím od začátku.
...bla bla bla...
Že zrovna vy dva kritizujete, že je něco komplikované, je vtipné. Místo abyste do konfiguračního souboru netplanu zkopírovali pět řádků konfigurace z internetu, budete odinstalovávat balíčky a instalovat jiné a komplikovaně ručně řešit to, co už má dsitribuce dávno vyřešené. Opravdu jednoduchost sama.
Ne jednodušší je to udělat tak, jak s tím uživatel měl dlouholetou zkušenost a jak to bezpečně funguje. Šetří to čas a zdroje. Což navrhujeme od začátku my. K tomu dáváme kompletní, jednoduché a rychlé řešení, které funguje jak je uživatel zvyklý. Vy jen teoretizujete a řešení nikde, jak konstatoval sám tazatel.
Speciálně pro vás: Věci jsou nahraditelné a dají se dělat i jinak, než jak vy jen jedním jediným způsobem (špatně) umíte. Když budete nutit ostatním jen svou jedinou možnou věc ve světě s mnoha možnostmi, budete za magora.
-
Filipe Jirsáku, jeste ze te tu mame.
Kdybys tu nebyl, tak si te snad musime vymyslet
-
Ne jednodušší je to udělat tak, jak s tím uživatel měl dlouholetou zkušenost a jak to bezpečně funguje.
Spojil jste to do jedné věty, jako by to samozřejmě jedno plynulo z druhého nebo se vyskytovalo současně. Jenže ono to jde často proti sobě - to, s čím má uživatel dlouhodobou zkušenost, nefunguje moc dobře. A speciálně u konfigurace systémových věcí platí, že nejlépe funguje to, co je přímo v distribuci. Můžete se s distribucí prát, ale není to dobrý nápad - distribuce nakonec vždycky vyhraje. Takže pokud má někdo potřebu se se svou distribucí prát, měl by se radši poohlédnout po jiné distribuci.
K tomu dáváme kompletní, jednoduché a rychlé řešení, které funguje jak je uživatel zvyklý.
Ne, vaše řešení nefunguje. Vy jste totiž ještě ani nepochopili, v čem je problém...
Vy jen teoretizujete a řešení nikde, jak konstatoval sám tazatel.
Já jsem napsal, co povede k řešení - opravit netplan. Tazatel už na to nereagoval. V dalším komentáři pak Alexander Kuna uvedl, proč se ten netplan rozbil, a přida odkaz na článek, kde je polopaticky vysvětlené, jak netplan nakonfigurovat.
Speciálně pro vás: Věci jsou nahraditelné a dají se dělat i jinak, než jak vy jen jedním jediným způsobem (špatně) umíte. Když budete nutit ostatním jen svou jedinou možnou věc ve světě s mnoha možnostmi, budete za magora.
Ano, věci se dají dělat různě. To ale neznamená, že vaše komplikované řešení přetahovat se s distribucí je lepší, než jednoduché řešení - prostě pětiřádkovým konfiguračním souborem opravit tu chybnou distribuční konfiguraci.
Rozdíl je také v tom, že řešení s opravou toho distribučního konfiguračního souboru opraví ten původní problém, tím pádem začnou fungovat všechny věci, které ten problém rozbil. Vaše řešení je, že odinstalujete systemd-resolved, nainstalujete dnsmasq, a zjistíte, že problém přetrvává, protože problém byl plně někde jinde, než jste si mysleli.
Kdybyste tu pořád neprosazovali svá nefunkční řešení (protože jste dosud nepochopili, v čem je problém), nemusel bych vám já vysvětlovat, proč jsou ta vaše řešení nefunkční a opakovat, jaké řešení vede k cíli. Ano, teoreticky jsme mohli vymýšlet různá funkční řešení, jenže tuhle možnost vy jste zabili tím, že bylo nutné řešit mnohem základnější věc - rozlišovat, které řešení je funkční a které nefunkční.
-
Ses proste 1****** a uz to snad staci, ne?
-
ručně řešit to, co už má dsitribuce dávno vyřešené. Opravdu jednoduchost sama.
Jak to má distribuce "vyřešené", to názorně předvedl tazatel. Ten krám to "vyřešil" tak, že vyhodil několikastránkový backtrace a tím bylo skutečně "vyřešeno". Jinak kdybys místo omílání hovadin a miliontého pokusu o podsouvání svých výmyslů jiným do huby uměl číst, tak by ses možná mohl zamyslet nad tím, že tazatel to již dávno vyřešeno a funkční měl. Opravdu nepotřebuje další zázračný (bohužel ale rozbitý) nástroj, aby znova vynalezl kolo. Opětovné vynalézání hranatých kol je totiž hlavní dominantou Lennartwaru. Tím, že generování konfigurace přenechá další abstraktní vrstvě (kterou je bohužel evidentně nedostatečně otestovaný a neodladěný YAML bastl), který navíc opětovně mění strukturu konfigurace (viz citace z jejich webu), takže se dá očekávat, že se to i po případné opravě nesmyslně zavazejícího bastlu abstrahujícího abstrahovanou abstrakci konfigurace sítě opět co nevidět rozesere a tazatel bude tam, kde bude.
Jinými slovy - nepovažuji za vhodné za popsaného stavu defaultní konfigurační nástroje v Ubuntu používat. Vyřešené mají evidentně hovno.
-
Vy jste totiž ještě ani nepochopili, v čem je problém...
Zatímco ty jsi se evidentně ani nesnažil pochopit to, co je cílem - což ti ostatně tazatel opakovaně sděloval, ale ty jseš hrozně busy se svou zaseknutou gramofonovou deskou. Tak naposled:
Dnsmasq bezici klientech pouzil routerem nabizeny DNS server a vsichni byli stastni.
Tazatel fakt netouží po tom, aby mu fungující a osvědčené řešení někdo nahrazoval rozbitým (https://github.com/systemd/systemd/issues/6490) Lennartovým resolverem a nutil ho opětovně jinak konfigurovat to, už už dávno fungovalo a tancovat tanečky kolem překážejících služeb systemd, které se nesmyslně vnucují jako výchozí.
-
Zatímco ty jsi se evidentně ani nesnažil pochopit to, co je cílem
Cílem bylo to, aby systém při překladu DNS názvů používal místní cache a na záznamy, které nemá v cache, se ptal DNS serverů nakonfigurovaných přes DHCP. Že se musí použít něco jiného, než distribuční systemd-resolved, to je jen vaše utkvělá představa.
-
Ne jednodušší je to udělat tak, jak s tím uživatel měl dlouholetou zkušenost a jak to bezpečně funguje.
Spojil jste to do jedné věty, jako by to samozřejmě jedno plynulo z druhého nebo se vyskytovalo současně. Jenže ono to jde často proti sobě - to, s čím má uživatel dlouhodobou zkušenost, nefunguje moc dobře. A speciálně u konfigurace systémových věcí platí, že nejlépe funguje to, co je přímo v distribuci.
Prima, dnsmasq v Ubuntu je, takže děkuji, že tímto argumentem podporujete naše řešení.
K tomu dáváme kompletní, jednoduché a rychlé řešení, které funguje jak je uživatel zvyklý.
Ne, vaše řešení nefunguje. Vy jste totiž ještě ani nepochopili, v čem je problém...
Nejaký důkaz? Zatím máme přesně opačnou zkušenost. Když budete tvrdit něco jiného než jaká se skutečnost, budete za cvoka, protože to normálně funguje a vy tvrdíte, že ne. Dokonce to funguje jednodušeji a přes méně vrstev když se chce. Jaká je na to diagnóza? Prozradíte?
Vy jen teoretizujete a řešení nikde, jak konstatoval sám tazatel.
Já jsem napsal, co povede k řešení - opravit netplan. Tazatel už na to nereagoval. V dalším komentáři pak Alexander Kuna uvedl, proč se ten netplan rozbil, a přida odkaz na článek, kde je polopaticky vysvětlené, jak netplan nakonfigurovat.
To si jen myslíte, protože cokoli jste navrhoval postupně jen vedlo k dalšímu problému a sám očividně netušíte, co vše se může v tom dlouhém řetězci složitosti rozsypat. Takže sice radíte možnost a já vím, že to umím zkonfigurovat i tímto způsobem, jen zjevně mám narozdíl od vás ponětí o tom, kde všude se to může ještě rozsypat, což se vám přesně dělo do začátku, co jste vstoupil do téhle diskuze.
Nějak stále mylně něco předpokládáte - teď např. to, že neumím(e) vyřešit postupně celou věc prolezením celého řetězce těch vrstev, ve které se to může rozsypat svými specifickými způsoby a nutíte někoho, kdo má zkušenost s úplně jiným a zcela funknčním softem, aby to předělal na tuhle složitou zhůvěřilost, místo aby jste pochopil, že je i jiné schůdnější, jenodušší a tími spolehlivější řešení.
Speciálně pro vás: Věci jsou nahraditelné a dají se dělat i jinak, než jak vy jen jedním jediným způsobem (špatně) umíte. Když budete nutit ostatním jen svou jedinou možnou věc ve světě s mnoha možnostmi, budete za magora.
Ano, věci se dají dělat různě. To ale neznamená, že vaše komplikované řešení přetahovat se s distribucí je lepší, než jednoduché řešení - prostě pětiřádkovým konfiguračním souborem opravit tu chybnou distribuční konfiguraci.
Nikdo se s ničím nepřetahuje, jak píšu výše, dnsmasq v distru je a není tedy problém ho používat. Pořád vymyšlíte nějaké neexistující problémy a pak se proti nim snažíte vymýšlet argumenty, protože normálně žádné nemáte. Bohužel tyhle uměle vytvořené nemají žádnou argumentační váhu, tak by bylo lepší, kdyby jste mlčel a uměle nevytvářel ani problémy ani argumenty na ně, je to to zbytečná ztráta času. Svým si plýtvejte jak chcete, ale neplýtvejte prosím časem ostatních.
Rozdíl je také v tom, že řešení s opravou toho distribučního konfiguračního souboru opraví ten původní problém, tím pádem začnou fungovat všechny věci, které ten problém rozbil. Vaše řešení je, že odinstalujete systemd-resolved, nainstalujete dnsmasq, a zjistíte, že problém přetrvává, protože problém byl plně někde jinde, než jste si mysleli.
Kdybyste tu pořád neprosazovali svá nefunkční řešení (protože jste dosud nepochopili, v čem je problém), nemusel bych vám já vysvětlovat, proč jsou ta vaše řešení nefunkční a opakovat, jaké řešení vede k cíli. Ano, teoreticky jsme mohli vymýšlet různá funkční řešení, jenže tuhle možnost vy jste zabili tím, že bylo nutné řešit mnohem základnější věc - rozlišovat, které řešení je funkční a které nefunkční.
Jen pořád dokola opakujete něco, co neplatí - a sice, že v *buntu dnsmasq je, takže není žádný prohřešek ani problém to použít a dále opakujete to, že to nefunguje, což je uplně normální lež. Vy jen nutíte něco jiného, o se očividně uživateli rozbilo, tvrdíte, že problém je kdekoli jinde, než v tom rozbitém, včetně toho, že za rozbité považujete tazatele i ty co navrhují relevantní, rychlé a funkční řešení, jen proto, aby jste si prosadil svou, přestože vidíte sám, že se vám další a další krok sype. Lidé nemají povinnost žít podle vás, mají svobodnou vůli rozhodnout se zcela jinak, tak je nechtě žít, jinak budete vážně za magora.
-
Zatímco ty jsi se evidentně ani nesnažil pochopit to, co je cílem
Cílem bylo to, aby systém při překladu DNS názvů používal místní cache a na záznamy, které nemá v cache, se ptal DNS serverů nakonfigurovaných přes DHCP. Že se musí použít něco jiného, než distribuční systemd-resolved, to je jen vaše utkvělá představa.
Utkvělou představu máte vy v tom, že dnsmasq není distribuční. Už s tou kravinou přestaňte, kdokoli pohledem do repozitáře může zjistit, že uplně normálně lžete, protože relevatní argument nemáte.
-
Utkvělou představu máte vy v tom, že dnsmasq není distribuční.
Zase si vymýšlíte, já jsem nic takového netvrdil. Něco jiného je, zda aplikace dostupná v distribuci jako balíček, a něco jiného je, zda jde o systémový balíček, který ta distribuce sama používá pro zabezpečení své základní funkcionality. dnsmasq byl před Ubuntu 2016.10 na desktopu systémovým balíčkem, protože pomocí něj Ubuntu zajišťovalo překlad DNS. Od verze 2016.10 už systémovým balíčkem není, protože ho v této roli nahradil systemd-resolved. To neznamená, že si dnsmasq dál nemůžete nainstalovat - můžete, třeba pokud budete chtít, aby váš počítač poskytoval překlad DNS ostatním počíačům v síti. Ale ty konfigurační nástroje distribuce, které se starají o síť, budou zcea jistě umět spolupracovat se systemd-resolved (protože je to systémový nástroj), ale nemusí umět spolupracovat s dnsmasq. Například grafické konfigurační nástroje neo obecně nástroje pro konfiguraci sítě. Samozřejmě, že si dnsmasq můžete nakonfigurovat sám, ale budete muset nejspíš řešit to, co jinak řeší ty distribuční nástroje - například to, že když se DHCP klient dozví o změně DNS serverů, musí to nějak propagovat DNS resolveru. Když použijete DNS resolver dodávaný s distribucí, postará se o tohle distribuce, když použijete nějaký jiný, distribuce se o to nejspíš starat nebude a musíte si to zařídit sám.
-
konfigurační nástroje distribuce, které se starají o síť, budou zcea jistě umět spolupracovat se systemd-resolved (protože je to systémový nástroj)
Ano, to vidíme názorně v tomto vláknu. Asi někde udělali soudruzi z NDR chybu. ;D ::)
když použijete nějaký jiný, distribuce se o to nejspíš starat nebude a musíte si to zařídit sám.
Proč zase blábolíš o něčem, co bylo mnohokrát vyvráceno?
-
Utkvělou představu máte vy v tom, že dnsmasq není distribuční.
Zase si vymýšlíte, já jsem nic takového netvrdil. Něco jiného je, zda aplikace dostupná v distribuci jako balíček, a něco jiného je, zda jde o systémový balíček, který ta distribuce sama používá pro zabezpečení své základní funkcionality. dnsmasq byl před Ubuntu 2016.10 na desktopu systémovým balíčkem, protože pomocí něj Ubuntu zajišťovalo překlad DNS. Od verze 2016.10 už systémovým balíčkem není, protože ho v této roli nahradil systemd-resolved. To neznamená, že si dnsmasq dál nemůžete nainstalovat - můžete, třeba pokud budete chtít, aby váš počítač poskytoval překlad DNS ostatním počíačům v síti. Ale ty konfigurační nástroje distribuce, které se starají o síť, budou zcea jistě umět spolupracovat se systemd-resolved (protože je to systémový nástroj), ale nemusí umět spolupracovat s dnsmasq. Například grafické konfigurační nástroje neo obecně nástroje pro konfiguraci sítě. Samozřejmě, že si dnsmasq můžete nakonfigurovat sám, ale budete muset nejspíš řešit to, co jinak řeší ty distribuční nástroje - například to, že když se DHCP klient dozví o změně DNS serverů, musí to nějak propagovat DNS resolveru. Když použijete DNS resolver dodávaný s distribucí, postará se o tohle distribuce, když použijete nějaký jiný, distribuce se o to nejspíš starat nebude a musíte si to zařídit sám.
cize tym si potvrdil to, co sa tvrdilo od uplneho zaciatku, a to ze systemd je monoliticky, totalne zadrotovany do linuxu a v podstate nenahraditelny. dakujem, ale neprosim. pravdupovediac desktop som zmigroval na freebsd uz pred rokom a servery na netbsd, s ktorym mam opat tie zvlastne pocity ako kedysi, ked som zacinal s linuxom...
-
Nechci se do toho nejak michat, ale netrpi nahodou pan Jirsak nejakou poruchou osobnosti? Ta jeho diskuze a manipulacni argumentace je silena. Prominte mi offtopic, ale nelze si toho nepovsimnout.
-
a to ze systemd je monoliticky, totalne zadrotovany do linuxu a v podstate nenahraditelny
To je nějaký omyl, Debian bez systemd běžně používám a bylo to na jeden příkaz (apt-get install sysvinit-core).
-
a to ze systemd je monoliticky, totalne zadrotovany do linuxu a v podstate nenahraditelny
To je nějaký omyl, Debian bez systemd běžně používám a bylo to na jeden příkaz (apt-get install sysvinit-core).
ale podla jirsaka ti to nemoze fungovat.
btw tiez pouzivam linux bez systemd, ale pride mi lepsie pouzit distribuciu na to stavanu (devuan)...
-
To systemd fakt radeji zahod kdyz to zpusobuje jen problemy a navic je ted budocnoust systemd vic nez nejista ...
-
a to ze systemd je monoliticky, totalne zadrotovany do linuxu a v podstate nenahraditelny
To je nějaký omyl, Debian bez systemd běžně používám a bylo to na jeden příkaz (apt-get install sysvinit-core).
No to neni omyl, jen debian dela kurva dobrou praci aby to pak narovnali.
I takovej zaklad jako dbus zavisi na systemd pokud se neohne.
-
ale podla jirsaka ti to nemoze fungovat.
Nikoli, to podle vás. Já netuším jak jste z toho, že Ubuntu používá pro konfiguraci sítě netplan, dospěl k závěru, že systemd je monolit. A nejspíš to netušíte ani vy.
-
ale podla jirsaka ti to nemoze fungovat.
Nikoli, to podle vás. Já netuším jak jste z toho, že Ubuntu používá pro konfiguraci sítě netplan, dospěl k závěru, že systemd je monolit. A nejspíš to netušíte ani vy.
Ne jednodušší je to udělat tak, jak s tím uživatel měl dlouholetou zkušenost a jak to bezpečně funguje.
... A speciálně u konfigurace systémových věcí platí, že nejlépe funguje to, co je přímo v distribuci. Můžete se s distribucí prát, ale není to dobrý nápad - distribuce nakonec vždycky vyhraje...
-
Vždyť jsem to psal, že to netušíte ani vy. Tam, kde by člověk očekával vaše vysvětlení, je prázdno.
-
Proč komentujete věci, kterým vůbec nerozumíte? ...
Jirsak, proc sem ty trotle lezes kdyz o tech vecech vis naprosto kulovy? To prave ta sracka systemd prepise na naprostou kokotinu resolf.conf. Nemluve o tom, ze tu je rec o vypnuty ty sracky a nahrazeni zcela bezproblemovou funkcni veci. Coz ty pry svym IQ hykajiciho osla vzivote nepochopis.
....Proč sakra takový bastl, který navíc rozbije out-of-the-box fungující DNSSEC na tom dnsmasq? Aby se to nedalo vůbec debugovat a zjistit, kde je problém?...
Protoze ses uplne blbej a nechapes ten dzenialni navrh
...
Doporucil bych ti zauvazovat nad vymenou distra, protoze at uz to vyresis jakkoli, stejne se ti to v blbuntu rozesere, a to zdaleka ne jen pri upgrade distra samotnyho, ale klidne i zcela kdykoli pri zcela libovolny aktualizaci.