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.

About

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

Search

Archives
« August 2012
SunMonTueWedThuFriSat
   
1
2
3
4
5
7
9
10
12
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today