As long as your platform fulfills the requirements above, ThinLinc should work as expected. As part of the quality assurance work for each release, ThinLinc is tested extensively on a few platforms. For this release of ThinLinc, the list of such platforms are:

The amount of computer resources needed to run a ThinLinc cluster varies greatly with the number of users, the type of hardware used for the servers, the application mix run by the users and the type of users. Trying to estimate the number of servers needed for a specific cluster is not something that can be done using a predefined table of facts. Instead decisions should be made based on benchmarks and experience.

Below, we will try to give some ideas on what kind of resources are needed based on customer experience. With time and experience from your own cluster with your own application set, you will work out your own set of figures.

It is important to remember that the ThinLinc load balancing feature makes it easy to add another server when the need arises. Start out with a number of servers and add more as the load increases.

Figure 3.1.  A Simple ThinLinc Setup

In Figure 3.1, a very simple ThinLinc setup is shown. In this setup, clients are configured to connect to thinlinc.example.com, DNS is configured with information about what IP addresses correspond to the hostnames thinlinc.example.com, tlagent1.thinlinc.com and tlagent2.thinlinc.com and no firewalls are in the path between the clients and the servers.

The number of VSM agents will range from 1 (on the same host as the VSM server) to a larger number, based on the number of users that are using the system. In this example, there are one host running both VSM server (the software controlling the whole ThinLinc cluster) and VSM agent, and two dedicated VSM agent hosts running only sessions.

Clients will communicate with the servers solely via SSH (by default port 22).

Figure 3.2.  ThinLinc in a Novell Network

In Figure 3.2, ThinLinc is installed in a Novell environment, and integration with Novell eDirectory and/or Novell Netware fileservers are in use.

The ThinLinc servers will need to communicate with the eDirectory servers on either port 389, if using unencrypted LDAP, or on port 636, if using encrypted LDAP (ldaps).

The ThinLinc servers will also need to communicate with the Novell Netware file servers. In the case where NCP is used to access the files, the ThinLinc servers needs to communicate with the Netware servers on TCP or UDP port 524. In the case where NFS is used to access files, UDP port 111, TCP and UDP port 2049 and a range of dynamically allocated UDP ports are used to communicate with the file servers. If there is a firewall between the ThinLinc servers and the Netware file servers, it needs to have support for understanding portmap requests, opening NFS UDP ports on demand, or there can be no restrictions for the traffic between the ThinLinc servers and the Netware file servers.

Figure 3.3.  ThinLinc in a Windows Network

In Figure 3.3, ThinLinc is installed in a Windows environment, and integration with Windows Domain Services and/or Windows Fileservers are in use.

The ThinLinc servers need to communicate with the Windows Domain Controller on TCP port 139.

The ThinLinc servers will need to communicate with the Windows file servers using TCP port 139 and/or TCP port 445.

Figure 3.4.  ThinLinc in a NAT/Split-DNS Environment

At many sites, the internal network is behind a firewall doing Network Address Translation (NAT). This means that the IP addresses on the internal network are allocated from so-called RFC1918 space, i.e., they are within the range 10.0.0.0-10.255.255.255, 172.16.0.0 - 172.31.255.255 or 192.168.0.0 - 192.168.255.255.

As long as ThinLinc servers are only meant to be accessed from the internal network, this is no problem, and the situation will be like the one described in Section 3.3.1, “ A Simple ThinLinc Setup ”. However, if the ThinLinc servers are meant to be accessed from the Internet as well, special arrangements need to be made.

If users are supposed to be able to connect using a web browser, using ThinLinc Web Access, they must be able to connect to port 300 on both the VSM server and on all VSM agents.

In the NAT/Split-DNS setup, relays must obviously be configured in the firewall for each ThinLinc server and the port 300.

In order for ThinLinc to function properly together with the rest of the network, they will need to synchronize time with some internal or external time source. Linux machines use the Network Time Protocol (NTP), so if there is one or several NTP servers on the internal network, the ThinLinc servers will need to communicate with them. Otherwise, the ThinLinc servers should be configured to use some external time source, and should be allowed to communicate with it.

The installation program is located in the root directory of the Server Bundle. Extract the bundle and start the installation program as follows:

sh ./install-server

If you prefer, you can also install the ThinLinc packages by hand. These packages are located in subdirectory packages of the Server Bundle.

After installing the software packages, ThinLinc must be configured. This is done by the program /opt/thinlinc/sbin/tl-setup. If you are running install-server, it will ask you if you want to start tl-setup at the end of the package installation.

# /opt/thinlinc/sbin/tl-setup -g OUTPUT-FILE

# /opt/thinlinc/sbin/tl-setup -a INPUT-FILE

Before performing an upgrade, find out if you need new license files to run the new version. ThinLinc license files delivered with version x.y.z will still work for versions with the same x and y but higher z, but not for increased x or y. For example, license files for ThinLinc 3.1.0 will still work for ThinLinc 3.1.1, but not for ThinLinc 3.2.0 or ThinLinc 4.0.0.

As the new licenses will work with the old (current) version, it's a good idea to install them as the first step in the upgrade process.

The same installation program that you used to install ThinLinc is also used to upgrade it. It is located in the root directory of the Server Bundle. Extract the bundle and start the installation program as follows:

sh ./install-server

and answer the questions. If you prefer, you can also upgrade the ThinLinc packages by hand. These packages are located in subdirectory packages on the Server Bundle.

After upgrading the software packages, ThinLinc must be configured. This is done by the program /opt/thinlinc/sbin/tl-setup. If you are running install-server, it will ask you if you want to start tl-setup at the end of the package upgrade.

The ThinLinc WTS Tools package contains support software for Windows Remote Desktop Servers. This includes:

Installation of the WTS Tools package is easy. Simply execute the tl-wts-tools.exe program from the windows-tools\wts-tools directory in the Server Bundle, and answer the questions.

VirtualGL is used to provide server-side hardware 3D acceleration to applications displayed on a remote client. VirtualGL can be used with ThinLinc to provide accelerated graphics for OpenGL applications running in Linux environment.

Although ThinLinc is designed to work in combination with VirtualGL, VirtualGL is not developed or maintained directly by Cendio AB, and as such is not shipped as a part of the ThinLinc product.

Full documentation regarding the installation and configuration of VirtualGL can be found online at http://www.virtualgl.org/Documentation/Documentation.

For the general case, it should be sufficient to consult the following sections:

And see also:

For more advanced configuration, such as using a remote application server with VGL Transport, see the following sections:

It is important that the CUPS Browsing feature is turned off on all machines in the cluster, or problems with duplicate thinlocal printers will occur.

Configure all printers that need to be available in the CUPS configuration on the machine running VSM Server. Either use distribution-specific tools, or the built-in administration interface in CUPS which can usually be reached by using a web browser, connecting to port 631 on the machine, i.e. http://tl.example.com:631/.

The nearest and thinlocal queues, used by the nearest printer and the local printer features respectively, are added by tl-setup when installing ThinLinc.

Printers, with one exception (see below) only needs to be configured on the machine running VSM Server. Agent nodes will use the CUPS daemon (cupsd) on the VSM Server machine for printing.

The machines in the cluster that run VSM Agent, i.e., the machines that host user sessions, needs a running CUPS daemon (cupsd), but this cupsd only needs one printer defined - the thinlocal queue. The reason for this is that the local printer backend needs to run on the same machine as the session of the user printing to local printer to be able to access the endpoint of the SSH tunnel used to transport the printer job to the client.

The thinlocal queue is added by tl-setup when installing the agent.

When a user submits a job to the local printer, i.e. to the thinlocal queue, the printer job will be submitted to the CUPS daemon running on the VSM Server host. It will then be respooled to the cupsd on the agent server hosting the session. This is to make central configuration of all other printers possible.

With ThinLinc, it is possible to print to a printer attached to the client computer. Two primary modes of operation available: device independent and device dependent. Both modes can be used at the same time. See below for details about the two modes.

The thinlocal printer is cluster-aware. If a user submits a print job on a node in a ThinLinc cluster which does not host the users session, the print job will automatically be respooled to the correct node. This is used in the recommended setup (see Section 5.2, “ Printer Configuration Overview ”.

If a user has more than one session, print jobs submitted to the local printer will be redirected to the client that made the last connection.

The local printer features is implemented as a backend to CUPS (Common Unix Printing System).

The device independent mode is designed to provide universal access to any local printer without having to install drivers on the ThinLinc server. This is achieved by converting the print job to the Adobe Portable Document Format (PDF) on the remote desktop server, and then sending it through an encrypted tunnel to the client. The client subsequently prints the job on the local printer using a built-in PDF renderer.

Because the driver on the ThinLinc server is device independent, it has no way to know what capabilities (duplex ability, trays, paper size, etc.) the printer connected to the client has. At the same time, applications that want to print needs to know about these capabilities to print correctly.

As a compromise, the universal printer is configured with a PPD (Postscript Printer Definition) that covers a broad range of printer capabilities - it's a Generic Postscript Printer driver. This makes it possible for CUPS to convert input formats to the correct format before sending them to the local printer. It also means that default values can be set for some of the configuration parameters, for example paper size, using the CUPS configuration interface.

The device dependent mode is to be used when it is necessary to access all options on the printer, or when the communication with the printer cannot be expressed in terms of normal pages (e.g. a label printer). In this mode the printer driver is installed on the ThinLinc server and the data is sent unmodified to the local printer.

Use tl-setup to install the PDF conversion filter, the backend and queue in CUPS on all machines running VSM Agent. This adds a new queue named thinlocal to CUPS and makes it available to your users. This queue is the one to use for device independent mode described above.

After installation, the local printer is ready for use. Make sure your ThinLinc client is configured to allow redirection of printers, then print to the thinlocal queue, and the job will be rerouted to the default printer of the client you're currently using.

Device dependent queues are installed as if installing the printer locally on the ThinLinc server. The only difference is that the URI shall be specified as thinlocal:/. Example:

# lpadmin -p thinlocal-label -v 'thinlocal:/' -P /media/cd/label-printer.ppd

ThinLinc also includes a very basic form of parallel port emulation that gives legacy application access to the local printer. It is built on top of the thinlocal queue, which means it only works if certain requirements are satisified:

To access the emulated parallel port, configure the application to use the port $TLSESSIONDATA/dev/lp0.

The Nearest Printer system needs information about groups of terminals, known as Locations, which typically represents some physical layout. The information connects Terminals to Locations and also links printers to the Locations. Available printers are automatically fetched from the underlying printing system and are available for assigment to Locations and/or Terminals.

Information about Terminals, Locations and their associated printers can be administrated using the ThinLinc Web Administration, see Chapter 17, Administration of ThinLinc using the Web Administration Interface .

Each Location should be entered with a name, and may have an optional description. A Location can for example represent a classroom, a department, a house, and so on. Each Location can be associated with one or more printers, including the special 'nearest' and 'thinlocal' printers. Typically it will include all printers available near that physical location the Location represents. If the location is so big that different printers are close to different parts of the location, then you should probably divide the Location into smaller parts, each represented by a separate Location.

A Location can be set to handle clients which are not defined using a Terminal definition ("unknown terminals").

Each Terminal in the ThinLinc Web Administration represents one physical terminal in the installation and is defined by its terminal network interface hardware (MAC) address. The hardware address can be entered in many formats, but will be converted to all uppercase hexadecimal form separated by colon, i.e. "01:23:45:67:89:AB".

A Terminal must be associated with a Location.

If a terminal has a printer directly assigned to it in the terminals module in tlwebadm, that printer will be the nearest printer for that terminal. For Terminals without a printer directly assigned (the normal situation), the first printer in the list of printers for the terminal's Location is selected when the user submits a printer job to the nearest queue.

If the client is not a known Terminal, i.e. its hardware address was not found, it will use the printer for the Location marked as handling "unknown terminals". If not, there will be no printer available.

If a user is using multiple sessions, print jobs submitted via nearest printer will be redirected to the printer that is found starting from the client that made the last connection.

When printing via the nearest printer, the CUPS client can't get hold of all information about the real printer where the job will actually be printed, because it doesn't know that the printer job will be rerouted by the nearest driver. Therefore, the printing application has no way to know about the number of trays, the paper sizes available etc.). This is a problem for some applications, and it also adds to the number of applications that will be misconfigured, for example selecting the wrong paper size.

As a compromise, the nearest printer is configured with a PPD (Postscript Printer Definition) that covers a broad range of printer capabilities - it's a Generic Postscript Printer driver. This makes it possible to configure default values for some of the settings, for example paper size, using the CUPS configuration interface.

If all the printers in your organisation are of the same type, it may be a good idea to replace the Generic Postscript PPD installed for the nearest queue with a PPD for the specific printer in use. That will let CUPS-aware applications select between the specific set of features available for the specific printer model.

Each time a user requests a new session or reconnects to an existing session, the hardware (MAC) address of the terminal is sent along with the request from the ThinLinc client. Using the same database as the nearest printer feature used to find which printer is closest to the user, the printer access control feature calculates which printers the user is allowed to use, and then configures the access control of the printing system (CUPS).

This way, the user is presented with a list of printers that only contains the printers relevant for the location where the terminal the user is currently using is located. In a situation where a user has multiple sessions running from multiple clients, all printers associated with the different terminals will be made available.

First, make sure you have configured the printers in your ThinLinc cluster as documented in Section 5.2, “ Printer Configuration Overview ”. For the Printer Access Control Feature, a central CUPS daemon on the VSM Server host is required, and all agent hosts must have a correctly configured /etc/cups/client.conf.

To activate the printer access feature, create two symlinks on the host running VSM Server, as follows:

ln -s /opt/thinlinc/sbin/tl-limit-printers /opt/thinlinc/etc/sessionstartup.d
ln -s /opt/thinlinc/sbin/tl-limit-printers /opt/thinlinc/etc/sessionreconnect.d

The first symlink makes sure tl-limit-printers is run when sessions are started. The second makes sure it is run at reconnects to existing sessions. More details about the session startup can be found in Section 14.4, “ Customizing the User's Session ”.

After creating the symlinks, try connecting to your ThinLinc cluster with a ThinLinc cluster and bring up an application that lists the available printers. The list of printers should now be limited according to configuration.

Configuration of the printer access control feature is mostly a matter of using tlwebadm (see Chapter 17, Administration of ThinLinc using the Web Administration Interface for details) to add the hardware address of all terminals as well as information about where they are located and which printers are to be available for each location.

The automatic redirection of printers to Windows Remote Desktop Servers is enabled by default, but can be disabled by setting /appservergroups/rdp/<appgroup>/redirect_printers to false.

If a user modifies the printer settings for a redirected printer on a Windows Remote Desktop Server, the changes are written to a file named ~/.rdesktop/rdpdr/<printername>/AutoPrinterCacheData.

If changes to printer setttings should be made for all printers, login to the Windows server, make the changes, then wait a few minutes, log out, then copy the generated ~/.rdesktop/rdpdr/<printername>/AutoPrinterCacheData to /opt/thinlinc/etc/rdpdr/<printername>. This must be done for all printers.

The settings file will now be copied to user home directories when tl-run-rdesktop is run. Existing files will not be overwritten, so if printer settings need to be changed, existing files in user home directories must be removed.

In a standard ThinLinc setup, there is a single point of failure - the machine running the VSM server. If the VSM server is down, no new ThinLinc connections can be made, and reconnections to existing sessions can't be established. Existing connections to VSM agent machines still running will however continue to work. A ThinLinc cluster of medium size with one machine running as VSM server and three VSM agent machines is illustrated in Figure 6.1

Figure 6.1.  A non-HA ThinLinc cluster setup

Here the incoming connections are handled by the VSM server which distributes the connections to the three VSM agent machines. If the VSM server goes down, no new connections can occur. The VSM server is a single point of failure in your ThinLinc setup.

In order to eliminate the single point of failure, we configure the VSM server in a HA configuration where two machines share the responsibility for keeping the service running. Note that ThinLinc's HA functionality only handles the parts of your HA setup that keeps the ThinLinc session database syncronized between the two machines. Supplementary software is required, read more about this in Section 6.1.3, “ Theory of Operation ”.

When ThinLinc as well as your systems are configured this way, the two machines are in constant contact with each other, each checking if the other one is up and running. If one of the machines goes down for some reason, for example hardware failure, the other machine detects the failure and automatically takes over the service with only a short interruption for the users. No action is needed from the system administrator.

Figure 6.2.  A ThinLinc HA cluster setup

In a HA setup, as illustrated in Figure 6.2 two equal machines are used to keep the VSM server running. One of the machines is primary, the other one is secondary. The primary machine is normally handling VSM server requests, but if it fails, the secondary machine kicks in. When the primary machine comes online again, it takes over again. That is, in normal operation, it's always the primary machine that's working, the secondary is just standby, receiving information from the primary about new and deleted sessions, maintaining its own copy of the session database.

Both machines have an unique hostname and an unique IP address, but there is also a third IP address that is active only on the node currently responsible for the VSM server service. This is usually referred to as a resource IP address, which the clients are connecting to. ThinLinc does not move this resource IP address between servers, supplementary software is required for this purpose.

In this section, we will describe how to setup a new HA cluster. In the examples we will use a primary node with the hostname tlha-primary and IP address 10.0.0.2, a secondary node with the hostname tlha-secondary and IP address 10.0.0.3, and a resource IP address of 10.0.0.4 with the DNS name tlha.

Your ThinLinc HA cluster is now configured! When sessions are created, changed or deleted on the currently active node, the information about them will be transferred to the other node using a inter-VSM server protocol. If the other node has to take over service, its copy of the session data will be up to date, and it can start serving new requests instantly. When the primary node comes up again, the secondary node will resynchronise with the master.

If you have an existing ThinLinc installation and want to eliminate the single point of failure (the VSM server), the procedure is very much like the procedure for installing a new HA cluster.

If the primary went down because of a minor failure (overheating trouble, faulty processor, faulty memory etc.) and the contents of the files in /var/lib/vsm are untouched, recovery is very simple and fully automatic. Simply start the server and let the two VSM servers resynchronize with eachother.

If a catastrophic failure has occured, and no data on the disks of the primary can be recovered, ThinLinc needs to be reinstalled and HA must be reinitialized.

Install ThinLinc as described in Section 6.2.1, “ Installation of a New HA Cluster ”, but before starting the VSM server after enabling HA in the configuration file, copy the file /var/lib/vsm/sessions from the secondary to the primary. That will preload the database of active sessions with more current values on the primary.

When the ThinLinc client is started it will show the login window. This window contains a ThinLinc logo, text fields where needed information can be entered, buttons for control and at the very bottom a status field that gives information about the login procedure.

Figure 7.1.  The ThinLinc client login window

To login into a ThinLinc server the client needs to do a successful user authentication. This means that it needs to tell the ThinLinc server a user name and a corresponding authentication information (a password or an encryption key). The ThinLinc server controls that the information is valid and accepts or denies the login attempt.

The things the client needs to know to successfully login the user against a ThinLinc server is a server address, a user name and the corresponding authentication information. When the client is normally started it will display two text fields labeled "Server" and "Name", and one text field labeled "Password", "Key" or "Certificate". This can differ some depending on command line arguments, but this is the normal behavior.

Accepted values for the server field is the hostname or the IP address of the server. The name field should be filled in with the ThinLinc username. The authentication information needed depends on the type of authentication used:

The server name, username, key path and certificate name are saved when the user tries to start the session, so they don't have to be entered again each time a new session is wanted.

When the user has entered server address, username and authentication information, it becomes possible to login. This is done by pressing the Connect button or the enter key on the keyboard. The client will then try to establish a connection with the ThinLinc server. If any of the fields has a bad value that prevents the client from successfully logging in, for example if the username or password is incorrect, there will be response message shown as a message box with the suiting information.

If the login attempt is successful a ThinLinc session will start, an old one will be reused or a session selection box might be presented, all depending on the client's settings and how many sessions the user has running, a . See Section 7.4.1, “ Options tab ” for more information on how the choice is made.

Figure 7.2.  The ThinLinc client session selection window

The session selection window presents the user with a list of relevant sessions and several buttons to act on those sessions:

The server will then prepare a graphical session on a ThinLinc server. The client then connects to this session and displays it. Normally the user now sees a dialog with different session options. The user can there select for example to run a Linux session or a Windows session. Depending on the choice the server at the other end will start that kind of session.

The ThinLinc client gets all its strings from a database. This way it can be easily translated, by just providing a new database for a new language.

On Unix based systems, the client picks up which language to use by reading the standard POSIX locale environment variables. A somewhat simplified description of these follow here:

There is also a variable called LANGUAGE on some systems, but it is non-standard, and we do not recommend the use of it.

If none of these variables are set, the locale defaults to C, which in practice means American English. The value of the variables should be of the form language_country, where language and country are 2 letter codes. Currently, the languages delivered with the client are Brazilian Portuguese (pt_BR), English (en_US), Dutch (nl_NL), French (fr_FR), German (de_DE), Italian (it_IT), Russian (ru_RU), Spanish (es_ES), Swedish (sv_SE), and Turkish (tr_TR).

On Windows, the same environment variables can be set in a script that also starts the ThinLinc client. An example script called altlang.cmd is installed with the ThinLinc client for Windows. If nothing is set, the Windows client will use the language setting that was given with the control panel.

When the user has started a ThinLinc session the client login interface disappears from the desktop. The client program continues to run in the background as long as the ThinLinc session is running. The client enters a service mode where it handles services needed to fulfill the requested features. For example the client handles the export of local printers, serial ports, and so on. When the ThinLinc session quits the client service engine quits as well.

There are several ways a session can end. The most common one is that the user chooses to logout from the session. That causes the session to finish on the server side. The ThinLinc server finds out that the session has finished and disconnects the client. Another possibility is to intentionally disconnect the client, without finishing the session on the server. This can be done by using the session menu. See Section 7.1.5, “ The session menu ” below for information about how to do this. When the client disconnects before the session running on the server is told to end, then the session will continue to run on the server. The next time the user logs in the server will reconnect the user to the very same session. This way it's possible to, for example, disconnect a session at work, go home, reconnect to that session and continue to work.

If the user knows that there already is a session running on the server, but still wants to start a new fresh session, then it's possible to check the End existing session check box that exists in the client login interface (advanced mode only). The client will then tell the server that it wants to end the existing session (if it exists) and get a new one.

Network issues or problems with ThinLinc services can sometimes prevent the servers from checking the status of a session. Such a session will be considered unreachable and the client will not be able to reconnect to it. The user can chose to abandon the session or wait for the problem to be resolved. However abandoning the session causes the ThinLinc server to stop tracking it and can leave applications running without any way of reaching them.

When the ThinLinc session is authenticated and the ThinLinc session is running it's possible to control the session. For example it's possible to change between full screen mode and window mode, and to disconnect the ThinLinc client from the server.

To switch to windowed mode there is a session menu that pops up when the user press a predefined key. The default key for this is F8, but the key is configurable from the client options. See Section 7.4.1, “ Options tab ” for more information about how to change this key. In the session menu you should select Full screen to toggle full screen mode.

This feature makes it possible to hear sound from applications that runs on the ThinLinc server. Sound will be sent from the ThinLinc server to your local client through a secure connection. A small local sound daemon will be automatically started by the ThinLinc client. A secure tunnel for sound will be established during the ThinLinc session setup.

All programs that support the Enlightened Sound Daemon (EsounD) or PulseAudio should automatically be aware of this tunnel and send their sound to the client. See also Section 12.3, “ Using Sound Device Redirection ” for information about supporting other applications.

The sound data that is sent from the server session to the local client is uncompressed audio data. This means that it can be relatively large and may use relatively much network bandwidth. This feature should not be used if you plan to use ThinLinc over low bandwidth connections such as modems or ISDN connections.

This feature makes it possible to export two local serial ports to the ThinLinc session. When serial port redirection is enabled, a small redirection daemon will be automatically started by the ThinLinc client during session startup. A secure tunnel for serial port data will be established.

This feature makes it possible to, in a secure way, export one or many local drives from the client machine to the server session. This can be local hard disk volumes, local CD-ROM drives, and so on. The local drive will be made available on the ThinLinc server session.

Each exported device can have individual permission settings. All export settings are made in the ThinLinc client options interface.

This feature makes it possible to export a local printer to make it available from the ThinLinc session. When enabled, the client will setup a secure tunnel for printer jobs. The client will also activate a small built-in print server that listens for printer jobs on this tunnel.

When you print to the special printer queue thinlocal in your ThinLinc session, then the job will be sent through this tunnel and then printed on the client machine. On UNIX platforms, the print job will always be sent to the default printer. On Windows and Mac OS X, it is possible to select whether the print job should be sent to the default printer or if the printer selection dialog should be used every print. Note that device dependent print jobs will always go to the default printer.

For more information about printer redirection in ThinLinc, see Section 5.3, “ Local printer support ”.

This feature makes it possible to export all local smart cards and smart card readers to make them available from the ThinLinc session. All smart card readers available to the system will be exported to the session so there is nothing to configure except an activation switch.

The ThinLinc client relies on the PC/SC interface present on the system to communicate with the smart card readers. If you have a reader that uses another system, then that reader will not be exported.

The Options tab contains general options for the ThinLinc session. This includes settings for which program to execute in the session, shadowing another users session, reassignment of session pop-up key and how reconnections are handled.

Figure 7.3.  Client settings Options tab

The Local Devices tab contains options for which local devices should be exported to the server and in what manner.

Figure 7.4.  Client settings Local Devices tab

The "Screen" tab contains options regarding the session screen. This includes initial screen size, resize behaviour and full screen mode.

Figure 7.9.  Client settings Screen tab

The "Optimization" tab contains various settings that affects the protocols used to transfer the graphic information. This includes algorithm used for the graphic encoding. The best choices may differ from case to case. Factors that affects the algorithm choices can for example be network bandwidth, network latency, and client computer performance.

The default setting is to use the Auto select mode, to automatically select the best suited algorithms.

Figure 7.10.  Client settings Optimization tab

The "Security" tab controls how the client authenticates against the ThinLinc server. The main interface of the client will be different depending on the choices made here.

Figure 7.11.  Client settings Security tab

When running in XDM mode a Control Panel button will be shown in the ThinLinc login window. When this button is clicked the client will show a control panel where the user can control the keyboard, mouse and screen. The reason for this control panel is that the user otherwise has few possibilities to change those settings, since the client runs without any graphical window manager with settings for these options.

The control panel consists of a window with three pages ordered by tabs. One page is used for mouse settings, one for keyboard and one for screen.

7.5.1.1.  Mouse tab

This page contains mouse settings. The user can here control whether the mouse buttons should be setup for left or right hand use. When changed the left and right mouse button change place. The mouse speed has two controls, the mouse acceleration and the acceleration threshold. The acceleration setting controls how much the mouse movements will accelerate when the mouse is moved faster. The threshold controls how fast the mouse needs to be moved before the movement will be accelerated. Acceleration is the phenomena where the mouse pointer is moved more if the mouse is moved fast than if it's moved the same distance slowly.

Figure 7.14.  The control panel mouse tab

7.5.1.2.  Keyboard tab

The keyboard tab contains settings for keyboard repetition. The check box Automatic repetition controls whether a key that is held down should be repeated automatically or not. The other two controls sets the repetition rate and the repetition delay. The repetition rate is the speed of the repetition, how many chars from a held down key that will be written each time interval. The repetition delay controls how long the key needs to be held down before it becomes repeated. A too short delay can be bad since it then becomes possible to write double characters by mistake.

Figure 7.15.  The control panel keyboard tab

7.5.1.3.  Screen tab

The screen tab makes it possible to select between different available screen resolutions. The list of possible resolutions is read from the settings for the current terminal.

Figure 7.16.  The control panel screen tab

On UNIX systems the logfile is located in the home directory for the user that runs the ThinLinc client. The path is ~/.thinlinc/tlclient.log.

On Windows systems the logfile is located in the directory referenced from the %TMP% variable. The value of this variable can be achieved by running any of the following commands in a Windows command window.

C:\> echo %TMP%

or

C:\> set

Observe that some directories in the Windows %TMP% path may be flagged as hidden by the Windows system. This means that you need to change directory options to display hidden files and directories to navigate to the log file.

The ThinLinc client does not use Hiveconf for its configuration. Instead, the Linux and OS X clients uses a plain text format with key/value pairs and the Windows client stores the values in the Windows registry.

Configuration parameters are typically stored in text based configuration files. The format is simple: Each parameter is written on one line, followed by an equal sign (=) and the value of the parameter, as in the following example:

SOUND_ENABLED = 0
SERVER_NAME = demo.thinlinc.com

By using the -C option, additional configuration files can be specified. Any name is accepted, but the file extension .tlclient is recommended. The Windows, Linux, and OS X packages configures the system to automatically recognize such files as configuration files for the ThinLinc Client. Additionally, the Internet Media Type "application-vnd.cendio.thinlinc.clientconf" is linked to such configuration files.

It is possible to add a custom logo to the main ThinLinc client window, making it easily distinguishable from a generic client. The custom logo will be placed to the right of the input fields.

Adding the logo is easy. The new logo must be a PNG file with maximum width and height of 50 pixels. On Windows, just add the file branding.png in the same directory as the executable with the custom logo. On Linux, the file name is /opt/thinlinc/lib/tlclient/branding.png.

This software lets you create customized ThinLinc client installation programs. This means that when users install the customized version, they will automatically get the default settings you have configured.

One advantage with this is that you can provide, for example, a default server name. A custom client can also be used to enhance security: You can distribute SSH host keys with the client itself, so that users don't need to be concerned with SSH host key fingerprint verification.

Before you can start, you have to install the build environment. This is done by running the command tl-4.8.0-client-customizer.exe located in the Client Bundle. This will also create a shortcut to the build directory in the Start menu.

To create a customized client, do the following:

To add your servers SSH host key to settings.reg, do the following:

When the client connects to server, it reports it's hardware address. On Linux, the active interface with the smallest MAC address is used. On Windows, the address of the first interface (as listed in the Control Panel) is used.

The client includes a feature which can periodically check for new versions. This functionality is affected by the configuration parameters UPDATE_ENABLED, UPDATE_INTERVAL, UPDATE_LASTCHECK, UPDATE_MANDATORY, and, UPDATE_URL. These are described in Section 7.7, “ Client configuration storage ”. During an update check, the client retrieves the file specified by UPDATE_URL. An example follows:

WINDOWSINSTALLER = https://www.cendio.com/downloads/clients/tl-latest-client-windows.exe
LINUXINSTALLER = https://www.cendio.com/downloads/clients/thinlinc-client-latest.i686.rpm
DEFAULTINSTALLER = https://www.cendio.com/thinlinc/download
OKVERSIONS = 3.2.0 3.3.0

The OKVERSIONS parameter specifies a list of valid client versions. If the running client version is different, the client will notify the user. The WINDOWSINSTALLER, LINUXINSTALLER, and DEFAULTINSTALLER parameters specifies the updated client packages for Windows, Linux, and other platforms, respectively.

The supported Windows versions are 7, 2008 R2, 8, 2012, 8.1, 2012 R2, and 10. Windows CE is currently not supported.

To install the client on a Windows machine, unpack the Client Bundle and enter the client-windows directory. Then click on the file tl-4.8.0-client-windows.exe and follow the instructions.

The tl-4.8.0-client-windows directory contains an unpacked version of the ThinLinc Windows client. It makes it possible to run the client directly from the bundle, without installing first.

For more information about how to configure the client, read Section 7.7, “ Client configuration storage ”.

During installation the ThinLinc client will be added to the Start menu. To start the client you select it from the Start menu.

The client for Mac OS X can be found in the directory client-osx in the Client Bundle. To install the client, follow these steps:

To start the ThinLinc Client, double click on the client application. The client can also be added to and started from the Dock.

The Alt key (also know as the Option key) behaves very differently on OS X compared to its behaviour on other platforms. It closely resembles the PC AltGr key, found on international keyboards. ThinLinc therefore treats these keys in a special manner on Mac OS X in order to provide a good integration between the client and the remote ThinLinc system.

Whenever either of the Alt keys are pressed, ThinLinc will behave as if AltGr was pressed. The left Command key is used as a replacement for Alt in order to use shortcuts like Alt+F. The right Command key retains its behaviour of acting like the Super/Windows key.

The Linux client is distributed in three different kinds of packages. One that can be installed using the RPM package system, one in the DEB package format, and one in compressed tar archive form for any Linux distribution.

If you need more information than mentioned here, read Section 7.7, “ Client configuration storage ”.

In the instructions below, we will assume that you have unpacked your Client Bundle to ~/tl-4.8.0-clients.

$ cd ~/tl-4.8.0-clients/client-linux-rpm
$ sudo rpm -Uvh thinlinc-client-4.8.0-5456.i686.rpm

$ cd ~/tl-4.8.0-clients/client-linux-rpm
$ sudo rpm -Uvh thinlinc-client-4.8.0-5456.x86_64.rpm

$ cd ~/tl-4.8.0-clients/client-linux-rpm
$ sudo rpm -Uvh thinlinc-client-4.8.0-5456.armv7hl.rpm

$ cd ~/tl-4.8.0-clients/client-linux-deb
$ sudo dpkg -i thinlinc-client_4.8.0-5456_i386.deb

$ cd ~/tl-4.8.0-clients/client-linux-deb
$ sudo dpkg -i thinlinc-client_4.8.0-5456_amd64.deb

$ cd ~/tl-4.8.0-clients/client-linux-deb
$ sudo dpkg -i thinlinc-client_4.8.0-5456_armhf.deb

$ cd ~/tl-4.8.0-clients/client-linux-dynamic
$ sudo mkdir -p /opt/thinlinc
$ sudo cp -a tl-4.8.0-5456-client-linux-dynamic-i686/* /opt/thinlinc/

$ cd ~/tl-4.8.0-clients/client-linux-dynamic
$ sudo mkdir -p /opt/thinlinc
$ sudo cp -a tl-4.8.0-5456-client-linux-dynamic-x86_64/* /opt/thinlinc/

$ cd ~/tl-4.8.0-clients/client-linux-dynamic
$ sudo mkdir -p /opt/thinlinc
$ sudo cp -a tl-4.8.0-5456-client-linux-dynamic-armhf/* /opt/thinlinc/

On Linux and other UNIX systems the client will be installed as /opt/thinlinc/bin/tlclient. The client package contains settings that adds /opt/thinlinc/bin to the path of the users.

To run the client, click on the "ThinLinc Client" icon in your desktop environment. Typically, the icon is found in the Internet category. You can also run the client by executing /opt/thinlinc/bin/tlclient.

ThinLinc has support for running the client on eLux-based thin terminals. This includes the Fujitsu Futro as well as NEXTerminal terminals such as the NEXceed. eLux is a modern embedded operating system which works well.

ThinLinc supports models that uses the eLux RP 5.x operating system. Microphone devices are known to work at least on the Futro models. However, make sure to disable "Sound in XDMCP sessions".

HP ThinPro terminals are based on Ubuntu, and therefore one can use the DEB package provided in our ThinLinc Client bundle for this terminal.

A client package for IGEL Universal Desktop terminals is provided. It is included in the directory client-igel in the Client Bundle. IGEL Universal Desktop is a modern embedded operating system which works well. Some editions includes a bundled ThinLinc client. We do not recommend this client. Instead, install the client as described below.

A client Add-On for Dell Wyse-terminals running "Dell Wyse-Enhanced SUSE Linux" is provided in the Client Bundle, inside the client-wyse/ directory. For instructions on how to install or upgrade this package, please consult the Wyse Linux documentation.

The Dell Wyse client bundled is built and packaged for SUSE Linux Enterprise Thin Client 11 Service Pack 2 (sletc11sp2). Due to limitations of the package metadata, a package can only support one service pack version of SLETC11 at the same time.

The ThinLinc client can be made to run on almost any Linux-based Thin Terminal as well as on some Windows-based appliances. Contact Cendio if you need help on a consultancy basis.

Begin by downloading and unpacking the Thinstation main distribution available from the Thinstation webpages.

Enter the Thinstation directory created while unpacking, and unpack the ThinLinc Thinstation client package, found in the client-thinstation directory in the Client Bundle, into this directory:

$ tar zxvf tl-4.8.0-5456-client-thinstation.tar.gz

This will unpack files into the packages/thinlinc directory, as well as the file README.thinlinc which contains some summarized information on the package.

Edit the build.conf and add a line 'package thinlinc' in the Applications section.

Run the build script and wait for its completion.

If everything went well, there will now be Thinstation images available in the boot-images directory. Use the appropriate boot image for your preferred boot method.

When running on a network-booted Thinstation terminal, the client is configured by adding statements to the configuration file that is downloaded at boot by Thinstation. The default name of this file is thinstation.conf.network, located in your tftproot. There can also be other filenames that configures specific terminals based on their IP or hardware (MAC) addresses.

SESSION_0_TYPE=thinlinc
SESSION_0_THINLINC_SERVER=demo.thinlinc.com
SESSION_0_THINLINC_OPTIONS="-u user -c"
SESSION_0_THINLINC_CONFIG_NFS_SERVER_ENABLED=0

SESSION_0_THINLINC_CONFIG_NFS_SERVER_ENABLED=1
SESSION_0_THINLINC_CONFIG_SOUND_ENABLED=1

SESSION_0_THINLINC_CONFIG_NFS_EXPORTS=/mnt/usbdevice,rw,/mnt/cdrom,ro
SESSION_0_THINLINC_CONFIG_NFS_SERVER_ENABLED=1
SESSION_0_THINLINC_CONFIG_SOUND_ENABLED=1
SESSION_0_THINLINC_CONFIG_NFS_ROOT_WARNING=0

It is possible to launch the native ThinLinc client from a web page. The process works like this:

<VirtualHost _default_:443>
	    ServerName catchall.example.com
	    ServerAlias *
	    ...

The launch file delivered to the client is generated from the template /opt/thinlinc/etc/tlclient.conf.webtemplate. The CGI script performs some substitutions on this file, before sending it to the client. Currently, the following variables are substituted:

The CGI script tlclient.cgi is used to start the native client, when launched from a web page. It accepts many parameters which affects its operation. These are described below:

To make it easier to test various parameters, the HTML file cgitest.html is included, in the same location as tlclient.cgi. It also demonstrates how to create icons on web pages, which launches ThinLinc sessions.

ThinLinc Web Access is a ThinLinc client that runs in modern browsers. This web application is based on the Open Source project noVNC. It uses HTML5 features such as WebSockets and Canvas. We have tested the latest versions of following browsers:

		$ sudo /opt/thinlinc/etc/tlwebaccess/make-dummy-cert `hostname --fqdn`

PAM is configured by editing the files located in the directory /etc/pam.d/ (at least in the distributions we've tested ThinLinc on).

Different Linux distributions have slightly different ways of configuring PAM. The ThinLinc installation program will setup ThinLinc to authenticate using the same PAM setup as the Secure Shell Daemon, by creating a symbolic link from /etc/pam.d/thinlinc to either /etc/pam.d/sshd or /etc/pam.d/ssh, depending on which of the latter files that exists at installation. This seems to work on most distributions. Be aware that the PAM settings for the Secure Shell Daemon might really be somewhere else. For example, on Red Hat distributions, the file /etc/pam.d/system-auth is included by all other pam-files, so in most cases, that is the file that should be modified instead of the file used by sshd.

Public key authentication is a more secure alternative to passwords. It uses a challenge/response mechanism that prevents even the server from gaining access to the authentication information. This section will describe how to configure ThinLinc to use it.

In order to use public key authentication, a pair of encryption keys must be generated. Tools to accomplish this should be included with the SSH server. On Linux, that server is normally OpenSSH and the tool to generate keys is called ssh-keygen.

Example:

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/test/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/test/.ssh/id_rsa.
Your public key has been saved in /home/test/.ssh/id_rsa.pub.
The key fingerprint is:
e1:87:0d:82:71:df:e9:4a:b0:a8:e3:cd:e8:79:58:32 testuser@example.com

Remember that the private key (id_rsa in the example) is a password equivalent and should be handled with care. The public key (id_rsa.pub in the example) does not need to be kept secret.

All SSH servers must support public key authentication, so any SSH server will work. It is important, however, to verify that public key authentication is not disabled. Refer to the documentation for your SSH server for instructions on how to do this.

Next, the public keys need to be associated with the correct users. For OpenSSH, you must store a copy of the public key in the users' home directory, specifically in the file ~/.ssh/authorized_keys. This file can contain multiple keys, each on a separate line.

The client must have a copy of the private key associated with the public key stored on the server. The key can be stored anywhere, although on UNIX it is commonly stored as ~/.ssh/id_rsa. The user will be able to specify where the key is located in the ThinLinc Client interface.

Smart card public key authentication is an advanced version of the method described in Section 9.3, “ Using Public Key Authentication ”. It uses the same basic principle but stores the private key on a smart card, where it can never be extracted. This section will describe how to configure ThinLinc to use it.

The keys on the smart card are generated when the smart card is issued. How this is done is not covered by this guide.

To use a smart card with ThinLinc, the public key must be extracted off the card and associated with a user on the ThinLinc server. The method for doing this depends on your smart card and your SSH server.

On Linux, with the OpenSSH server and an PKCS#15 compliant smart card, the tool pkcs15-tool (part of the OpenSC suite) is able to extract the public key.

The first step is identifying the certificate on the card:

# pkcs15-tool --list-certificates
X.509 Certificate [identification]
        Flags    : 0
        Authority: no
        Path     : 3f0050154331
        ID       : 45

The second step is to extract the key, based on the ID number:

# pkcs15-tool --read-ssh-key 45
1024 65537 918282501237151981353694684191630174855276113858858644490084487922635
27407657612671471887563630990149686313179737831148878256058532261207121307761545
37226554073750496652425001832055579758510787971892507619849564722087378266977930
9875752082163453335538210518946058646748977963861144645730357512544251473818679
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCCxIx/xtVoDR2qwY4Pym7F6yKmdJsB26MUbbTiGT7o
6M6G4A2l5Go1kdQRNjOWDJE9HZWToaApSkVprNeiQLeOkbELz2yND2Te/Oyl3u44YeIUImT1v4t7q9jC
MTpfZ+TpxLf0sd3DAk2So8EBAtUkhib/ugKqfTCqB7WNoHf0Nw==

The second line, starting with "ssh-rsa", is the one needed for SSH version 2 authentication. For instructions on how to associate this key with a user, see Section 9.3, “ Using Public Key Authentication ”.

The ThinLinc client requires no special configuration to use the smart card.

The client is able to automatically connect to the server when a smart card is inserted (see Section 7.4.5, “ Security tab ”). It does, however, require that the user is able to log in using the subject name on the card. As that is rarely a valid user name, ThinLinc ships with a special NSS module, called nss-passwdaliases, that enables alternate names for users.

The module is configured by editing the file /etc/passwdaliases. The file is a colon-delimited table of alternate names and their corresponding user ids. Example:

givenname=John,sn=Doe,c=us:572

To activate the nss-passwdaliases module, it must be added to the list of NSS modules for the passwd database. This is specified in the file /etc/nsswitch.conf. For example, replace the following line:

passwd: files ldap

with this line:

passwd: files ldap passwdaliases

ThinLinc includes the tool tl-ldap-certalias that can automatically update the local databases needed for smart card public key authentication, provided the system uses the OpenSSH server (or any SSH server that uses a compatible format and location for authorized public keys) and standards compliant LDAP servers where users and certificates are stored.

The tl-ldap-certalias command can also perform validation of certificates it finds in LDAP databases. Read more about this in Section 9.4.7.3, “ Certificate validation ”.

After deployment, tl-ldap-certalias is meant to be run from cron at regular intervals, for example every 15 minutes. This makes sure that the ThinLinc system automatically keeps all user certificates updated. However, please note that if you're using certificate validation, downloading and parsing certificate revocation lists may take a long time (up to 5 minutes each). This is mitigated by caching the data from the CRL:s, but the first run and whenever the CRL needs to be updated may take a long time. Thus, if you have certificates from a lot of different certificate authorities, don't run tl-ldap-certalias too often.

Since the default use of this tool is to be run from cron, the default behaviour is to produces no output other than error messages. If you want more output from tl-ldap-certalias, see options in Section 9.4.7.1, “ Command line options ”.

In this section, we will describe how to configure ThinLinc for authentication against One Time Password (OTP) servers, such as the RSA SecurID. By using OTPs, you can increase the system security.

This section describes how to deploy a OTP solution based on RSA SecurID with ThinLinc. When using this solution, the SecurID PASSCODEs are used instead of normal passwords. The PASSCODE should be entered in the ThinLinc client password input field. Please observe the following limitations:

The configuration example below assumes that you are using LDAP and RADIUS, and the Steel-Belted Radius (SBR) server. Step 8 through 11 should be repeated on all ThinLinc servers.

This chapter describes how to setup a ThinLinc server to access Windows file servers via the SMB/CIFS protocol. CIFS is a modern version of SMB. In this document, we use the term CIFS, but the procedure described in this documentation works for SMB servers as well.

CIFS is different from NFS in that CIFS mounts are per user, not per system. For example, with NFS, it's possible to mount all network file systems when the server boots. One NFS mount can be used by all users on the system. With CIFS, each user must have their own mounts. Also, when mounting a CIFS file system, the password of the user is usually required.

ThinLinc and many other UNIX applications requires that hard links are supported in the user's home directory. There are often other POSIX file system semantic requirements as well. This means that the user's home directories cannot be a mounted CIFS filesystem. The Linux CIFS client (smbfs) does not support all POSIX file operations, such as hard links. The newer CIFS client (cifsfs) supports the CIFS UNIX extensions, but few CIFS servers support this and this feature has not been tested with ThinLinc.

ThinLinc includes two utility programs for dealing with CIFS mounts: tl-mount-cifs and tl-umount-all-cifs . These are described below.

The method described in this chapter mounts all CIFS shares below the directory ~/winshares. The user's CIFS home directory, if any, is mounted at ~/winshares/home.

When accessing directories from CIFS and NCP servers, these are mounted in subdirectories of the users UNIX home directory. It is not possible to place the UNIX home directory on a CIFS or NCP server, since these typically does not support the necessary POSIX file system semantics (such as hard links). In a typical setup, applications such as Mozilla uses the UNIX home directory for settings (~/.mozilla), while the user saves documents in ~/MyDocuments. In this case, it might be desirable to restrict access to the UNIX home directory: Forbid saving arbitrary files to it. This can be solved by using a feature of ThinLinc called homecreatefilter .

To activate homecreatefilter , create a symbolic link in the xstartup.d directory:

# ln -s /opt/thinlinc/libexec/tl-homecreatefilter.sh /opt/thinlinc/etc/xstartup.d/06-tl-homecreatefilter.sh

The configuration file /opt/thinlinc/etc/homecreatefilter.conf controls which files and directories are allowed. By default, all files starting with a dot are allowed, as well as the files necessary for KDE to start.

The configuration file is line based. A line not starting with a colon specifies a file object pattern that should be allowed. A line starting with a colon specifies a command line pattern. Processes matching this pattern will also be allowed write access, even if no file object pattern allows access.

The homecreatefilter feature is based on the LD_PRELOAD mechanism, which means it does not support statically linked applications. Since environment variables can be modified by the user, the user can disable the filter at will. homecreatefilter should not be regarded as a security mechanism, but rather a mechanism that prevents the user from saving documents to the UNIX home directory by mistake.

In addition to the home directory, homecreatefilter restricts write access to the ~/Desktop directory.

ThinLinc provides Single Sign-On functionality into the Windows Remote Desktop Server using either password or smart card authentication. It is required that your ThinLinc servers are integrated with your Windows infrastructure so that user authentication shares the same source on both Windows and ThinLinc.

If requirements mentioned above are met, Single Sign-On works out of the box with one exception regarding smart card and CredSSP which is documented in the following section.

If your Windows Remote Desktop Server is configured to explicitly only allow CredSSP authentication level, ThinLinc needs to know a provide name for your smart card Crypto Service Provider (CSP). The provider name is configured per application server group and is added to rdesktop_args configuration value like the example below. See Section 14.2.4, “ Parameters in /appservergroups/ ” for more information.

rdesktop_args=-o sc-csp-name="CSP Provider Name",

To obtain the provider name of your Crypto Service Provider (CSP) make sure that your smart card driver are installed on your Windows server. Open regedit and find the following registry key, HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider. In this container you will find a list of CSP providers registered with the system, find the matching provider for your smartcard and use the key name as the CSP Provider Name.

Sometimes it's useful to run a Windows desktop in a window. This mode resembles many virtulization solutions. The distinction between the Windows and UNIX environment is obvious. Connections of this type can be made by using the tl-run-rdesktop command.

In this mode, the Windows desktop fully replaces the UNIX desktop. The UNIX environment is completely hidden. Connections of this type can be made by using the tl-run-windesk command.

The Standard Mode provides a limited form of application publishing. No extra software on the Windows server is required. Typically, connections of this type are created with a command such as: tl-run-winapp -D -T Excel excel.exe. When using this mode, please note:

For more information about tl-run-winapp, see the tl-run-winapp details in Chapter 13, Commands on the ThinLinc Server .

This mode makes it possible to publish applications "seamlessly", and allows for full integration with the desktop. The remote applications can be moved, resized and restacked. Support for non-maximized and multi-window applications is provided. When using the SeamlessRDP mode, the "WTS Tools" package must be installed on all Windows Remote Desktop Servers. The installation is described in Section 3.7, “ The ThinLinc WTS Tools Package ”. Typically, connections of this type are created with a command such as: tl-run-winapp-seamless c:\program\mozilla.org\mozilla\mozilla.exe http://www.cendio.com. When using this mode, please note:

For more information about tl-run-winapp-seamless, see the tl-run-winapp details in Chapter 13, Commands on the ThinLinc Server .

Using ThinLinc, it is possible to access the clients' drives and filesystems from the ThinLinc session. With thin terminals, one might want to access a local CD-ROM drive. When running the client on a workstation, applications on the remote desktop server can access all filesystems mounted at the workstation, just like local applications can.

The exported local drives can be mounted with the command tl-mount-localdrives . The drives will be mounted below $TLSESSIONDATA/drives. A symbolic link called "thindrives" will be created in the user's home directory, pointing to this directory. The syntax for tl-mount-localdrives is:

The -v option causes the tool to be executed in verbose mode, while -h shows the syntax.

The Hiveconf parameter /utils/tl-mount-localdrives/mount_args specifies the mount arguments. This Hiveconf parameter is normally found in /opt/thinlinc/etc/conf.d/tl-mount-localdrives.hconf. The options mountport, port, mountvers, nfsvers, nolock, and tcp will always be used.

Mounted local drives can be unmounted with the command tl-umount-localdrives .If some applications are using a mount at this time, they can continue to access the mount, even though the mount has been removed from the filesystem hierarchy (so called "lazy" umount). The syntax for tl-umount-localdrives is:

If -a is specified, then all mounted local drives, for all users on this machine, will be unmounted. If -s is specified, then all mounted local drives, for all sessions belonging to the current user, will be unmounted. If -l is specified, the thindrives link will not be updated.

Access to the Local Drives via RDP requires no extra configuration. Sessions started with tl-run-rdesktop (and associated commands) will automatically have the local drives redirected.

Often, it's convenient to automatically mount all local drives for a user when the session starts. This is done by default via a symbolic link in /opt/thinlinc/etc/xstartup.d, pointing at /opt/thinlinc/bin/tl-mount-localdrives. This link is created for you during installation, as well as its counterpart in /opt/thinlinc/etc/xlogout.d which points to /opt/thinlinc/bin/tl-umount-localdrives.

Using ThinLinc, it is possible to access the serial ports of the client from the ThinLinc session. This means that you can utilize peripheral devices which connect through a serial port, such as digital cameras, PDAs and modems. Up to two serial ports are supported at a time.

Serial port redirection is activated (for the current user session) by sourcing the file tl-serial-redir.sh. It can be done manually with this command:

$ source /opt/thinlinc/libexec/tl-serial-redir.sh

It is necessary to source this file, because it sets the environment variables CYCLADE_DEVICES and LD_PRELOAD. Thus, all applications needing serial port access should be started as a subprocess to this shell. The easiset way to accomplish this is to source tl-serial-redir.sh from the session startup scripts. To automatically activate serial port redirection at login for all users, execute this command:

# ln -s /opt/thinlinc/libexec/tl-serial-redir.sh /opt/thinlinc/etc/xstartup.d/42-tl-serial-redir.sh

When using redirected serial ports, applications should be configured to use a special, personal device-file, instead of a port such as /dev/ttyS0. The two device files are called $TLSESSIONDATA/dev/ttyS0. and $TLSESSIONDATA/dev/ttyS1.

With ThinLinc, it is possible to access the client's sound device from the ThinLinc session. This means that you can run sound applications on the remote desktop servers and listen to the sound through the client's sound device and speakers. Input devices such as microphones can also be used.

ThinLinc can support sound redirection for almost all applications, provided that the correct libraries and utilities are installed on the ThinLinc server.

padsp <application>

esddsp -m <application>

$ ldd /usr/bin/someapp
        not a dynamic executable

mkdir /tmp/.esd
touch /tmp/.esd/socket

pcm.!default {
    type pulse
}
ctl.!default {
    type pulse
}

It is possible to use sound redirection with applications running on Windows Remote Desktop Servers, via RDP. This is controlled by the parameter /appservergroups/rdp/<group>/sound . For more information, please refer to Section 14.2.4, “ Parameters in /appservergroups/ ”.

To use input devices with applications running on Windows Remote Desktop Servers, it is necessary to use the ThinLinc WTS sound driver. See Section 3.7, “ The ThinLinc WTS Tools Package ” for more information.

Using ThinLinc, it is possible to access the locally connected smart cards and smart card readers from the ThinLinc session. This means that you can use smart cards for encrypting your email, signing documents and authenticing against remote systems.

Smart card redirection is always activated on the server so there is no administration required to enable it.

When configuring ThinLinc servers as a cluster, there are two main configuration options which need to be set, one on the master and one on the agent(s):

Once the two parameters above have been configured, and the vsmagent and vsmserver services have been restarted, these ThinLinc servers will then function as a cluster.

When multiple agents have been configured as part of a cluster, it is usually desirable to keep their configurations synchronised. Instead of making the same change seperately on each agent, ThinLinc ships with the tool tl-rsync-all to ensure that configuration changes can be synchronised easily across all agents in a cluster. See Chapter 13, Commands on the ThinLinc Server for more information on how to use this tool.

The tl-rsync-all command should be run on the master server, since it is the master which has a list of all agents in the cluster (in /vsmserver/terminalservers ). For this reason, it is often useful to configure the master server as an agent as well, even if it will not be used to host user sessions in general. This allows the master to be used as a "template" agent, where configuration changes can be made and tested by an administrator before pushing them out to the rest of the agents in the cluster. In this way, configuration changes are never made on the agents themselves; rather, the changes are always made on the master server, and then distributed to the agents using tl-rsync-all.

An example of how one might implement such a system is to configure the master server as an agent which only accepts sessions for a single administrative user. The steps to do this are as follows:

In this way, configuration changes are never made on the agents themselves; rather, the changes are always made on the master server, and then tested by logging in as the tladmin user. If successful, these changes are then distributed to the agents using tl-rsync-all.

In this section, we will describe all the parameters currently used by the VSM agent.

In this section, we will describe all the parameters currently used by the VSM server.