Saturday Aug 11, 2012

One Blank To Rule Them All

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

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

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

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

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

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

X Server Blanking:


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


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

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

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

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

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

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

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

Mobility Security Features (screen-locking)


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


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

Remote Hotdesk Authentication (RHA)

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

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

Energy Star Features:

Sun Ray 3 Power-Off Feature

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

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

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

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


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

Video Blanking (local firmware configuration)

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

Energy Star Monitors

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

     xscreensaver &


# End of utNoBlank


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


« August 2012