MaaS cloud-init configuration specifies 'manage_etc_hosts: localhost'

Bug #1087183 reported by James Page on 2012-12-06
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Raphaël Badin

Bug Description

The default cloud-init configuration for MaaS uses 'manage_etc_hosts: localhost'; this causes a line such as:

# Added by cloud-init test-12

To be added to /etc/hosts; this is problematic for a few reasons when using Juju with MaaS as:

unit-get private-address

returns ''; and if I then try to bind services or connect to services running locally using this hostname I get connected/bound to ''. And then other services connecting to `hostname` using relation-get private-address (which resolves to the external IP address) can't actually connect to the service as its running on

This part of the configuration is coming from MaaS rather than Juju and it makes the maas provider for Juju function in a different way to other providers which I don't believe use this configuration option.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: maas (not installed)
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu4
Architecture: amd64
Date: Thu Dec 6 04:31:58 2012
InstallationMedia: Ubuntu-Server 11.10 "Oneiric Ocelot" - Release amd64 (20111011)
MarkForUpload: True
 PATH=(custom, no user)
SourcePackage: maas
UpgradeStatus: Upgraded to quantal on 2012-05-01 (218 days ago)

Related branches

Changed in maas:
status: New → Confirmed
Changed in juju:
status: New → Confirmed
Changed in maas (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Dave Walker (davewalker) wrote :

I thought this was enabled to resolve an issue of using avahi with maas/juju?

Julian Edwards (julian-edwards) wrote :

Dave, see this bug about that:
bug 1086307
I suspect these are related.

Julian Edwards (julian-edwards) wrote :

The commit message on the revno (from 2012-10-03) that added manage_etc_hosts says:

          specify 'preserve_sources_list' to cloud-init in install preseed

          This moves the cloud-init/local-cloud-config out of the preseed explicitly
          and instead renders it in compose_cloud_init_preseed.

          We now put 2 items in this debconf escaped yaml, essentially feeding
          cloud-init this yaml:
            manage_etc_hosts: localhost
            preserve_source_list: true


Not sure this helps understand why it is there but at the same time I think it was added way after Avahi booting worked?

Changed in maas:
status: Confirmed → Incomplete
Julian Edwards (julian-edwards) wrote :

I can remove it, but I don't know enough about cloud-init to know what, if anything, it will break. So if someone can confirm it's ok I'll do it.

Scott Moser (smoser) wrote :

Some context. The situation is not at all simple. Here are some things to
think about:

a.) debian manual says what you see in /etc/hosts is actually *correct*

    Ie, there *should* be an entry for pointing to the system's
    hostname. This is done so that 'hostname' always resolves to
    something that can be reached (even in the absense of dns or

b.) relying on dns provided by maas assumes that connection to maas's dhcp
    server is present even after installation. Ideally the instance once
    deployed could be detached from the management network entirely.

    This is very much a future maas feature, but it is something to think

c.) 'hostname --fqdn' as juju (and other things use) should not be used.
    From the man page of 'hostname'
     | If a machine has multiple network interfaces/addresses or is used
     | in a mobile environment, then it may either have multiple
     | FQDNs/domain names or none at all. Therefore avoid using
     | hostname --fqdn, hostname --domain and dnsdomain‐ name.
     | -f, --fqdn, --long
     | Display the FQDN (Fully Qualified Domain Name). A FQDN
     | consists of a short host name and the DNS domain name. Unless
     | you are using bind or NIS for host lookups you can change the
     | FQDN and the DNS domain name (which is part of the FQDN) in the
     | /etc/hosts file. See the warnings in section THE FQDN above, and
     | avoid using this option; use hostname --all-fqdns instead.

d.) There are really at least 2 different "hostnames" that matter
      Maas has this concept, and provides 'local-hostname' to cloud-init
      in meta-data. Juju's MAAS provider assumes that it can reach
      machines via the 'local-hostname'. ('juju ssh service/0' for

      That assumption might not be true. While MAAS nodes (and thus the
      juju bootstrap node) are likely to be able to talk to each other via
      "local-hostname"s, it isn't true that other resources can.

      In EC2, there is a 'public-hostname' that is resolves to the IPv4
      globally routeable address. This makes sense to use in some cases,
      but as it is something like
      Its probably not something that a user would say
      "Check out my new website at"

      This is what the user would actually direct people to.

e.) for reference, 'manage_etc_hosts' first came into MAAS in revno 395
    (my commit) due to bug 972067
    I have a long winded bug report there

Mainly the above is just a brain dump, and a list of things that have to
be thought about.

Curtis Hovey (sinzui) on 2013-10-12
Changed in juju:
importance: Undecided → Low
status: Confirmed → Triaged
James Page (james-page) wrote :

Pertains to bug 1087183

Andreas Hasenack (ahasenack) wrote :

About Scott's (a) point, the debian document says you should have host.domain in /etc/hosts if the system has a permanent address, and the host.domain line should be for that address, not
For a system with a permanent IP address, that permanent IP address should be used here instead of

For a system with a permanent IP address and a fully qualified domain name (FQDN) provided by the Domain Name System (DNS), that canonical <host_name>.<domain_name> should be used instead of just <host_name>.

Now, is a dhcp lease a permanent address? :) I think it's permanent enough for this scenario where MAAS is giving it out, as it even updates the DNS record.

Andreas Hasenack (ahasenack) wrote :

Can someone mark the pyjuju task as won't fix?

tags: added: landscape
tags: added: cloud-installer
Changed in maas:
milestone: none → 1.7.0
Changed in juju:
status: Triaged → Won't Fix
Gavin Panella (allenap) wrote :

> Now, is a dhcp lease a permanent address? :) I think it's permanent
> enough for this scenario where MAAS is giving it out, as it even
> updates the DNS record.

In this case, yes, I think it is permanent. MAAS promises to keep that
address for that node until it is released. DHCP is simply the
mechanism. Users are free to set this address statically in their node's
networking configuration.

Changed in maas:
status: Incomplete → Triaged
importance: Undecided → High
Raphaël Badin (rvb) on 2014-09-30
Changed in maas:
importance: High → Critical
Dean Henrichsmeyer (dean) wrote :

We (Landscape team) had a meeting to discuss this with the server team (James Page, Scott Moser). Based on our discussion, there's consensus that it would be great if MAAS simply adhered to the Debian policy (see )

That would mean that the permanent address would be written to /etc/hosts and the wouldn't be written. That would be consistent and other applications would know what to expect.


Christian Reis (kiko) on 2014-10-08
Changed in maas:
assignee: nobody → Raphaël Badin (rvb)
Christian Reis (kiko) on 2014-10-09
Changed in maas:
status: Triaged → In Progress
Raphaël Badin (rvb) on 2014-10-15
Changed in maas:
status: In Progress → Fix Committed
Adam Collard (adam-collard) wrote :

I believe this fix in MAAS to be wrong :/

If we look in /etc/hosts after this fix landed there is no entry for the node's name

This breaks juju bootstrap:

Adam Collard (adam-collard) wrote :

Just did another bootstrap and it went without issue. Continuing to investigate...

Adam Collard (adam-collard) wrote :

So it seems that I was actually hitting bug 1383329 - because there is no entry in /etc/hosts anymore (fine) juju bootstrap is relying on DNS, which was flaky (as per bug).

Changed in maas:
status: Fix Committed → Fix Released
no longer affects: maas (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers