Thursday Apr 16, 2009

Kiosks and Firefox: Overriding or disabling "Firefox has been updated", making Firefox the default browser, and fix the homepage

I couldn't pass the opportunity of writing a note to myself on this one.

Next time you are setting up Kiosk mode with Firefox as an application, here's how to get rid of the annoying behavior of Firefox telling you about the update...

Just copy/paste this preference:
user_pref("browser.startup.homepage_override.mstone", "ignore");

In the most convenient location for you:
1) prefs.js on your user profile
2) prefs.js on the global profile (firefox/defaults/profile/prefs.js)
3) user.js on the global profile (firefox/defaults/profile/user.js)

And... making Firefox the default browser? Easy...
user_pref("", false);

And...another one of my favorites, to fix the homepage, (best to put it in user.js:)
user_pref("browser.startup.homepage", "");

or just copy/paste the lot...
user_pref("browser.startup.homepage_override.mstone", "ignore");
user_pref("", "false");
user_pref("browser.startup.homepage", "");

UPDATE 16-June-2009:
And yet, sometimes Firefox stills asks if you want it as the default browser?

Well, don't despair - this one seems to be the ultimate fix:
- Edit [FIREFOX INSTALL DIR]/defaults/pref/firefox.js
- Change from true to false

Friday Feb 06, 2009

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

"One Kiosk to Rule Them All"...

One of the coolest features of the Sun Ray platform is "Kiosk Mode". Sadly, it typically only gets associated with running a "Library" type locked down session with a web browser, or when a Windows deployment takes advantage of it to deliver Windows based sessions, be it from Terminal Services or VDI.

It is very common in demo environments and even in many production environments to have the need of presenting multiple different types of Kiosks served from the same infrastructure, which can be easily achieved by associating the token presented to the Sun Ray to the particular context required for the token. For example, you may want a number of users to get a session from a Windows Terminal Server, some others to get a Linux desktop, some users to leverage a VDI desktop, some Sun Rays in public areas to present a controlled desktop with a web browser for leasurely access and a Sun Ray in the foyer permanently running a presentation to a large LCD display. And of course, the administrator may want access to his Windows Vista desktop on a casual basis without having to rely on the Sun VDI broker. All of this from the Sun Ray Server or FOG.

In my experience, it has been mighty useful to have a fixed framework I can use at PoCs and demos for a variety of things. The piece of work presented here is an aggregation of some of the work that grew from a requirement at a large PoC in South Australia when Sun VDi wasn't around and also from the current demo environment shown to customers at the Sydney Sun Solution Centre.  There is a WOW factor that still grips the imagination of most people when they see the Sun Ray platform in full action. I mean, who's ever seen a handful of different desktops presented on the same screen in less than 10 seconds???

The purpose of this "Meta Kiosk" (or Kiosk Broker) is to provide multiple kiosk capabilities to the Sun Ray platform, which is typically constrained by the use of a single kiosk mode across the board. One day, Engineering may give me a pull down in the Token Administration GUI for me to choose what the token is supposed to do, but for now, this is the next best thing.

So, how does this "Meta Kiosk" come together? Meta Kiosk leverages the "Other Info" field of any token (a smartcard ora  pseudo token of a Sun Ray) by letting you specify a string to identify what type of session that token is entitled to, for example UTTSC, JDSKIOSK, VDA, VDANOCARD, VNC, etc. Additionally, you can specify a default kiosk mode for non-registered tokens, by changing  the UNREG_TOKEN_ACTION variable in the script. After the script decides what Kiosk the token is entitled to, it actually instantiates that particular kiosk mode, as if it had been called naturally by the Sun Ray kiosk framework. Should the first string in the "Other Info" field not be recognised, the action indicated by the variable DEFAULT_ACTION will be undertaken (which can also modify. DEFAULT_ACTION for registered tokens in the script is to use VDA, which is convenient as the VDA script also makes use of this field as the placeholder for the poolname the token owner is entitled to from the available SOE pools.

The only caveat to this is that typically, the arguments passed to the kiosk session are defined in the Sun Ray Admin GUI setup for the system-wide kiosk mode you choose, but since Meta Kiosk calls upon a large number of kiosks itself, this is no longer useful. To work around this, the script assumes that the parameteres you want for a specific kiosk mode are actually contained in the relevant "kiosk.conf file for that particular kiosk, typically found in /etc/opt/SUNWkio/sessions. For example, if I wanted to enable Full Screen to all the uttsc kiosk sessions, I would simply edit /etc/opt/SUNWkio/sessions/uttsc.conf and type something like KIOSK_SESSION_ARGS="-t 1800 -- -m mywindowsterminalserver".

What options can I enter in the "Other Info" field of a Sun Ray token?
Below are the different options available "out of the box" with the present release of Meta Kiosk, along with some of the features, that you can specify in the "Other Info" field of your tokens - and don't forget you can add any of your own easily by editing the script at /etc/opt/SUNWkio/sessions/meta-kiosk/meta-kiosk-session (and if you do and you consider it useful, please share it with me!):

: for the traditional Solaris based locked down Sun Ray kiosk mode
"Other Info" field specs: JDSKIOSK

: to make a call upon a specified Windows (or RDP capable) system, whether it is a physical PC, a VM, a WTS or a session directory server or the console of a VirtualBox VM with VRDP...
"Other Info" field specs: UTTSC [username [target system]]
UTTSC can leverage the main system name passed in the uttsc.conf file, presented as the last field of KIOSK_SESSION_ARGS. If username is present, then this name will appear in the login box (where possible). If "target system" is specified this field will be stripped from the uttsc.conf definition and replaced by that found at "Other Info". Note that when you configure the uttsc kiosk mode, it is expected that you enter a system name at the end of the string. As such, Meta Kiosk expects this too.

: In case you need or want to register it. Note that the script will treat this as the default mode for any \*registered\* token anyway.
"Other Info" field specs: VDA
the VDA kiosk script will later re-read and interpret this field as a pool name, so typing  any parameters would be useless! If this is used with VDA, then a default pool called VDA can be setup, unless you have already assigned the username a permanent virtual machine.

: In case you need or want to register an existing token or  pseudo-token to use Dirk Grobler's "Non Card VDI for Sun Ray".
"Other Info" field specs: VDANOCARD

: In case you want to use VMware's broker in your environment separately. You will need to download the Sun Ray connector for VMware Virtual Desktop Manager and install it (guess what - it's a kiosk mode too!)
"Other Info" field specs: VDM

The next options are not not defined typically as kiosks. Their code is contained within the Meta Kiosk script itself:

: Experimental at this point, useful mostly for MACs (not that you couldn't use with Solaris/Linux or even Windows), by way of leveraging  a VNC server or similar (the builtin ARD server does NOT work with standard VMC clients)
"Other Info" field specs: VNC [system-name [password]]
Both parameters are optional, although you can't specify password if you don't  specify a system name. Password will get written to a file and then the argument  passed through, and although this is not dramatically secure, it allows for a  quick demo of a MAC on a Sun Ray. A good VNC server to use is Vine. You may need to pass the port to the VNC service on the server as part of the system name, e.g. mymac:5901   

: Let's you run a specified Solaris app, but take heed, there will be no Window manager for it. Otherwise, simply use JDSKIOSK and specify the app there.
"Other Info" field specs: APPLICATION command-name <parameters>
For example, you could run a full screen presentation on a dedicated Sun Ray like this, like we do at the foyer of the Sydney Sun Solution Centre:
APPLICATION /usr/bin/staroffice -invisible - nologo -show /presentations/sunray-presso.od

UTSWITCH: Need a token to get redirected without AMHG? This is it!
"Other Info" field specs: UTSWITCH sunray-server-hostname
Beware that the Sun Ray will remain attached to that other Sun Ray server when you pull the smartcard or disconnect the session, so it's important to remember to STOP-A the Sun Ray at the end of the session.

: An Xsession. This will run Xnest within the Sun Ray X session canvas.
"Other Info" field specs: X11 servername [geometry]
NOTE: On your Sun Ray server, you may have to execute this: chmod 04755 /usr/openwin/bin/Xnest ulness Xephyr is available.

: An X term (xterm) on the Sun Ray server. Good for testing!
"Other Info" field specs: XTERM
It also starts twm as the window manager. Just good to have...

Meta Kiosk Workflow - how does a kiosk mode get chosen?
The following diagram depicts the default actions chosen by the script based on the token conditions, i.e. Token registered or not and "Other Info" field contents:

Putting it all into action
The requirements are quite simple:

  • DOWNLOAD "Meta Kiosk" (TAR file)

  • Unpack the downloaded file on a Solaris Sun Ray server: the files are created from the root directory, straight into /etc/opt/SUNWkio/sessions.

  • Under the Sun Ray Web Admin go to Advanced -> Kiosk Mode.

  • Choose "Meta Kiosk Broker Session" from the kiosk options pull down.

  • Pick any Solaris apps you desire to run under the JDS kiosk mode (if at all) as part of the Meta Kiosk, instead of JDS.

  • For EACH and ALL kiosk modes you will be employing that requires it, make sure you edit the associated ".conf" file in /etc/opt/SUNWkio/sessions and include the parameters you want to regularly use: simply type them in for that kiosk mode under KIOSK_SESSION_ARGS (see example above for UTTSC.)

  • Pick the default action you desire for unregistered tokens (if your policy allows) by editing /etc/opt/SUNWkio/sessions/meta-kiosk/meta-kiosk-session and assigning it to UNREG_TOKEN_ACTION (see Flow Chart above.)
    NOTE: By default the script assumes that unregistered tokens get JDSKIOSK as the default, and if this is what you want, make sure you specify something like Firefox as a Critical app under the Meta Kiosk app pane.

  • Pick the default action you desire for registered tokens that do not present an identifiable string in "Other Info" by editing /etc/opt/SUNWkio/sessions/meta-kiosk/meta-kiosk-session and assigning it to DEFAULT_ACTION (see Flow Chart above.)
    NOTE: By default the script assumes this to be VDA, the Sun VDI broker

  • Don't forget you need to have the token registered AND set as a Kiosk token for any of this to work.

  • If you want to assign a kiosk mode to a Sun Ray without using  a smartcard, simply register the pseudo token of the Sun Ray through the Web Admin GUI. The token is always "pseudo.<MAC address>" of the Sun Ray you need. This is often done under VDA to present the same Windows VM to the same person at the same desk all the time (much like ... your PC.)

Enjoy and make sure you share any other worthwhile uses you can think of...

UPDATE 19/02/2009:
Made some improvements on the X11 kiosk - it now works with Centos and OpenSolaris, thanks to the use of Xephyr on Solaris 10 x86

UPDATE 02/07/2009:
For a pure and supported methodology on assigning different kiosk sessions to different tokens, there's a new feature available since SRS 4.1 that allows individual Kiosk session assignment to different tokens. For more info, please visit Jörg Barfurth's blog entry "Using different Kiosk Sessions for different tokens". Thanks Jörg! While I'm on this subject, could engineering please deploy a kiosk selection pull-down on the token administration page in the Sun Ray web admin? Ta :)

Thursday Jul 24, 2008

A "USB Drive" daemon for Sun Ray sessions - AKA "usbdrived" (V2)

Hopefully you are reading this because you either have a need to better present USB disks via the Sun Ray platform or because you are an "existing customer" of version 1, first blogged here.

After looooong in the making and with careful analysis of requirements and listening to useful feedback from the likes of Brad Lackey, I am pleased to announce that "version 2" of the good old "usbdrived" is finally ready  (well, not really v2,  it has had more iterations than that...)

Features that you will find in this version are:

  1. Multiple mount partitions & drives connected to the same Sun Ray

  2. Mount point "unwriteability" (Yeah!)

  3. Address Gnome/JDS and Windows sessions from the same script, automatically

  4. Polished Disk icons on Gnome/JDS (instead of links)

  5. No stale mount points presented to the end user

  6. Usage documentation provided as text files on the desktop/mountpoint (this can be switched off)

  7. Installer for system-wide or single user with no root permissions

  8. Single point of aggregation for all Windows mounts (Drive "USBDRVS")

Simply download it, and then execute it (chmod +x first) on every Sun Ray server of your FOG, like so:

./usbdrived install

Option 0 will give you generic install instructions... Enjoy!


I get a lot of comments telling me "it doesn't work, can you help me?" - as it turns out usbdrived is actually a pretty simple beast, and if you think it's not working, you may be looking in the wrong place. Start with some of these hints:

  • Can you see usbdrived running in your Solaris session? (ps -ef | grep usbdrived)

  • Can you see a file called "Attaching USB Drives to your Sun Ray README.txt" on your Solaris desktop?

  • Did you install it properly? If so, can you see and what permissions does this have:
    It should be executable by everybody, something like rwxr-xr-x

  • When you plug in a USB drive, does it mount in /tmp/SUNWut/mnt/<username> under Solaris?

  • Under Windows, can you see in  "My Computer" a Network drive (In "Others") called "USBDRVS" and is there a file within that explains usage?

  • Have you hit refresh in file manager when looking at your USBDRVS mount?

  • Most important and useful of all: Do any mounts show up if on a Solaris Sun Ray session you issue:
    /opt/SUNWut/bin/utdiskadm -l

  • With Sun VDI 2.0, make sure that you have properly positioned your arguments in the kiosk call, as "-service hostname" needs to be the last parameter:
    -t 1800 -- -m -b -r disk:USBDRVS=$HOME/USBDRVS -service localhost

  • With Sun VDI 3.0, this works for me:
    -- -m -b -r disk:USBDRVS=$HOME/USBDRVS
    where the actual vda kiosk parameters go to the left of "--"

  • With the Sun Ray Connector for VMware View, this works for me:
    -s viewmanager-server -http -- -m -b -r disk:USBDRVS=$HOME/USBDRVS

  • Unfortunately, NOT ALL USB drives work. Some drives, Solaris refuses to mount (PCFS issues) either because the device is simply not "liked", or because Solaris can't read the file system. Look at "dmesg" for errors.

  • Is your drive FAT16/32 or is it NTFS? The latter does not work, the formatting mut be FAT.

  • Many people have asked me why passing the parameter does not work
    as explained within the script... It appears that people look at the guts of the
    script to understand the instructions and bump into the line that reads
    and assume that that is the literal context. Noooooo! That "\\" is there
    so that when you read the instructions offered via the command line
    option of "usbdrived install" and press "0", the actual HOME directory
    of the user is not displayed...

NOTE OF SUPPORT: This tool is provided as is. It is not supported by Oracle. If you find any issues, please contact me and will try to help!

    Wednesday Jul 04, 2007

    Playing with the new KIOSK mode in SRS4u2

    I finally upgraded my SPARC box to Solaris 10u3 so I could install SRS4u2... it was up and running in no time and I had a go at the new interface and the new Kiosk mode. The interface is a lot slicker than I expected and some of the annoyances of the original have disappeared with it. 

    And the new Kiosk mode is also slick AND simple. The setup may take a bit of getting used to, but I had a go at setting up a JDS desktop with Firefox and it was  a breeze. Then I thought... let me add my USB drive daemon script to see how it would work, and there was no magic required- I simply added it as a critical application (from a central path) and voila! It all came to life pretty automagically - and the USB drive daemon didn't show up in the applications menu, which makes total sense. Now, if only I could lock Nautilus down...

    Further... there was some great work done in terms of locking the JDS session RIGHT down for the new Kiosk - like application execution restrictions should you happen to wander off into the forbidden woods, which should only happen if you let users do flexible things like run the file manager. Thanks go to Brad Lackey  for telling me that some features can be relaxed by passing "-s" as an option to the JDS kiosk. There's a wealth of info within the Kiosk based directories I just wasn't aware of!

    The other feature that blew me away is that regardless of your specification for Kiosk mode, you can have assigned tokens that will be granted a separate mode to the default. Next on my wish list: multiple Kiosk modes!


    A thin thinker down under


    « July 2016