Description of problem: On hosts that have BOOTPROTO=static interfaces won't properly configure dnsmasq to use the defined upstream nameservers. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Configure eth0 using static config like this: # cat /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE="Ethernet" #BOOTPROTO="dhcp" BOOTPROTO="static" IPADDR=192.168.122.134 GATEWAY=192.168.122.1 DEFROUTE="yes" PEERDNS="yes" PEERROUTES="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="yes" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_PEERDNS="yes" IPV6_PEERROUTES="yes" IPV6_FAILURE_FATAL="no" NAME="eth0" UUID="c53fc5a3-651c-4e84-9311-6ea56e4a7fb3" DEVICE="eth0" ONBOOT="yes" DNS1=192.168.122.1 2. install 3.2 with dnsmasq Actual results: observe that /etc/dnsmasq.d/origin-upstream-dns.conf has no server=192.168.122.1 and dns probably completely broken dig google.com Expected results: server=192.168.122.1 in /etc/dnsmasq.d/origin-upstream-dns.conf and we're able to resolve google.com Additional info:
proposed fix https://github.com/openshift/openshift-ansible/pull/1875
Did this go into GA yet? (did a 3.2GA install and had the same problem)
No, not yet. This will be in the first post 3.2 update coming soon.
(In reply to Scott Dodson from comment #3) > No, not yet. This will be in the first post 3.2 update coming soon. Thanks Scott. I guess we need to post a work-around KSC in the mean time?
I'll leave that up to support to decide what to do. I don't believe that many users will use staticly configured interfaces but I may be wrong. Please collaborate with support if you want a solution written up.
(In reply to Scott Dodson from comment #5) > I'll leave that up to support to decide what to do. I don't believe that > many users will use staticly configured interfaces but I may be wrong. > Please collaborate with support if you want a solution written up. I was under the impression that statically defined interfaces were a requirement for OpenShift to function and work properly, as changing IP addresses via DHCP leases can lead to outages or miss-configurations on the openshift configuration side, especially if these changes don't propagate to DNS. Scott with out the code from the PR what is the defined workaround to this issue? If we have a solutions we can document it into a KCS solution.
You can add the host's defined DNS servers to /etc/dnsmasq.d/static-workaround.conf in the following format and restart dnsmasq. server=4.4.4.4 server=8.8.8.8 I really do suspect almost no one is using static configurations though.
(In reply to Scott Dodson from comment #7) > You can add the host's defined DNS servers to > /etc/dnsmasq.d/static-workaround.conf in the following format and restart > dnsmasq. > > server=4.4.4.4 > server=8.8.8.8 > > I really do suspect almost no one is using static configurations though. I'll like to add to this bugzilla that I know of NO installation that does NOT use static IPs (not using DHCP). Not even on a cloud service solution like AWS. I understand that some deployment automation tools (like our Satellite and OpenStack) works from the presumption that it controls the DHCP setup and can add static entries for the MACs when provisioning new servers. That's not the typical use-case I've seen with OSE for now - in particular in pre-production (evaluation) environments.
I have created a solution for this issue to mitigate the short term effects of this bug.
Check on openshift-ansible-3.0.90-1 Install env with static IP #vim /etc/sysconfig/network-script/ifcfg-eth0 BOOTPROTO="static" IPADDR=192.168.2.226 GATEWAY=192.168.2.2 TYPE=Ethernet DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no PEERDNS=yes PEERROUTES=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes DNS1=10.73.2.107 DNS2=10.73.2.108 DNS3=192.168.2.2 after installation, check the resolv.conf # cat /etc/resolv.conf # Generated by NetworkManager search lab.eng.nay.redhat.com nameserver 192.168.2.226 nameserver 192.168.2.226 nameserver 192.168.2.226 # nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh Get the expected result, move this issue to VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1208