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.
Once you have your ICA file, copy it to the Citrix client install directory on your chroot session:
$ cp my-ica-file.ica /usr/lib/ICAClient/desktop.ica
Now, let's create the screen script for the Citrix session in /usr/share/ltsp/screen.d. We'll call this script citrix1:
#!/bin/sh # Copy the ica file to a temp file because # wfica deletes the file on execution. cp /usr/lib/ICAClient/desktop.ica \ /usr/lib/ICAClient/temp-file-desktop.ica sudo xinit /usr/lib/ICAClient/wfica \ /usr/lib/ICAClient/temp-file-desktop.ica
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.
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:
[default] VNC_OPTIONS = "-FullColor -passwd /usr/share/ltsp/vnc-passwd" VNC_SERVER = your.mac.ip.address RDP_OPTIONS = "-a 16" RDP_SERVER = your.windowsTS.ip.address SCREEN_01 = shell SCREEN_02 = rdesktop SCREEN_03 = ldm SCREEN_04 = vnc1 SCREEN_05 = citrix
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.
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- Shashlik - a Tasty New Android Simulator
- Purism Librem 13 Review
- diff -u: What's New in Kernel Development