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.
2) The locale that system services run under (eg. logging). I'll call
this the system locale.
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.
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. 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.
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?
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?
(I wouldn't run the server this way, of course, but I think it's a valid
use case which helps demonstrate the locale issues I'm trying to present
here).
On Tue, Jun 04, 2013 at 12:03:10PM +0200, Martin Pitt wrote:
> Robie Basak [2013-06-04 9:32 +0100]:
> > c) Make openssh default to not passing the locale across
>
> 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?
This might apply to any multi-user system too, of course - not just on a
server.
> 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.
> > (seems a pain for longer lived instances, where you would want it to
> > be carried across).
>
> 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.
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.
Alternatively, if we conclude that locales shouldn't be passed through
ssh, and that dropping my multi-locale multi-user use case is fine, then
sticking to the system locale (/etc/default/locale or whatever) would be
fine for the original bug that prompted this thread.
> postgresql bug, if you build a cloud instance without any locale and
> install postgresql in it, then your instance will not have any idea
> about correct collation, sorting, charsets, and so on. 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?
Robie
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
