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 er..security.   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

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

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

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:

echo "SUN_SUNRAY_UTXLOCK_PREF=; export SUN_SUNRAY_UTXLOCK_PREF" >> $HOME/.dtprofile

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:

poweroff=0

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.

#!/bin/sh
#
# utNoBlank.sh: 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 ###############
######################################
## PROVIDED AS IS, WITHOUT WARRANTY ##
##        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/0050.SUNWut.sh

#
# 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

theOS=`uname`

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

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

# 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

theDispFile="/tmp/SUNWut/config/dispinfo/$theDisplay"

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 &

fi

# 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.

Background

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.

Solution

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

Instructions

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
Apollo
Athena
Boomer
Crashdown
Freaker
Hardball
Helo
Hotdog
Husker
Jammer
Kat
Redwing
Skulls
Starbuck


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
  4. KIOSK_SESSION_EXEC=$KIOSK_SESSION_DIR/utchooser.sh
    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/utchooser.sh (or download it here)
  2. After copying, make utchooser.sh executable.
    chmod +x /etc/opt/SUNWkio/sessions/utchooser/utchooser.sh


#!/bin/bash
#
# Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
#
# utchooser.sh:  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 ###############
######################################
## PROVIDED AS IS, WITHOUT WARRANTY ##
##        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 &
fi

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

LIST=/etc/serverlist

# 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

ZENPIX="26.67"

# 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

WID=320

# Command to switch Sun Ray to that server

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

# Location of Zenity, which is used for Dialogs

ZENITY="/usr/bin/zenity"

# 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
fi


# Read the server list and create an array
SERVERS=`cat $LIST`
SERVERLIST="${SERVERS[@]}"


# 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"
        fi

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

$UTSWITCH $CHOICE

done

# 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 utchooser.sh 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

Footnotes

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. 

Monday Aug 06, 2012

Got Java (configured correctly)?

Have you ever had firefox crash with the following error when trying to access a Java-based application?

Didn't find JVM under /<path to>/firefox/plugins
Assertion failed: foundJVM, file ../../../../src/plugin/solaris/plugin2/common/JavaVM.c, line 104
Abort (core dumped )

I'm not talking about a sophisticated Java app here.  Just hitting the "Do I have Java?" test page on Java.com will crash Firefox and pretty much any Mozilla-based browser left with the default Java configuration.

Here's what the default (and incorrect) Java configuration looks like on pretty much every version of Firefox since 3.5.  You can see it by typing about:config in the URL bar, acknowledge the warning, and filter on "java" (click for larger view):


Stating that the default Java configuration is incorrect, really means that it's set to use the old Java plugin and (in most cases) a rather old version of Java.  This plugin that is configured by default is incompatible with Firefox 3.5 and beyond.   The first generation Java plugin is called javaplugin_oji and cannot be used with any modern version of Firefox. 

Unfortunately, even the latest Firefox (14 at the time of this post) comes configured to use the old Java plugin by default. 

This means that if you're trying to run a Java-based app on anything greater than Firefox 3.5, you'll wind up with a crashed app and a core file a few seconds after the browser tries to start Java. 

If you've been frustrated by not being able to run Oracle Forms-based apps, WebEx, or any other Java-based browser app on Solaris or Oracle Linux, follow the instructions below.  If you're an Oracle Forms user, get ready for smoking fast response time sans MS Windows and IE. 

Disclaimer: I know neither Solaris or Oracle Linux are supported clients for Oracle Forms-based apps.  Doesn't mean it doesn't work.  It, in fact, works great!  :)

First things first, learn the name and location of the "second generation" Java plugin.  The second generation Java plugin is called libnpjp2.so and is located in:

<path to java>/jre/lib/i386/ for x86 based machines

<path to java>/jre/lib/sparc/  for SPARC based machines.

NOTE:  The second generation Java plugin was introduced in Java 1.6 update 10.  Ensure that you aren't running an older version of Java, if you are upgrade.  Solaris 10 U9 ships with 1.4.2_26, so that will need to be updated in order to access Java-based apps with Firefox 3.5 or greater.

TIP:  Sun Ray Software and Oracle VDI always ships with a relatively recent Java release.  An administrator can symlink these installations to /usr/java.  This will ensure that the browser's Java configuration will always be as current as the JRE used with Sun Ray Software or Oracle VDI, even across upgrades of those products.

For a Sun Ray Server:

rm -rf /usr/java
ln -s /etc/opt/SUNWut/jre /usr/java

For a Oracle VDI server:

rm -rf /usr/java
ln -s /opt/SUNWvda/java /usr/java

Note: The remainder of these instructions assume the following three things:

1) Java, greater that 1.6 U10, is installed (or linked to) /usr/java
2) Firefox, greater than 3.5 is installed in /opt/firefox.
3) The platform is x86

If any of those assumptions do not match your environment, just substitute the correct paths to Java, Firefox, and the correct platform (i386 or SPARC) for your environment


Step 1) Configure Firefox plugins directory

1.1) Create plugins sub-directory under /opt/firefox.  

The plugins directory doesn't exist by default since about Firefox 6, so you'll have create it.  Just create /opt/firefox/plugins and change the permissions so everyone can read/execute the contents:

mkdir /opt/firefox/plugins
chmod -R 755 /opt/firefox/plugins


1.2) Create symlink the new plugin in /opt/firefox/plugins/

Given the location and platform assumptions above, create a symbolic link in /opt/firefox/plugins that points to /usr/java/lib/i386/libnpjp2:

ln -s /usr/java/lib/i386/libnpjp2.so /<path to>/firefox/plugins/libnpjp2.so

Note:  Do not "copy" the library to the plugins directory, this will not work.  The plugin is dependent on the relative path of where it resides.  This is different than other plugins that you may be used to installing such as Acrobat Reader or Flash.

1.3) Remove any symlinks that point to the old java plugin.

rm /opt/firefox/plugins/libjavaplugin_oji.so

Note: Some sites may use a personal plugins directory.  If so, be sure to remove any symlinks for libjavaplugin_oji.so from $HOME/.mozilla/firefox/*.default/plugins

1.4)  Test.  At this point, accessing the "Do I have Java" test page from java.com will now succeed and tell you are using the second generation plugin, but certain apps, such as Oracle Forms and WebEx, will still fail. 

Now that the correct second generation plugin correctly linked to the Firefox plugins directory, it's time to tell Firefox the name of the plugin and the location of Java.


Step 2) Configure Firefox with the location of Java and the name of plugin

Note: This step needs to be done by each user who has ever ran Firefox with the old Java configuration. 

2.1) Open Firefox
2.2) Type "about:config" in the URL bar and acknowledge the "I'll be careful" warning
2.3 ) In the Filter Box, type java and hit return
2.4) Set both java.default_java_location_others and java.default_java_location_solaris to: /usr/java
2.5) Remove/blank out the existing entry under java.global_java_version_file (as the file referenced there does not exist)
2.6) Set the java.java_plugin_library_name to libnpjp2 (or libnpjp2.so, either will work)
2.7) Remove/blank out the existing entry under java.private_java_version_file (as the file referenced there does not exist)
2.8) Close and re-open firefox.  Enter about:config in the url and ensure the settings took place.

The about config screen should now resemble this picture (click for larger image):


2.9) Test out a Java based app, such as WebEx or Oracle E*Business Suite (EBS uses Oracle Forms).  The applications should work correctly, and more importantly, firefox should not crash anymore. At least not due to an incorrect Java plugin configuration!

Step 3) Create default Firefox preferences file for new users

This will prevent first time users of Firefox (or those who wanted to create a new profile) from having to perform the actions in Step 2.  To do this, the administrator creates (or appends to the contents of) a file called prefs.js under the firefox default profiles directory and fills out these values for all new users.

3.1) Create the default profile directory, if one does not exist under /opt/firefox/defaults/

mkdir /opt/firefox/defaults/profile
chmod -R 755 /opt/firefox/defaults/profile

3.2) Edit /opt/firefox/defaults/profile/prefs.js

The contents of prefs.js for a proper Java plugin configuration would be:

# Mozilla User Preferences
user_pref("java.default_java_location_others", "/usr/java");
user_pref("java.default_java_location_solaris", "/usr/java");
user_pref("java.global_java_version_file", "");
user_pref("java.private_java_version_file", "");
user_pref("java.java_plugin_library_name", "libnpjp2");



That's it.  All users should be good to go for running Java-based apps on a modern release of Firefox.

Tuesday May 10, 2011

Sun Ray Software 5.2 Now Available!

If you've been eagerly awaiting Sun Ray Software 5.2, the wait is over! 

Highlights of this release include:
  • Real-time audio support and audio bandwidth optimizations.
  • Better multimedia.
  • An integrated installer. This combines the server side components that were previously installed separately into one installation package.
  • Support for more smart cards.
  • If you're using Solaris IPMP, Sun Ray Software 5.2 now supports it.
Go get it, or read the press release.

Thursday Apr 07, 2011

Sun Rays are "Citrix Ready"

Meet the three newest members of the Citrix ReadyTM family of Thin Clients. 

While the Sun Ray has always been a capable client when paired with Citrix, it's now official.  This classification is for XenApp, but we will also be pursing the same classification for XenDesktop which has its own set of tests. 

If you are ever in a situation where you're deploying a certain Healthcare EMR application, and you are told by a vendor that Sun Rays are not supported because they are not "Citrix Ready", be sure to point that application vendor here.




Thursday Jan 27, 2011

Eco-Enterprise Webinar

Hey, you!

No, not you on the Sun Ray.

I mean "you" over there, the one killing our planet with a kilowatt consuming thick client.  Point that energy hungry beast over to http://bit.ly/dOtAWL and join Michael Dann and myself for webinar where we will be discussing greening the enterprise with Sun Ray clients.   Find out how how Sun Ray Clients can help your organization meet its green computing objectives while providing  a rich desktop experience that offers high security, improved mobility, and excellent manageability over existing PC-based infrastructures.

Monday Jan 24, 2011

Sun Ray Software 5.1.2 Maintenance Release Available

Oracle has just released the second maintenance release to Sun Ray Software 5.1.

This release is available on My Oracle Support to customers with a valid support agreement.

To find this patch, click the Patches and Updates tab and in the Search section enter the Patch ID 11659754.

This release addresses the following issues. 

Sun Ray Server Software
  • 6623503 - utfwload doesn't list the DTUs showing yuvicons
  • 6623505 - utwho doesn't list the DTUs showing yuvicons
  • 6767357 - RHA loops on disconnect/reconnect when previous RHA greeter didn't exit for some reason
  • 6879782 - "Line in" option should be grayed out in Audio Input as Sun Ray 3 plus DTU doesn't have Line in port
  • 6928850 - "Line in" option should be grayed out in Audio Input as Venice DTU doesn't have Line in port
  • 6895777 - utseriald mutex locking needs cleanup
  • 6969162 - Default control chars wrong on Linux serial ports
  • 6969188 - Missing ioctls on utseriald on Linux cause "stty --all" to fail
  • 6920052 - utdevctl can fail to establish contact with the DTU on lossy networks
  • 6922945 - Multihead re-configuration takes about 50 seconds occasionally
  • 6926827 - "utdesktop -a" with specific characters could cause error in "utpushd"
  • 6932123 - Support for the Evoluent "Vertical Mouse 3"
  • 6970293 - HP laserjet model number P3015 dn does not work with SRWC 2.2
  • 6988752 - USB library fix for HP P3015 dn printer (for 4.2_patch only, N/P for 4.1_patch)
  • 6971449 - SRSS X visuals on Linux need to expose RGB pixel byte order
  • 6968005 - need capability to support RGB pixel byte order
  • 6977061 - Lost packets issue on SR3/3i (MiTAC)
  • 6985280 - SR3 DTUs suddenly reset after receiving specific types of network traffic.
  • 6985708 - Xnewt crashes when running 3D applications
  • 6981354 - Exiting Autocad 12.0 GUI causes user's Sun Ray Session to exit and requires user to log back in
  • 6990471 - "Force Full Duplex" option not working on Sun Ray 3 Plus
  • 6993384 - Xnewt default font path should use unscaled & scaled modifiers
  • 6993679 - Lock screen text is garbled in Japanese locale because 6811761 fix is incomplete
  • 6995619 - uttsc-bin aborts if DISPLAY is set to IP-addr:<X>.<s> (s = screen# of SR mutihead group)
  • 6996009 - Sun Ray 3 family (3/3plus/3i) firmware should include the fix for CR# 6910599
  • 7004863 - utkioskoverride can core because libutadmin mallocs wrong size
Sun Ray Connector for Windows OS
  • 6942148 - uttsc often crashes while using Novell GroupWise client (version 8.01)
  • 6973511 - Clicking on the close advert link in hotmail.com will cause uttsc to exit abnormally
  • 6973512 - Uttsc dies when accessing a website with the Sun Flash MMR extension installed in Internet Explorer
  • 6991409 - uttsc-bin process crashes or spikes up CPU utilization to 25% after IE process crash or killed
  • 6991978 - Frozen XP Desktop session on VDI 3.2 with latest Sun Ray Software patches
  • 6993074 - Windows Connector segmentation fault with -r sound:off or -r sound:remote on Windows XP/2003
  • 6993438 - Session does not get redirected with windows 2008 R2 when Security Layer is set to Negotiate
  • 6995350 - Make pulldown header available in non fullscreen mode when no Window manager is running
  • 6995342 - Minimize option in pulldown header should be disabled for VDI kiosk - the functionality doesn't work
  • 6995351 - The pulldown header should get a modern look
  • 6995358 - Add new optimized hotdesking mode that allows follow-me printing
  • 6997715 - Printer redirection fails when -i or -p options used with uttsc
  • 6999683 - Disconnections of uttsc at VM's boot up
  • 7002809 - uttsc session hangs when connected to Windows 2008 R2 during start up sometimes

Tuesday Jan 11, 2011

VDI In The Sky: Encore

A while back my colleague ThinGuy posted a blog entry called "VDI In The Sky" showing photos of the Oracle Virtual Desktop Client on a Netbook accessing a Oracle VDI hosted desktop from 30,000 feet.   On a trip I took to San Francisco I could not help wanting to try it myself.  I often talk of the benefits of the Sun Ray Appliance Link Protocol to customers.  With wifi service available on many airlines and at reasonable prices for business travel I was in luck.   

As a side note, when I am discussing with customers the concept of Virtual Desktop Infrastructure I always get the "What about when I am not connected like on a airplane?" question.  I ask you to look at the evolution of being connected (or "Online") and the pace of the adoption of network technologies making network access ubiquitous.   It is amazing how quickly network access and network speeds have evolved.   So I ask in return, "When are you not connected?  if you are not, do you really have much to do?"

So there I was on a plane in premium economy with a bit more leg room, wifi internet access, a Cisco VPN connection to my lab,  and the Oracle Virtual Desktop Client installed.  It was too hard to resist trying what Thinguy showed, so I fired up my mobile phone video recorder and gave it a try (Sorry for the shaky hand but typing and recording at the same time was a challenge)

I couple of things I want to point out as you watch this:

  1. The internet access was from 30,000 feet traveling at several hundred miles per hour (A incredible networking feat on it's own)
  2. The greatest challenge to using internet access on a airplane is "Latency" that impacts the user experience by having to wait for those emails messages to load,  files to download / upload,  or in this case for the screen to draw a VDI hosted desktop.   Latency is measured in milliseconds (ms) and on your home broadband network will likely be in area of 100ms to 150ms depending upon what you use.  Over airplane wifi connections you will see in this video it is 300ms to 400ms latency and it is not consistent, it changes up and down frequently thanks to the plane's airspeed.
  3. In order to access my VDI hosted desktop securely I needed to create a VPN tunnel so now I have added IPsec encryption to the 300-400ms latency. 

My goal was to answer the question "Would accessing a Virtual Deskop from 30,000ft at high latency be usable or just a gimmick?" I will certainly say that playing youtube videos over this connection is entirely unreasonable so I did not even try.   I set out to access a variety of desktops - Windows 7,  Windows XP, Windows Server 2003, Windows Server 2008, and Ubuntu Linux all accessed by Oracle VDI software.  My focus was on the following tests:

  • Responsiveness of the Oracle VDI login and desktop selection screens
  • Initial desktop screen draw time and pix-elation  from network delay.  Initial screen draws are typically the largest.
  • Mouse click response time such as selecting windows manager functions and having them respond reasonably.  Click delays will drive even the most patient user crazy.
  • Determine the impact of accessing different desktop back-ends such as Windows Server, Windows 7, and Ubuntu Linux

I could have spent hours on different tasks but I chose these basic ones for the sake of time and so I have a reason to test other things on another trip ;-)

Some conclusions for me:

  • The usability for displaying a desktop is very good for a variety of desktops with Oracle VDI using the Sun Ray Appliance Link Protocol
  • I could certainly do more over this connection with remotely displaying a VDI desktop and applications.  Data intensive tasks are better left in the data center such as:
    • Trying to load a large inbox to a mail client and open attachments. When opening mail using a VDI hosted desktop that one big attachment can be opened in a few seconds rather than loading it into a mail client over the airplane wifi at high latency
    • Many applications are accessed by a browser and are very "chatty",  meaning they frequent transactions back and forth and will suffer by high latency on a WAN. These applications will perform well in a VDI model since the browser and the applications are on a data-center backbone and not on a WAN.
    • Trying to access large files from a home directory.  Users can load any size file needed into OpenOffice that resides a VDI hosted desktop and not worry about the data transfer time to a laptop
    • I prepared a presentation during travel time and never had to close then re-open the file.  Same thing goes for email messages I was editing.
So what is the big deal?  Why VDI in the sky anyway?
  1. Corporate and customer data are completely secure in the data-center. (As long as it is kept there)
  2. Desktops OS and personal data are backed up transparently - Less time spent as a desktop administrator and more time for what users are paid to do.  (Example: My corp laptop is old and makes unnerving noises at times so I am worried)
  3. With Oracle VDI users can have a variety of desktops and not be limited by the hardware they carry - Windows XP, Windows 7, Ubuntu Desktop, Oracle Enterprise Linux, Solaris, and more.
  4. Tasks can be started then disconnect and reconnect from them as needed without having to restart from the beginning
  • Think editing a OpenOffice presentation, document, spreadsheet and not having to worry if your laptop battery dies losing critical changes
  • The ability to access any size file a user needs whether it is in email, on a home directory, or on a company shared folder and not be impacted by limitations of the network being using at the time
  • A developer can load source files into development tools and run tests or compiles then disconnecting while traveling and  knowing they keep on running as needed

There are many more examples that I will save for a forth coming blog series called "Why VDI"

 Thanks for reading

Wednesday Dec 22, 2010

Sun Rays\* and Round Robin

\*While the title of this blog is misleading, know that my intent is to help people find answers via search engines.  In reality, this post is about using operating systems that perform caching of resolved DNS names and how it can affect name resolution.  Nothing to do with Sun Ray, except the fact that they are the most widely used client for readers of this blog.

Every once in a while a problem shows up where an application or script installed on a Sun Ray server always connects to the first server in a list of hosts that has been configured for round robin in DNS.  Typically, this is noticed in kiosk mode where something like the Sun Ray Windows Connector is pointed at a DNS name that is configured to round robin (RR) through multiple Windows Servers hosts running Terminal/Remote Desktop Services.  Sun Ray administrators are often left scratching their heads as to the root cause.

The most common initial reaction is that the DNS server is setup incorrectly (I'll plead guilty that I've had the same reaction).  It is true that some DNS servers can be configured will return the same IP on the initial DNS query.  This is called a cyclic ordering and  results in the first IP address of the resolved name on every client to be identical.   For example, if a DNS server is set for cyclic ordering, every first request for the IP address of xyz.com will be that of "Server A" on all clients. The second query from the same client for xyz.com should result in "Server B" being resolved (if not, then you do have a DNS problem).  However, in the case of Sun Ray Server, the "second query from the same client" would be from the second Sun Ray session.  As far as the DNS server is concerned, all the Sun Ray sessions (at least those on the same server) are coming from the same client.  Therefore, even with cyclic ordering, round robin should work as expected (or even better) in a Sun Ray environment as compared to a "fat" client environment. You can check the documentation for specific DNS servers on how to set a random order for round robin (which should be the default), but know that chasing down cyclic ordering of RR entries as a cause to this "issue" is basically a red herring in a Sun Ray environment.

The most likely culprit in this scenario is a side effect of the name service caching daemon (nscd) that is active on the operating system where Sun Ray Server Software (SRSS) is installed.  The job of nscd is to speed up name resolution of a lot of things; hosts, groups, and in the case of Solaris, even things like user attributes (i.e. RBAC).  However, we are primarily concerned about the caching of host IP addresses.

The truth is that nscd usually breaks round robin scheme as it caches the first server returned by the first query from the "caller" (i.e. the host doing the name lookup, aka in this case the Sun Ray server) and all applications/scripts on the caller will use that address for the lifetime of the cache (TTL). The default TTL of the nscd cache on Solaris and Linux is 3600 seconds (an hour).  If you think that TTL is long, consider the similar mechanism on Windows is 86,400 seconds (1 day). 

On Solaris to disable the caching of hosts, edit /etc/nscd.conf on every Sun Ray server in the host group (aka FOG) and uncomment the line that reads "enable-cache        hosts           no".  To completely disable the name service caching daemon for Solaris 10, run the following command on every Sun Ray server in the host group (aka FOG): svcadm disable system/name-service-cache

On Linux to disable the caching of hosts, edit /etc/nscd.conf on every Sun Ray server in the host group (aka FOG) and change "enable-cache        hosts           yes"  to "enable-cache        hosts           no".   Then restart nscd /etc/init.d/nscd restart  Note that utilities per distro can vary, for instance on Oracle Linux or Red Hat you could run authconfig --disablecache to completely disable nscd.

On Windows...Ok, I'll include it for fun even though SRSS does not run on Windows.  Every release of Windows after Windows 2000 has an nscd like feature called "dnscache".  To permanently disable dnscache, use the Services control panel applet to set the 'Windows DNS Client' service to disabled.  Note that this service may also appear as "Dnscache."  You can stop caching temporarily until next reboot with net stop dnscache

If the caching of host names is still desirable on your platform, yet you'd like to shorten the cache life to something that more suits your needs, that is possible too.  Just read the man pages for nscd, though I'm sure if you made the edits above you've figured the cache TTL already.  For Windows, google "windows client dns cache".  Normally I'd just to post a link to technet article, but in my experience, Microsoft has been about as reliable with "permalinks" on support articles as a 20 year old Yugo would be on cross country road trips five year old PC having Windows 7 drivers available.

For those running Sun Ray Server Software on Solaris, there's one final step.  An über smart colleague (Ed. Note: I just love that he is listed as a "Newbie") mentioned the possibility of another problem that could exist in a Solaris environment, even if nscd is disabled.  This has to do with hosts on the same subnet as the caller and the default behavior of the Solaris resolver library.  By default, the Solaris resolver library puts servers that reside on the same subnet as the caller at the top of the sort order. You can read the notes in the Solaris man pages for "gethostbyname" and  nss(4) for more information, but both reference how this behavior can break round robin. The fix is to edit /etc/default/nss and uncomment (or add) the statement SORT_ADDRS=FALSE

Following these changes should allow sessions on your Sun Ray Server to behave as one would expect with round robin DNS entries. 

Happy Holidays and Happy computing resolving!

Thursday Oct 28, 2010

Documentation Updates for Sun Ray Software 5.1 and Sun Ray 3 Series Clients

Sun Ray 3 Series ClientsWe've had some product announcements the past few months and I want to make sure you all remember where to find the latest documentation.

The Sun Ray 3 and Sun Ray 3i clients are now available and you can find out all about their technical specifications and cool environmental stats on the Sun Ray Hardware Information Center.  If you need additional information about these thin clients that you can't find on the site, don't hesitate to ask.

Just this week, we announced the new Sun Ray Software 5.1 release, which has a number of new features aimed at the Windows connector feature (SRWC).  Check out the SRS 5.1 product documentation.


Saturday Oct 02, 2010

Bein' Green

Kermit was right, it ain't easy being green.  To create truly eco-friendly products, you have to consider their entire life-cycle.  From supply chains to disposal, Oracle has worked hard to make the Sun Ray 3 family the most efficient and environmentally friendly thin client ever.  The 98% recyclable (and ENERGY STAR® 5.0 Thin Client Category A certifiedSun Ray 3 and Sun Ray 3 Plus even share the same eco-friendly box.  A space saving box that was designed from the ground up using recycled materials to maximize palletization, thus reducing the carbon footprint when shipping the device from the factory.  With a 20 year MTBF, "WEEE" expect Sun Ray 3's to be around for a long, long time.  For more information and facts about the green design of the Sun Ray 3 family, check out Michael Dann's Oracle Technology Network webcast.

Sun Ray 3 Sun Ray 3 Plus

Monday Sep 20, 2010

New Arrivals to the Sun Ray 3 Family

The Sun Ray 3 Plus is proud to announce the arrival of two siblings.  The Sun Ray 3 and the Sun Ray 3i.

Check them out!

Datasheets:

Friday Sep 03, 2010

Sun Ray 3 Plus with USB Speakers

While not "VDI In The Sky" (Man that was cool!)  as a every day user of my Sun Ray 3 Plus I try to play music while I work.  I wanted a bit better a sound experience along with the portability that Sun Ray mobile session technology provides.    I came across some very well rated yet inexpensive USB powered speakers and gave them a try.  Since all I need is a USB 2.0 port and a audio out port (Which a Sun Ray 3 Plus has) I was good to go.

See the results

To better clarify on what is being used for the audio and to show the cool Sun Ray Session Mobility feature I added another short clip.

Wednesday Aug 18, 2010

VDI In The Sky

On a recent trip (my first as an employee!) to Oracle HQ, I decided to test out Oracle VDI 3.2 from an airplane.  Sure, everyone (who can...if the latency will allow their protocol to work that is) has done this, but hey it's been my first trip since being part of the Big O.  One could say I don't travel like I used to. 

Unfortunately, I was a bit ill prepared to do this demo from a battery standpoint on my video camera, but still managed to get some screen caps with my phone.  On my next trip I'll bring my flip fully charged to get the full sequence.  But I'll tell you, from some 30K thousand feet, 300 ms (plus) latency, it did awesome.  While it won't surprise most to know I really believe in our technology, I did all of this on my own dime.  From the the gogo inflight internet to the first class upgrade.  Hey, us tall folk need space to work!

 My Building:  (The "Big Building" if you know what I mean)


Somewhere over the Mojave:


And Let's Connect:


Picking my Windows 7 Pool: 


And here we are: 


This is the Virtual Desktop Client in windowed mode. It's hard to make out the latency, but it's over 300: 



OVDC and MTU

A few years ago I wrote about the "Importance of MTU" as it pertains to Sun Ray clients.  Things changed with the Sun Ray and in most circumstances, we can detect and adjust the Path MTU accordingly.  While the Oracle Virtual Desktop Client (OVDC) is designed to be just like a physical Sun Ray, for various reasons it currently lacks the Path MTU Discovery (PMTUD) code.  In short, what's old is new again..Or is it what's new is old again.  Either way, you need to set the MTU for the best experience (improper MTU demo video below).

You can set the MTU with a slider from the network tab:

Unfortunately the slider isn't as precise as you might need it and seems to jump in blocks ranging from 6-8 (i.e. try to set yours like mine with an MTU of 1333 and good luck!).  If somewhere within that range lies the your value, you can use the command line to set a precise MTU.  Simply run the vdc command with the --mtu argument.

For Windows:

C:\\Program Files\\Oracle\\Virtual Desktop Client\\vdc --mtu 1333

For OS X:

/Applications/Oracle Virtual Desktop client.app/Contents/MacOS/vdc --mtu 1333

The MTU setting is sticky and will stay for all subsequent connections, unless of course you use the slider and change it.

Quick (no audio) Video of what an improperly set MTU looks like:

Monday Aug 16, 2010

Oracle VDI 3.2 In Action!

An attempt to use Jing here.  Even went "Pro".  Still a five minute limit and I got cut short, but you'll get the gist.  Check out the functionality!  Big hat tip to the folks in Hamburg, Leeds, and Dublin.  :)  (I just realized I have 2GB traffic limit per month with pro...I'll see what I can do)

(And no, I cannot tell you why Javier was not ruled offsides there. )




Oh, and Jaap...this is for you.

Friday Jul 30, 2010

Multi-Core or Hyper-Threaded? Or Both?

Recently a question was posed to the Sun Ray User Community:  Intel or AMD for Linux Sun Ray Server?

Ford vs Chevy!  Coke vs Pepsi!  What a great blog topic for a Friday.

You could choose from dual Intel 6 core X5670 2.93 GHz ("Nehalem") or dual AMD Opteron 12 core 6168 1.9 GHz ("Magny-Cours")

Of course the "I love my job and I'd really like to keep it" answer would be Intel since Oracle does not offer any servers based on the 12 core Opteron (just 8 core models).  But let's throw caution to the wind and think about this in the context of what a Sun Ray Server in "traditional" mode (i.e. not kiosk mode) really is.  It's a desktop.  Unlike kiosk mode where normally applications execute "somewhere else" (i.e. terminal server, a VM, etc) in traditional mode the applications execute on the Sun Ray Server.  Unlike a desktop, it's multi-user.

So while you definitely want something "server class", you also want something that is going to run \*your\* applications at the best price/performance ratio.

At the end of the day, both options offer 24 threads.   The Intel solution does so by offering 6 Hyper-Threaded Technology (HTT) cores per socket and the AMD by offering 12 single threaded cores per socket.  There's a 1 GHz clock speed difference favoring the Intel solution, but let's not fall prey to the "megahertz myth".  Not just yet anyways.

While you can go out there and find all kinds of "Bench This", "Spec That" types of reviews, those tests are generally written to take the most advantage out of any platform.  However, most of the end user applications we all use aren't.

So, which design is better for "desktop applications", Intel with HTT or AMD with all those glorious physical cores? 

Here's I get to use the most popular, catch all answer of all-time when it comes to any Server Based Computing or VDI question. 

It depends. 

It depends on the applications.  Doesn't everything?

Recent history would indicate that desktop applications prefer the multiple cores over HTT.  Or perhaps better stated, the developers of those applications may prefer multi-core development (or at least find it easier).  

Remember that Pentium HTT ("Northwood") actually was replaced on the desktop in favor of  multi-core processors (see CoreDuo). In a traditional Sun Ray environment where a variety of "desktop applications" execute on the Sun Ray Server, understanding some of the possible reasons HTT was replaced by multi-core is interesting, if not important.

When HTT was introduced, most desktop applications simply weren't able to take advantage of the it.  Add to that, the HTT chips actually consumed a lot more power.  End result was a system that increased your energy costs while decreasing your application's performance.  Explain that one to your boss, Mr Technology influencer.   Especially with "all those CPUs" showing up in mpstat or perfmon.

None of that of course was the fault of the technology, well the power was, but not the bad performance or the misconception of threads as physical processor that sits in a socket.  Truthfully our traditional performance monitoring tools still promote that misconception.  The performance was due to applications not taking advantage of the HTT and it being on a single core.  Didn't it seem like around 2004-05, the catch-all response to all desktop application performance queries was: "Pentium 4, you say?  Did you try disabling Hyper-Threading in the BIOS?"

With Nehalem, Intel put all that bad PR behind them and brought HTT back to the desktop, but with a twist, it's also multi-core.  

This is different, but is it better?  Maybe.  Maybe not.  Probably, but...it depends.  (Ha!)

We know that the OSes are better equipped for HTT (i.e. Solaris is now optimized for it along with a million other things), and they actually don't consume that much more power, so they are "greener".  Goodness for the data center.

From my experience, I'd say both Sun Ray Software and the Oracle VDI stack performs better with HTT (based on sizing numbers in kiosk mode and per core VM sizing data under Solaris) than they did under the non-HTT models of those chips.  Considerably better, all other things being equal (clock speed, # of cores, etc).  But those aren't typically considered "desktop applications", they are more in the realm of pseudo-operating systems, or at least "Server Systems".  Both of which have been HTT aware for a long time, but that doesn't exactly help \*your\* application.  Which leads us to the million dollar question:

How many of the applications that you use today are parallelized so they can execute across multiple threads simultaneously (i.e. HTT aware)?  If the answer is "very few" then you're not taking advantage of the Intel design and the physical cores on AMD solution may actually perform better for your apps even with the "lower clock speed". 

Making applications multi-core aware is fairly easy (says the non-programming "developer"), and most existing applications already support this.  However adding HTT capabilities to existing applications is considerably far more work.  And sure, there are those that will say that HTT can help certain multi-core aware applications depending on what they are doing. Though I think a lot of these arguments mistake multi-threading for Hyper-Threading, which in fact is simultaneous multi-threading.

But really, to get the most out of HTT, you need to code your applications a certain way.  Intel has guides, and all kinds of tools to aid the application developer get the most out of HTT.  But what if those aren't used?

In a single user use case, the average person might never know the applications they are using aren't taking advantage of HTT technology because of the multi-core and relatively high clock rate. The HTT multi-core becomes a Swiss Army Knife so to speak.  If your app can take advantage of HTT, great.  If it can't, we've got cores.  And on top of that we have speed!  That's beautiful for a PC.  A single user PC.

But how well does it scale out when we are talking about multiple users running those "non-HTT aware" apps on the same server? In the AMD design, multi-core (but non-HTT aware) apps have 24 "physical" cores to work with, what's the trade off of the "virtual" cores on the HTT chips?  Is the clock speed enough to overcome? The other features on HTT chips enough to tip the scales? Maybe.  Probably.  It depends.

If you were running Sun Ray Server Software in Kiosk mode or choosing a server to be the hypervisor for Oracle VDI, go with Intel and their HTT "Nehalem" processors.  You won't be disappointed.  At least I haven't been.  I'm sure I'd also have a lot of good things to say about the AMD as well.

But if you are actually running desktop apps on the Sun Ray Server, and trying to do so at any kind of scale, I'd say it's at least worth doing some investigating and maybe even some application testing at scale.  Then you can really understand what's the best fit for your environment.

Monday Jul 19, 2010

Sun Ray Connector for VMware View 4 Available

In a recent post I highlighted some new features offered for Sun Ray Software 5.  If you actually read the press release, you probably saw mention of a "Sun Ray connector for VMware View 4".  And you might be wondering why I didn't blog about it in that recent post.

Since people are asking about it,  I thought it would be smart to provide the link to the actual software.  You can download the Sun Ray Connector for VMWare View 1.2 Manager today.  You can also read the Installation and Configuration Guide.

Why didn't I mention1 this new feature?  I was actually waiting to blog about it once the VMware HCL pages reflected both the new software and Sun Ray 3+ as being View 4 Certified under a search for "Oracle".  But since the software is available, why wait?  The certification process is done, and we are just waiting on web pages to be updated, so have at it.

Update:  Since I was already asked if the VMware View 4 certification applies to only the Sun Ray 3 Plus, I thought it best if I addressed that here as well.  If you understand the Sun Ray Architecture (i.e. nothing runs on the Sun Ray itself, it all runs on the Sun Ray Server) , there's no reason to have any correlation between the actual Sun Ray device models and our Sun Ray Connector for VMWare View.  However, that's not how VMware does their HCL (or one can read that as nothing else is like a Sun Ray). So in short, this will work with everything from a Sun Ray 1 to a Sun Ray 3+ (including the OVDC) though our MMR features will vary.   We've asked VMware and we will have to wait to see how open they are to a single entry that reads "All Sun Ray Clients".

1Since I'm all about honesty, now I'll tell you the real reason I didn't mention it.  I \*thought\* we were going to name it something easy to remember that,  you know, made sense to someone looking for a Sun Ray connector that was certified to work with View 4.  Perhaps even something catchy like "Sun Ray Connector for VMware View 4".  When looking at the download page I saw "Sun Ray Connector for VMware View 1.2 Manager" and thought it was the old version. Note this is purely my opinion and it is not that of my employer, nor is it meant to disparage, poke fun at2,  or otherwise make those who named the product feel bad.  I honestly thought we were changing the name.

2 OK, I may be poking fun, but it is well intended, utmost respect, kind of poking fun.

Saturday Jul 17, 2010

<Sarcasm> Oracle executives don't care about Sun Ray </Sarcasm>

Pictures speak louder than words.  Although, there are quite a few words on the Official Oracle Virtualization Blog\* too. :)

Check out the office of my boss's boss.  (Psst.  You can follow him on Twitter @wimcoekaerts )

 While it's true we are far less transparent than a lot of you are used to, we are no less passionate about, and dare I say more committed to, our portfolio than ever before.

\*Don't worry, we will keep Think Thin going and continue to be focused mainly on Sun Ray, SGD, and Oracle VDI.

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).


Wednesday Jul 14, 2010

PC/SC-Lite 1.3 Released

The Oracle Desktop Virtualization Team is proud to announce the availability of  PC/SC-lite 1.3 and CCID IFD Handler 1.3.10 (enables PC/SC-lite to access external USB Smart Card readers) for Sun Ray Server Software running on Solaris 10.  The packages are available for download here.

This update is recommended to increase security and improve stability of smart card use in a Sun Ray environment.

The 1.3 release contains two critical bug fixes and incorporates the fix for security vulnerability CVE-2010-0407 discovered in the M.U.S.C.L.E. open source project, and described at the National Vulnerability Database website.

As always, please see the PCSC-Lite and CCID IFD Handler release notes for more information.

Tuesday Jul 13, 2010

Sun Ray Boot Process Defined

Hello Think Thin Readers,

I am proud to present a new page on the Sun Ray Software Wiki, a detailed work flow of the Sun Ray Boot Process.  This took a bit of work to get into human readable format on behalf of several people, not the least of which are Paul Kasper and (the non-blogging) Kent Peacock.  Please take a look and provide feedback!

Enjoy

About

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

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today