Saturday Aug 11, 2012

One Blank To Rule Them All

From the Customer Request Department: I have a large mixture of different Sun Ray models.  The information being displayed on our Sun Ray 3i units is mission critical, thus these units should never blank, lock, or sleep.  How can I disable these features on certain models of Sun Rays, while retaining them on the others?

Don't care about the why?  Then jump to the how.

Over the years, you've probably seen a lot of different tips and trick to control Sun Ray clients from "screen blanking", usually the tip/trick involves running the command xset.  That's usually correct, however it's also possible that it's only partially correct.  Extras steps may be required depending on how you've deployed Sun Ray clients, what they are displaying and, more importantly, the environment in which they are displaying it.

Let's begin by taking a look at screen blanking from three standpoints: technical, ecological, and securitogical   Screen blanking, at a very high level technical level, is the X server deciding it should stop "burning in your monitor" based on nothing other than idle time.  Is this legacy behavior from the days when a CRT would get an image burned into it if sat idle on the same screen for too long?  Of course, but that's only part of the story. 

What started as an attempt save you money by not destroying your monitor, eventually evolved into trying to save you money (and the planet) by decreasing electrical consumption.  Somewhere between CRT burn-in and being financially / ecologically responsible, the security folks got involved.  Forget about reducing your hardware spend rate, or electricity consumption, that's small peanuts.  Protect the intellectual property being display by requiring a user to re-authenticate if the computer sat idle for too long.  Otherwise you probably won't be in business long, so you won't have any money to buy a monitor or pay the power bill.

To understand what you must do in your environment, it's good to have a full understanding of the different mechanisms that are responsible for screen blanking, power-saving, and screen locking.

X Server Blanking:


xset is a utility for setting user preferences for the user's X display.  One of the preferences that xset controls is screen blanking, which is referred to as the screensaver in xset terminology.  xset is fairly old, requires hooks into the x server that may not exist.  This is sometimes the case with Sun Ray.  A prime example of this is that the xset shipped with Solaris is not aware of XKeyBoard (XKB), thus the xset keyboard control preferences that you may have used when Sun Ray used XSun as for it's X Server, no longer work when you use the newer X Org based Xnewt X Server.  Similarly, xset under Solaris has hooks for Display Power Management Signaling (dpms), while xset shipped with Oracle Linux does not.  xset can only blank the screen, it cannot lock the screen.  Which leads us to the next mechanism, XScreenSaver.


XScreenSaver is the default screen-saver and lock-screen method for Solaris JDS sessions.  There are some discrepancies, at least in my understanding, between the interaction between xset and XScreenSaver.  If you read up on xset, it would appear that xset controls xscreensaver.  In my experience, the reverse is true.  This could be completely due to the order in which things get started,  but without running a xset command and having a .xscreensaver file in your home directory that has the below items in it, those setting will be reflected in the command "xset q".  However, the reverse is not true.  Meaning if you set the timeout and cycle in xset, it has no affect on XScreenSaver.   The curious may wonder why xset alone works for Kiosk mode.  This is due to the fact that, in most circumstances, XscreenSaver is *NOT* invoked while in Kiosk mode.  However, if you are using the the Locked-down JDS Kiosk session, or using a custom Kiosk session that invokes certain Gnome utilities, then XscreenSaver will get invoked.

If you never want a screen to blank and never want monitors to go into power-saving mode, and XScreenSaver is running for your session, then do the following.

echo "timeout: 0" > $HOME/.xscreensaver
echo "cycle: 0" >> $HOME/.xscreensaver
echo "lock: False" >> $HOME/.xscreensaver
echo "dpmsEnabled: False" >> $HOME/.xscreensaver
echo "mode: off" >> $HOME/.xscreensaver

That's it.  Next time you start a session, XScreenSaver should never blank and never lock, nor should your monitor ever go into power-save mode.  Cha-Ching! says the power company! 

NOTE: All Kiosk sessions, regardless of session type, have XScreenSaver's lock function disabled.  This is required since Kiosk user accounts are locked in /etc/password, and having the screen lock itself with a user whose account is locked out, would be very bad. 

TIP: If you wanted to add the extra steps I've listed to all Sun Ray sessions running in Kiosk mode, you would simply echo the above lines into /etc/opt/SUNWkio/prototypes/default/.xscreensaver instead of $HOME/.xscreensaver.  This needs to be done on each server in the host group/FOG.

NOTE: A simple way to disable XScreenSaver on a system-wide basis under Solaris is rename the directory /usr/openwin/lib/xscreensaver/hacks.  Call it hack.old or shacks, or whatever floats your boat. In this case, per the customer request, we don't want to disable it system wide.  There's also the fact that I believe XScreenSaver does a far better job at controlling screen blanking then just xset alone.

Mobility Security Features (screen-locking)


utxlock is an executable shell script that locks the screen.  utxlock gets invoked when a user, who is running a regular session (not kiosk a session), disconnects or hotdesks their session. Upon reconnecting, the user is asked to reauthenticate.  If you want to hotdesk without entering your password, perform the following:


NOTE: utxlock been replaced by a new mechanism called Remote Hotdesk Authentication or RHA.  However, if an administrator disables RHA, then utxlock is still relevant for regular session. utxlock is disabled under Kiosk mode.

Remote Hotdesk Authentication (RHA)

RHA is the replacement for utxlock.  While not screen blanking, it is screen locking, and like it's predecessor utxlock, it is invoked when a user disconnect their session.  

RHA was created due to bugs in XscreenSaver that would prevent it from locking the screen in certain scenarios.  For instance, clicking on and expanding the JDS "Launch" menu will prevent XScreenSaver from being able to lock the screen.  Prior to RHA, users who left their JDS Launch menu (or certain other gnome-panel and application menus) expanded, would return to an unlocked screen.  Needless to say, many customers were a bit perturbed to find their session in this unlocked state.  You can point fingers all day long, but what mattered was that a huge security hole existed and it needed to be closed.  Unfortunately, the fixes created by Sun Microsystems to address these problems never got picked up by XScreenSaver's maintainer.  So instead of forking XScreenSaver, the Sun Ray group engineered a new solution now known as RHA.  When using RHA, the Sun Ray disconnects from it's real session and you are sent off to transient session for authentication.  When authenticated, the Sun Ray client gets redirected to the real session.  Since RHA is a security mechanism first and foremost, only the server administrator can disable RHA.  Disabling RHA by including the -D option with utpolicy CLI or by selecting "Direct Session Access" under the Sun Ray Server Admin GUI's system policy page.  RHA is not enabled in Kiosk mode.

Energy Star Features:

Sun Ray 3 Power-Off Feature

The Sun Ray 3 family line has a feature that will power off the client when it has sat idle for 30 minutes (default setting).   Regardless of the fact that a Sun Ray consumes less power than a PC in sleep mode, Energy Star required a power-off mode to get an "A" Thin Client rating. 

The Power Off feature can be controlled in one of two places: Locally, through SROS (aka firmware) if the GUI menu as been enabled or in the parameter files

If you enabled the GUI menu for SROS local configuration,  you can control the amount of time before, but as of this post, you cannot set it to zero to disable it. Despite that bug, you would want to avoid this, because it means you have to visit each desktop.

That means it's best to set it in the Sun Ray Parameters file which reside on the server that delivers SROS to the clients.  Choosing this method allows you to disable the Power-Off feature by the model of the Sun Ray client, although not as granular as you may like since some Sun Rays, while different form factors, carry the same Model ID.  Suppose you only wanted to prevent Sun Ray 3i clients from powering off, you would add a line /tftpboot/SunRayP10.parms that reads:


Here's what I mean by the control not being as granular as you may like it to be.  Adding this statement to the P10 parms file will result in disabling the power off feature for both the Sun Ray 3 and Sun Ray 3i clients, as they are both P10 models.  However, it would not get applied to Sun Ray 3 Plus clients, since their model ID is P9 and P9-E.

Video Blanking (local firmware configuration)

If you have the GUI enabled in the local firmware, there is a menu item under Advanced -> Video -> Blanking.  I'm sure I'll come back have to edit this section, but as far as I can tell, this is just a setting to prevent the DVI ports on a physcial Sun Ray client from going into power-saving mode.  To put that another way, I've never seen it take affect, regardless of the setting.   OK, I'll do some experimenting, but if you disable the above, I don't this setting is worth playing with.

Energy Star Monitors

Most monitors will go into sleep or power-saving mode when they detect a loss of video signal.  All of the methods that have been discussed address keeping that video signal alive.  In every scenario, it's the job of the OS to control the video signal.  In the Sun Ray environment, the OS is across the network.  Thus a loss of network connectivity to the Sun Ray server means a loss of video signal.  So unless you've turned off your monitor's Energy Star features, your monitors will go into power-save mode within a few minutes of losing the network connection.  While atypical, just something to bear in mind while testing. 

A real world example of this would be my test lab.  I work from home and, for the most part, all my Sun Rays connect to Sun Ray servers that located in our engineering lab at Oracle Headquarters.  Regardless of what methods I set, to prevent blanking, I can only control it for 24 hours.  Why only 24 hours?  Because Oracle's security policy limits the amount of time allowed for VPN connections to 24 hours.  Thus, after 24 hours, my VPN drops, and if I'm not there to sign back in, my monitors will blank and go into power-saving mode.

To the best of my knowledge, that sums up the different mechanisms that can cause a screen to go blank (or lock) while idle. 

In most cases, administrators of Sun Ray servers in Kiosk mode (such as those those running Oracle VDI) will most likely only face two issues.  Those being the X server blanking the screen and the new power-off feature of the Sun Ray 3 clients.  If XScreenSaver is invoked during Kiosk mode, or if you're not sure, then better to be safe than sorry frustrated and use the methods I've listed to disable it.

In the Power Off feature section, I demonstrated how to disable the power off feature for a specific Sun Ray model via the parameter  (aka "parms") files.  The following script will use the same type of per-model logic, to disable screen blanking using the mechanisms discussed about.  It will run both both xset and configure XscreenSaver in a manner that should prevent the Sun Ray model of your choice from blanking.

The how-to on this on the xset portion command is covered here in the Sun Ray Administration if you wanted to run it on a system wide basis, but it doesn't cover controlling the settings at a more granular level, such as doing it only for a certain model of Sun Ray.  Nor does it cover scenarios where XScreenSaver is in play. 

If you remember way back to the top of his blog post, the customer wanted to disable screen blanking only on Sun Ray 3i clients.  This script will do that, even if XScreenSaver were to be invoked. This script will run xscreensaver, in order to tell it not to blank, powersave, or lock. As previously mentioned, it seems to have far greater control than just using xset.  If you'd rather not have it run, it's OK to comment it out.  You'll still be protected if it gets invoked due the settings we push to it's configuration file, $HOME/.xscreensaver

The following script is fairly well documented (less than 15 lines without the comments), but if you have any questions, feel free to leave them the comment section.  We can also do this by the Client ID (aka MAC address of a physical Sun Ray Client).  Look for a follow-on blog for a how-to on that.  I promise to practice brevity in that post.

# A script to disable the X server from blanking certain Sun Ray Clients
# based on the model of the Sun Ray.  It covers controlling by xset and XscreenSaver
# Written by Craig Bender, Consulting Developer
# Oracle Desktop Virtualization and Sun Ray Engineering
############### NOTICE ###############
##        USE AT OWN RISK           ##
############### NOTICE ###############
###### File Location Information #####
# Solaris Admins: Save this script as /usr/dt/config/Xsession.d/0050.SUNWut
# Oracle Linux Admins: Save this script as /etc/X11/xinit/xinitrc.d/

# For both, make sure to make the file executable i.e chmod +x filename

# In this example Sun Ray 3 and 3i units will be prevented from
# having the X server blank
# Sun Ray Models aren't always specific. There are a few cases of model overlap
# e.g.  Both the Sun Ray 3 and 3i are SunRayP10 models
# Sun Ray Model ID breakdown:
# ---------------------------
# SunRayP10 = Sun Ray 3 and Sun Ray 3i
# SunRayP9 = Sun Ray 3 Plus
# SunRayP9-E = Sun Ray 3 Plus with SROS
# SunRayP8 = Sun Ray 2
# SunRayP8-FS =  Sun Ray 2FS
# SunRayP8-270 = Sun Ray 270
# SunRayS1 = OVDC
# SunRayP1 = Sun Ray 1
# SunRayP2 = Sun Ray 1 or Sun Ray 100
# SunRayP3 = Sun Ray 150
# SunRayP4 = Sun Ray 1 or Sun Ray 100
# SunRayP5 = Sun Ray 150
# SunRayP7 = Sun Ray 1g or Sun Ray 100
# SunRayP7-170 = Sun Ray 170

# Check for OS and add location of xset for Solaris
# Under Linux xset lives in /usr/bin which is in
# the default path


if [ "$theOS" = "SunOS" ];then

    PATH=$PATH:/usr/openwin/bin;export PATH

# Get current display and remove leading colon and trailing screen info
# so we can match it up with the SRSS dispinfo file that contains the model ID

theDisplay=`echo $DISPLAY | sed 's/.*:\([^.]*\).*/\1/'`;export theDisplay

# Now that we have the display, we can get the model


theModel=`sed -n 's/^MODEL_ID=//p' $theDispFile`;export theModel

# Now we'll limit the scope of the xset command used to
# turn off blanking by the model ID of the Sun Ray only hitting Sun Ray 3 and 3i clients

if [ "$theModel" = "SunRayP10" ]; then

# Note: If you wanted to do a few different models, you would use the or function in
# the test. For example, if you also wanted to stop blanking on Sun Ray 3, 3i,
# 2FS clients you would change the if statement to read:
if [ "$theModel" = "SunRayP10" ] || [ "$theModel" = "SunRayP8-FS" ]; then

    # The s option in xset controls the X server's blanking settings
    # Note that if XScreenSaver is invoked, its configuration takes precedence

    # xset s noblank tells display not to blank
    # xset s 0 0 sets the timeout and time-cycle
    # xset s off turns off the screen blanking function unless XScreenSaver is invoked

       xset s noblank;xset s 0 0;xset s off

    # XScreenSaver is configured by reading $HOME/.xscreensaver
    # man xscreensaver for more information on the below settings.
    # timeout and cycle set to zero, just like with xset
    # lock: False - disables the locking of the screen
    # dpmsEnabled: False - Will disable power management if the Xserver supports it
    # mode: off - Will disable xscreensaver and dpms completely

      echo "timeout: 0" > $HOME/.xscreensaver
      echo "cycle: 0" >> $HOME/.xscreensaver
      echo "lock: False" >> $HOME/.xscreensaver
      echo "dpmsEnabled: False" >> $HOME/.xscreensaver
      echo "mode: off" >> $HOME/.xscreensaver

    # Regardless of environment, Start XscreenSaver and force it to read the settings

    # Note: If you'd like to save the memory and CPU resources consumed by XScreenSaver
    # you can comment out the below line.  Session will still be protected from
    # accidental invocation blanking locking from an non-planned invocation of
    # XscreenSaver

     xscreensaver &


# End of utNoBlank

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. 

Thursday Jul 15, 2010

SRS 5: Big updates disguised in a patch

Greetings Think Thin Readers,

Those who watch things like SunSolve for new patch releases noticed starting last Saturday that a slew of new patches began showing up.  If you read the "fixes" in the patch read me files, that's exactly what it looked like...a patch.  But there's so much more.  Beyond numerous bug fixes ("black screens", High CPU using Flash or USB redirection, etc) these patches enable some great new features, details of which were in a press release today.  Just some of the highlights:

New Platform Support:

  • Support for Oracle Enterprise Linux as a Sun Ray Server Software Platform
    • Continued support for Solaris, RHEL, and SLES
Oracle Virtual Desktop Client 2.0 (formerly SDAC)
  • Renaming & Oracle branding of the Sun Desktop Access Client (SDAC) to Oracle Virtual Desktop Client (OVDC)
  • New Apple OS X Version of the OVDC 
    • Continued support for Windows XP, Vista, 7
  • Smart card support for OVDC
    • Hot Desk from your PC or Mac with a smart card reader to a Sun Ray Thin Client
  • Support for Upstream Audio
  • Support for Client Serial Port Mapping

Sun Ray Connector for Windows OS

  • Upstream Audio
    • bidirectional audio capabilities for Windows XP and Windows Server 2003
    • Requires SRSS 4.2 and SRWC 2.2 patches, version -03 or later, and the SRWC Components 1.1 patch, version -01 or late
    • Note upstream audio is off by default.  New uttsc argument required -r soundin:(low|medium|high)
  • Multiple pesky bug fixes ("Double login" for 2008 session directory, black screens, Flash and USB-R fixes)

Install the latest patches per platform, download the new OVDC and let us know what you think!

And as always...Stay Tuned.  Hopefully making noise about things like this will put to rest any doubt that Oracle is committed to it's Desktop Virtualization Portfolio (Sun Ray, SGD, Oracle VDI).

Thursday Feb 05, 2009

Meta Kiosk: How to run multiple different types of kiosk modes on a Sun Ray Server/FOG

Haven't you ever wanted to be able to have more than one type of  kiosk running from the same Sun Ray server or FOG? Now you can. JDS, UTTSC, VDA, VDA no Card, VDM, and even non-kiosk uses like X11 (using Xnest), VNC and full screen apps. (I've even thrown utswitch and xterm for convenience.)

I've "productised" a Kiosk mode that sits above other Kiosks to call on them as required - as always, based on what you tell your tokens to use, leveraging the "Other Info" field.

It's called "META KIOSK".

Sunday Sep 07, 2008

Customized Sun Ray kiosk sessions

Have you ever tried to customize your Sun Ray installation to display different 'things' for different Sun Rays and users' cards? HERE you'll find an info how to do so (configuration via SRSS Admin GUI only).
What can be displayed?
- full Windows/Solaris session
- single Windows/Solaris application
- menu with some Windows/Solaris applications
- wallpaper - ie. to see your girlfriend photo if card is not inserted
- images slideshow - ie. reception desk or tradeshow.
Scripts support USB storage, serial devices and printers connected to Sun Ray.

Additionally HERE you can find some instructions/scripts which can help to install, configure and connect
your SGD server to Active Directory.

Wednesday Jul 23, 2008

A "USB Drive" daemon for Sun Ray sessions - revisited...

After a year in the making, a new version of the good old "usbdrived" is out. USB drive access on a Sun Ray is now looking better than ever!

Thursday Feb 22, 2007

CAM Deep Dive

[Read More]

Tuesday Nov 21, 2006

Turbo CAM

As promised from my Immersion Week classes here are some ways to really help reduce the amount of work your Sun Ray Server does on bring up.  While we focused on CAM, all of these apply (except dtsession) to normal Sun Ray operations

Update:  We've found that the utprodinfo hack breaks normal sessions using NSCM (Mobile Sessions).  Do not use the utprodinfo hack for anything other than CAM.  It may also break other things that we are not yet aware of so use at your own risk.

In our case study we were trying to bring up 50 Sun Rays but were running into problems.  We started with a base line of 36 terminals coming up in about 30 minutes.  The box was so busy that certain calls in the cam script that did call backs to authd were timing out.  You could consider this the same as a cold restart or a massive shift change in a call center environment. 

Here are the magic 5 things you can do to tune CAM

(Thanks to those in Sun Ray Engineering who don't blog namely Sangeeta Varma and Ron Shipper)

What: Increase Authd worker threads from 8 to 32.

Why:  This is the target number of spare threads to maintain to handle new terminal connections.  When many sessions are starting up, we can exhaust authd fairly easily.  This can have a big effect on a Sun Ray Server that is servicing a lot of DTU's. 

How: Change the Workers = 8 to Workers = 32 in /etc/opt/SUNWut/auth.props

What: Change utprodinfo to do an echo vs. a pkginfo

NOTE:  This will break NSCM (i.e. non smart card mobile sessions).  Do not use if you are NOT running CAM for non-card sessions.

Why: While we currently only support installing Sun Ray Server Software in /opt, there are plenty of hooks to allow for future changes.  One of these is to query where the packages are installed.  This is done via pkginfo -r <package name> via a script called utprodinfo.  Consider that in order to just get to a login screen (i.e. dtgreet) eight pkginfo's are ran.  Multiply that by the number of DTU's you have, and the fact that pkginfo can be fairly taxing in itself and you have a recipe for wasted cycles.  Since we currently only support Sun Ray Server Software to be installed in /opt, we can change utprodinfo just echo out "/opt". 

How:  Make a copy of /opt/SUNWut/lib/utprodinfo

Find the line that reads:

r)     setOP "r";;

And change it to this:

#Tuning Fix - echo "/opt" and exit
r)     setOP "r" 
       echo "/opt" 

What: Use non-invasive methods for finding the Sun Ray MAC address or other information from the data store

Why:  If the Sun Ray Server is already taxed due to massive session creations, making calls to the data store that requires real time data from the session manager just worsens the situation.  A lot of folks use commands like utwho, utdesktop -Lc, utuser -lc, utdesktop -p, etc.  While these will return the desired information, if authd is too busy to service this request, it will time out.  If your CAM script relies on information from these queries, it will fail and cause your session to cycle.  This further exacerbates the problem of a taxed box.

How:  Check to see if the command you wish to use requires authd.  Open one window and truss the java process running authd.  Open another window and run your commands.  You should notice the changes to the truss.  Any command that gets current information or status information is going to make a callback to authd.  For example, utdesktop -lc will open authd, while utdesktop -l is just an ldap call.  Yes the -l will result in more information to parse through, but it does not rely on authd to readily service your request.  Most ut\* calls that call authd have a time out of 5000 ms.  utwho on the other hand does not seem to time out which could lead to CAM scripts hanging if authd is too busy.

Some folks also use these commands to figure out the MAC of the Sun Ray DTU.  Typically I've always recommended that people do a pwd on $UTDEVROOT, like so:

SRMAC=`cd $UTDEVROOT; pwd | sed 's/.\*\\(............\\)/\\1/'`

While that's a non-invasive command, it won't work if your Sun Ray is NAT'd.  Another method that will work in a NAT'd environment and is also non-invasive from a authd standport is to create a small script that queries the dispinfo files:

MYDISP=`echo $DISPLAY | awk -F: '{print $2}' | awk -F. '{print $1}'`
MYMAC=`grep TERMINAL /tmp/SUNWut/config/dispinfo/$MYDISP | awk -F. '{print $2}'`
echo $MYMAC

You can then use that script to set your variable.

What: Remove dtsession as a CAM application if not required.

Why: Not only does dtsession consume at least 30 MB of RAM per session (more for multihead), it takes cycles away from the CPU's and in most cases is not required.  If you are using CAM for full screen windows, dump dtsession.

How:  Remove dtsession from from the applications to launch selection under CAM.  Remember however that at least one application must be set to critical.  Dtsession usually fills this role, just remember to set on of your CAM applications to critical.

What: Increase the initial and max heap size for Authd

Why:  Under the 1.4 JRE, the max heap size will default to 64 MB.  Increasing this to 128 allows for more head room and will lower the number of times garbage collection occurs.  We find this setting to be a good balance between the number of times GC occurs and the amount of time GC takes.

How:  Make a copy of /opt/SUNWut/lib/utauthd and make the following changes:

Find the lines that read:


And add one more option:

JAVA_OPTS="-Xmixed -Xms128M -Xmx128M"

The end result of these changes? 

82 terminals up and logged into windows in 3 minutes from a cold restart of Sun Ray Services


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


« April 2014