This has been around for a while, but is still a thorn in my side: Who though it was a good idea to no longer store a user’s desktop selection (kde, gnome, etc) w/in the user’s home directory and move it to per-machine storage beneath /var/lib/AccountsService?
I’ve got users who aren’t savvy about ‘desktops’. When their machine is upgraded or even simply replaced because of failed hardware, they say “It doesn’t look the same!” If I ask, “What desktop were you using?”, they have no idea what I am talking about. I certainly don’t know what desktop they were using. The best I can do is manually step them through the login process selecting each desktop in turn asking, “Is this what it looked like?”
Just to be clear here, the situation I’m dealing w/ here is where users have their own workstations sitting on their desk, but their home directories live on a central file-server, and password/login info comes from a central LDAP server.
Note: I have seen Why does AccountsService keep locale configuration? And why in the path /var/lib/AccountsService/users/? and this is not a satisfactory answer in my mind for desktop-selection info. It even fails in the case that it claims to be supporting. 1) The first time a user logs into a machine, no previous AccountsService info has been stored in /var/lib/AccountServices/ for that user, so it cannot provide a user-specific locale/language for the password prompt. Further 2) it can NEVER provide a user-specific locale/language for the username prompt, as the user isn’t known at that point. So all in all, I find no real utility in the supposed validation of the practice.
The final decision on what desktop session to start isn’t needed until it is actually going to be started, which will require that the user’s home be mounted at that point. So choosing which desktop session to initiate if the user has not entered an explicit choice during the login/password prompts can use data from the user’s home directory.
No. You don’t need a explicit “I’m not making a choice” choice. You just need to know that they didn’t explicitly pick one. Until they click one, you leave them ALL unchecked.
What if they never click on the gear when at the password prompt? You only get the radio-buttons if you click it to explicitly set your desktop choice. I’d argue most people don’t even know they have that choice.
As I stated in my initial post/complaint, I’ve got users who don’t know what desktop they have been using. When they get a fresh machine, if they know to click on the gear (they don’t) it will tell them “this is the desktop I’m going to give you, but you can choose one of these others”. They don’t know what desktop they have been using. They don’t even know what a “desktop” is. This certainly won’t be of any use for them. And when their workstation has had a hardware failure and been replaced, all information about what desktop they were using is lost. If the information was stored beneath their home directory, it would still be there.
If they are not using the default session, then they must have used the gear button at one point in the past.
No. That doesn’t track. They may have been using what used to be the default session, but is no longer the default session. IE, the default got changed out from under them. EG “gnome-classic”??? And if they did it once, years ago, many will not remember this.
Look, I’m not really all that concerned about how it is presented to the user. What menus, radio-buttons, presentation order, etc. are used. What I am concerned about is that when their original machine is lost, their desktop choice information is lost along with it. Users expect that if their home directories are on a central, backed-up server, that all their configuration information is preserved.
As it stands – and I had just this issue this past week, which is what prompted my post – when I replace a user’s broken workstation, install the same OS and software on the new system, and the user then logs in, they complain that “It doesn’t look the same!”
If that’s a really bothering issue, is it possible to have a simple script which copies "/var/lib/AccountsService/users/tom" to "/home/tom/.accountsservice.config" on login after the home dir is mounted & available ?
Since, it’s LDAP I assume it should be possible to do it in one central location.
Sorry, this doesn’t track to me. The users don’t know what a desktop is, but somehow they have managed to reconfigure their entire system to use a different desktop without actually knowing it, or understanding why it looked and behaved completely different from the computer in the room next door? Why do these systems even have multiple desktops installed, if this is such a trap? Is anyone doing help desk for these users that has noticed this happening previously? It just seems like this is going to cause a lot worse problems in a day-to-day situation than your issue with restoring configuration after a wipe…
I think what he probably meant was "Desktop" in the sense of a "Desktop session" ( GNOME / GNOME Classic / GNOME on Xorg … etc ), not a "Desktop PC".
E.g.
In Windows, macOS we don’t ask the user: "Which macOS desktop do you use … ? "
But in Linux, this confusion could be an issue, since we now list a lot of desktop sessions in the GDM login screen ( by default ), and we don’t explicitly name them as a "Desktop Session" anywhere as in:
"Select a Desktop session" menu item.
"Select a Desktop session" button tooltip on hover.
Yes, I understand, but that makes it more confusing… why is the user being presented with “GNOME Classic” , “Gnome on Xorg” etc. if they don’t know what any of that means, and there is no explanation anywhere, and by accidentally clicking on it they can get their system into a strange state that they can’t explain to the office staff? That seems to be the core of the problem, not any kind of configuration issue.
I see what you’re thinking, and it would probably be applicable in an office/business setting. But the situation I’m in is an academic setting w/ people using them for research purposes with a vast range of savvy-ness regarding computer usage. (We do actually have some office use for the front-office, but they’re using windows, not linux, and I’m the unix/linux dude.) So we have some people that want and know how to use assorted desktops like KDE and such. But there is a small, but non-zero fraction of users that don’t understand these nuances, and had help getting any special tweaks to their desktop/configuration/etc set up in the distant past. We already have enough difficulty w/ these users just due to old software being replaced by newer version or substitutes. We’ve got people w/ 10+ year old research code they expect to still run just like it always used to. I’ve got people w/ code that was originally meant to run on Scientific Linux 6 that they expect to run just like it did ten years ago.
That sounds like even more reason to disable the setting for those users that never change it, and also keep an inventory of every local setting on those machines all the time. Because I am sure there is more hidden around if this is 10+ years of upgrades to the same machine without re-imaging it. I guess I am still not sure the practical difference here for IT between a business setting, either way the staff (i.e. you) are managing the machines. That “user who got help to set it up years ago but can’t reproduce anything” is always going to be a liability.
