Unsupported locale is still an installation problem

I think there is one way to solve this problem completely. We could run our own database cluster, similarly to how we run our own bind and isc-dhcpd. It would depend on the postgresql packages for code and static data, but run in an environment we have much more control over.

Can you attach a log of the installation session please. AFAIK this is a bug in postgres not MAAS but it would be good to confirm.

It's not so much a bug in postgres as it is a requirement: to set up a cluster with the right configuration, it needs a working locale.

For the generic job of creating an initial cluster, it's probably better for it to fail than to make a sensible-but-not-necessarily-correct choice. What we have though is an application-specific database. We're in a better position to enforce choices.

I'm attaching a term.log from a failed installation. For reference, here's my locale (which, honestly, I didn't set up this way to be difficult — it's just what came out of the system installer):

$ locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_TELEPHONE=en_GB.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION=en_GB.UTF-8
LC_ALL=

An example of what happens when your ssh session's locale (in this case, English) is not supported on the system where you try to install. The failure starts near the end of the log with postgresql failing to set up its cluster; after that, maas-region-controller installation gets stuck and throws up an abort/retry/ignore dialogue.

On 31/03/14 13:52, Jeroen T. Vermeulen wrote:
> It's not so much a bug in postgres as it is a requirement: to set up a
> cluster with the right configuration, it needs a working locale.

I meant that it's a bug in the PG packaging. I think it could also be
considered a bug in sshd where it accepts a locale on the client side
that does not exist on the server side.

Indeed ssh has a misfeature of applying the local locale to the remote session even though the remote server doesn't have that locale available. That breaks a lot of things, but it breaks postgresql particularly hard. This was fixed around raring in this version:

postgresql-common (145) unstable; urgency=low
[...]
  * debian/maintscripts-functions, configure_cluster(): Do not trust the
    locale from the environment, as programs like ssh and sudo propagate
    remote and user locale by default. Instead, only use the locale settings
    from /etc/environment and /etc/default/locale, to prevent trying to
    configure the default cluster with a nonexisting or hard to predict
    locale. (LP: #969462, also see Debian #700271)

 -- Christoph Berg <email address hidden> Mon, 10 Jun 2013 17:01:01 +0200

Hence this is really a duplicate of bug 969462, I'm updating the status of this.