Thanks for this information. See in-line.
--
*********************************************************
David P. Both, RHCE
He/Him/His
*********************************************************
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*********************************************************
The value of any software lies in its usefulness
not in its price.
— Linus Torvalds
*********************************************************
On Thu, 18 Feb 2021, Michael Catanzaro wrote:
Date: Thu, 18 Feb 2021 10:46:53
From: Michael Catanzaro <mcatanzaro@xxxxxxxxx>
Reply-To: Development discussions related to Fedora
<devel@xxxxxxxxxxxxxxxxxxxxxxx>
To: David Both <david@xxxxxxxx>
Cc: Development discussions related to Fedora
<devel@xxxxxxxxxxxxxxxxxxxxxxx>,
Steve Dickson <SteveD@xxxxxxxxxx>
Subject: Re: Don't update to the latest f33!
On Thu, Feb 18, 2021 at 10:39 am, David Both <LinuxGeek46@xxxxxxxx> wrote:
Ok, so I manage my network using DHCP on an internal server for all except
that server and my Linux firewall/router which both use a complete static
configuration for networking.
My DHCP server does provide DNS resolver information which, in order, is
my internal BIND server (same physical server host), 8.8.8.8, and 8.8.4.4.
But my hosts were not getting that information. I think the difference
between the working and failing hosts is possibly (experiments required)
left-over ifcfg files some of which specified DHCP but also name servers
while others specified DHCP but did not specify name servers, as well as
some newer hosts that do not have any ifcfg files. I have also noticed
that ifcfg files are no longer created automatically but work when
created. I missed that information also.
OK, so DHCP is not working somehow. Are you running NetworkManager? That is
my #1 guess right now, because without NetworkManager, you have no easy way
to get DNS configuration from DHCP to systemd-resolved. systemd-resolved
doesn't configure itself: that's the responsibility of a higher-level
management layer, usually NetworkManager, or alternatively systemd-networkd.
You can configure it manually with your own scripts if you're really
hardcore. But if you have disabled NetworkManager, then my recommendation
would be to disable systemd-resolved as well. If you *are* running
NetworkManager, then unfortunately we're probably going to need to debug
NetworkManager to figure out why the configuration from DHCP is getting
dropped. I don't know how to help with that, but that also seems unlikely
because nobody has reported bugs related to that as far as I know.
If you are running NetworkManager, here are some more general
troubleshooting steps that I had typed up to send before reading the above:
I am running NetworkManager. I had disabled and stopped systemd-resolved on GP
after other hosts failed. After starting systemd-resolved everything looks to
be configured correctly:
[root@david ~]# resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
DNS Servers: 192.168.0.52
Fallback DNS Servers: 1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700::1111
2001:4860:4860::8888 2606:4700:4700::1001 2001:4860:4860::8844
DNS Domain: both.org
Link 2 (enp0s31f6)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
DNS Servers: 192.168.0.52 8.8.8.8 8.8.4.4
DNS Domain: both.org ~.
Link 3 (vboxnet0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
But everything is working and has been on my primary workstation - which is why
I did not see this until I upgraded to F33 on other hosts. This host has no
ifcfg file.
I really need to experiment with this a bit. I will get back to you with my
results.
The most important thing to do is to check the output of 'resolvectl' and
look for anything suspicious. Ideally the DNS server you want things going
to will be listed under each desired network interface with +DefaultRoute
set. Hopefully something will be obviously wrong there, but if not, you can
post the output of 'resolvectl' here for us to take a look.
To ensure systemd-resolved's configuration doesn't get bypassed, you'll also
want to ensure you're running Fedora's new default configuration, which you
should be, since users should be automatically upgraded. But just in case,
it's good to check:
* Ensure NetworkManager is running ('systemctl status
NetworkManager.service'). If not, you're on your own and should consider
disabling systemd-resolved since it's not worth trying to use manually.
* Ensure systemd-resolved is running: 'systemctl status
systemd-resolved.service'
* Ensure /etc/resolv.conf is symlinked to
/run/systemd/resolve/stub-resolv.conf (this ensures anything reading it
manually gets pointed to systemd-resolved's IP address, 127.0.0.53)
* Ensure the hosts line in /etc/nsswitch.conf looks like this: files
mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns
[root@david network-scripts]# systemctl status NetworkManager
● NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled;
vendor preset: enabled)
Active: active (running) since Sat 2021-01-30 12:30:59 EST; 2 weeks 4 days
ago
Docs: man:NetworkManager(8)
Main PID: 1667 (NetworkManager)
Tasks: 3 (limit: 76724)
Memory: 8.9M
CPU: 2min 6.146s
CGroup: /system.slice/NetworkManager.service
└─1667 /usr/sbin/NetworkManager --no-daemon
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option requested_rfc3442_classless_static_routes => '1'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option requested_root_path => '1'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option requested_routers => '1'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option requested_static_routes => '1'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option requested_subnet_mask => '1'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option requested_time_offset => '1'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option requested_wpad => '1'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option routers => '192.168.0.254'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): option subnet_mask => '255.255.255.0'
Feb 18 10:31:05 david.both.org NetworkManager[1667]: <info> [1613662265.0849]
dhcp4 (enp0s31f6): state changed extended -> extended
(Remember to never edit /etc/nsswitch.conf manually, instead edit
/etc/authselect/user-nsswitch.conf and then run 'sudo authselect
apply-changes'.)
I have not edited nsswitch.conf.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
