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
