Thursday Feb 05, 2009

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

Monday Sep 08, 2008

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.

Monday Jun 30, 2008

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

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

     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

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.

Friday Mar 07, 2008

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

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

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


[Read More]