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* http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution Ie, there *should* be an entry for 127.0.1.1 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 networking). 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 about. 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 "local-hostname": 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 example). 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. "public-hostname": 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 ec2-54-234-174-100.compute-1.amazonaws.com Its probably not something that a user would say "Check out my new website at http://ec2-54-234-174-100.compute-1.amazonaws.com" "extrenally-provided-hostname": 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 https://bugs.launchpad.net/maas/+bug/972067 Mainly the above is just a brain dump, and a list of things that have to be thought about. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to maas in Ubuntu. https://bugs.launchpad.net/bugs/1087183 Title: MaaS cloud-init configuration specifies 'manage_etc_hosts: localhost' To manage notifications about this bug go to: https://bugs.launchpad.net/juju/+bug/1087183/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs