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?”
Addendum 2023-09-23: 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.
There are reasons why some user-specific metadata needs to be stored outside of the user’s home directory. E.g. the home directory may be encrypted and require the user’s password to mount. If you want to know the user’s locale so you can show them the password prompt translated into the right language, you cannot rely on the home directory being already mounted.
That might make some small sense for locale info, but not, IMAO, for desktop choice. And even for locale info for trying to select the proper language for the password prompt, it won’t ever work for the username prompt, and if it’s the first time a user uses a machine, it won’t work for the password prompt either, so I fail to see any real usefulness of it.
You can use an extra LDAP attribute or local config to store the session name.
Then use a script to check the current session name and load the last used one if empty.
That would be a valid mechanism for obtaining that info. I agree. But it would have to be built into the session start-up code, as well as a mechanism for storing that info, and it currently isn’t; all that is there is just the existing–IMAO broken–behavior. At the current time, I’m not looking to rewrite an entire new replacement for gdm and the session startup code.
User desktop choice may need to be visible in cases where a particular desktop has an unpatched security issue or creates problems for a “mission-critical” application. In such cases, notifications can target to affected users and follow-up done without annoying all the users of unaffected desktops (and attempts to switch to the unwanted desktop can be detected).
While the user can explicitly state what desktop they want for the current login session during the login prompting, what they choose isn’t actually used until the session is initiated, and for that their home directory has to be already mounted, so it is completely reasonable to leave the determination of what desktop to use if the user hasn’t entered an explicit choice to that point in time.
Here are the functions to save/restore the session:
sudo tee /etc/profile.d/session-conf.sh << "EOI" > /dev/null
session_save() {
if [ -z "${XDG_SESSION_DESKTOP}" ] \
|| [ -z "${XDG_SESSION_TYPE}" ]
then return 0
fi
mkdir -p "${XDG_SESSION_CONF%/*}"
tee "${XDG_SESSION_CONF}" << EOF > /dev/null
XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP}
XDG_SESSION_TYPE=${XDG_SESSION_TYPE}
EOF
}
session_restore() {
local XDG_SESSION_DESKTOP="$(busctl -j \
get-property org.freedesktop.Accounts \
/org/freedesktop/Accounts/User"${USER_UID}" \
org.freedesktop.Accounts.User Session \
| jq -r .data)"
local XDG_SESSION_TYPE="$(busctl -j \
get-property org.freedesktop.Accounts \
/org/freedesktop/Accounts/User"${USER_UID}" \
org.freedesktop.Accounts.User SessionType \
| jq -r .data)"
if [ -n "${XDG_SESSION_DESKTOP}" ] \
&& [ -n "${XDG_SESSION_TYPE}" ]
then return 0
elif [ ! -e "${XDG_SESSION_CONF}" ]
then return 1
fi
. "${XDG_SESSION_CONF}"
busctl call org.freedesktop.Accounts \
/org/freedesktop/Accounts/User"${USER_UID}" \
org.freedesktop.Accounts.User \
SetSession s "${XDG_SESSION_DESKTOP}"
busctl call org.freedesktop.Accounts \
/org/freedesktop/Accounts/User"${USER_UID}" \
org.freedesktop.Accounts.User \
SetSessionType s "${XDG_SESSION_TYPE}"
}
USER_NAME="${1:-${USER}}"
USER_UID="$(id -u "${USER_NAME}")"
USER_HOME="$(eval echo ~"${USER_NAME}")"
XDG_SESSION_CONF="${USER_HOME}/.config/session.conf)"
session_save
EOI
The problem is to trigger the restore function before the user logins.
In theory, you can call the restore function in a loop over the LDAP users at startup.
No, I don’t think I’d want to run this restore over all 600+ users at system startup. Also, that would miss if they updated their desktop choice on some other system between the time the system was booted and the time they log in.
I may just try to hack /usr/bin/gnome-session (and any kde, or other equivalents) to divert to a different session depending on the content of ~/.dmrc.
And a quick side note: What is this odd tee file <<EOI >/dev/null construct you are using? Whey not just cat >file <<EOI? Is there some special behavior from using ‘tee’?
Like many decisions over configuration defaults, some use cases are adversely affected. The default needs to consider security, scaling, certifications (e.g., out of box energy efficiency), etc.
Waiting for user logins ties timing of notifications to logins.
Wait, you’re not talking about giving notices when they try to login, but sending them out (presumably by email) w/out them even attempting logins? In that case, I would think that having the data stored per-machine would be more complicated than having the data stored in home directories. W/ home directory data, you would only have to scan user home directories on the central file-server, while w/ per-machine data, you would have to probe every workstation to see who might have a troublesome configuration. That can be especially difficult if some of the workstations get turned off. You might have a few file-servers, but you might have hundreds of workstations.
Yeah, I saw that. It didn’t look like that went anywhere. It doesn’t appear to be active to my eye. Especially since the latest version they mention on that page is 2.0 and the current sssd is 2.8
The folks on the GNOME forum suggest to store the AccountsService data directory on the server along with the home directory, this sounds promising as it scales well and should solve the core problem.
I expect what is needed is to explain the reasoning behind moving to the “AccountsService” setup in the first place. That’s not meant as a hostile question, rather to see what issues were being addressed in the first place. Then if the design/implementation needs to be tweaked we could see what use-cases were missed.