|C H A P T E R 5|
Hotdesking (Mobile Sessions)
|Note - The Sun Ray system is designed to enable session mobility, or hotdesking, with smart cards. Every Sun Ray DTU is equipped with a smart card reader. Non-Smart Card Mobility is implemented only on Solaris platforms.|
Regional hotdesking can be enabled by means of multiple failover groups. Multiple failover groups are useful for various reasons, such as:
It is sometimes advantageous to have multiple, geographically-separate locations, each with a failover group, so that if an outage occurs at one location, another location can continue to function.
Some sites have different administrative policies at different locations. It can be advantageous to keep separate failover groups at these locations.
Regional hotdesking, sometimes referred to as Automatic Multi-Group Hotdesking (AMGH), is useful when an enterprise has multiple failover groups and users who move from one location to another who wish to gain access to their existing session wherever they roam. The following sections describe regional hotdesking. For further technical detail, please refer to the utamghadm(8), ut_amgh_get_server_list(3), and ut_amgh_script_interface(3) man pages.
|Note - Regional hotdesking is not enabled for multihead groups.|
Once regional hotdesking is configured, user login information and sessions are handled as follows:
1. When a smart card is inserted or removed from the system or a user logs in via the greeter GUI, parameters such as the user name (if known at the time), smart card token, and terminal identifier are passed to a piece of site-integration logic.
2. The site-integration software uses these parameters to determine to which Sun Ray servers it should direct the Sun Ray DTU.
3. If the smart card token is associated with a local session, then that session gets preference, and regional hotdesking is not invoked.
4. Otherwise, the regional hotdesking software redirects the Sun Ray DTU to connect to the appropriate Sun Ray server.
Thus, if the user has an existing session, the DTU connects to that session; if not, the regional hotdesking software creates a new session for that user.
To utilize regional hotdesking, a site must provide some site integration logic that can utilize enterprise data to determine which users or Sun Ray DTUs should connect to which failover groups. This is ordinarily provided through the use of a dynamic C library or a shell script that implements a particular interface used by regional hotdesking software. SRSS provides some reference code that a site administrator can use as an example or adapt as required. An administrator must configure the regional hotdesking software to utilize a specified library or shell script, then implement the PAM stack of the login applications, as described below.
|Note - To ensure continuous operation, the be sure to include enough servers in the target group to provide availability for session location and placement in the event that a particular server becomes unavailable. Two servers should be minimally sufficient for most sites; three servers provide a conservative margin of error.|
To determine where given Sun Ray DTUs or users should be connected when creating or accessing sessions, the administrator must utilize enterprise data. Sun Ray Server Software 4.0 includes for this purpose:
The administrator for each site must determine what mapping library to use. It may be a site-specific implementation, as described above, or one of the sample implementations provided with the SRSS software.
Use the /opt/SUNWut/sbin/utamghadm command to configure the regional hotdesking software to use this library.
1. To configure the token-based mapping implementation provided as a sample, execute the following:
2. To configure the user name-based mapping implementation provided as a sample, execute the following:
3. To configure a script-based back-end mapping (for example, the token-and-user name-combination-based mapping sample), use the -s option to this command:
4. Do a cold restart of the SRSS services using either the utrestart CLI or the Admin GUI.
To utilize token readers with regional hotdesking based on Sun Ray pseudo-tokens, use the Site-specific Mapping Library to produce the desired behavior for them.
Configured token readers should have the following value formats:
|Note - If a registered policy is in place, use the insert_token key instead of the token key, which is not globally unique.|
Each site must configure a data store to contain site-specific mapping information for regional hotdesking. This data store is used by the site mapping library to determine whether regional hotdesking should be initiated for the parameters presented. The data store can be a simple flat file. The sample implementations included with the SRSS require a simple flat file configuration.
Create the back-end database file under /opt/SUNWutref/amgh/back_end_db on the Sun Ray server:
a. For a token-based mapping, use entries of the form:
b. For a user name-based mapping, use entries of the form:
c. For a combined mapping, use entries of the form:
A sample line for this file would look like the following:
1. To disable AMGH configuration for a group, run the following command:
2. Do a cold restart of the SRSS services using either the utrestart CLI or the Admin GUI.