Friday Apr 22, 2011

Webinar: Real World VDI with Oracle VDI

Hey Folks,

We have a great webinar coming up on Thursday, April 28 at 9AM PT that will feature Think Thin's own Jeff Reilly.  The main topic covered will be the "real world" scenarios that customer face when they choose to virtualize their desktops.  Read a bit more about it over on Oracle's Virtualization Blog including the link to register for the event.

 Hope to see you there!


Thursday Feb 17, 2011

We're going to HIMSS!

The Desktop Virtualization Team is going to this years HIMSS conference, and we are going in a big way! To show our new united Oracle front, Hardware, Software,  Complete, we will be demonstrating 14 Oracle software applications using Oracle's VDI technology. More details about the conference and Oracle's presence at HIMSS can be found on the Oracle Virtualization Blog. We've also just launched a new solutions page for Healthcare Virtualization to kick off the conference.

Wednesday Aug 04, 2010

Oracle Virtualization Event line up...Holy Cow!

On August 19th from 9 AM until 3 PM, Oracle will be hosting an Online Virtualization Forum that covers our v12n technology from the Desktop to the Datacenter.  What I'm really impressed by is the two people that will comprise the "panel".  Former Sun hardware guru and now Oracle's Executive Vice President of Systems John Fowler and my boss's boss's boss, Oracle's Chief Corporate Architect Edward Screven.

Folks, these are what we call "Big Guns".  What's more, they are extremely intelligent...no scratch that.  They are "scary smart".  Be honest, you've sat through more than your share of executives pitching things they could care less about.  These two gentlemen are in a different league.  Passionate is the best word that describes them. 

I'm sure long time followers of Think Thin are more than familiar with the Executive branch of "the company formerly known as Sun Microsystems" and you've seen John Fowler many times.  But unless you were an Oracle customer, you may not have had the chance to hear Edward Screven speak.  With absolutely zero patronizing involved here (like he reads this blog), watch him.  He's brilliant.  He gets it.  And by "it" I mean pretty much anything you could imagine, but specifically he gets VDI.

If there's one thing I've learned about the executives at Oracle, it's that they don't mess around.  You wouldn't get this caliber of people talking about the entire virtualization stack if Oracle was not committed to it.  I've also noticed, "Committed" = "Wants to dominate" in Oracle speak.

So to the v12n world out there, and specifically the VDI market, watch out.  The "Big Guns" are about to fire a warning shot across the bow of the marketplace.  To paraphrase Al Pacino's character in "Scent of a Woman", We are just getting warmed up.

Monday Aug 02, 2010

TechCast Live: Sun Ray and Oracle VDI Edition

Happy Monday to all the Think Thin readers!

I'll be on Oracle TechCast Live tomorrow at 10 AM Pacific where I'll be having a nice little chat with Justin Kestelyn about Sun Ray and Oracle VDI.

I'll also be taking some community questions.  From the TechCast Live page, you can can sign in using your Twitter, Facebook, AIM, or Myspace account.  Can't promise I'll be able to answer every type of question, we have different rules at Oracle than Sun did.  I hope however to make it worth your while and I hope you find it enjoyable.

Wednesday Nov 25, 2009

Command Line Reference Doc Updated

Hi everyone, short note here.

I have created a new version of the handy Command Line Reference doc for Sun desktop technologies. This is  a pdf with quick links to the complete man page reference for SRSS 4.2, SRWC 2.0 and VDI 3.1.

I know that the man pages are now up on the Wiki, but sometimes it's easiest to just have this thing as a shortcut for quick reference.

Enjoy, let me know if this pdf doesn't work on your system.

Desktop_Cmd_Ref-11.25.09.pdf

Brad 

Thursday Feb 05, 2009

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

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

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

It's called "META KIOSK".

Sunday Sep 07, 2008

Customized Sun Ray kiosk sessions

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


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

Sunday Jun 29, 2008

Follow me kiosk printing

My colleague in the Dubai office, Mitch DSouza, is a shy and retiring fellow not give to self-aggrandisment via blogs.  For this reason, I agreed to post these kiosk mode follow-me printing scripts here on his behalf.

The scripts are here.

Mitch's insructions -

Note, this is written specifically for windows (uttsc) Sun Ray desktops in kiosk mode and also doesn't take into consideration Linux SRSS setups. The scripts currently only cater for 1 locally attached printer but are trivial to extend. You will need to add the scripts and execute the kiosk profile setup script to all servers in the FOG (if any).

So essentially follow-me pass thru printing consists of 3 scripts.

1. The 'setupprof' script that adds pseudo kiosk users to the Printer Adminsitration profile so they can execute lpadmin commands dynamically
2. The '1100.LocalPrint' script to start the utaction action to add or remove printers from the unix srss spooler
3. The 'set-printer.sh' which is called by utaction to do the dirty work

To set this up you need to run the following commands as the root user.  I'm assuming here that you've extracted the tar file to /opt/utprint):

 /opt/utprint/setupprof
 cd /usr/dt/config/Xsession.d
 ln -s /opt/utprint/1100.LocalPrint


That's it. You also need to add the option '-r printer:SR-Default' to the uttsc kiosk mode web config page. Once you restart the session(s) and you and plug a card in, a printer will be dynamically created for you and a zenity message will popup up with the current printer. You can remove the zenity line if you don't want the popup message. If you move your card to another desktop with a locally attached printer it will change the printer dynamically.

It's left to the script reader to configure a default printer if there is no locally attached printer. The windows driver \*must\* match the locally attached printer or you will probably get garbage printed. You can easily set the windows driver automatically also by using the '-r printer:SR-Default="Driver Name"'

Monday May 05, 2008

User assigned VDI on Sun Rays without Cards

Dirk and his team keep rolling with helpful scripts and components for the Desktop Connector. This time, it is the ability to deploy user-assigned VM's to Sun Ray users without cards.

 http://blogs.sun.com/whitemencantjump/entry/non_card_vdi_for_sun

They have also been working with Provision Netoworks to allow Sun Ray users to request and connect to VM's managed by their broker.

http://blogs.sun.com/whitemencantjump/entry/let_s_talk_about_provision 

Have fun with all the new options. 

Tuesday Mar 18, 2008

Just Released - Sun Virtual Desktop Infrastructure Software 2.0

     Hot off the presses is Sun's Virtual Desktop Infrastructure Software 2.0, just released last night. Included is the new Sun Virtual Desktop Connector, acting as a broker between Sun Ray and Secure Global Desktop infrastructure and VMware virtual machines.  This solution provides exceptional flexibility in deploying virtual desktops in an easy, secure manner to both Sun Ray clients as well as a variety of other clients, with a choice of desktop operating systems, including Windows, Solaris and Linux. This would probably be a good time to note our recent announcement of entering an OEM agreement with VMware, making it that much easier for a complete solution from Sun.

     Heck, so many interesting things happening in this space, it's hard to keep track of it all. Wouldn't want to miss our purchase of innotek and their VirtualBox technology, an open source virtualization software technology that allows running virtual machines under a variety of host operating systems to run many different guest OSes, including Solaris, Linux, Windows and OS X. Nor would I want to forget the ongoing work incorporating Xen open source technology into both OpenSolaris, and into xVM Server,  giving you the ability to run guest operating systems with no hypervisor knowledge as usual, and those guest operating systems that are hypervisor aware and can take advantage of performance enhancements through direct hypervisor calls.


Sunday Mar 16, 2008

Point and Shoot VDI

Certainly the most feature rich method to deliver VDI is through the use of a "broker" like the Sun Virtual Desktop Connector. This broker is then connected to VMWare Virtual Center and the combination of the two gives the environment all sorts of features like Pooling, VM Lifecycle management, one-to-one mapping, Dynamic Resource Scheduling, and VMotion.

Not all VDI environments need to have all of these features. Maybe the VM's aren't even hosted in VMWare, or maybe they're not even VM's at all as in the case with blade based PC's. Maybe there is no need for Pooling, just a one-to-one relationship. No need to manage the VM's they're already provisioned through another process.

I like to call this the "Point and Shoot" VDI architecture. It should be dead simple and easy to set up. It doesn't matter where the OS images are, just that they exist on the network and that we are going to assign one VM to one user. Here are the steps to do Point and Shoot VDI using Sun Rays.

NOTE: These examples are for SRSS 4.0

Example 1: VM's assigned to a user. The user is identified by their smart card.

1) Create the Kiosk Descriptor

vi /etc/opt/SUNWkio/sessions/simple-vdi.conf

KIOSK_SESSION_EXEC=$KIOSK_SESSION_DIR/start-vdi.sh
KIOSK_SESSION_LABEL="Static Assigned VDI"
KIOSK_SESSION_DESCRIPTION="Static VM Assignment"
2) Create the Session exec script

mkdir /etc/opt/SUNWkio/sessions/simple-vdi

vi /etc/opt/SUNWkio/sessions/simple-vdi/start-vdi.sh

#!/bin/sh

# Check for Card or Non-Card session
case $SUN_SUNRAY_TOKEN in
pseudo.\*)
# Non-Card Session
zenity --info --text="Please insert your smart card..."
;;
\*)
# Card Session
# Read Other Info Field
REG_OTHER=`/opt/SUNWut/sbin/utuser -o | \\
grep $SUN_SUNRAY_TOKEN | awk -F, '{print $5;}'`

if [ "$REG_OTHER" = "" ]; then
zenity --error --text="This card has not been assigned a VM"
exit 1
else
# Check for VM Availability
/usr/sbin/ping $REG_OTHER 2
if [ "$?" != "0" ]; then
zenity --error --text="VM $REG_OTHER is not available for connection."
exit 1
else
# Call uttsc Kiosk script with VM name
KIOSK_SESSION_DIR=/etc/opt/SUNWkio/sessions/uttsc
export KIOSK_SESSION_DIR
/etc/opt/SUNWkio/sessions/uttsc/uttsc $REG_OTHER
fi
fi
;;
esac
#End

chmod 755 /etc/opt/SUNWkio/sessions/simple-vdi/start-vdi.sh

3) Select Kiosk Mode Configuration

Open SR Admin GUI

Select Advanced->Kiosk

Click Edit

Select Static Assigned VDI from the Session type drop down.

4) Register Cards and assign VM name

Admin GUI - Tokens Tab

Search for currently used tokens.

You may then pick the token and Edit that token's registration.

You must assign a User Name. (This may be free form "Brad Lackey")

Place the VMs DNS name in the Other Information Field.


Example 2: VM's assigned to a DTU. Identified by MAC Address

1) Setup exactly like Example 1, only with a different start-vdi.sh

vi /etc/opt/SUNWkio/sessions/simple-vdi/start-vdi.sh

#!/bin/sh
if [ `uname` = Linux ] ; then
theFlag="-P"
fi

theMACAddr=`cd $theFlag $UTDEVROOT ; /bin/pwd | sed 's/.\*\\(............\\)/\\1/'`
theVM=`/opt/SUNWut/sbin/utdesktop -o | \\
grep $theMACAddr | \\
/usr/bin/awk -F, '{print $2;}'`

if [ "$theVM" != "" ] ; then
# Check for VM Availability
/usr/sbin/ping $theVM 2
if [ "$?" != "0" ]; then
zenity --error --text="VM $REG_OTHER is not available for connection."
exit 1
fi

# Call uttsc Kiosk script with VM name
KIOSK_SESSION_DIR=/etc/opt/SUNWkio/sessions/uttsc
export KIOSK_SESSION_DIR
/etc/opt/SUNWkio/sessions/uttsc/uttsc $theVM
else
zenity --error --text="This Sun Ray has not been assigned a VM."
exit 1
fi

2) Register Desktop and assign VM name

Admin GUI - Desktops Tab

Search for currently connected Desktops.

You may then pick the Desktop and Edit that it's registration.

Place the VMs DNS name in the Location Field.

Thursday Mar 06, 2008

Kiosk Mode Browser

A few folks have been trying to get a Kiosk mode browser working. Whether for an actual "Kiosk" or for access to a web based application, this can be rather handy. I thought that I'd post how I've been doing it lately.

A kiosk web browser can also be handy for delivering access to Secure Global Desktop applications from Sun Rays. I have included a few additional steps to make the SGD experience better.

Install firefox in /opt:
----------------------------

Download the latest firefox from
ftp://ftp.mozilla.org/pub/firefox/releases/2.0.0.12/contrib/solaris_tarball/
Unzip firefox to /opt/firefox

Install and Configure Kiosk extensions:
-----------------------------------------

Download the two kiosk XPI's from
https://www.mozdevgroup.com/dropbox/jslib/signed/jslib_current_signed.xpi
http://brooklynmuseum.mozdevgroup.com/install/xpi/signed/bmakiosk_current-ff-generic_signed.xpi

Put them in /opt/firefox/bma
    mkdir /opt/firefox/bma

You will need ssh -X or be on the console to perform the remaining pieces

Register the Components
    /opt/firefox/firefox -install-global-extension /opt/firefox/bma/jslib_current_signed.xpi (If you get an error, try it again.)
    /opt/firefox/firefox -install-global-extension /opt/firefox/bma/bmakiosk_current-ff-generic_signed.xpi

Create a URL whitelist file.. /opt/firefox/whitelist
    allowed[sgdserver.domain.com, ALL];

Start the Kiosk extension admin GUI:
    /opt/firefox/firefox -kiosk admin
    Enter "admin" as the password
    Set the home page
    Tick With Titlebar
    Click the Filters Tab
        Click Enable Filters
        Put /opt/firefox/whitelist in the text box
    Click the Sessions Tab
        un-set the inactive timeout
    Click the Customize Tab
        un-tick tabbed browsing
        un-tick print button, zoom controls, save button, logout button
    Click OK

Set up the Java Plugin for x64
    ln -s /usr/java/jre/plugin/i386/ns7/libjavaplugin_oji.so /opt/firefox/plugins/.

Set up the Java Plugin for Sparc

ln -s /usr/java/jre/plugin/sparc/ns7/libjavaplugin_oji.so /opt/firefox/plugins/.


Configure Kiosk Mode:
-------------------------

Create a kiosk application called Secure Global Desktop
    vi /etc/opt/SUNWkio/applications/firefox.conf

KIOSK_APP_EXEC=/opt/firefox/firefox
KIOSK_APP_ARGS="-kiosk"
KIOSK_APP_LABEL="Firefox Kiosk"
KIOSK_APP_ICON=/opt/firefox/icons/mozicon50.xpm
KIOSK_APP_DESCRIPTION="Launch Firefox"

Set up Kiosk mode to launch a JDS 3 session
Add the Firefox application as AUTO start to the JDS 3 session.

SGD Integration:
-----------------------

If you are looking to point the browser at SGD, you will want to also make the following changes.

  • Set the home page to your SGD URL (http://sgd.domain.com/sgd/)
  • Add this line to your firefox.conf
KIOSK_APP_PROTOTYPE=sgd
  • To speed up initialization, remove Java cert approval, and remove SGD connection approval
As root launch tarantella and login. Accept java and tarantella conenction warning.
mkdir /etc/opt/SUNWkio/prototypes/sgd
cp -r ~/.tarantella to /etc/opt/SUNWkio/prototypes/sgd/
mkdir -p /etc/opt/SUNWkio/prototypes/sgd/.java/deployment/security
cp ~/.java/deployment/security/trusted.certs /etc/opt/SUNWkio/prototypes/sgd/.java/deployment/security/

Friday Oct 05, 2007

The New Kiosk Mode Scripts - What they do

Have you had a look at the new Kiosk Mode in SRS4 0907 (aka SRS4u2)? The thing you notice right away is it's really different from our old friend CAM. I really liked the things we were able to do with CAM and wanted to begin to learn to replicate those in Kiosk Mode.

I like to set up the environment for my scripts in a single script that is sourced from each script in the package. Learned that trick from Brad Lackey's TSAffinity work. So I asked my buds if I could use KIOSK_SESSION_PRE for that purpose so it would be sourced automatically for me. I got great information from Joerg Barfurth so I thought I'd pass it along. Here's what he said:


KIOSK_SESSION_PRE runs as root during the session preparation phase. You can't set variables here that are inherited by KIOSK_SESSION_EXEC, except by creating a .profile-style file, which your session script then sources.

KIOSK_SESSION_PRE can be used to do pre-session setup which needs additional privilege, e.g special home directory setup, set file permissions, start per-session daemons etc. If you need a 'pre' script that is sourced within the session context, so that you can inherit environment, you can easily source such a script yourself within your KIOSK_SESSION_EXEC script. You can use a fixed script in a well-known location (e.g. put it into KIOSK_SESSION_DIR [/etc/opt/SUNWkio/sessions/<session-name>] or next to your session script). Or if you need to have a script that can be modified for each user, source it from $HOME.

On the other hand, if you need something done with privileges (e.g. create per-session data that is write-protected for the kiosk user) for session preparation, you could not (easily) do it on your own.

KIOSK_SESSION_POST can be used to clean up the things set up by KIOSK_SESSION_PRE.

If I wanted to use the .profile approach, I suppose I could create a .profile-$USER, but where to put it? Is $USER's $HOME created at the point where KIOSK_SESSION_PRE is executed?  I would think that to be ideal as it will go away for sure when $USER's session is destroyed without having to worry about a KIOSK_SESSION_POST to clean it up. Again from Joerg:

All of $USER, $HOME, $KIOSK_SESSION_DIR are set when the PRE and POST scripts are run.

But then you have the issue of how/when to create the .profile-$USER. That sounded messy so I looke at another approach. Put a .profile in the prototype directory for the session type then source it in the KIOSK_SESSION_EXEC. It would get copied into the Kiosk user's $HOME by the session startup and I could source it from $HOME. Sounded good to me. I asked Joerg how that would play:

You really only need to copy it into place, if you do per-session customization. For a fixed script, simply put it into a well-known place and source it from there.
 

A well-known place? Where would that be? Has to be protected from future patches, etc; not interfere with any other Kiosk Mode functionality and so forth. Joerg had said earlier:

You can use a fixed script in a well-known location (e.g. put it into KIOSK_SESSION_DIR [/etc/opt/SUNWkio/sessions/<session-name>] or next to your session script).

OK, I'm good with that. My new standard will be:

/etc/opt/SUNWkio/sessions/mysession.conf is the session descriptor which points to ....

  /etc/opt/SUNWkio/sessions/mysession/my_exec.sh is the my main Kiosk Mode script which sources ...

/etc/opt/SUNWkio/sessions/mysession/my_env.sh is the script to build the environment

One note that I learned the hard way: the directory name you use for you scripts and the name of the .conf file must be the same and they must be the same case. DUH! this is \*nix isn't it!?! Well I overlooked that and spent an afternoon figuring it out.

Do yourself a favor and grab a copy of the manpage.pdf with the bookmarks that Brad created, it is SUPER handy and not very big. You can find it here.

 


Monday Sep 24, 2007

CAM Mode Gotcha

There are few gotcha's here and there in Controlled Access Mode (note this is CAM under Sun Ray 3.x and 2.x, not the new Kiosk under SRSS 4 U2).  None more elusive than this one that seems to rear it's ugly head about once a year.  After I have them check "here and there" and everything is OK, it usually means that /var/adm/sulog is full.  The only problems is that I always seem to forget about sulog.  :(

Under CAM 2.x and 3.x, one of the CAM scripts has root su to one of the CAM users which then runs your CAM script.  If this log is full (50 MB limit), then the CAM Startup will bail and you'll be left with cycling Sun Rays.  And since that server won't have any sessions on it, it will always get the new sessions in a FOG since it is the least loaded.  Big headache.

If you enable debugging (the "there" link above) you'll see something like this happen right before the session gets torn down:

/opt/SUNWbb/bin/bbrootsession[191]: 8057 File Size Limit Exceeded
+ remove_lock

If you look at /opt/SUNWbb/bin/bbrootsession, you'll see that's where it's trying to do the su and that little message means that sulog is full.   

Simple fix is to assume root, rm /var/adm/sulog;touch /var/adm/sulog and things will once again be happy.

And no, I don't know the history behind sulog having that limit.  But one way or another, that's a lot of su'ing to fill that log so either your Sun Ray Servers have been up for a real long time, or your script does have a problem in it that causing it to cycle.

Finally, with Sun Ray Software 09/07 Kiosk has been totally re-written to use PAM.  The su doesn't happen anymore.
 



 

 

Thursday Feb 22, 2007

CAM Deep Dive


[Read More]

Tuesday Jan 30, 2007

Important Update to the Turbo CAM post

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>

Wednesday Nov 22, 2006

Windows Lock Screen Update

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.

Tuesday Nov 21, 2006

Turbo CAM

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

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

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

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

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

What: Increase Authd worker threads from 8 to 32.

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

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

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

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

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

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

Find the line that reads:

r)     setOP "r";;

And change it to this:

#Tuning Fix - echo "/opt" and exit
r)     setOP "r" 
       echo "/opt" 
       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

Wednesday Oct 04, 2006

Creating additional CAM Users

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)

Monday Sep 25, 2006

A useful tip for CAM debugging

        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.

Thursday Aug 24, 2006

Configuring a CAM application without using the Web GUI

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

Friday Jul 14, 2006

Debugging Controlled Access Mode

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.

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