Bug 1014327

(In reply to Marko Myllynen from comment #0)
> When logging in to
> GNOME with the user account created during installation and marked being an
> administrator, if the user merely opens the Region & Language from
> control-center and selects e.g. Deutsch (Deutschland) from the Language
> menu, then /etc/locale.conf is already updated and contains the following
> 
> LANG=de_DE.utf8

This is as designed. See https://bugzilla.gnome.org/show_bug.cgi?id=694922 .

> (even though Formats is de_DE on the GNOME side):

Not pushing the Formats to the system was an oversight that is being fixed upstream in https://bugzilla.gnome.org/show_bug.cgi?id=695535 .

(In reply to Rui Matos from comment #1)
> > When logging in to
> > GNOME with the user account created during installation and marked being an
> > administrator, if the user merely opens the Region & Language from
> > control-center and selects e.g. Deutsch (Deutschland) from the Language
> > menu, then /etc/locale.conf is already updated and contains the following
> > 
> > LANG=de_DE.utf8
> 
> This is as designed. See https://bugzilla.gnome.org/show_bug.cgi?id=694922 .

IMHO the rationale is fundamentally flawed for Fedora (the rationale could make sense for GNOME OS running on a tablet) as on Fedora 1) the GNOME user is not always the superuser 2) the superuser might be adding more users later on and, perhaps most importantly, 3) there might be network authenticated users in addition to the local user.

I'm reopening this (only for this one time) for you to reconsider the above points but if you decide to close this again then so bit it.

Thanks.

1) is already handled, or rather, GNOME simply *can't* update the system configuration transparently in this case, as it just doesn't have the privs. When there are multiple users or a single unprivileged user, you have an explicit button for pushing the setting system-wide, which requires (re)-authentication.

I think 3) is definitely a case that should be handled, though. At least, this mechanism should perhaps not kick in if the machine has been joined to a remote domain, or if a remote user has ever logged in (something that is supposed to be kept track of somewhere for the purpose of showing them on the GDM user list, though that function seems broken for me ATM).

Sorry, I was a bit unclear wrt 1). GNOME indeed updates the system configuration completely transparently without hinting anything about it to the user if the user was marked as an administrator during installation (i.e., belonging to wheel group) and there are no other local users. But what I meant is that even if the user is part of wheel group the person himself/herself or someone else might want to use the system as the superuser (root) occasionally, for example when troubleshooting something.

Both NIS/YP and SSSD are often used on systems which are not part of a (IPA/AD) domain so behaving differently e.g. when using SSSD against AD as a domain member vs using SSSD against AD without being a domain member would make things even more confusing.

Sure, if one knows how to login as root from console and how to setup SSSD to authenticate against AD without being a domain member then one probably knows how to change back the original system locale but since there already exists GNOME interfaces to change both the user language and the Login Screen language I don't think all this special casing and complexity is warranted here.

I really don't understand your comment entirely, but one thing I think you're missing is that in GNOME's design, when you see a button to apply a setting to the 'Login Screen', what it actually means is 'systemwide'.

Ok, let's recap. As said the problem is that "if the user merely opens the Region & Language from control-center and selects e.g. Deutsch (Deutschland) from the Language menu, then /etc/locale.conf is already updated".

To this you replied "GNOME simply *can't* update the system configuration transparently in this case" but if you'll reread the entire problem statement you'll see that GNOME *can* and it *does* update the system configuration behind user's back, without any notifications, warnings, or authentication dialogs.

Your proposals about special casing situations when the system is part of a domain sound suboptimal to me. I think it would be better for GDM to use EnvironmentFile=/var/lib/gdm/.i18n in gdm.service and never touch system configuration files like /etc/locale.conf, even if a user changes 'Login Screen' language.

Thanks.

To this you replied "GNOME simply *can't* update the system configuration transparently in this case"

No, I did not. You missed the flow of the conversation. Let's explain clearly:

* If there is only one user account on the system (I don't know precisely if or how remote accounts are taken into consideration) AND that user account is an administrator, then changes in this and a few other control panel applets are applied systemwide automatically

* If GNOME thinks there are multiple accounts on the system OR there is only a single account but it is not an administrator, the button to apply the settings to the "login screen" will be present, and what that really means is "apply these settings systemwide" - i.e. they will NOT be applied systemwide transparently. When you click the button it will prompt for authentication to push the settings out systemwide.

(In reply to Marko Myllynen from comment #6)
> To this you replied "GNOME simply *can't* update the system configuration
> transparently in this case" but if you'll reread the entire problem
> statement you'll see that GNOME *can* and it *does* update the system
> configuration behind user's back, without any notifications, warnings, or
> authentication dialogs.

It can and it does on single user systems where the current account is considered an admin, because on a single user system, why should we bother users with prompts?

> Your proposals about special casing situations when the system is part of a
> domain sound suboptimal to me. I think it would be better for GDM to use
> EnvironmentFile=/var/lib/gdm/.i18n in gdm.service and never touch system
> configuration files like /etc/locale.conf, even if a user changes 'Login
> Screen' language.

That could be considered but you'll have to take the issue upstream with a rationale for it.

(In reply to Adam Williamson from comment #7)
> To this you replied "GNOME simply *can't* update the system configuration
> transparently in this case"
> 
> No, I did not. You missed the flow of the conversation.

Right, so when in comment 2 I mentioned a possible issue "1) ..." and then right after that in comment 3 you stated "1) is already handled ..." then I guess I indeed missed the flow of the conversation if you were not replying.

(In reply to Rui Matos from comment #8)
> It can and it does on single user systems where the current account is
> considered an admin, because on a single user system, why should we bother
> users with prompts?

As I've tried to explain, a system which is a single user system from GNOME perspective might not be a single user system from OS perspective - although "root" is not a valid GNOME user it certainly is a valid user at console.

And when /etc/locale.conf is used instead of ~/.i18n it also affects non-GNOME processes. By changing LANG=ru_RU.UTF-8 in /etc/locale.conf, rebooting to non-graphical mode (old school runlevel 3) I see:

# grep ru_RU /proc/*/environ | wc -l
30

> > Your proposals about special casing situations when the system is part of a
> > domain sound suboptimal to me. I think it would be better for GDM to use
> > EnvironmentFile=/var/lib/gdm/.i18n in gdm.service and never touch system
> > configuration files like /etc/locale.conf, even if a user changes 'Login
> > Screen' language.
> 
> That could be considered but you'll have to take the issue upstream with a
> rationale for it.

Fair enough, I've opened an upstream bug and listed all the arguments/issues in it, I think we can continue there:

https://bugzilla.gnome.org/show_bug.cgi?id=710246

Thanks.

"As I've tried to explain, a system which is a single user system from GNOME perspective might not be a single user system from OS perspective - although "root" is not a valid GNOME user it certainly is a valid user at console."

A single user with admin privileges is root, to all intents and purposes. I can't see a valid reason for a configuration where you have an accessible 'root' account (i.e. non-locked), and a single accessible user account with administrative privileges, but the person who has the user account password doesn't have the root password. What could possibly be the point of such a scenario? The user can, for instance, change or lock root's password on his own authority.

This is not about who knows the superuser password or not but what the superuser prefers on console and what most often relates to maintenance and troubleshooting where seeing mixed language in logs etc (as many lower level components are not as well localised as GNOME) is counter-productive.

I can share a couple of scenarios related to this based on recent real-world experiences. It can be just one person with two roles (e.g. someone on Fedora Alpha/Rawhide otherwise as a regular user but when something goes wrong s/he needs to drop to console as root to sort things out - guess how I noticed this issue in the first place :). It can be a friend or a partner using his/hers system but occasionally asking help from a more experienced user who then works as root on console. It can be a team member installing Fedora and then various daemons, then another team member is tasked to install and configure something related to his/hers expertise and it happens to involve using GUI (e.g. configuring FreeIPA with a browser) who then starts GNOME only once for that purpose.

But regardless whether we agree on these use cases or not I don't see any reason to favour the current approach instead of the scheme I proposed in comment 6. If there are no technical issues preventing using it I suspect it would be even less effort than the possible changes needed e.g. for network users with the current approach. And following the principle of the least impact seems to be fitting also in this case, if you want to change GNOME / Login Screen language, then change GNOME / Login Screen language, not language for the whole OS.

Thanks.

"I don't see any reason to favour the current approach instead of the scheme I proposed in comment 6"

The reason is that the GNOME developers specifically want the preference to change the systemwide configuration. They don't want it to only change the login screen configuration. The dialog doesn't refer to 'login screen' because the intent is only to change the setting for the login screen, but on the basis that 'login screen' is easier for an unskilled user to understand than 'system-wide', I think: buttons like this used to be labelled 'Apply systemwide' or something like that, in earlier designs. I don't want to give my personal opinion of this or risk mis-representing the design intent here, but the primary point is that the developers actually intend for this whole setup and others like it (there are other elements of the control center that follow this basic pattern) to apply systemwide, it's not really just about the 'login screen'.

"The reason is that the GNOME developers specifically want the preference to change the systemwide configuration. They don't want it to only change the login screen configuration."

Reading the upstream bug referenced above IMHO leaves room for interpretation:

"When there's only one user, there's no conceptual difference between user
settings and system settings ... If they change the display language,
this should automatically be reflected in the login screen rather than having
to do the extra work involved in apply their settings to the system."

Neither network users nor the scheme proposed here was not discussed there at all so at least for me it's hard to say whether they were taken into consideration at some point or not.

If we're talking about unskilled users then I don't think they care much what happens under the hood, they're looking at Plymouth during boot and after GDM appears they live in GNOME-only world, unskilled users rarely care about console, daemons, or system logs. But with skilled users the current approach makes it infeasible to have root on console and non-GNOME processes to use /etc/locale.conf and GDM/GNOME to use whatever was configured under GNOME.

Anyway, since this is somewhat turning into speculation perhaps it'd be best if we continue in the upstream bug I filed earlier as suggested by Rui?

Thanks.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This breaks things pretty badly on F23. An example scenario follows:

1) Install F23 Workstation using en_US, create a test user
2) After installation, login as the test user and change language to ru_RU
3) Reboot and switch to console
4) Type in something invalid like "abc"
5) Notice how the error message is be completely unreadable

Closing as it's tracked upstream.