FQDN written to /etc/hosts causes problems for clustering systems about cloud-init HOT 14 CLOSED

Launchpad user Launchpad Janitor(janitor) wrote on 2011-10-10T19:45:38.976389+00:00

Status changed to 'Confirmed' because the bug affects multiple users.

from cloud-init.

Launchpad user Scott Moser(smoser) wrote on 2011-10-11T00:18:27.743518+00:00

gethostbyname(hostname) is non-determinable.
there could be multiple responses. and indeterminable order.

from cloud-init.

Launchpad user James Page(james-page) wrote on 2011-10-11T09:02:53.399115+00:00

As a work-around until this is resolved in one way or another in juju I'm using:

dig +short unit-get private-address

dig deals with being passed an IP address nicely and will resolve a hostname correctly to the internal IP address of the instance in ec2 and openstack environments.

from cloud-init.

Launchpad user James Page(james-page) wrote on 2011-10-11T11:48:21.390561+00:00

A bit more testing reveals that this solution does not work so well in a local juju environment; adapting with a check to see if an IP address is returned from private-address before trying to resolve using dig

from cloud-init.

Launchpad user Clint Byrum(clint-fewbar) wrote on 2011-10-11T14:39:38+00:00

Excerpts from Scott Moser's message of Tue Oct 11 00:18:27 UTC 2011:

gethostbyname(hostname) is non-determinable.
there could be multiple responses. and indeterminable order.

Agreed, which is precisely why I believe cloud-init must leave the FQDN
out of /etc/hosts if there is any response to this call.

from cloud-init.

Launchpad user Scott Moser(smoser) wrote on 2011-10-11T16:57:27+00:00

On Tue, 11 Oct 2011, Clint Byrum wrote:

Excerpts from Scott Moser's message of Tue Oct 11 00:18:27 UTC 2011:

gethostbyname(hostname) is non-determinable.
there could be multiple responses. and indeterminable order.

Agreed, which is precisely why I believe cloud-init must leave the FQDN
out of /etc/hosts if there is any response to this call.

That doesn't make any sense. Its non-determinable, its non-determinable
when cloud-init runs as well as later on.
When cloud-init ran to decide if there was a response to this call, it may
give a single value, or may give 4 values, or may give no response. That
may change later on when some other utility was asking.

from cloud-init.

Launchpad user Clint Byrum(clint-fewbar) wrote on 2011-10-11T17:30:22+00:00

Excerpts from Scott Moser's message of Tue Oct 11 16:57:27 UTC 2011:

On Tue, 11 Oct 2011, Clint Byrum wrote:

Excerpts from Scott Moser's message of Tue Oct 11 00:18:27 UTC 2011:

gethostbyname(hostname) is non-determinable.
there could be multiple responses. and indeterminable order.

Agreed, which is precisely why I believe cloud-init must leave the FQDN
out of /etc/hosts if there is any response to this call.

That doesn't make any sense. Its non-determinable, its non-determinable
when cloud-init runs as well as later on.
When cloud-init ran to decide if there was a response to this call, it may
give a single value, or may give 4 values, or may give no response. That
may change later on when some other utility was asking.

The number and content of responses is irrelevant, only that the count
of positive responses is at least one.

The idea isn't to cover the case for all time, its to cover the case
where users have not asked to have fqdn "fixed", yet we need to make a
best effort attempt to make sure it is resolvable during bootup.

If it can be resolved through the normal means, what reason do we have
to override that with a value like 127.0.1.1?

from cloud-init.

Launchpad user Clint Byrum(clint-fewbar) wrote on 2011-10-11T19:33:03.965547+00:00

After discussing with Scott Moser, its agreed that this may cause issues, but not necessarily that it is a "bug" as much as a change in behavior that needs documenting. Adding a ubuntu-release-notes task with suggested release note.

from cloud-init.

Launchpad user Scott Moser(smoser) wrote on 2011-12-20T03:50:35.060592+00:00

This is fix-commited in cloud-init in revision 491 (http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/491).

See the commit message there for more information.

from cloud-init.

Launchpad user Scott Moser(smoser) wrote on 2011-12-20T03:50:38.227628+00:00

This is fix-commited in cloud-init in revision 491 (http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/491).

See the commit message there for more information.

from cloud-init.

Launchpad user Launchpad Janitor(janitor) wrote on 2011-12-22T09:10:13.291010+00:00

This bug was fixed in the package cloud-init - 0.6.3~bzr497-0ubuntu1

cloud-init (0.6.3~bzr497-0ubuntu1) precise; urgency=low

• New upstream snapshot.
  • cloud-config support for configuring apt-proxy
  • selection of local mirror based on presense of 'ubuntu-mirror' dns
    entry in local domain. (LP: #897688)
  • DataSourceEc2: more resilliant to slow metadata service (LP: #894279)
  • close stdin in all programs launched by cloud-init (LP: #903993)
  • revert management of /etc/hosts to 0.6.1 style (LP: #890501, LP: #871966)
  • write full ssh keys to console for easy machine consumption (LP: #893400)
  • put INSTANCE_ID environment variable in bootcmd scripts
  • add 'cloud-init-per' script for easily running things with a given freq
    (this replaced cloud-init-run-module)
  • support configuration of landscape-client via cloud-config (LP: #857366)
  • part-handlers now get base64 decoded content rather than 2xbase64 encoded
    in the payload parameter. (LP: #874342)
    -- Scott Moser [email protected] Thu, 22 Dec 2011 04:07:38 -0500

from cloud-init.

Launchpad user Jason X.(jasxun) wrote on 2012-01-05T18:12:56.450825+00:00

Will the fix also be available for Oneiric?

from cloud-init.

Launchpad user Scott Moser(smoser) wrote on 2012-01-05T21:01:50.680147+00:00

Jason,
I would actually like to not pull the fix back to oneiric. As doing so would break people using oneiric who were expecting the behavior that is present there now. At very least we have to think seriously about it and come up with a list of what types of users would be affected. Do you have any thoughts?

from cloud-init.

Launchpad user Eric Hammond(esh) wrote on 2012-01-06T10:03:11.001956+00:00

Though I don't like the current way Oneiric manages /etc/hosts (and submitted related bug #890501) I agree with Scott that it is how Oneiric works on EC2 and changes could cause existing installations to break. In fact, I have automated system code that works around the "bug" which would break if the behavior were fixed. Not horrible for me personally, but I don't know how many might be in a similar situation.

from cloud-init.