@dwalsh - can you comment on this?

The workaround is:

export LANG=C.UTF-8

We should probably export this by default in the base image's ENV.

testing ...

Sorry, doesn't work.

initdb: invalid locale name "en_utf8"

-bash-4.3$ export LANG=C.UTF8
-bash-4.3$ initdb -D /pgdata/data --locale=en_UTF8
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

initdb: invalid locale name "en_UTF8"
-bash-4.3$ initdb -D /pgdata/data --locale=en_utf8
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

initdb: invalid locale name "en_utf8"
-bash-4.3$ initdb -D /pgdata/data --locale=EN_utf8
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

initdb: invalid locale name "EN_utf8"

On a full-blown Ferdora system, I'd fix the above with localectl, but that's not present in the base image.

How large is localctl?

Josh, you need a - there.

initdb -D /pgdata/data --locale=C.UTF-8

@jberkus ^^

Sorry, that was suppsoed to be en_US, not en_UTF8. Still errors out.

The problem is that C.UTF8 isn't a real locale. It's just barely good enough for English speakers, and it's useless for supporting foriegn-language speakers. We've effectively made our base image English-only, which I expect violates some Fedora project policy somewhere.

Like I said, though, I don't have an easy technical solution for this.

We don't document this well, but it is possible to add back in all locales.

The basic step is:

rm /etc/rpm/macros.image-language-conf
yum reinstall glibc-all-langpacks

However, that only undoes the configuration, any existing RPMs will still have their locales stripped. For example, the coreutils-common RPM has the translations for coreutils utilities like touch:

$ env LANG=fr_FR.UTF-8 touch /foo/bar
touch: cannot touch '/foo/bar': No such file or directory
$ yum reinstall coreutils-common
$ env LANG=fr_FR.UTF-8 touch /foo/bar
touch: impossible de faire un touch '/foo/bar': No such file or directory
$

Systemd's localectl is almost entirely irrelevant here - it can set the default locale for login shells, but it has no idea about the RPM configuration or how Fedora implements glibc-all-locales etc.

From my google searching, the steps have been discovered for CentOS 7, e.g.: http://serverfault.com/a/694922

We should clearly put this in a document somewhere, but I'm not sure if we have any for the base image?

Walters: are you saying that the CentOS solution should work for Fedora as well? Testing ...

No, the commands for Fedora (at least 24) and CentOS 7 are different. I linked the commands for Fedora in https://pagure.io/atomic-wg/issue/178#comment-43101

walters wrote:

initdb -D /pgdata/data --locale=C.UTF-8

FWIW, this also works:

initdb -D /pgdata/data --encoding=UTF8 --locale=C 

jberkus wrote:

This means that any server application which depends on server locale ... such as PostgreSQL or HTTPD ... cannot be delpoyed [sic] to production on our base image.

This isn't true in general - i.e. it depends on your use case. For example, often enough one explicitly chooses the 'C' locale for performance reasons when - say - the expected data sort as-good/good-enough (or even more intuitively) under byte-comparison rules. This also applies to Postgresql.

Thus, it's a good default that the base image doesn't waste like 100 MiBs on locale data.