News, Information and Commentary from the XenApp for UNIX product team
Often when publishing an application in XenApp for UNIX (XAU) it looks different in a desktop. In most cases the reason is the application is looking for properties set on the root window, and when published these properties are not there, so it falls back to it's defaults.
It's easiest to illustrate with an example. Let's say we want to publish the /usr/dt/bin/dtterm application. BTW I did this on Solaris, but the same is applicable to the other O/S's that XAU supports. When you launch this in a seamless session you get this:-
Not quite how it looks in a desktop. The difference as I said is the properties the application reads. You can use the xrdb utility to examine the difference. Type xrdb -query in your published application, and then in a desktop and you will see what I mean. Here is an abbreviated example of what you might see on a desktop:-
busta>xrdb -query
*multiClickTime: 500
*promptDialog.bboard.frame.form.text.columns: 45
*sessionVersion: 3.0
*systemFont: -dt-interface system-medium-r-normal-s*-*-*-*-*-*-*-*-*: *textFontList: -dt-interface user-medium-r-normal-s*-*-*-*-*-*-*-*-*:
Dtfile*view: large_icon
Dtwm*0*FrontPanel*geometry: +20-0
..............................
Dtwm*useSameBackdrop: False
Maxwell*font: -b&h-lucida sans typewriter-bold-r-normal-sans-0-0-72-72-m-0-iso8859-1
Maxwell*fontList: -b&h-lucida sans typewriter-bold-r-normal-sans-0-0-72-72-m-0-iso8859-1
Maxwell*geometry: 979x750+0+0
OpenWindows.BasicLocale: C
OpenWindows.Beep: always
...................
*background: #FFFFF7F7E9E9
*buttonFontList: -dt-interface system-medium-r-normal-s*-*-*-*-*-*-*-*-*:
..............................
*enableUrlAwareness: True
Most of these are not relevant for this application. Knowing what toolkit was used to produce the application can help decide which values are. For example all the dt.... applications are based on the Motif toolkit, and you can consult the Motif user documentation. Running ldd on your application binary will show which dynamic libraries are loaded, if libXm.so is listed this is a good indication that it is Motif based. Failing that you can experiment with the different values used on the desktop and see which make a difference. I've selected the relevant values for dtterm and used them in the script below:-
#!/usr/bin/sh
/usr/openwin/bin/xrdb -merge <<HERE
*textFontList: -dt-interface user-medium-r-normal-s*-*-*-*-*-*-*-*-*: *buttonFontList: -dt-interface system-medium-r-normal-s*-*-*-*-*-*-*-*-*: *systemFont: -dt-interface system-medium-r-normal-s*-*-*-*-*-*-*-*-*:
*background: #FFFFF7F7E9E9
HERE
/usr/dt/bin/dtterm
exit 0
If you now specify this script as the command line when publishing the application you get this:-
Which is much more as you would expect.
As a follow up to Sridhar's post about Future of XenApp for UNIX I'll like to dig a little deeper on what options there are for publishing Linux applications and desktops though the existing Citrix UNIX product offerings.
There are a variety of methods on how this can be achieved and they are all generally variations on the use of XAU/CPSU as a broker to serve the Linux applications/desktops to ICA clients from the environment they are run in.
The simplest way to achieve this is to use separate Linux servers to run the applications/desktops and publish the mechanism to access these on the XAU/CPSU server. Any of the existing platform versions of XAU/CPSU (Solaris x86/x64, Solaris SPARC, AIX POWER or HP/UX PA-RISC) can be used in this method. The publishing mechanism is commonly a shell script that uses remote shell access (eg rsh, ssh) which is made easier if network user accounts are available but this is not a requirement. Other things to think about is session load balancing, if a multi-server XAU/CPSU farm is used to broker session there are advantages to tying individual Linux servers to particular XAU/CPSU servers. If there are differences in the performance characteristics of the Linux servers this can be evened out through XAU/CPSU load balancing tools.
A variation of the above is to make use of Solaris 10 x86/x64 Linux Container technology. This is a capability introduced in Solaris 10 where Linux applications are run in a Linux container on the Solaris 10 system. A Linux Container is effectively a Solaris kernel with Linux kernel interfaces (system calls, /proc, etc) with standard Linux distribution user-land components (utilities, etc) and Sun claims a high-level of binary compatibility with Linux distributions. In this variation XAU/CPSU can be installed on the same Solaris 10 x86/x64 server that hosts the Linux Container and through shell scripting mechanisms already mention access to the Linux applications/desktop can be achieved. Now that Solaris 10 x86/x64 is officially supported on HP, IBM and Dell hardware as well of course on Sun's own x86/x64 hardware there is a range of hardware vendor supported options here.
Another variation is the use one of the x86/x64 server virtualization solutions to virtualize both the XAU/CPSU and Linux servers. The requirement here is the support for both Solaris x86/x64 and Linux x86/x64 virtual machines. The example below shows how it might be achieved with XenServer virtalizing Linux and Solaris 10 servers once Sun completes their paravirtualized kernel and drivers. However, any other server virtualisation technology that can virtualize the Linux and Solaris servers can be used to provide a similar solution.
Options in this area are appearing all the time and and some may well warrant investigation. One recent announcement from Transitive offers capabilities to run Solaris SPARC binaries on Linux x86/x64.
So I hope I have shown there are ways to architect a solution to publish Linux Applications/Desktops with existing XAU/CPSU offerings but do please do tell us what you think.
As a follow up to Carlo's post on XenApp for UNIX, I would like to discuss our future for the UNIX product. XenApp for UNIX is a fully supported, maintained and enhanced product. Since we released Presentation Server for UNIX 4.0, the product has been following an incremental feature delivery model. Since the 2005 release we have added over 80 feature enhancements like seamless improvements, session query utility, enhanced diagnostic logging, roaming user support, adding support for Solaris x86/x64 platform, Solaris SPARC license server, Virtual Channel SDK, Enhanced keyboard and wheel mouse support, Solaris zones support, enhanced server farm publishing options etc. Instead of coming up with a brand new release (like PS for UNIX 4.5 or 5.0), we have opted to get these enhancements as public hot fixes and feature packs. e.g. we added Solaris x86/x64 support when we released PS 4.5 Feature Pack 1. And we will have the next feature pack update for UNIX that will align with the upcoming Delaware release.
The reason for using this delivery model is it speeds up our feature development and helps our customers easily adopt the functionality they need. The customer can install these updates as either hot fixes or as feature packs based on their needs. Of course, you need to be current on SA in order to use the features.
Regarding support for Linux platform, we still don't see a huge market for Linux apps. Also, we might not have native Linux support but some of our customers use XenApp for UNIX as a proxy to serve Linux applications. We will soon have a KB article explaining how you can do that.
