After a reboot of our (one and only, for now) OOD 1.5.5 client node, I discovered that though I could connect to an Interactive Desktop (MATE), it was all black. Upon examination of my session log, it was clear that the reason was that dconf lacked permissions to create a /run/user/$UID directory. I set the permissions on /run/user to 0777, which did work, but is too ugly for my taste and shouldn’t be necessary. My bc_desktop/template/script.sh.erb was setting XDG_RUNTIME_DIR to "/tmp/${UID}", which was the default configuration, but it appeared that that wasn’t being passed to dconf.
My solution was to edit script.sh.erb and move the export command that sets XDG_RUNTIME_DIR from the end of the template to just preceding the “Launching desktop” message. That seems to be working for me now, but I am hoping that for my edification, someone with more experience with OOD could tell me if that is really a good solution, or if that is going to cause some other undesirable side effects. I’m supposed to have this thing ready for our early adopters within a week, and would just like some confidence that I’m doing the right thing here.
Richard, you’re using the same solution (setting a custom XDG_RUNTIME_DIR) that I have used to get around the permissions problem in the KDE example. I’m running it by one of our sysadmins now to confirm if it’s an acceptable production solution, or if there is a better way.
“I see no problem setting XDG_RUNTIME_DIR to some unique temp directory. If this is in context of a job you could also maybe use $TMPDIR which is pretty common pattern for HPC to set to some place in /tmp that belongs to a user’s job. $TMPDIR is cleaned up by epilog but random other places used by mktemp will eventually get cleaned up too by systemd which cleans /tmp and /var/tmp depending on files age.”
Thank you. I’d seen several other discourse entries for other issues in which the proposed solution was to set XDG_RUNTIME_DIR to /tmp/$UID or to simply unset it. At least on my installation, that was already being done, but only after dconf had already executed. It sounds like that’s probably just fine. It does seem to be the smallest change I could make to get it working for me, and that is what I was going for. I appreciate you sharing the feedback.
The XDG_RUNTIME_DIR is supposed to be set by pam_systemd, and it is usually set to /run/user/<uid>. It would be possible, inadvertantly, for some other use to create a file or directory in /tmp that is the same as the UID of another user.
pam_systemd is being circumvented because OOD isn’t using pam to authenticate the user.
One way to deal with this is to add something like
to the end of the user’s .bashrc file, then in the .bash_logout file, add
rm -rf $XDG_RUNTIME_DIR
It seems like there should be a way to get reproduce the session setup done by pam_systemd/systemd-logind.service. Alas, I don’t have any good suggestions how to do that.
One might think that /bin/su - username, which starts a login shell, might start an actual login session, but that might be an abuse of PAM, which wants the user to authenticate. Probably wouldn’t want /bin/su - username to get kerberos credentials, either.