Tuesday Sep 29, 2009

Odd Sizes

Starting from SRSS 4.1, the Sun Ray Xnewt X server supports the XRandR extension, which allows resizing your desktop while the session is running. This is particularly useful, if you often hotdesk among Sun Ray DTUs with monitors of different sizes.

Bob even has created a utfit script, which you can use automatically fit your desktop size to the new screen size on hotdesk (needs to be run via utaction on connect).

But the set of sizes any given Sun Ray session can be resized to is limited. And this selection of sizes doesn't really have anything to do with the currently used Sun Ray and its monitor. If the monitor is small, you may be able to something larger than your monitor and will get scan+pan behavior. If the monitor is large, its size may simply not be available. Instead the sizes that are offered depend on the initial size of your desktop - or more precisely the size of the X server canvas.

When a Sun Ray Xnewt X server is started, it creates a frame buffer that best fits the display of the currently connected DTU. Only if this monitor is very small, a certain minimum size will be reserved. This size is then seen as the initial size of the desktop. As the frame buffer can't be grown later, this size then becomes the limit for future resizing: you can shrink your desktop and enlarge it again, but only up to the original size. XrandR will offer you a set of standard sizes, but these must be smaller than the starting size in both dimensions.

This is particularly troublesome, if you frequently move between screens where neither is smaller than the other in both dimensions. Myself I usually use a 1600x1200 20,1" monitor at work and a 22" 1680x1050 monitor at home. Now if I start my session at work (1600x1200), I can't resize it to fit my home screen, as 1680px is wider than the frame buffer. But if the session is started at 1680x1050, then I can't resize for my work screen either, as 1200px is taller than the 1050px frame buffer :-(

utxconfig to the rescue

To solve this problem, you can control the size of the X server canvas using the utxconfig command. If you specify a resolution (i.e. a size), a newly started X server will create a frame buffer that can hold this size. In my case, I used

  $ utxconfig -r 1680x1200
to specify an odd size, which fits no real monitor exactly. The important property of this choice is that it is at least as large as the pixes dimensions of all the monitor I regularly use. After issuing this command and getting a new X server, I can see that XrandR now allows me to resize my desktop to all the sizes I need:
  $ xrandr
   SZ:    Pixels          Physical       Refresh
   0    640 x 480    ( 180mm x 135mm )
   1    800 x 600    ( 225mm x 169mm )
   2   1024 x 768    ( 288mm x 216mm )
   3   1152 x 900    ( 325mm x 254mm )
   4   1280 x 1024   ( 361mm x 289mm )
   5   1400 x 1050   ( 395mm x 296mm )
   6   1440 x 900    ( 406mm x 254mm )
   7   1600 x 1024   ( 451mm x 289mm )
  \*8   1600 x 1200   ( 451mm x 339mm )
   9   1680 x 1050   ( 474mm x 296mm )
   10  1680 x 1200   ( 474mm x 339mm )
  Current rotation - normal
  Current reflection - none
  Rotations possible - normal 
  Reflections possible - none
I need to adjust the size right after initial login, but the utfit script will do even that automatically. And the benefit is well worth the tiny effort anyhow.

Update: the utxconfig command binds the chosen size to your token and stores it in the Sun Ray Data Store. Thus the command needs to be run only once within a failover group. The setting applies on all servers of the group and stays active until you run utxconfig again to change it. But if you occasionally use multiple tokens, you have to set up the session size separately for each one.

Thursday Sep 24, 2009

Hotdesking sessions to and from the Sun Display Access Client

The initial release of the Sun Desktop Access Client (SDAC) does not participate in the smartcard-based hotdesking that is typically used with Sun Ray Desktop Units (DTUs).

Update: The latest update of SRSS 4.2 now supports (well, mostly) smartcard-based hotdesking for OVDC (the new name for SDAC).

Nevertheless hotdesking capabilities are an important feature of the Sun Ray system. So how can SDAC participate?

Answer 1: NSCM

The simplest solution to be able to hotdesk Sun Ray sessions to and from an instance of SDAC is to use NSCM. This has a few restrictions:

  • It works only on Solaris. Not much of a restriction, if you are running SRSS on Solaris already, but a significant problem, if you are using Linux.
  • KioskMode and NSCM are a poor fit, as every user must authenticate on UNIX in order to get session access. No problem, if your users have a UNIX login account and are logging into a regular UNIX session anyhow. But if you are using Kiosk Mode, then requiring UNIX authentication first is a poor fit. Even if you can set up PAM to make NSCM use a different authentication source (for example ActiveDirectory), there is no single sign-on: the user will have to authenticate again within your Kiosk Session.
  • NSCM is an all or nothing decision for non-smartcard sessions. If you enable NSCM, it applies to all non-card sessions. You can't disable it selectively, for example when you use token-specific kiosk policy.
  • NSCM is slightly less comfortable than smartcard-based hotdesking. When you hotdesk a NSCM session, you need to enter both your user name and password. With smartcard-based hotdesking, you only need to enter your password to unlock the screen. And you can use AMGH to preselect a username even on initial login.
If you are not affected by these restrictions or can live with them, then NSCM is clearly the method of choice to obtain sessions that can be hotdesked to SDAC.

Answer 2: Token Aliasing

What if NSCM is not an option, because Kiosk Mode is being used, SRSS is running on Linux or your users can't remember their user names?

In that case you can use a lesser known features of SRSS: token aliasing.

Token aliasing comes at the cost of added administrative effort. It requires that only registered tokens are allowed access. This means that every smartcard, every DTU used for non-smartcard access and every SDAC instance (more exactly: profile) must be registered in the Sun Ray data store, before it can be used for Sun Ray sessions. This burden can be offloaded to your users, by enabling self-registration functionality when configuring registered token policy. Or it can be integrated with a corporate database of tokens, by using the ATI feature (see the ut_ati_script_interface(3) man page for more information). But neither of these will create aliased tokens for you - that will require manual intervention by an administrator.

So how does token aliasing help with SDAC hotdesking?

When you configure two (or more) tokens as aliases of each other, all the aliased tokens access the same session. Every smartcard is associated with a unique token, as is every DTU and every SDAC profile. (The tokens for the latter two are called pseudo-tokens.) So if you configure a SDAC pseudo token as an alias of a smartcard token, then a specific SDAC profile can be used to access sessions bound to this smartcard. In other words, you can hotdesk your card session to SDAC (with this profile) and vice versa.

As you probably noticed this means that an SDAC profile can access only one predetermined smartcard session. This is good for security - the session bound to Alice's smartcard can only be accessed using Alice's SDAC profile, but not using Bob's profile. But it also means that you can't use SDAC to quickly access an arbitrary session from any client. Bob's boss can't borrow Bob's laptop to get to his session, as he most likely has no registered profile there.

There is one pitfall with aliasing: if more than one aliased tokens are connected at once, only one of them can get access to the session. In older releases of SRSS, this resulted in session ping-pong: the second token that connects takes over the session from the first. This causes the first DTU to restart, present its token again, and take back the session. Now the second client restarts and everything repeats itself until one of the clients is disconnected.

Fortunately the 'RHA' hotdesk security feature, introduced in SRSS 4.1, fixes this problem: now the user can only take over a session for her token after authenticating to the RHA session lock. When she does this, the first client will restart, but will only display the session lock and wait for the user to come back to that location. If you like ping-pong, you can still get the old misbehavior by disabling RHA.

The pitfall that remains, even with RHA, concerns Kiosk Mode: as there is no authenticated UNIX user, no RHA authentication can take place. The session takeover protection still applies though, so if the user left his card inserted in a DTU, he will be unable to get to his Kiosk session from his aliased SDAC profile. Of course with traditional smartcard hotdesking you also don't get to hotdesk, if you forget your card elsewhere.

And how can token aliasing be set up?

By now you are probably itching to learn how you can configure token aliases.

If you aren't, why are you still reading? ;-)

Keep in mind though, that use of token aliasing is only suitable, if 'registered token only' policy can be used in your deployment. And if NSCM works for you, you can save all this administration effort.

The approach I outline here is to start with unaliased registered tokens, delete one of them from the Sun Ray Data Store and reregister it as an alias of the other. I recommend to start with both tokens registered, so that you can leave the task of figuring out the token identifier to the initial registration process, for example to self-registration. Alternatively you can obtain smartcard token identifiers by using a token reader and derive pseudo tokens from the desktop identifier (see the utdesktop(1M) man page or the Desktop Units tab in the Sun Ray administration GUI).

To make a SDAC pseudo-token an alias of another token using the Sun Ray administration GUI:
  1. Go to the Tokens tab
  2. Find the SDAC pseudo token for the user. An SDAC pseudo token id has the form pseudo.<32 hexadecimal digits>, for example pseudo.d98765f12345f23b697cfd9d072786b7.
  3. Click on the token ID to go to the pseudo.d98765f12345f23b697cfd9d072786b7- Token Properties page.
  4. Select the pseudo token ID and copy it (to the clipboard).
  5. Check that there are no sessions for this token (Advanced section). If there are sessions, terminate them.
  6. Go back to the Tokens page.
  7. Place a check mark on this pseudo token to select it and click Delete to delete it.
  8. Find the smartcard token for the same user, for example Payflex.500abcd000000100.
  9. Click on the token ID to go to the Payflex.500abcd000000100 - Token Properties page.
  10. Click the New... button on the Alias Tokens table (Advanced section) to open the New Alias Token for Payflex.500abcd000000100 page.
  11. Select Enter token identifier manually: and paste the pseudo token into the token id field (from the clipboard).
  12. Click OK.
To do the same using the command line (assuming both tokens have the name 'Barfurth'):

First determine the involved tokens, for example:

  # sdactoken=`utuser -ln Barfurth | sed -n 's/\^\\(pseudo\\.[0-9a-f]\\{32\\}\\) .\*/\\1/p'`
  # echo $sdactoken
  # cardtoken=`utuser -ln Barfurth | sed -n 's/\^\\(Payflex\\.[\^ ]\*\\) .\*/\\1/p'
  # echo $cardtoken
After obtaining the tokens, delete the existing unaliased registration and create an alias instead:
  # utuser -d $sdactoken
  # utuser -ai $cardtoken $sdactoken


Musings about my work in the (virtual) desktop space and whatever else moves me.

Keep on your desktop at all times.

Disclaimer: The statements and opinions expressed here are my own and do not necessarily reflect those of Oracle


« September 2009 »