(add link to bug) |
m (fix spacing) |
||
Line 81: | Line 81: | ||
== User Experience == | == User Experience == | ||
Slightly easier ssh sessions . | Slightly easier ssh sessions. | ||
See also [https://bugzilla.redhat.com/show_bug.cgi?id=1432426 1432426]. | See also [https://bugzilla.redhat.com/show_bug.cgi?id=1432426 1432426]. | ||
Revision as of 06:32, 8 January 2019
Reset locale if not available
Summary
When logging in over ssh or another mechanism, locale settings are forwarded. If the destination does not support that locale, C.UTF-8 will be used instead.
Owner
- Name: Zbigniew Jędrzejewski-Szmek
- Email: zbyszek@in.waw.pl
- Release notes owner:
Current status
- Targeted release: Fedora 30
- Last updated: 2019-01-08
- Tracker bug:
Detailed Description
This is a continuation of Changes/Remove glibc-langpacks-all from buildroot. With that change implemented, it is much more likely for a system to only support C.UTF-8 or some other small set of locales. When logging in into such an image from a normal system that uses a "full" locale like en_US.UTF-8 or the equivalent for another language, those locale settings are forwarded, resulting in a session with invalid locale settings and errors from various tools.
The same problem could occur previously, for example when logging in from a desktop with LANG=fr_FR.UTF-8 to a container with only en_EN.UTF-8 installed.
To avoid this, the locale setting will be reset to C.UTF-8 if the current setting is "invalid" (not found).
We already have a mechanism to reset locale information if it is unusable. /etc/profile.d/lang.sh
will unset Japanese/Korean/Chinese/... locales only the tty, because the kernel cannot display such fonts properly, so we switch to en_US.UTF-8
to get something displayed. The same mechanism will be used for this.
Benefit to Fedora
Avoid stupid warnings like
perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_CTYPE = "fr_FR.UTF-8", LANG = "en_US.UTF-8" ... are supported and installed on your system. perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Scope
- Proposal owners:
- Provide a patch to
/etc/profile.d/lang.{sh,csh}
to check if the inherited locale is present, and if not, reset to C.UTF-8.
- Provide a patch to
- Other developers: n/a
- Release engineering: https://pagure.io/releng/issue/8036
- List of deliverables: N/A
- Policies and guidelines: no changes needed
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
I think this should be beneficial in all cases. I doubt that anyone runs with broken locale settings on purpose.
How To Test
Login to a different machine with a locale not installed on that machine. Verify that the locale is set to C.UTF-8. If the locale is installed on the target machine, it should not be reset.
User Experience
Slightly easier ssh sessions. See also 1432426.
Dependencies
None.
Contingency Plan
Revert the change to /etc/profile.d/lang.*
.
- Contingency mechanism: revert the patch, rebuild
setup
package - Contingency deadline: any time before relase
- Blocks release? no
- Blocks product? no
Documentation
None needed.
Release Notes
Locale settings will be reset to C.UTF-8 when logging into a machine which does not have the locale that is used on the source machine.