Document Actions
14.3. Customizing the User's Session
In this section, we will describe how the session startup in ThinLinc can be customized.
The session setup is constructed to be easy to use and configure yet still easy to customize for advanced use cases.
In Figure 14.1, shows a (simplified) description of what happens on the VSM Server when a client connects to login:
The VSM Server checks if the user has an existing session.
If a session exists, VSM Server contacts the VSM Agent running on the host where the session is running, and asks it to verify that the session is still alive.
If the session was alive, VSM Server runs any scripts placed in /opt/thinlinc/etc/sessionreconnect.d. When all such scripts are completed, session information is returned to the client. The client proceeds by contacting the agent on which the session is running.
If the existing session was not alive, or if there were no existing session at all, VSM Server finds out which VSM Agent has the least load, and contacts this agent to request a new session.
When the agent responds that a new session has been created, VSM Server runs any scripts placeed in /opt/thinlinc/etc/sessionstartup.d. When all such scripts are completed, session information is sent back to the client. The client proceeds by contacting the agent on which the session was started.
Scripts in /opt/thinlinc/etc/sessionstartup.d and /opt/thinlinc/etc/sessionreconnect.d are run by the root user, on the VSM Server. Session information will not be sent back to the client until these scripts have completed. This makes it possible to ensure that commands have been run before the client connects to the VSM Agent.
If background execution is desired, place the command to be run in the background and make sure all file descriptors are closed. Here's an example on how to execute a script in the background.
${TLPREFIX}/sbin/tl-limit-printers < /dev/null > /dev/null 2>&1 &
Figure 14.2 outlines what happens when an VSM Agent is contacted by VSM Server to request a new session. In detail, the following happens:
The VSM agent on the machine where the session will reside executes the script /opt/thinlinc/etc/xsession.
The file /opt/thinlinc/etc/xsession is a shell script that can be customized by advanced users. In its standard version, as delivered with ThinLinc, it will check if there is a file named ~/.thinlinc/xstartup in the user's home directory. If there is such a file, it will be executed. If no such file exists, the file /opt/thinlinc/etc/xstartup.default is executed instead. See Section 14.3.3, “ Profiles and the standard xstartup.default file. ” for a description of the standard behaviour of this file.
This system allows for experienced users to customize how their session startup should work by editing the file ~/.thinlinc/xstartup. On the other hand, at sites where users should not be able to customize their system startup, /opt/thinlinc/etc/xsession can be modified so that it doesn't try to execute user-specific xstartup-files. The standard setup should however suit the needs of the majority of installations.
ThinLinc allows for different "profiles" when starting up a user session. The users will be presented with a menu after logging in, where they can choose for example between a desktop suited for engineering users, a desktop suited for the marketing department or a windows desktop. The example configuration files that are delivered with ThinLinc have six alternatives; A KDE Desktop, a GNOME Desktop, a Windows desktop (via a Windows Terminal Server, if existent), an OpenWindows desktop, Common Desktop Environment or a X terminal. Only those sessions that are actually available on the system are displayed. This is just an example configuration, meant to be customized for each individual ThinLinc installation.
As described in Section 14.3.1, “ Session startup - the big picture ”, /opt/thinlinc/etc/xstartup.default is executed if there is no ~/.thinlinc/xstartup for the user. This file, in its unmodified version as delivered with ThinLinc, executes three steps, as outlined in Figure 14.3.
The command tl-run-xstartup.d is executed, which causes all files in /opt/thinlinc/etc/xstartup.d/ to be executed. Files that have filenames ending with .sh will be sourced as shell scripts. Other files are executed normally. This way, environment variables that persist down to the session command can be set in *.sh files.
If a specific execution order is needed for the scripts in the xstartup.d/ directory, let the names of the scripts begin with numbers, where a script with a lower number will be executed before one with a higher number. For example 10setuphomedir will be executed before 20copyfiles.
By default, the script /opt/thinlinc/etc/xstartup.d/03-select-profile.sh will invoke tl-select-profile, to let the user choose among the possible profiles. See Section 14.3.5, “ Configuring available profiles ” for documentation on how to setup profiles. If only one profile is available, tl-select-profile will select it without asking the user. The environment variable TLPROFILE is set to the name of the selected profile.
Worth to note is that the environment variable TLPROFILE is available when running the scripts in xstartup.d, for decisions based on what profile will be run.
The command tl-run-profile is run. This runs the commands associated with the selected profile, for example startkde to start a KDE session.
When the commands run by tl-run-profile exits, xstartup.default runs the command tl-run-xlogout.d which runs scripts and commands located in the directory /opt/thinlinc/etc/xlogout.d. The same information that applies to files in xstartup.d (as documented in 1) applies to files in this directory.
Note
Scripts in /opt/thinlinc/etc/xstartup.d and /opt/thinlinc/etc/xlogout.d are run on the agent, with the same rights as the user owning the session.
If the client has requested that the session should be started with a command supplied by the client, VSM agent will set the environment variable TLCOMMAND to this command. In this case, the profile selection dialog will be disabled and tl-run-profile will execute the command specified by the client, instead of a profile command. To disable client supplied start programs, create the file /opt/thinlinc/etc/xstartup.d/00-no-startprog.sh, containing:
unset TLCOMMAND
The profiles choosable via the tl-select-profile command are configured via Hiveconf, under the /profiles path. An example of a profiles.hconf is listed below. The default parameter must be present, and specifies the default profile. The order parameter selects the order of the presented profiles. Additionally, each profile has several parameters. The description parameter specifies a text that will be presented to the user. The cmdline contains the command to execute, when the profile is selected. Finally, the testcmd parameter controls if the profile should be available or not. If the command listed here exits with a true value, the profile will be available.
[/profiles]
default=kde
order=kde gnome
[/profiles/kde]
description=Linux KDE
cmdline=startkde
testcmd=type startkde
[/profiles/gnome]
description=Linux GNOME
cmdline=gnome-session
testcmd=type gnome-session
This defines two profiles: "Linux KDE" and "Linux GNOME".
Note
All profiles that should be choosable must also be listed in the order variable.
Please read Chapter 17, Building Custom Linux Desktops with the ThinLinc Desktop Customizer for documentation on how to configure different desktops with for example different menu and desktop icons depending on what profile were selected.
If a user has a complicated session startup with many time-consuming operations, it can take quite a while before the user's window environment (for example KDE or Gnome) begins to start. Prime examples of when this happends is when mounting local drives, or when mounting some shared directories from a Netware server.
One way of speeding up this process is to execute some of the operations in the background. Most often, there is no need to mount the local drives before starting KDE, because it takes longer time to start KDE than it takes to mount the local drives. The two operations can easily run in parallell. The same goes for the example of mounting shared directories.
The easiest way to accomplish this is to add an & sign after commands run by scripts in /opt/thinlinc/etc/xstartup.d.
Make sure that commands that must be run before starting the window environment are run sequentially. For example, configuring desktops via TLDC must be done before starting KDE.
Another related tip is to create a file in /opt/thinlinc/etc/xstartup.d that is named something like 00-setbackground and have it set the background, for example by running the xsetroot command. That will look better for users waiting for pre-session operations to finish.
Beginning with ThinLinc 1.4, the client reports the language settings on the client side when requesting a session. This can be used to configure the language on the server side. The idea is that in an environment where several languages are in use, a user could automatically get their preferred language based on what their client computer is configure for.
To activate this, a symlink needs to be created:
# ln -s /opt/thinlinc/bin/tl-set-clientlang.sh /opt/thinlinc/etc/xstartup.d
Also, make sure no other parts of the startup environment is trying to set the LANG variable. For example, on Fedora Core, the files /etc/profile.d/lang.sh and /etc/profile/lang.csh will override the LANG variable set by tl-set-clientlang.sh.
Beginning with ThinLinc 1.4, a utility called tl-clean-sessiondir is shipped with ThinLinc. It is configured at installation or upgrade to be run when a session terminates, and cleans directories under /var/opt/thinlinc/sessions to prevent that old unused session startup logs etc. occupy disk space.
If automatic session directory cleanup is not desired, remove the symlink /opt/thinlinc/etc/xlogout.d/ZZ-clean-sessiondir.
In some situations, it is desirable to force sessions for certain users to be started on a specific agent host. Examples of when this is needed is when testing a new server platform, allowing a group of test users to run their sessions on the new platform, and when configuring desktops with the KDE Kiosk Tool, as described in Chapter 17, Building Custom Linux Desktops with the ThinLinc Desktop Customizer , where you want to end up on the same server every time to make it easier to copy the resulting files to all other hosts.
ThinLinc provides a mechanism for this. By creating a unix group and associate it with a specific agent server, sessions for users that are members of the group will always be created on the agent host in question.
The configuration parameter used for this is /vsmserver/explicit_agentselection. Add pairs of groups and agent hostnames as a space-separated list to this parameter. The names of the groups should be prepended by a + sign, to identify them as groups, if ThinLinc in a future version supports specifying single users in this parameter.
An example:
/vsmserver/explicit_agentselection = +group1:agent1 +group2:agent3
Since only one server can be associated with each group, no load balancing is used. That means that if a user that is a member of group1 requests a session, and agent1 is down, no session will be created.
If a server associated with a group is also listed in /vsmserver/terminalservers, sessions will be created for all users, not only the ones that are members of the group associated with the server. If the server is not listed in /vsmserver/terminalservers, only users in the group associated with the server will have sessions on the server.
At some sites it is a legal requirement that the user must be told when shadowing is in progress. By running the tl-shadow-notify program during the session lifetime, a window will pop up with information about the shadowing whenever shadowing starts or stops.
To activate tl-shadow-notify, a symlink must be created:
# ln -s /opt/thinlinc/bin/tl-shadow-notify.sh /opt/thinlinc/etc/xstartup.d