Think Thin: Thin Client and Server Based Computing Group Blog

[Read More]

I've made to updates to the Turbo CAM post.  One of them is critical as it turns out that the utprodinfo hack breaks NSCM session.  It could possibly break other things yet to be discovered so use at your own risk.

The other was a fixed to the Java_Opts as the line I asked you to replace, never existed.

Never trust me for QA. 

<Sigh>

If you read my earlier post, you'd see a caveat that states "xvkbd requires a window manager, so leave dtsession as an application to launch in CAM".

Well, that's not entirely correct.  In fact it's not correct at all.  Rdeskop, Sun Ray Connector, and Even SGD work just fine if you try to lock the screen without dtsession.  The trick is to not have utaction call a script.   i.e.:

/opt/SUNWut/bin/utaction -i -d "/usr/openwin/bin/xvkbd -text '\Ml'" &

(or what ever sequence you need...See the post mentioned above for SGD, XP, Win2K)

But...(there is always a but).  It does not work with Citrix.  It only seems to work with Citrix if you have dtsession enabled.

Until now.  You can dump dtsession and have the smart card lock the screen using xvkbd using Citrix.  The trick here, not really a trick, is to have utaction call a script.  It's the magic in the script that tells xvkbd what window to send the keystrokes to.  Let's say your CAM script that called Citrix looked like this:

#!/bin/sh
set -x
/opt/SUNWut/bin/utaction -i -d "/opt/Citrix/winlock" &
/usr/lib/ICAClient/wfica -desc Desktop

Your winlock will look like this:

#!/bin/sh
set -x
WINID=`/usr/openwin/bin/xwininfo -name "Desktop "|grep xwininfo |awk '{print $4}'`
/usr/openwin/bin/xvkbd -window $WINID -text '\Ml'

The key is the -name part.  It actually matches exactly what you call your published app (i.e. the -desc part of your wfica script).  It also needs to be in quotes and have the trailing space.  If you have a different name, you can figure it out doing the follow:

Before removing dtsession, add a new CAM app for dtterm (/usr/dt/bin/dtterm).  Set it to be default so it launches.  So on your screen you may have a full screen Citrix session and a terminal.  The terminal may be behind the ICA window, so you might have to alt+tab to get to it.
Then you can just type xwininfo in the dtterm and click on the Citrix session to get the proper name (quotes/# of trailing spaces/etc) to use for your winlock script.

That's it.  This little tip will save you at least 30 MB of RAM per session.

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

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

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

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

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

What: Increase Authd worker threads from 8 to 32.

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

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

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

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

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

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

Find the line that reads:

r)     setOP "r";;

And change it to this:

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

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

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

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

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

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

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

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

You can then use that script to set your variable.

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

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

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

What: Increase the initial and max heap size for Authd

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

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

Find the lines that read:

ETCDIR=/etc/opt/SUNWut
JAVA_HOME=$ETCDIR/jre
JAVA=$JAVA_HOME/bin/java

And add one more option:

JAVA_OPTS="-Xmixed -Xms128M -Xmx128M"

The end result of these changes? 

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

Note: This method does not apply to SRSS 4.0 and Kiosk Mode. For SRSS 4.0 see "man -M /opt/SUNWkio/man kiokuseradm"

I've been asked a few times how to add additional CAM users without having to run utconfig -u then utconfig again.  Usually I would instruct people on files to hack manually, but that's not the proper way.

Here's the proper way to add more CAM users.

Logon as root
Change directory to /opt/SUNWbb/bin
Run bbmkuser without any options, it will display the following:

# ./bbmkuser
current settings:
prefix: utcu
start : 150000
count : 25

What you can do now is run bbmkuser with the the -m argument. This will delete the current CAM users and then recreate them.  The three options are user prefix, Starting UID, and the number of CAM users to configure.

# ./bbmkuser -m utcu 150000 75
.........................
25 of 25 users deleted
...........................................................................
75 users configured

You can then run bbmkuser without any options to see the new settings:

# ./bbmkuser
current settings
prefix: utcu
start : 150000
count : 75



Remember to do this on each server in your FOG (fail over group)

        I have found that sometimes when I am debugging a new Controlled Access Mode (CAM) script, it can be frustrating to have to go back to the server for console access, particularly when I have CAM set for both card users and non-card users. Also, in trying to figure out why the script isn't doing what I think it should, it is handy to be able to check out the environment of the CAM user live. So, I tend to use a variant of the following script code to allow me to use a specific card to bring up a terminal window. From there I can check out the status of environment variables, etc, as well as launch other scripts or apps, to see what error codes or behavior I may be missing otherwise.
        In order for this to work, you need to know the Sun Ray TOKEN for the card you are going to use. The easy way to figure out the TOKEN value is to use the same process the script code uses, and that is to check the value of the SUN_SUNRAY_TOKEN environment variable. For example, using the Bourne shell (sh) use:

set | grep TOKEN

      Or if using C shell (csh) use :

setenv | grep TOKEN

        The resulting output will look something like this :

>set | grep TOKEN
SUN_SUNRAY_TOKEN=MicroPayflex.5001436700130100

        OK, now that you have your token, here is the code. Replace the 'MicroPayflex.5001436700130100' in the script code below with your own token from above.

# check for my card token and start terminal window if it is my card
if [ "`set | /usr/bin/grep SUN_SUNRAY_TOKEN | /usr/bin/cut -c 18-`" = 
"MicroPayflex.5001436700130100" ];then
#  my card for shell access

  /usr/openwin/bin/xterm

fi

        If you use the same card, then it's easy enough to re-use the same chunk of code, but if you find you've left you usual card at home, it's not too hard to change. I hope you find this as useful as I do.

Note: This method does not work for the new Kiosk mode found in SRSS 4.0 and newer. 

I've spent some time playing with configuring CAM applications without the GUI and wanted to share what I've found.

Here is what appears to work for me. This example creates CAM application called CAMstart. This must be performed on the primary FOG server.

NOTE:This does not install the CAM script nor any supporting applications on any of the FOG servers. This merely tells SRSS to launch a particular script when CAM starts. You must install your application launch script and application binaries on each member of the Fail Over Group

$ vi /var/opt/SUNWut/kiosk/config/CAMstart
name="CAMstart"
label="CAMstart"
pathapp="/opt/SUNWwbt/CAMstart.sh"
enable="1"
attribute="0"

$ chmod 777 /var/opt/SUNWut/kiosk/config/CAMstart

$ chown root:utadmin /var/opt/SUNWut/kiosk/config/CAMstart

$ echo CAMstart >> /var/opt/SUNWut/kiosk/useapps

$ /opt/SUNWut/sbin/utkiosk -i kiosk

$ /opt/SUNWut/sbin/utrestart -c

---

More information follows to help explain why this works......

CAM settings are stored in the Sun Ray Data Store so that they may be retrieved by all members of the FOG.

When SRSS is started after boot or utrestart, /etc/init.d/utsvc exports that information from the DS to flat files in /var/opt/SUNWut/kiosk

The files created from the directory export are:

• availapps - contains a line for each application which has been created but not enabled
• useapps - contains a line for each application which is enabled to launch at session start up
• kiosk.conf - contains all CAM configuration rolled up from availapps, useapps, config dir, and preferences
• config - This is a directory containing one file for each CAM application. These files contain name, mode, binary to start, etc.
• preferences - contains CAM mode settings (Session Action, CPU time, max sizes, etc)

The main point of interest is the config directory.

To add a new application you must create a new file in the config directory named the same as the CAM application name. This file will contain the following lines.

name=""
label=""
pathapp=""
enable=""
attribute=""

name - is the internal SRSS name of the application. This must be the same name as the file in the config directory
label - is the label that the application will get in the CAM mouse menu
pathapp - is the executable to launch when this app is started
enable - specifies if the application will be included in a new CAM session
attribute - specifies weather the application is Critical (0), Menu (1), Default (2)

You must then add the application to the useapps file so that the Web GUI will show it

echo CAMstart >> /var/opt/SUNWut/kiosk/useapps

After creating the file in the config directory and adding the application to use apps, the CAM configuration must be imported into the DS.

/opt/SUNWut/sbin/utkiosk -i kiosk

Then restart SRSS

/opt/SUNWut/sbin/utrestart -c

Editors Note: This debugging method no longer applies to SRSS 4.0 and Kiosk Mode. See the presentation on this post for more details:

Desktop Virtualization Days

When deploying applications via Controlled Access Mode, you are in some regards blind to what's really going on in the session.  For instance if you were to try to launch rdesktop as a critical application and unbeknownst to you, your script that is called by CAM had a typo in it. In this case you'd only see cycling on the Sun Ray.  Or perhaps Rdesktop was looking for a library that wasn't properly pathed in the CAM environment, yet worked just fine in a full Solaris desktop session.

Typically I always recommend that a customer create a CAM application that launches a terminal and that you try to test your CAM script from that terminal.  It's important that your CAM script contains command set -x up at the top of the script so the actions that the CAM script performs become verbose.

If that's not deep enough you can watch the entire setup and tear down of a CAM session by turning on the debug option in the kiosk.start file. You'll still want to have set -x in your CAM script as well.

Edit /etc/opt/SUNWut/kiosk.start

Twenty or so lines down you will find this:

# exec 2>/var/tmp/bbkiosk.$DISPLAY.$$ 1>&2  # Debug
#        set -x
#        set -u
exec 2>/dev/null 1>&2

Change this to this:

exec 2>/var/tmp/bbkiosk.$DISPLAY.$$ 1>&2  # Debug
set -x
#        set -u
#exec 2>/dev/null 1>&2

Outside of the creation of the log files this is non-invasive.  No restart or other changes need to take effect to make this happen.  As new CAM sessions start, debug files will start up in /var/tmp for each CAM Session.

Feel free to change the path if you want to contain the debug files in a different location.

Some Sun Ray deployments require having data on the screen at all times. The DTUs are being used for monitoring the current state of something or displaying reference data.

In these scenarios it is important that the screens are always active, and usually there is no mouse or keyboard to wake them from power saving/screen saver mode.

When used in CAM mode to connect to Windows, there are two screen blanks that can happen, one through the X server on the Sun Ray server and one with the Windows screensaver. The Windows screensaver is easily fixed with right-click on background and choose "None" on the sceensaver tab.

Since in CAM mode there is no GUI to configure the X screensaver, the xset command with the appropriate entries needs to be run after the X Session is started.

The solution is to add a line to the beginning of your CAM application script to execute the "xset" command before launching the interop client. (SRCW, SGD, etc.)

The correct command is:

 

xset -dpms -fbpm s off

After adding this line to your CAM script, any new sessions will get the change but old sessions will need to be reset to receive the change.

 

/opt/SUNWut/sbin/utrestart -c

This currently is an all or nothing fix. It will turn off the sceensaving feature for all users at once. You could configure the Windows screensaver to blank the screen after a period of time for individual users, but this will not let the DTU go into low power mode.

There is the possibility of using a script similar to the Folllow-me-printing script to enable/disable screen blanking on a per-DTU basis if necessary.

Have you ever wanted to have a quick little "Click Here to Start XYZ" type script?  If so this is for you.



A lot of my customers find this useful in Controlled Access Mode when they don't want the applications running all the time (i.e. consuming resources), but want to give the user something easier than right clicking on the workspace menu to launch.  It even has a little bit of logic in it to center itself on the screen.

It also works great for full screen Windows deployments in non-smart card mode which as most of you know will time out after 120 seconds of sitting at the Windows login screen.

When the user clicks one of the application buttons the chooser box will disappear (as long as your application doesn't fork), and then reappear once the application exits.  If it is configured as a Critical application, when the user clicks the Restart button, the Sun Ray will cycle.  Particularly useful when launching a web browser so all the cache of the last users session are cleared out.

There are two scripts that make this happen, utsplash and utmsgbox.

utsplash will be your CAM Application and it will call the utmsgbox script.

utsplash is the script you will edit and customize.  You can also customize the icon, which is a unix pixmap. 

Hint: use /usr/dt/bin/sdtimage to convert a gif or jpeg into xpm format.

Here's an example of the customizable parts of utsplash

NOTE: This is only a part of the script. A tarball of the complete script is provided here.

#!/bin/sh
PATH=$PATH:/usr/openwin/bin:.;export PATH
# TITLE - What you want the label Title to be
TITLE="Sun Ray...Powered by Sun"
#ICON - What icon to display
ICON=170.xpm
#Width of the Greeter
WIDTH=550
#Height of the Greeter
HEIGHT=200
#Background color
BACKGROUND=white
#Font color
FOREGROUND=black
# Text for the 1st button - otherwise APP1 will be displayed
BTN1="MS Windows"
# Text for the 2nd button - otherwise APP2 will be displayed
BTN2="Firefox"
# Text for the 3rd button - otherwise Restart will be displayed
BTN3="Restart"
#
#
# Get screen information to center the box
XWID=`/usr/openwin/bin/xwininfo -root|grep Width | awk -F: '{print $2}'|sed 's/ //'`
XHGT=`/usr/openwin/bin/xwininfo -root|grep Height | awk -F: '{print $2}' |sed 's/ //'`
XCTR=`expr $XWID / 2`
YCTR=`expr $XHGT / 2`
YCUT=`expr $HEIGHT / 2`
XCUT=`expr $WIDTH / 2`
GEOX1=`expr $XCUT - $XCTR`
GEOY1=`expr $YCUT - $YCTR`
GEOX=`echo $GEOX1 | sed 's/-//'`
GEOY=`echo $GEOY1 | sed 's/-//'`
#
# -- Define Messages ---
#Message to be displayed on first line of the greeter
MESSAGE1="Welcome to the Sun Ray Cafe"
#Message to be displayed on second line of greeter
MESSAGE2="Please select an application"
MSG=`printf "%s\n\n" "$MESSAGE1" "$MESSAGE2"`
#-- Applications to run when buttons pushed --
APP2RUN1="/opt/SUNWutWBT/WBTStart.rdesktop"
APP2RUN2="/opt/firefox/firefox"


Dowload the sample scripts here. As always, have fun with it.