| Citrix receiver on Ubuntu Lucid | ||
|---|---|---|
 | Part I. Miscellaneous subjects (and those still to be sorted) |  |
| Citrix receiver on Ubuntu Lucid | ||
|---|---|---|
| | Part I. Miscellaneous subjects (and those still to be sorted) | |
Loosely following a Citrix Support article, we try to install the Citrix Receiver on Lucid.
Getting OpenMotif
We fetch the OpenMotif RPM the article suggests we fetch:
apprentice@testbox:~$ wget -q http://www.motifzone.net/files/public_downloads/openmotif/2.3/2.3.3/openmotif-2.3.3-1.el5.3.i386.rpm
Then the article suggests we use alien to convert the RPM to a DEB archive.
On a 64-bit Debian however, the resulting package won't be installable, because it's built for the wrong architecture.
Besides, it appears that only very few files from the package are actually needed, and having an alien package in a system always composes something of a risk.
So we don't.
Instead, we convert the pacakge to a tarball:
apprentice@testbox:~$ alien --to-tgz openmotif-2.3.3-1.el5.3.i386.rpm
apprentice@testbox:~$ mkdir unpacked-openmotif-tarball
apprentice@testbox:~$ tar zxC unpacked-openmotif-tarball -f openmotif-2.3.3.tgz
Copying OpenMotif libraries to the system
Now, as luck would have it, the only files from the OpenMotif suite that the Citrix Receiver seems to needs are the Xm libraries.
And it doesn't look for them in the proper places thad /etc/ld.so.conf suggests, but instead it seems to start looking for hardcoded paths, some of which don't even exist on an Ubuntu/Debian system.
This is all very ugly, but we can use it to our advantage: we create one of the nonexisting paths, and we copy the libraries from the unpacked tarball to that directory, where they won't interfere with the rest of the system:
apprentice@testbox:~$ sudo mkdir /lib/i486-linux-gnu
apprentice@testbox:~$ sudo cp unpacked-openmotif-tarball/usr/lib/libXm.so* /lib/i486-linux-gnu/
Installing the Receiver
Through the downloads section of the Citrix page, we fetch icaclient_12.0.0_amd64.deb.
Examining the contents of that file, we see that the client installs to /opt, which goes against the Debian Policy.
And the postinst script is a generic-installer-made-specific that does e.g. its own checks on whether a previously existing version should be overwritten.
This is error-prone, and my guess is that this will just create a big mess when we do apt-get install of an older version over a newer one.
But what the heck, this is just a test, and maybe I'm just too much of a pessimist.
So here goes:
apprentice@testbox:~$ dpkg -i ./icaclient_12.0.0_amd64.deb
(no output except for the EULA question).
Running the client
According to /usr/share/menu/icaclient, the command to run the client is: /opt/Citrix/ICAClient/wfcmgr -icaroot /opt/Citrix/ICAClient.
apprentice@testbox:~$ /opt/Citrix/ICAClient/wfcmgr -icaroot /opt/Citrix/ICAClient
Further testing shows that it actually works: you can run Windows apps from Linux, which then run on the remote system.
But how to configure that client-side is highly dependent on the server(s) and beyond the scope of these notes.
Conclusion: It's ugly. And I wouldn't want to maintain it. But when hacked, it seems to work.
Before this is actually maintainable, a few things need to be done:
It needs to be clear whether really only the Xm libraries are needed by the Citrix Receiver.
We need to be sure that the Citrix Receiver .deb package doesn't violate the Debian Policy or system security/stability. At first sight, I suspect it does.
There needs to be a clean way to install 32-bit libraries on a 64-bit system, e.g. through MultiArch.
The Citrix Receiver binaries need to heed configuration that points them to the proper places for such 32-bit libraries.
In short: the CitrixReceiver needs to adjust to the system it is installed on, instead of demanding that the system be hacked in ugly ways.
| |  | |
| Avahi and domains named “.local” |  | Installing Debian Squeeze on a headless Soekris, using debootstrap |
