Red Hat Bugzilla – Bug 1273167
static kickstart file created DHCP-based ifcfg profile
Last modified: 2015-10-22 11:46:32 EDT
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):
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 220.127.116.11).
2. On the installed system, observe that /etc/resolv.conf contains the DHCP-assigned entry before the manual one.
/etc/resolv.conf contains the DHCP-assigned entry before the manual one.
Only the manual DNS server address should be in resolv.conf
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.autoconnect-slaves: -1 (default)
ipv6.ip6-privacy: -1 (unknown)
DHCP4.OPTION: requested_classless_static_routes = 1
DHCP4.OPTION: requested_rfc3442_classless_static_routes = 1
DHCP4.OPTION: subnet_mask = 255.255.255.0
DHCP4.OPTION: requested_subnet_mask = 1
DHCP4.OPTION: domain_name_servers = 192.168.124.1
DHCP4.OPTION: ip_address = 192.168.124.102
DHCP4.OPTION: requested_static_routes = 1
DHCP4.OPTION: dhcp_server_identifier = 192.168.124.1
DHCP4.OPTION: requested_nis_servers = 1
DHCP4.OPTION: requested_time_offset = 1
DHCP4.OPTION: broadcast_address = 192.168.124.255
DHCP4.OPTION: requested_interface_mtu = 1
DHCP4.OPTION: dhcp_rebinding_time = 3150
DHCP4.OPTION: requested_domain_name_servers = 1
DHCP4.OPTION: dhcp_message_type = 5
DHCP4.OPTION: requested_broadcast_address = 1
DHCP4.OPTION: routers = 192.168.124.1
DHCP4.OPTION: dhcp_renewal_time = 1800
DHCP4.OPTION: requested_domain_name = 1
DHCP4.OPTION: requested_routers = 1
DHCP4.OPTION: expiry = 1445285472
DHCP4.OPTION: requested_wpad = 1
DHCP4.OPTION: host_name = ipaksclient
DHCP4.OPTION: requested_nis_domain = 1
DHCP4.OPTION: requested_ms_classless_static_routes = 1
DHCP4.OPTION: network_number = 192.168.124.0
DHCP4.OPTION: requested_domain_search = 1
DHCP4.OPTION: next_server = 192.168.124.1
DHCP4.OPTION: requested_ntp_servers = 1
DHCP4.OPTION: requested_host_name = 1
DHCP4.OPTION: dhcp_lease_time = 3600
Note particularly that, despite the kickstart settings of static IP address and DNS servers, the installed system had
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:
> 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.
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.
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:
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 email@example.com 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
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.