Mailing list thread, for reference: https://lists.launchpad.net/maas-devel/msg01375.html
Some charms use the relation value "private-address" to set host based access controls. Postgresql, for example, uses this value for the pg_hba.conf line like this:
host all all kmkxr.maaslocal md5
In the case of MAAS, that value is the CNAME record for that host:
# host kmkxr.maaslocal
kmkxr.maaslocal is an alias for 10-0-5-100.maaslocal.
10-0-5-100.maaslocal has address 10.0.5.100
And this breaks the access control:
2013-11-07 13:47:02 UTC FATAL: no pg_hba.conf entry for host "10.0.5.100",
user "landscape", database "landscape-standalone-main", SSL off
2013-11-07 13:47:02 UTC DETAIL: Client IP address resolved to
"10-0-5-100.maaslocal", forward lookup not checked.
It's also how openssh behaves. If you setup a key in authorized_hosts to only accept connections from a specific hostname, this is what happens:
Nov 11 11:45:49 wfaxq sshd[2332]: Authentication tried for ubuntu with correct key but not from a permitted host (host=10-0-5-103.maaslocal, ip=10.0.5.103).
Nov 11 11:45:49 wfaxq sshd[2332]: Connection closed by 10.0.5.103 [preauth]
/home/ubuntu/.ssh/authorized_keys:
from="k8q9m.maaslocal" ssh-rsa AAAAB3NzaC1yc2EA...
# host k8q9m.maaslocal
k8q9m.maaslocal is an alias for 10-0-5-103.maaslocal.
10-0-5-103.maaslocal has address 10.0.5.103
As long as the CNAME record is what shows up in juju's private-address, these types of access controls won't work. It doesn't happen with the AWS, LXC and OpenStack providers (didn't test others).
Some options were briefly discussed:
a) Drop the CNAME entirely and keep the generated A and PTR records only
b) Keep the CNAME, but use the A record for the private-address (and probably the actual $(hostname -f) of the unit)
c) Drop the CNAME and use the "friendly" name for the A record
Possibly others I forgot.
Escalated by Dean.