Bug 5562 - Wrong locale when connected to a machine via SSH
: Wrong locale when connected to a machine via SSH
Status: RESOLVED WORKSFORME
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: All Linux
: Normal normal
: ---
Assigned To: ROSA Linux Bugs
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-05-15 12:34 MSD by Eugene Shatokhin
Modified: 2015-05-18 17:45 MSD (History)
1 user (show)

See Also:
RPM Package:
ISO-related:
Bad POT generating:
Upstream:


Attachments
Screenshot - locale problem (124.91 KB, image/png)
2015-05-15 12:34 MSD, Eugene Shatokhin
Details
Screenshot - problem with Russian letters in vi over SSH (88.30 KB, image/png)
2015-05-18 12:07 MSD, Eugene Shatokhin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Shatokhin 2015-05-15 12:34:11 MSD
Created attachment 3963 [details]
Screenshot - locale problem

After the recent updates (all available updates as of May 14, 2015) in a virtual machine, russian letters are no longer displayed right when I connect to that machine via SSH.

I guess, there is a problem with locales or environment because setting LC_ALL=en_US.utf8 explicitly seems to fix the issue. See the screenshot below.
Comment 1 Eugene Shatokhin 2015-05-18 12:07:04 MSD
Created attachment 3966 [details]
Screenshot - problem with Russian letters in vi over SSH

When I connect to a machine over SSH, open vi there and paste a text containing Russian letters, I see this. Some letters are shown OK, many are not. 

No such problem if I launch vi with LC_ALL=en_US.utf8.
Comment 2 a.lahin 2015-05-18 12:20:39 MSD
Please, show output of "locale" and "export | grep -E 'LC|LANG'" commands.

sshd config contains list of client variables that should be accepted for a new session:
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

So this behavior is intended, and it not worked before just because locale variables were always reset by /etc/profile.d/10lang.sh.
Comment 3 Eugene Shatokhin 2015-05-18 13:57:55 MSD
$ locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

$ export | grep -E 'LC|LANG'
<no output>
Comment 4 a.lahin 2015-05-18 14:07:49 MSD
(In reply to comment #3)
> $ locale
> LANG=
...
> LC_ALL=
> 
> $ export | grep -E 'LC|LANG'
> <no output>

And which variables set on a remote (client) computer?
I use Ubuntu as a main system and my locale variables passed correctly:
For example
LANG=en_US.UTF-8 ssh user@1.201
and I get en_US locale in ssh session.
With LANG=fr_FR.UTF-8 ssh user@1.201
I get French.
Comment 5 Eugene Shatokhin 2015-05-18 14:13:32 MSD
(In reply to comment #4)
These were from the remote machine, the one I connect to.

Here are the variables from the local machine:

$ locale
LANG=ru_RU.UTF-8
LC_CTYPE=ru_RU.UTF-8
LC_NUMERIC=ru_RU.UTF-8
LC_TIME=ru_RU.UTF-8
LC_COLLATE=ru_RU.UTF-8
LC_MONETARY=ru_RU.UTF-8
LC_MESSAGES=ru_RU.UTF-8
LC_PAPER=ru_RU.UTF-8
LC_NAME=ru_RU.UTF-8
LC_ADDRESS=ru_RU.UTF-8
LC_TELEPHONE=ru_RU.UTF-8
LC_MEASUREMENT=ru_RU.UTF-8
LC_IDENTIFICATION=ru_RU.UTF-8
LC_ALL=

$ export | grep -E 'LC|LANG'
declare -x LANG="ru_RU.UTF-8"
declare -x LANGUAGE="ru_RU.UTF-8"
declare -x LC_ADDRESS="ru_RU.UTF-8"
declare -x LC_COLLATE="ru_RU.UTF-8"
declare -x LC_CTYPE="ru_RU.UTF-8"
declare -x LC_IDENTIFICATION="ru_RU.UTF-8"
declare -x LC_MEASUREMENT="ru_RU.UTF-8"
declare -x LC_MESSAGES="ru_RU.UTF-8"
declare -x LC_MONETARY="ru_RU.UTF-8"
declare -x LC_NAME="ru_RU.UTF-8"
declare -x LC_NUMERIC="ru_RU.UTF-8"
declare -x LC_PAPER="ru_RU.UTF-8"
declare -x LC_SOURCED="1"
declare -x LC_TELEPHONE="ru_RU.UTF-8"
declare -x LC_TIME="ru_RU.UTF-8"
Comment 6 a.lahin 2015-05-18 14:26:47 MSD
(In reply to comment #5)
> (In reply to comment #4)
> These were from the remote machine, the one I connect to.
> 
Does your /etc/ssh/sshd_config contain these strings?

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

Please, check whether the problem persists with default ssh configuration?
Comment 7 Eugene Shatokhin 2015-05-18 14:33:27 MSD
(In reply to comment #6)
> Does your /etc/ssh/sshd_config contain these strings?

# grep AcceptEnv /etc/ssh/sshd_config 
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
 
> Please, check whether the problem persists with default ssh configuration?

The SSH configuration remains as it is by default, I did not change it.
Comment 8 a.lahin 2015-05-18 15:26:22 MSD
(In reply to comment #7)
What ROSA version (from which image) is installed in the virtual machine?
(I've tested ssh connection with Current and Fresh R5 (updated) and could not reproduce the issue.)
Comment 9 Eugene Shatokhin 2015-05-18 17:20:01 MSD
(In reply to comment #8)
> What ROSA version (from which image) is installed in the virtual machine?

The release image of ROSA Fresh R5 KDE x64, with the newer software updates installed.

Meanwhile, I cannot reproduce the problem on the recent autotested image of ROSA R5 (#11110).

Still, a fix or a workaround would be nice: reinstalling that system is something I'd like to avoid now.
Comment 10 a.lahin 2015-05-18 17:27:33 MSD
As a workaround I would suggest to
cp /etc/locale.conf /home/{user}/.i18n

Private user locale settings would override settings passed (or not passed).
Comment 11 Eugene Shatokhin 2015-05-18 17:45:21 MSD
(In reply to comment #10)
> cp /etc/locale.conf /home/{user}/.i18n

Copying /etc/locale.conf to /home/{user}/.i18n file on the remote machine solved the problem.

As the simple workaround exists and the problem seems to be absent in the new ISO images of ROSA R5, I am closing this bug for now.