This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1273167 - static kickstart file created DHCP-based ifcfg profile
static kickstart file created DHCP-based ifcfg profile
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
23
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-19 15:58 EDT by Stephen Gallagher
Modified: 2015-10-22 11:46 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-22 11:46:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
nmcli c show ens3 (5.53 KB, text/plain)
2015-10-19 15:58 EDT, Stephen Gallagher
no flags Details

  None (edit)
Description Stephen Gallagher 2015-10-19 15:58:58 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):
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).
Comment 1 Adam Williamson 2015-10-19 16:13:42 EDT
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.
Comment 2 Stephen Gallagher 2015-10-19 17:09:18 EDT
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.
Comment 3 Stephen Gallagher 2015-10-19 17:09:43 EDT
Addendum: If we can figure out what is causing this to happen in a timely manner, I'm also +1 FE.
Comment 4 Stephen Gallagher 2015-10-19 17:16:13 EDT
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.
Comment 5 Stef Walter 2015-10-20 03:30:12 EDT
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.
Comment 6 Stef Walter 2015-10-20 05:04:16 EDT
(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.
Comment 7 Stef Walter 2015-10-20 05:58:13 EDT
Cockpit regression fixed here: https://github.com/cockpit-project/cockpit/pull/2984
Comment 8 Jirka Klimes 2015-10-20 07:43:33 EDT
(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.
Comment 9 Radek Vykydal 2015-10-20 08:04:39 EDT
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?
Comment 10 Neal Gompa 2015-10-21 21:40:07 EDT
@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".
Comment 11 Stephen Gallagher 2015-10-22 08:13:16 EDT
(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...)
Comment 12 Radek Vykydal 2015-10-22 08:21:50 EDT
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.
Comment 13 Radek Vykydal 2015-10-22 08:43:36 EDT
(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
Comment 14 Stephen Gallagher 2015-10-22 11:00:13 EDT
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"?
Comment 15 Radek Vykydal 2015-10-22 11:23:33 EDT
(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
Comment 16 Adam Williamson 2015-10-22 11:26:36 EDT
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.
Comment 17 Radek Vykydal 2015-10-22 11:32:26 EDT
(In reply to awilliam@redhat.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
> 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.
Comment 18 Adam Williamson 2015-10-22 11:35:19 EDT
Hmm, OK - I would've guessed it would be more common.
Comment 19 Radek Vykydal 2015-10-22 11:45:38 EDT
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.
Comment 20 Adam Williamson 2015-10-22 11:46:32 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.