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
Bugs, which is subscribed to 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-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
