Wednesday Aug 08, 2012

Server Chooser

I recently helped out a customer who required a small amount of customization of their Sun Ray environment due to their specific application use case.  This type of request comes up often, and I was asked to share this with a larger audience.   This post will cover a solution that was devised to enable users to pick and choose the server they want to run a session on, as each server has a different software load, thus a different purpose.   After the end user finished their work, the customer wanted the Sun Ray to return to the point where the user could make a new server choice.  This post will look at the unique workflow of the customer and cover the problems they encountered by deploying Sun Rays in a "traditional" manner and the solution that solved these problems.  Instructions will be provide on how to configure a Sun Ray environment to meet the needs of this customer, including the creation of a simple graphical chooser1 to assist users with selecting and getting redirected to a server of their choice.  It will also illustrate how to use the Sun Ray Software feature called AMGH (aka regional hot desking) to return a Sun Ray client (or Oracle Virtual Desktop Client) back to the its originating server.


The customer had recently replaced their Sun SPARC Workstations with Sun Ray 3 Plus clients and consolidated the compute power of all those workstations down to one Oracle Sun SPARC Server.

Prior to the consolidation, each workstation had single-purpose, which was to run one of fifteen different applications.  These fifteen different applications were the individual components of a larger satellite control system.  While single-purposed, there were multiple workstations running the same app.  While I don't have an exact workstation count, let's just say there was exponential number of workstations based on the individual fifteen applications since the workstation model is typically on a one to one ratio of machines and users.

Through the use of Oracle VM Server for SPARC (which is virtualization through hardware partitioning),  the customer carved up the server into fifteen virtual servers (previously these servers would have been called logical domains or LDOMS, but let's stick with the current marketing lingo).  Now instead of mutiple workstations with one of the fifteen different applications, they have a fifteen virtualized servers, one per application, that can be accessed by multiple users simultaneously.  Along with the individual application, each of the virtualized servers run an instance of Sun Ray Software. 

Note: While the customer uses SPARC due to application requirements, there is no reason you couldn't do the same consolidation on x86 using Oracle Virtual Machine, VirtualBox, Hyper-V, Vmware ESX, etc. 

Through the use of Sun Ray, and the multi-user goodness of Solaris, they also tackled the one to one ratio of workstations to users.

From a physical system administration standpoint, the customer obtained a drastic reduction from how ever many workstations they had, down to one.  From an OS instance, they reduced from many (one per workstation) to 15.  Good stuff!  However, the customer found that, as deployed, the system did not meet their requirements.  Primarily, it did not allow the users to use the system as they had in the past.  Extra steps were now required to run a certain app.   As deployed, it changed the workflow for the end user in a negative manner.  That usually makes users unhappy and we all know having unhappy users is a bad thing.  That's where I come in <insert blare of trumpets>.

Use Case

Even though the customer was happy with the all of the benefits that consolidation and virtualization bring, they needed to keep their current workflow of each "workstation" having single purpose.  If operator Bob, needed to run "application one", he needed to connect to "server one" and "server one" only.

Normally when you have multiple Sun Ray Servers, you put them together in a host group2 (aka FOG).  The Sun Ray is pointed at a server in the host group and from there, based on policies in use, will normally get load balanced to another server. 

Hopefully you can see why this "normal" deployment practice did not work for this customer.  When operator Bob wanted to use "application one", he'd usually get load balanced over to something other than "server one", and that server does not have "application one" on it.  That's not good, at least not for their use case.

And just assuming that operator Bob landed and stayed on "server one" (either by luck or by manual intervention), ran "application one", the Sun Ray itself was now homed to that "server one".  When Bob leaves for the day at shift change, his replacement operator Bill now faces the same headache.  Bill needs run "application five" which is on "server five".  

The solution to this customers problem can be provided by meeting each of the following objectives:

  1. Avoid the game of server roulette brought on by load balancing3 and allow the users to select the server of their choice to run the required application without requiring the user to log in multiple times and without creating multiple sessions2.
  2. Make the server choice selection as simple as sitting down at the "right workstation", but allow the "right workstation" to be any one that the user sits down at.  All without requiring the user to manually perform a command line switch or having to know server names.
  3. After the user has completed their work, return the Sun Ray client to the point where another selection can be made.


Exact details of the solution follow in the instructions, but at a very high level, the solution features the following:

  • Use of a "landing zone" server, where all Sun Rays are configured to make their initial connection
  • Kiosk mode4 enabled as the default policy for the landing zone server.  Kiosk mode runs a simple chooser that allows the user to select from list of server names
  • Upon the user making a selection, the chooser application redirects the Sun Ray to that server by performing a utswitch. 
  • Once redirected, the user is presented with a regular Solaris JDS session.  At this point the environment and workflow is the same it was with the old workstations
  • After the user has completed their session by logging out, the Sun Ray client is automatically redirected back to the landing zone server via AMGH


NOTE: This configuration requires at least two standalone (i.e. not configured in a host group/FOG) Sun Ray Servers.  One instance will be known as the "Landing Zone Server".  This where Sun Rays get directed to initially and where users make a choice to connect to another server.  The server chosen by the user is referred to as the "Workstation Server(s)", normally there will be more than one "workstation server", otherwise there's really no point in choosing between servers.  This is where the users do their actual work, the same work as they did on their former workstations.

Landing Zone Server Configuration

Note: All Sun Rays should be pointed to the landing zone server via one of the available provisioning options. i.e. DHCP, DNS, parms, etc.

Step 1) Create A Server List

Purpose: The kiosk script (utchooser) will read this file to populate the server choices available to the end user

  1. Edit /etc/serverlist
  2. Put a unique server name or IP address on it's own line

Example server list:

# cat /etc/serverlist

Step 2) Create Kiosk Session Configuration File

Purpose: This is what the Kiosk framework will reference on what to run

  1. Create directory /etc/opt/SUNWkio/sessions/utchooser
  2. Edit /etc/opt/SUNWkio/sessions/utchooser.conf
  3. Put the following in /etc/opt/SUNWkio/sessions/utchooser.conf
    KIOSK_SESSION_LABEL="Sun Ray Session Chooser"

Step 3) Copy kiosk script to Landing Zone server

Purpose: This is what the kiosk session will actually run

  1. Copy and paste the following example into a file called /etc/opt/SUNWkio/sessions/utchooser/ (or download it here)
  2. After copying, make executable.
    chmod +x /etc/opt/SUNWkio/sessions/utchooser/

# Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
#  A sample script to present a list of standalone servers
# that users can choose to redirect their Sun Ray Client to.
# Written by Craig Bender, Consulting Developer
# Oracle Desktop Virtualization and Sun Ray Engineering
############### NOTICE ###############
##        USE AT OWN RISK           ##
############### NOTICE ###############

# Check to see if a window manager is running
# If not, start one

WMCheck=`ps -U $USER |grep metacity | tail -1`
if [ -z "$WMCheck" ];then
metacity &

# This defines the location list of servers to show.
# Names in this list must be resolvable
# IP addresses OK, but not as useful


# Count how many entries so we can automatically
# configure the height of the zenity box

COUNT=`cat $LIST | wc -l`

# Zenity takes roughly 26.67 pixels for each row displayed
# using standard system font.  We multiply this by the
# number of choices to get the height of the Zenity box. 
# Otherwise, scroll bars show up if more than about 5 choices


# The height of the dialog box.
# This is a calculation of the
# COUNT multiplied by ZENPIX

# bc used since expr can't handle decimals

HGT=`echo "scale=0;$COUNT*$ZENPIX" | bc;exit`

# The width of the dialog box. Note that zenity will
# default to the the width of the text in the title.
# If you wind up with scroll bars or wrapped text
# increase the width as needed


# Command to switch Sun Ray to that server

UTSWITCH="/opt/SUNWut/bin/utswitch -h"

# Location of Zenity, which is used for Dialogs


# Title displayed in the chooser

TITLE="Choose a Server"

#Check to make sure the server list exists

# If not display an error message so Kiosk mode does not cycle
if [ ! -r "$LIST" ]; then
     $ZENITY \
     --error \
     --title "Configuration Error" \
     --text "Please have an Administrator specify a list of server names in $LIST"
     exit 1

# Read the server list and create an array

# If we have a list of servers, present them in a dialog box
while [ -z $CHOICE ];do
        CHOICE=$($ZENITY \
                --title="$TITLE" \
                --width $WID \
                --height $HGT \
                --list --radiolist \
                --column="Pick" \
                --column="Server" \
                $(printf 'FALSE %s\n' ${SERVERLIST[@]}))

# Check to see if user clicked Zenity's Cancel button
# if so exit script
        if [ "$?" = "1" ]; then exit 0;fi

#Check to see if user selected a server
        if [ ! -n "$CHOICE" ]; then
           $ZENITY \
           --error \
           --title "Whoops!" \
           --text "Please Select Server First"

# Otherwise proceed to run utswitch
# with the chosen server as the argument



# End of Scriptt

Step 4) Enable Kiosk Mode for non-card sessions

Purpose: So the landing zone server will come up in kiosk mode

  1. Log into the Sun Ray Server Admin GUI (http://servername:1660), then choose Advanced -> System Policy.
  2. Check the Enabled Box next to Kiosk Mode in the non-card session box
  3. Uncheck mobile sessions for non-card sessions (if selected)
  4. Click Save
Step 5) Configure Kiosk Mode to run the chooser application

Purpose: So kiosk mode on the landing zone server will run the script

  1. Via the admin gui, choose Advanced -> Kiosk Mode
  2. Click Edit
  3. In the Session drop down box, select "Sun Ray Session Chooser"
  4. Click Save

Step 6) Perform cold restart of Sun Ray Servers

Purpose: To have Kiosk mode take effect

  1. Use either the servers tab in the web admin GUI or utstart -c CLI

All Sun Rays directed to the Landing Zone server should now be displaying the chooser

Workstation Server Configuration

Step 1) Activate AMGH
Purpose: This is what returns the Sun Ray to the landing Zone Server

  1. Create a return script file and make it executable

  2. touch /opt/SUNWutref/amgh/utamghref_return
    chmod +x /opt/SUNWutref/amgh/utamghref_return

  3. Edit the file and copy the code below:

  4. #!/bin/bash
    echo "use_firstserver=true"
    exit 0
Step 2) Enable Mobile Sessions for non-card users
Purpose: Without mobile sessions, AMGH will not get activated to return to the landing zone server until the user types in the username.

  1. Enable Mobile Sessions via the admin gui (Advanced -> System Policy) or via the utpolicy CLI

Step 3) Perform cold restart of Sun Ray Servers
Purpose: To have AMGH and Mobile Session take effect

  1. Use either the servers tab in the web admin GUI or utstart -c CLI

Set up complete! You should now have a functional system that meet the above objectives.  Users can now:

  • Choose the server of their choice
  • Perform their work on that specific server while only creating one Sun Ray session for that user and only requiring a single logon
  • Return the Sun Ray client to the Landing Zone server once the user logs off


1While the chooser in this post uses a mechanism called utswitch to direct a Sun Ray client to different Sun Ray server, you could easily adapt the same chooser to run any application.  Because that's all utswitch is, an application.  Perhaps you wanted to choose from a list of Solaris containers to access via ssh or Xnest.  All the chooser really does is present the user with a choice and execute some program based on that choice.

2 Besides load balancing, another job of a host group, and where the FOG moniker comes in, is that the settings, policies, and certain data points (like desktop or smart card registration) get replicated across all members of the host group.  For instance if you had 99 Sun Ray servers and you didn't want to allow users without smart cards to get a session, you'd have to go change the policy on all 99 servers.  If you combine them into a host group, you set the policy once and all the servers share it.  If you filled out information about a Sun Ray client, such as location, you only do it once and that data gets replicated across all 99 servers.  Finally the host group provides session management.  As you disconnect or move from Sun Ray to Sun Ray, the session manager will direct your client back to the correct session, regardless of the server the client is currently connected to.

3 There are ways to turn off load balancing by editing the auth.props file.  However, this has to be done on each server.  If there is no data to replicate, or you want servers to have different policies, and you don't want to load balance, then there is no point in having a host group.

4 Kiosk mode allows "unauthenticated application access" to applications.  Unauthenticated application access means that an application, as defined by the administrator,  can run without requiring the end user to authenticate before interacting with the application.  It does not mean that the application itself does not or will not require authentication, that all depends on the application.  An example of this would be Sun Ray Kiosk mode configured to run an RDP connection to a Windows terminal server.  The user does not need to authenticate to Solaris to run the Sun Ray Windows Connector, but would need to authenticate to Windows. 


Think Thin is a collection of bloggers that work with Oracle's Virtual Desktop portfolio of products.


« April 2014