fix is now released to xenial under bug 1595302. daily cloud-images with this newer version of cloud-init should appear in the next few days. Any image with a serial number *newer* than 20160707 should have cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .
** Changed in: cloud-init (Ubuntu Xenial) Status: New => Fix Released ** Changed in: cloud-init (Ubuntu Xenial) Assignee: (unassigned) => Scott Moser (smoser) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1581200 Title: Ubuntu cloud-init expects trailing dot on GCE metadata FQDN Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Trusty: In Progress Status in cloud-init source package in Xenial: Fix Released Bug description: [Impact] * If bind9 is installed and configured as a local DNS server on an ubuntu instance on GCE then on every reboot cloud-init will fail to retrieve instance metadata from GCE due to the lookup hostname not resolving. * Backporting of this is necessary as instances with bind9 installed can no longer take advantage of cloud-init * The patch fixes this bug by updating the hostname used in the metadata lookup to one that is included in /etc/hosts. As such it will resolve, even if bind9 hasn't started yet. [Test Case] #launch an instance of ubuntu 14.04 on GCE sudo apt-get update sudo apt-get install -y bind9 #Add the Google DNS servers as global forwarders and configure bind9 for the GCE environment cat << EOF | sudo tee /etc/bind/named.conf.options options { directory "/var/cache/bind"; forwarders { 169.254.169.254; }; recursion yes; dnssec-validation no; dnssec-enable no; auth-nxdomain no; listen-on { 127.0.0.1; }; }; EOF sudo service bind9 restart #setup your instance to use bind9 instead of the Google server echo "supersede domain-name-servers 127.0.0.1;" | sudo tee -a /etc/dhcp/dhclient.conf sudo dhclient -pf /run/dhclient.eth0.pid -x sudo dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 if grep -q "nameserver 127.0.0.1" "/etc/resolv.conf"; then echo "resolv.conf has been updated"; fi if host -t A metadata.google.internal | grep '169.254.169.254' > /dev/null; then echo "host lookup succeeded as expected"; fi sudo service bind9 stop if host -t A metadata.google.internal | grep 'connection timed out' > /dev/null; then echo "host lookup failed as expected"; fi #Now reboot the instance sudo reboot #Once rebooted run the following if grep -q "http://metadata.google.internal./computeMetadata/v1/ is not resolvable" "/var/log/cloud-init.log"; then echo "cloud-init failed to lookup metadata as expected"; else echo "cloud-init did _not_ fail to lookup metadata as expected"; fi A patched ubuntu14.04 has been built. To test the patch run the above but after reboot run #launch a patched instance gcloud compute instances create ubuntu1404-patched-cloudinit --image daily-ubuntu-proche-cloudinit-1404-trusty-v20160627 --image-project ubuntu-os-cloud-devel #on a patched instance run the following after reboot if grep -q "http://metadata.google.internal/computeMetadata/v1/ is not resolvable" "/var/log/cloud-init.log"; then echo "cloud-init failed to retrieve metadata"; else echo "cloud-init did successfully retrieve metadata as expected"; fi [Regression Potential] * GCE are questing this change. * The reported issue only affects GCE users and only a small set of those users will be using a local DNS server. * The change is a single character change and has been tested and as such has limited regression potential. [Original Bug Report] cloud-init hostname breaks because /etc/hosts does not have the trailing dot on metadata FQDN. Background: On Ubuntu, cloud-init sets the hostname using our metadata service. To do this, it hits "metadata.google.internal." (note trailing dot) via HTTP. We have entries in /etc/hosts for the metadata service to ensure that we can access it at boot time (if DNS is not yet up) as we have other init scripts which block bootup when metadata cannot be reached. However, these /etc/hosts entries only have "metadata.google.internal" (no trailing dot) entries. When a customer runs their own bind9 daemon, it starts *after* cloud- init, meaning that cloud-init must use /etc/hosts to find the metadata service. When it cannot, it incorrectly sets the hostname to "$hostname.localdomain" instead of just $hostname. Proposed fix: Update: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceGCE.py Line 28 should read: 'metadata_url': 'http://metadata.google.internal/computeMetadata/v1/' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1581200/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp