AdSense Mobile Ad

Thursday, June 3, 2010

Installing Sun Ray Server Software on OpenSolaris 2009.06

Overview

Yesterday I received my first Sun Ray client and was looking forward to trying. The Sun Ray client is a display device which can be connected to a remote OS instance in basically two ways:
  • Using the Sun Ray Server Software.
  • Using Sun Virtual Desktop Infrastructure.

The Sun Ray client I'm using is a Sun Ray 2, which is a very low power device (about 4W), equipped with the following ports:
  • 1 DVI port
  • 1 serial port
  • 1 Ethernet RJ45 port

Sun Virtual Desktop Infrastructure (VDI) is a connection broker which gives Sun Ray devices access to a supported operating system such as Sun Microsystems' Solaris, Linux or Microsoft Windows which must be executed by one of the virtualization technology supported by VDI:
  • VirtualBox.
  • VMWare.
  • Microsoft Hyper-V.

Sun Ray Server Software (SRSS), on the other end, is a server software available for Solaris and Linux which gives Sun Ray clients remote access to an UNIX desktop session. Since we're only running Solaris on our machines, Sun Ray Server Software and Sun Rays are the quickest way to go to provide a low cost and effective desktop to all of our users.

Prerequisites

Solaris' SRSS prerequisite are very simple: Solaris 10 05/09 or newer. That's where fun begins. Sun Ray Server Software is supported on Solaris 10 but not (yet) on OpenSolaris. We'll be running Solaris 10 on our production environment but, for this proof of concept, I tried to use an already existing OpenSolaris virtual machine (OSOL 2009.06 upgraded to b134 from /dev) running on VirtualBox on a Mac OS X host. Taking into account the problems I've had in the past trying to run software supported on Solaris 10 (such as Sun Java Enterprise System) on OpenSolaris, I seriously considered installing a Solaris 10 VM and get rid of all those problems that are a direct consequence of the great job the OpenSolaris developers are doing (especially package refactoring and changes to Xorg installation paths.) At the end, curiosity kills the cat and now SRSS is running on OpenSolaris.

Installation Steps

First of all, download SRSS. You'll just need the following files:
  • Sun Ray Server Software 4.2.
  • Sun Ray Connector for Windows Operating System (only if you want to connect your Sun Ray client to a Windows operating system instance.)

Unzip SRSS on a temporary location on your Sun Ray server:

# unzip srss_4.2_solaris.zip

I will refer to this path as $SRSS from now on.

Bundled Apache Tomcat for the Sun Ray Admin GUI

If you plan to use the Sun Ray Admin GUI you should install a suitable web container (Servlet 2.4 and JSP 2.0 are required.) SRSS is bundled with Apache Tomcat which you can use to run the Admin GUI:

# cd $SRSS/Supplemental/Apache_Tomcat
# gtar -xvv -C /opt -f apache-tomcat-5.5.20.tar.gz

Please note that GNU tar is required to extract the Apache Tomcat bundle.

Since the default Apache Tomcat installation path used by SRSS is /opt/apache-tomcat you'd better make a symlink to your Apache Tomcat installation path:

# ln -s /opt/apache-tomcat-5.5.20 /opt/apache-tomcat

Installing SRSS

To launch the installation script for SRSS just run:

# $SRSS/utinstall

The script will just ask you a few question. Be ready to provide the following:
  • JRE installation path.
  • Apache Tomcat installation path.

From now on, the SRSS installation path (/opt/SUNWut) will be referred to as SRSS_INST.

Upon script termination it's now required that you restart your Sun Ray server:

# init 6

Planning Your SRSS Network Topology

The first thing you've got to do is defining your network topology. SRSS can be configured with or without a separate DHCP server, on private and shared networks, etc. The official SRSS documentation can give you hints to how to configure your server if your in doubt. For the sake of this proof of concept, I'll choose the simplest network topology: a shared network with an existing DHCP server. For alternate configuration, please have a look at the official SRSS documentation.

To configure SRSS on a shared network using an external DHCP server all you've got to do is:

# $SRSS_INST/sbin/utadm -L on
# $SRSS_INST/sbin/utrestart

On OpenSolaris some required Solaris 10 packages were missing and installation scripts correctly informed me about the situation. The missing packages can be installed with pkg:

# pkg install SUNWdhcs SUNWdhcsb SUNWdhcm

Configuring SRSS

SRSS has got an interactive configuration script which can be run to establish the initial SRSS configuration:

# $SRSS_INST/sbin/utconfig

Please take into account that the script will ask, amongst others, the following questions:
  • SRSS admin password.
  • Configuration parameters for the Admin GUI:
    • Tomcat path.
    • HTTP port.
    • HTTP admin port.
  • Whether you want to enable remote administration.
  • Whether you want to configure kiosk mode:
    • Kiosk user prefix.
    • Kiosk users' group.
    • Number of users.
  • Whether you want to configure a failover group.

To enable the use of GDM by SRSS you'll need to touch the following file:

# touch /etc/opt/SUNWut/ut_enable_gdm

Synchronize the Sun Ray DTU Firmware

The last step in the configuration process is synchronizing the Sun Ray DTU firmware:

# $SRSS_INST/sbin/utfwsync

SRSS Up and Running on Solaris 10

Solaris 10 configuration ends here and SRSS should now be up and running. In the next section I'll detail the workarounds needed to fix the quirks I've found while configuring SRSS on OpenSolaris.

Additional Configuration for OpenSolaris 2009.06 or >b134

As soon as I configured SRSS, I tried to plug my Sun Ray client on to see if it would work correctly. The Sun Ray client was discovering the SRSS server correctly but then hung with a 26 B error code. The SRSS logs were reporting that GDM session was dying almost upon startup. So, there was a problem with GDM.

Fixing Bug 6803899

There's a known bug that affects $SRSS_INST/lib/utdtsession. Open it with vi and replace awk with nawk.

< tid=$(awk -F= '$1 == "TOKEN" {print $2;exit}' ${DISPDIR}/${dpyparm})
> tid=$(nawk -F= '$1 == "TOKEN" {print $2;exit}' ${DISPDIR}/${dpyparm})

NWAM

OpenSolaris has got a new SMF managed service to autoconfigure the network physical layer called NWAM. Using SRSS with NWAM (and with other server software as well) can be quirky. I suggest you disable NWAM and fall back to manual network configuration. More details on this can be found on official OpenSolaris documentation.

Motif

OpenSolaris is not shipped with the Motif libraries (and dependencies) required by SRSS. You can ignore them and set up a new policy accordingly:

# $SRSS_INST/sbin/utpolicy -a -g -z both -D
# $SRSS_INST/sbin/utrestart -c

or proceed and install the missing packages:

# pkg install SUNWmfrun SUNWtltk SUNWdtbas

Since this is a proof of concept I'm not going to use features such as mobility. Nevertheless, I wanted to try and install Motif to see if additional problems would come out.

Fixing GDM

As I told at the beginning of this section, SRSS logs were indicating some kind of problem with GDM. If you're following OpenSolaris evolution, you'll know that, indeed, Xorg as well as GDM have undergone major changes and now notably differ from their Solaris 10 "parents". The first error that was showing up on GDM logs, which can be found on /var/log/gdm, were complaints about missing fonts:

Fatal server error:
could not open default font 'fixed'

Font locations, indeed, changed considerably on latest OpenSolaris builds. To fix this you have to create a file called /etc/opt/SUNWut/X11/fontpath to reflect correct font paths on your system. On OpenSolaris b134 such paths are the following:

/usr/share/fonts/X11/100dpi
/usr/share/fonts/X11/100dpi-ISO8859-1
/usr/share/fonts/X11/100dpi-ISO8859-15
/usr/share/fonts/X11/75dpi
/usr/share/fonts/X11/75dpi-ISO8859-1
/usr/share/fonts/X11/75dpi-ISO8859-15
/usr/share/fonts/X11/encodings
/usr/share/fonts/X11/isas
/usr/share/fonts/X11/misc
/usr/share/fonts/X11/misc-ISO8859-1
/usr/share/fonts/X11/misc-ISO8859-15
/usr/share/fonts/X11/Type1

After fixing font paths GDM complained about missing dependencies for the following libraries: libXfont and libfontenc. Although this is not the "Solaris way" of doing things, a quick and dirty solution was making symlinks to the missing dependencies in /usr/lib:

# cd /usr/lib
# ln -s xorg/libXfont.so
# ln -s xorg/libXfont.so.1
# cd amd64
# ln -s ../xorg/amd64/libXfont.so
# ln -s ../xorg/amd64/libXfont.so.1
# cd /usr/lib
# ln -s xorg/libfontenc.so
# ln -s xorg/libfontenc.so.1
# cd amd64
# ln -s ../xorg/amd64/libfontenc.so
# ln -s ../xorg/amd64/libfontenc.so.1

The last thing to do is fixing a problem in $SRSS_INST/lib/xmgr/gdm/remove-dpy for gdmdynamic syntax:

< gdmglue="; gdmdynamic -b -d "'$UT_DPY'
> gdmglue="; gdmdynamic -d "'$UT_DPY'

Done.

Now, your Sun Ray clients should be able to connect to your SRSS running on OpenSolaris (at least, b134.) As you can see in the following picture, there's my MacBook with a virtualized OpenSolaris (b134) acting as a Sun Ray Server, the Sun Ray 2 client and the virtualized desktop on the screen behind the MacBook.


Have fun!




5 comments:

Deniz said...

This is a great post, I understand that one might want to do this for a POC but have you had any chance to actually test this with more than one SunRay user? Did it perform well?

Enrico M. Crisostomo said...

Thanks Deniz.

Yes. Indeed I'm running some Sun Rays with Sun Ray Server Software (SRSS) deployments. All of these run on Solaris 10 and I did this proof of concept to start investigating whether I can migrate some Solaris 10 servers to OpenSolaris because we're interested to some ZFS characteristics which haven't made it to Solaris 10 (yet.)

I've scheduled another post where I'll describe options (Sun Ray Server Software vs. Sun VDI) and their performance.

To give you some numbers, I'm giving a Solaris desktop to more than 20 users using Sun Rays and Sun Ray Servers running on a small Sun Fire X2100 M2. CPU and memory consumption using SRSS are very similar to what I measured simulating the same activity without SRSS.

Desktops provide OpenOffice and Firefox which are the programs that require most of the RAM. I'm estimating 150 MB/user given the usage pattern in my office. Some desktops also provide NetBeans instances, in which case the required RAM/user can quickly go up to 500 MB/user depending on NetBeans usage pattern.

As far as it concerns CPU, desktop applications aren't generally CPU-avid: that depends on the programs you'll provide to your users. As far as it concerns basic desktop environments, accounting tells me that the server CPU is idle most of the time. The story is very different for development desktops: I'm reserving up to 50% CPU core per user in some cases. That may not seem too much but developers aren't experiencing any problem but NetBeans taking a little longer to compile or start the embedded Glassfish. The desktop responsiveness is generally very good.

What kind of workload are you interested in?

Unknown said...

So where I put those command lines that are shown here?

Enrico M. Crisostomo said...

Hi Jani.

Open your preferred shell and follow the instructions.

animono said...

I've just received my first Sun Ray 2 client!
Let's see if I'm able of making it run!