Unsupported locale is still an installation problem

Bug #1299378 reported by Jeroen T. Vermeulen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Triaged
High
Unassigned

Bug Description

When installing MAAS in an ssh session, database setup still fails horribly when the ssh client specifies a locale that is not supported on the server. In my case, some locale entries are set to en_GB. Installing the English language pack (!!) solves the problem, but you have to remember to do it before installing MAAS.

Could we at least check for this, and fail with a more helpful message?

Revision history for this message
Jeroen T. Vermeulen (jtv) wrote :

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.

Revision history for this message
Julian Edwards (julian-edwards) wrote :

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.

Changed in maas:
status: Triaged → Incomplete
Revision history for this message
Jeroen T. Vermeulen (jtv) 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.

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=

Revision history for this message
Jeroen T. Vermeulen (jtv) wrote :

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.

Revision history for this message
Julian Edwards (julian-edwards) wrote : Re: [Bug 1299378] Re: Unsupported locale is still an installation problem

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.

Changed in maas:
status: Incomplete → Triaged
Revision history for this message
Martin Pitt (pitti) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.