Arcana of /etc/ltsp/ldm-global-dmrc
A tip of the trade from a fellow LTSP administrator: how to set up the default language and desktop session on LTSP terminals booting off a Fedora 11 terminal server.
In the Fedora 11 flavor of LTSP, you can set a default language and desktop environment for the users' session by editing the file /etc/ltsp/ldm-global-dmrc
. This is "documented" behavior; Warren Togami kindly wrote a one-line blurb about it in the RPM change log. A Busey clap for their dedication to not documenting their "configuration" options publicly:
* Thu Dec 11 2008 Warren Togami - 2.0.22-1 - Show good names in Session menu - Use and write to user .dmrc It is now possible to set a default session that is not GNOME. Set LDM_GLOBAL_DMRC=/etc/ltsp/ldm-global-dmrc in lts.conf and specify your choice in /etc/ltsp/ldm-global-dmrc on the server.
I wanted to understand how a file in the server filesystem, not exported via NFS to the client, gets to affect the configuration of the terminal itself.
My first look was inside the ldminfod
RPM package -- a companion package to the LDM greeter that goes in the terminal and serves some information the terminal needs to display to the user on the greeter. Since that file is distributed inside the ldminfod
RPM package, that was the logical step, right? But said file does not appear to be read by the ldminfod
on-demand xinetd
daemon, so I was left stumped and wondering where and how it's read.
In case you wanted to know, it's read by the terminal client itself upon LDM login, when it's time to set up the desktop session, in the script /opt/ltsp/i386/usr/share/ldm/rc.d/X50-dmrc-processing
.
The way that the script works is rather convoluted (I would have expected the LDM info daemon to give out the information in the file to the LDM greeter). The script specified in /var/lib/tftpboot/ltsp/i386/lts.conf
in the variable LDM_GLOBAL_DMRC
(which defaults to the file name in the first paragraph) is copied via scp to a temporary location into the terminal memory, along with the .dmrc
of the user. Those files are then merged, and finally a decision on desktop environment and language is made upon the merged content of those files.
How did I discover this? Thanks to the audit subsystem. I set a watch on the file of interest, and watched it be fetched by the terminal when I logged on to it.
I admit: this scp shenanigan is rather ingenious. However, unless having a user .dmrc
is so important, I think it's overengineering; in my humble opinion, the LDM info daemon should export that information instead; after all, it's just security-insensitive defaults.
In fact, this whole LDM_GLOBAL_DMRC
problem could be easily bypassed if LTSP simply obeyed the global terminal server configuration. I don't see why I should need to specify a default language in a separate file, when that default language has already been specified in the system configuration via the LANG
environment variable. I also do not see why I should need to specify a default desktop environment, when that information has already been specified via distribution methods -- just run whatever gets me the session that I use when I logon locally and that's it!
For example, in Fedora, you just launch the Xsession
script with the name of the desktop session that you want to run. Which is, all in all, what the terminal ends up remoting via SSH on the server, so the session piggybacks to the client display. The whole thing could be done by serving a "default" session line in the LDM info daemon output before all the lines of the other sessions, and serving the default language as the first line as well. Then LDM can use the first choice of language as the default language, and the default session gets to be the default system session. It would all work integrated with the Fedora X Window System client startup subsystem.