HISTORY: Meta Kiosk: How to run multiple different types of kiosk modes on a Sun Ray Server/FOG
I decided to pull this one out of my original Oracle blog post at Oracle - this is my intellectual property and there is no guarantee that Oracle will not pull it out.
"One Kiosk to Rule Them All" (Originally posted Feb 06, 2009)
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!):
JDSKIOSK: for the traditional Solaris based locked down Sun Ray kiosk mode
"Other Info" field specs: JDSKIOSK
UTTSC: 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.
VDA: 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.
VDANOCARD: 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
VDM: 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:
VNC: 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
APPLICATION: 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.
X11: 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.
XTERM: 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:
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 :)
"One Kiosk to Rule Them All" (Originally posted Feb 06, 2009)
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!):
JDSKIOSK: for the traditional Solaris based locked down Sun Ray kiosk mode
"Other Info" field specs: JDSKIOSK
UTTSC: 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.
VDA: 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.
VDANOCARD: 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
VDM: 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:
VNC: 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
APPLICATION: 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.
X11: 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.
XTERM: 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 :)
Comments
Post a Comment