<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 5, 2014 at 2:15 PM, Andres Rodriguez <span dir="ltr"><<a href="mailto:andres.rodriguez@canonical.com" target="_blank">andres.rodriguez@canonical.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't have any strong opinions on what the possible fix might be, but I'm wondering if an appropriate fix for this should better be made on the actual postgresql charm? I mean, we have other services that do not have these type of issues, so it seems to me that the appropriate place to have a fix for this, is on the charm side.<div>


<br></div></div></blockquote><div><br></div><div>Look at the branch attached to the bug, it's against the postgresql charm and it checks to see if the unit name is a cname or not. We couldn't have postgresql not deploying for months :)</div>

<div><br></div><div>I consider it a workaround. CNAMEs are for humans, it's the www in <a href="http://www.canonical.com">www.canonical.com</a>. And the fact that ssh does the same check tells me it's the right thing to do when it comes to access controls.</div>

</div></div></div>