Created attachment 1084493 [details] nmcli c show ens3 Description of problem: When specifying a machine to use DHCP for the IP address but a manually-assigned DNS server address, the result is that I end up with the manual address added as a secondary DNS to the one DHCP wants to assign. This changed sometime since Fedora 23 Beta, where it would properly replace the DHCP address. Version-Release number of selected component (if applicable): NetworkManager-1.0.6-6.fc23.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install Fedora Server 23 Final TC11, leaving DHCP address assignment on and setting a manual DNS server address different from that which DHCP would assign (such as 8.8.8.8). 2. On the installed system, observe that /etc/resolv.conf contains the DHCP-assigned entry before the manual one. Actual results: /etc/resolv.conf contains the DHCP-assigned entry before the manual one. Expected results: Only the manual DNS server address should be in resolv.conf Additional info: This causes problems with kickstarting machines to join a domain if the domain controller is not resolvable with the DHCP-assigned DNS server (common for testing and other environments where the Domain Controller is not resolvable from the common DHCP rules). As a result, this is causing https://fedoraproject.org/wiki/QA:Testcase_realmd_join_kickstart to fail when working with a KVM-based environment. This makes it difficult to test this functionality. Further information: when attempting to set these values in the Cockpit admin interface, the user is unable to modify the "Automatic" setting of the DNS field. (It displays "off" but setting it in either direction has no effect on the DNS server list).
Transferring blocker nomination from #1273145, as this is really the more significant bug here. joining a realm via kickstart will fail in the case that you need to override the nameserver via 'nameserver=' parameter and you don't also configure an entire static IP setup (so no DNS server is configured via DHCP). We *think* things should still work OK if the DHCP-provided DNS server supports realm discovery, though.
Right, while this bug makes testing a real pain in the neck, it is unlikely to be an issue in the majority of production environments, so I'm -1 to blocking on it.
Addendum: If we can figure out what is causing this to happen in a timely manner, I'm also +1 FE.
One more note: I just also performed an installation against the F23 Server Final TC11 media using this kickstart: https://sgallagh.fedorapeople.org/kickstarts/f23/static.ks The resulting system had: [root@ipaksclient ~]# nmcli c show ens3 connection.id: ens3 connection.uuid: 7ee1db3b-54c4-45c7-bcde-4d39ec8a77a9 connection.interface-name: ens3 connection.type: 802-3-ethernet connection.autoconnect: yes connection.autoconnect-priority: 0 connection.timestamp: 1445281872 connection.read-only: no connection.permissions: connection.zone: -- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: connection.gateway-ping-timeout: 0 connection.metered: unknown 802-3-ethernet.port: -- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: -- 802-3-ethernet.auto-negotiate: yes 802-3-ethernet.mac-address: -- 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.mac-address-blacklist: 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels: 802-3-ethernet.s390-nettype: -- 802-3-ethernet.s390-options: 802-3-ethernet.wake-on-lan: default 802-3-ethernet.wake-on-lan-password: -- ipv4.method: auto ipv4.dns: 192.168.124.79 ipv4.dns-search: ipv4.addresses: ipv4.gateway: -- ipv4.routes: ipv4.route-metric: -1 ipv4.ignore-auto-routes: no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id: -- ipv4.dhcp-send-hostname: yes ipv4.dhcp-hostname: -- ipv4.never-default: no ipv4.may-fail: yes ipv6.method: auto ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.gateway: -- ipv6.routes: ipv6.route-metric: -1 ipv6.ignore-auto-routes: no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: -1 (unknown) ipv6.dhcp-send-hostname: yes ipv6.dhcp-hostname: -- GENERAL.NAME: ens3 GENERAL.UUID: 7ee1db3b-54c4-45c7-bcde-4d39ec8a77a9 GENERAL.DEVICES: ens3 GENERAL.STATE: activated GENERAL.DEFAULT: yes GENERAL.DEFAULT6: no GENERAL.VPN: no GENERAL.ZONE: -- GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveConnection/0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Settings/0 GENERAL.SPEC-OBJECT: / GENERAL.MASTER-PATH: -- IP4.ADDRESS[1]: 192.168.124.102/24 IP4.GATEWAY: 192.168.124.1 IP4.DNS[1]: 192.168.124.1 IP4.DNS[2]: 192.168.124.79 DHCP4.OPTION[1]: requested_classless_static_routes = 1 DHCP4.OPTION[2]: requested_rfc3442_classless_static_routes = 1 DHCP4.OPTION[3]: subnet_mask = 255.255.255.0 DHCP4.OPTION[4]: requested_subnet_mask = 1 DHCP4.OPTION[5]: domain_name_servers = 192.168.124.1 DHCP4.OPTION[6]: ip_address = 192.168.124.102 DHCP4.OPTION[7]: requested_static_routes = 1 DHCP4.OPTION[8]: dhcp_server_identifier = 192.168.124.1 DHCP4.OPTION[9]: requested_nis_servers = 1 DHCP4.OPTION[10]: requested_time_offset = 1 DHCP4.OPTION[11]: broadcast_address = 192.168.124.255 DHCP4.OPTION[12]: requested_interface_mtu = 1 DHCP4.OPTION[13]: dhcp_rebinding_time = 3150 DHCP4.OPTION[14]: requested_domain_name_servers = 1 DHCP4.OPTION[15]: dhcp_message_type = 5 DHCP4.OPTION[16]: requested_broadcast_address = 1 DHCP4.OPTION[17]: routers = 192.168.124.1 DHCP4.OPTION[18]: dhcp_renewal_time = 1800 DHCP4.OPTION[19]: requested_domain_name = 1 DHCP4.OPTION[20]: requested_routers = 1 DHCP4.OPTION[21]: expiry = 1445285472 DHCP4.OPTION[22]: requested_wpad = 1 DHCP4.OPTION[23]: host_name = ipaksclient DHCP4.OPTION[24]: requested_nis_domain = 1 DHCP4.OPTION[25]: requested_ms_classless_static_routes = 1 DHCP4.OPTION[26]: network_number = 192.168.124.0 DHCP4.OPTION[27]: requested_domain_search = 1 DHCP4.OPTION[28]: next_server = 192.168.124.1 DHCP4.OPTION[29]: requested_ntp_servers = 1 DHCP4.OPTION[30]: requested_host_name = 1 DHCP4.OPTION[31]: dhcp_lease_time = 3600 IP6.ADDRESS[1]: fe80::5054:ff:fee2:19ed/64 IP6.GATEWAY: Note particularly that, despite the kickstart settings of static IP address and DNS servers, the installed system had ipv4.method: auto ipv4.ignore-auto-dns: no This certainly doesn't match the intent, so something went wrong somewhere.
I can reproduce this with Cockpit 0.80 and F23. Toggling the 'DNS Automatic' toggle seems to have no effect on the 'ipv4.ignore-auto-dns' setting. Performing the same action in gnome-control-center *does* have an effect.
(In reply to Stephen Gallagher from comment #0) > Further information: when attempting to set these values in the Cockpit > admin interface, the user is unable to modify the "Automatic" setting of the > DNS field. (It displays "off" but setting it in either direction has no > effect on the DNS server list). This part is a Cockput bug.
Cockpit regression fixed here: https://github.com/cockpit-project/cockpit/pull/2984
(In reply to Stephen Gallagher from comment #4) > One more note: I just also performed an installation against the F23 Server > Final TC11 media using this kickstart: > https://sgallagh.fedorapeople.org/kickstarts/f23/static.ks > > Note particularly that, despite the kickstart settings of static IP address > and DNS servers, the installed system had > ipv4.method: auto > ipv4.ignore-auto-dns: no > > > This certainly doesn't match the intent, so something went wrong somewhere. NetworkManager works correctly. I have tested with "ipv4.ignore-auto-dns: yes" and that works as expected (only using manually configured DNS server). So the question is who created the ens3 profile and if it is correct according to the kickstart file. Re-assigning for anaconda for thoughts.
Looking at the kickstart from comment #8 network --device=eth0 --bootproto=static --ip=192.168.124.73 --netmask=255.255.255.0 --gateway=192.168.124.1 --nameserver=192.168.124.79 --hostname=ipaksclient.tc11.final.f23 shouldn't there be --device=ens3 ? AFAIK only virtio VM network devices didn't use predictable names (as ens3). Maybe you are not using virtio? Or perhaps virtio started to use predictable names?
@Radek: virtio net interfaces don't use predictable names unless you are using systemd 226 or newer. Since Fedora 23 uses systemd 222, it should still be designated as "unstable".
(In reply to Neal Gompa from comment #10) > @Radek: virtio net interfaces don't use predictable names unless you are > using systemd 226 or newer. Since Fedora 23 uses systemd 222, it should > still be designated as "unstable". Can someone then explain to me how setting a static IP and such in a kickstart is supposed to be possible? If you can never predict what name an interface will have, how can you ever set that? (Alternately, if the answer is "don't use --device and the first detected device will get the rest of the settings", that should be in the documentation...)
You can use --device=link. https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-docs.rst#network Actually no --device which should default to --device=link might be broken currently. We've just been fixing it in RHEL and are going to backport the patches to master.
(In reply to Radek Vykydal from comment #12) > Actually no --device which should default to --device=link might be broken > currently. We've just been fixing it in RHEL and are going to backport the > patches to master. https://github.com/rhinstaller/anaconda/pull/412
I can confirm that leaving out --device does not fix the problem. When I specify --device=ens3 (which is different from what the virtio device comes up as in F23 Beta, which was eth0), the installation appears to go properly. (So on that note, I'm firmly -1 blocker) Would you mind adding some documentation on what exactly "--device=link" means? The word "link" appears on that page exactly once: when it's used in that example. Does it mean "the first detected device"? The first interface that has a detected "cable"?
(In reply to Stephen Gallagher from comment #14) > Would you mind adding some documentation on what exactly "--device=link" > means? The word "link" appears on that page exactly once: when it's used in > that example. Does it mean "the first detected device"? The first interface > that has a detected "cable"? You couldn't find it because the --device network option on the page links to other doc: https://rhinstaller.github.io/anaconda/boot-options.html#ksdevice
Hmmm, "no --device is broken" actually sounds like a *more* serious bug, if anything. Does that mean that any kickstart with a network line that doesn't specify a particular device will be broken? If so I'd say that's at least an FE.
(In reply to awilliam from comment #16) > Hmmm, "no --device is broken" actually sounds like a *more* serious bug, if > anything. Does that mean that any kickstart with a network line that doesn't > specify a particular device will be broken? If so I'd say that's at least an > FE. The kickstart command will just be ignored. But to be clear, it didn't break recently, I think f22 and f21 have the same behavior.
Hmm, OK - I would've guessed it would be more common.
I've just checked that f22 behaves the same. But I'm not opposed to get the patch into f23. It will definitely go to rawhide.
I'm gonna call this one NOTABUG, there isn't really anything sensible to track here. We *could* open a Fedora bug for the 'omitting --device doesn't work as intended' issue and throw an FE/CommonBugs at it if we want, not sure if it's worth the trouble, but using this bug for that would just be confusing, I think.