Multisession Workstations

Press F1 for bash, F2 for Windows, F3 for Ubuntu, F4 for Mac OS and F5 for Citrix. Linux makes it all possible, and you don't even need a hard drive!

Connecting to Citrix

Go to the Citrix Web site, look for the XenApp Linux client and
download it. Copy the downloaded file into your chroot system. In your
chrooted session, untar the Citrix client file.
After decompression, you should have a new folder named linuxx86 and a few
extra files,
including the install script called setupwfc. To install, as root, execute
./setupwfc, and answer the text wizard questions. You
may have to fill in some dependencies for your distro, but after a few
moments, your LTSP image will be Citrix-enabled.

The Citrix server configuration is beyond the scope of this article. You
should start with a working Citrix XenApp Server. The good news is that you don't
even need to be one of the Citrix server administrators at your company,
you just need to have the user name and password for an account with
published applications on the server. In other words, if you already
have access to a desktop or an application via Citrix, you can set up
that connection as one of the screens on your multisession terminal server.
Simply log in to your Citrix session as a regular user and download the
session definition ICA file (Figure 5). ICA files are actually text files
that contain the information and settings to establish a connection
to a XenApp server. The easiest way to download this file is to right-click on one of the icons displayed on your Citrix server Web interface
and select Save link as.

Figure 5. Citrix ICA File Download from Web Interface Icon

Once you have your ICA file, copy it to the Citrix client install
directory on your chroot session:

Notice that XenApp is the new name for the Citrix presentation
server, so any Citrix server XenApp or presentation server will work.

Finally, exit your chroot session and add the new screen parameter for the
citrix1 script in your lts.conf file. It should look like this:

[default]
...
SCREEN_05 = citrix1

Now you can rebuild your LTSP image with the
ltsp-update-image
command, and test the Citrix session on your PXE boot client when you
press Ctrl-Alt-F5.

Connecting to a Windows Terminal Server

The rdesktop client and script are included in the LTSP install
package, so you won't have to create scripts or install new
packages. All you need to do is include their screen parameters in
the lts.conf file. Your final file should look like this:

This time, you don't need to run ltsp-update-image. When you use
the /var/lib/tftpboot/ltsp/i386/lts.conf file, it's read directly
from the server and not from the ltsp-image. Be aware that there
is another lts.conf file inside the chroot directory; avoid using that one.

Stopping the Screen Takeover Problem

If you've tested each step of your progress, you surely know by now
that sometimes different “screens” suddenly take over the
monitor output. They seem to be fighting each other to be top dog.
This is not a bug. It happens when a remote session login
screen timeouts. Windows and Citrix wait patiently for your
login credentials, but after some inactivity time, they drop your
connection. When this happens, X dies. Then your LTSP terminal
restarts X and restarts the connection.
This pulls the visible screen to the newly started X screen,
taking over the monitor output.

To avoid this effect, you need to log in to all of your available
sessions. Logged-in sessions also have timeouts, but they are much longer.

The simplest solution is based on an idea I found in an older version
(from LTSP 3.0) of the rdesktop script.
The script included a “read” statement just before the xinit call.
That way, users had to press a key to start their rdesktop session.
You can use that same approach. It's not fancy, but it works.

A more stylish solution is to use zgv to show a
picture just before the session start line.
zgv closes when users press the Enter or Esc key.
Remember to add a “Press Enter to start” banner to your image.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.