Sorry for the confusing subject line. This is the issue: 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.
My landscape unit (kmkxr.maaslocal) cannot talk to postgresql. pg_hba.conf: host all all kmkxr.maaslocal md5 connecting machine is 10.0.5.100: # host 10.0.5.100 100.5.0.10.in-addr.arpa domain name pointer 10-0-5-100.maaslocal. # 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 Postgresql does a reverse lookup on the connecting IP, which gives it the name "10-0-5-100.maaslocal". That doesn't match the entry in pg_hba.conf (kmkxr.maaslocal), and the connection is rejected. The "kmkxr.maaslocal" string came from the juju relation "private-address" key: postgresql/0:db-admin-relation-changed % relation-get private-address: kmkxr.maaslocal On that kmkxr machine /etc/hosts has this entry: # Added by cloud-init on Thu, 07 Nov 2013 13:11:18 +0000 127.0.1.1 kmkxr.maaslocal kmkxr And: root@kmkxr:~# hostname -f kmkxr.maaslocal I'm guessing that's why private-address was set to kmkxr.maaslocal (although "address" implies an IP to me, not a fqdn). If I remove that entry from /etc/hosts: root@kmkxr:~# hostname -f 10-0-5-100.maaslocal As I understand it, maas pre-generates all possible A and PTR records for the network it was given, and adds CNAMEs as machines get provisioned. In this case, kmkxr.maaslocal is a CNAME, but at the same time it was added to /etc/hosts. So, I don't know where the bug is. I'm tempted to say we shouldn't add that /etc/hosts entry since everything is in DNS handled by maas. In any case, the postgresql charm can't get the unit's connecting IP from the relation data unless it's explicitly set.
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
