Robie Basak [2013-06-06 12:42 +0100]: > I'd like to distinguish three different use cases of locales. > > 1) The locale that a sysadmin sees for commands that he types under > his own login (whether local or over ssh). I'll call this the user > locale.
This actually needs to be split in two: (1host) the locale as it is configured on your host (from where you run ssh), and (1remote) the locale that your user has configured on the remote host (where you ssh into). These are usually defined in the respective ~/.profile or ~/.pam_profile. Let's > 2) The locale that system services run under (eg. logging). I'll call > this the system locale. ... which is usually specified in /etc/default/locale, or on older systems, /etc/environment. > 3) The locale served to users accessing services that the server > provides. Example: what a user using a web application gets as a > collation order when he sorts some listing by name. I'll call this the > service locale. My feeling is that this will usually be equal to the system locale, or you have to configure the particular process for that specific locale, overriding /etc/default/locale and the environment. Note that due to the default behaviour of our ssh, (1host) becomes (1remote) iff the remote system has no (2) or (1remote) configured (that's the precise case I'm picking on, as this is just broken), and due to our default behaviour of sudo, (1remote) even becomes (2). I. e. due to these two, these concepts can easily become mixed up. > Example: > > I (English) work with a French sysadmin on a server which > provides services to Polish customers. I'd want all three locales > configured on my server. We might settle on C or en_GB for the system > locale. My French co-worker may use LANG=fr(?) and expects to see > messages in French when he uses ssh to diagnose issues. You said the server has en_GB.UTF-8 in /etc/default/locale. In that case, ssh'ing in would give your French sysadmin that if he didn't configure anything in his remote ~/.profile, or he puts LANG=fr_FR.UTF-8 into his remote profile. (1host) only comes into play if the remote server would not have an /etc/default/locale, then ssh would transfer his (1host) locale (presumably fr_FR.UTF-8) to (1remote), but that wouldn't actually work unless the remote server actually has fr_FR.UTF-8 available (which wasn't the case in said bug reports). > I need to see English, since I don't understand French well enough. > The server runs a web application which uses Postgres, so Postgres > should use a Polish collation order. PostgreSQL can define the collation and locales per-database and thus individually per webapp, but for the sake of argument let's pretend it can't, and it would always use the locale of template1 (i. e. the default database created at installation). > Problem 1: does postgresql-9.1's postinst do a different thing depending > on whether me or my colleague installs it? Why? Now that we have > /etc/default/locale, wouldn't it be better to use this? If you have a (2) set in /etc/default/locale, then it will use that. ssh maintains the right fallback here: (1remote) wins over (2) wins over (1host). (And again, I claim that the latter is bad behaviour). If you neither have (1remote) nor (2), then yes, it will depend on what your host locale is due to how ssh and sudo combined behave, and either fail because (1host) doesn't exist on the server, or create the default db with just (1host). But in that case there is nothing else that PostgreSQL could use, except perhaps for saying that "if I have a locale defined by the environment, but it's not in /etc/default/locale, /etc/environment, /etc/postgresql/version/cluster/environment, ~/.profile, ~/.pam_profile, or whereever else you could set environment variables, then use C", but that would make things even less predictable and robust IMHO. > Problem 2: but I wanted Postgres configured with a Polish collation > order, which doesn't happen either way. Maybe the postinst should use > debconf to ask the user, defaulting to what /etc/default/locale says? That would be overkill IMHO. Except in the pathological case above, it works just fine, and then you often want different locales for different DBs/applications anyway. You can create more clusters or databases, and in each case (pg_createcluster/createdb) specify an individual locale combination. > > I have always considered this default behaviour of ssh unexpected and > > wrong. It blindly applies the host locale to the remote ssh session > > without any checks whether that locale is actually valid. In > > particular because it only seems to do that if the remote server does > > not have any default locale from /etc/default/locale, > > .pam_environment, or otherwise, which usually only occurs in servers > > where locales have not been installed and configured at all (this > > might be the case in our cloud instances, something we ought to fix). > > I hope I've presented the case for passing the locale setting through in > my use case above. Two different sysadmins want two different locales > available when they log in. How should we cater for this? There can be just one (2), so they need to fight out which of the two should become it. The other can then set a different locale in their ~/.profile. This is independent of ssh's behaviour, but of course the sudo behaviour still applies here: if the other sysadmin uses sudo, all operations will be done under his locale. > > So in this situation it is very likely that the locale that ssh passes > > from the host to the remote shell will not work. > > IMHO, we should make it work, or drop to C if a locale isn't configured. My preferred fix would be to ssh to simply stop passing (1host) at least if the remote system does not have that available. The very first time you press <tab> in the remote shell you'll get screen clutter by error messages, apt/dpkg will spit out a plethora of errors from perl, and the locale will not work and behave like C anyway. It's somewhat debatable if we want to pass (1host) if it is available on the server; I'd personally prefer not to because of our sudo behaviour, but I have no strong opionion about it, and good arguments can be made either way. > > I don't understand this -- if you run your entire server without > > locales, then a lot of stuff will not work; e. g. your cited > > No, perhaps I haven't been clear. I want multiple locales configured, so > that on a multi-user system users see their own locales when they shell > in. That's fine. But in the bug you cited the problem was that none of the locales involved were configured on the server. > But because we don't know what these locales might be, we can't easily > configure them in advance. So a warning of an unconfigured locale is > great, but that doesn't stop it being broken. That's why I'm proposing > dropping the user down to C until the misconfiguration is fixed. As I said in my reply to Steve, I'm happy to make the package installation succeed, but not create any cluster in that case (and print a warning instead, which might or might not be actually seen). That's somewhat cleaner from a package installation POV, but again leads to bug reports like "I installed postgresql and did not get a default DB", which are rather hard to debug. As for predicting which locales you might need on a server: If we keep the current behaviour of ssh, then you could just generate _all_ locales on the server to be prepared for anything? > Alternatively, if we conclude that locales shouldn't be passed through > ssh, and that dropping my multi-locale multi-user use case is fine Those are not the same thing as far as I can see. Working with multiple locales on the server is fine; what's not fine is to throw an arbitrary LANG= setting into a remote shell and expecting it to work without checking whether it's valid. > then sticking to the system locale (/etc/default/locale or > whatever) would be fine for the original bug that prompted this > thread. That's what is already happening, as far as I can see. > > I'd think that on a server you ought to set the system locale to > > what you actually want, and then have your services use that, not > > some random locale from outside that someone happens to use on > > their workstation? > > Right - but the locale the user installing Postgres on is using isn't > necessarily the system locale. So how about using /etc/default/locale > instead of the environment-defined one? Again, the referenced bug occurs when there is no /etc/default/locale. Canonically, locales are defined by environment variables, and /etc/default/locale, /etc/environment, /etc/postgresql/version/cluster/environment, /root/.profile, and what not are means to set them. We can probably add some heuristics there, but if we limit it to only /etc/default/locale, we'd break other cases which are legitimately working right now. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
