Bug 1273167

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.