Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

Sun Ray

From Livedoc - The Documentation Repository
Revision as of 22:14, 9 September 2009 by William Yang (talk | contribs) (USB Flash Drives: updates)
Jump to: navigation, search

Sun Ray is a proprietary thin client technology developed by Sun Microsystems. The technology includes thin clients, server software, and the communication protocol. The client is sometimes called an ultra-thin client because they possess only a firmware, whereas some thin clients run a mini-OS (such as Windows XPe or CE) and may contain local user-accessible storage.

Sun Rays use the closed, bandwidth-efficient ALP protocol to communicate with Sun Ray servers. When video playback is not involved, a 100 Mbps server uplink is more than sufficient to simultaneously support over 30 Sun Ray users.

This article is meant to supplement the official Sun Ray server documentation.


  • FOG: Failover Group (a FOG does not strictly need to contain more than one server; the concept can simply be used to separate one server from other server(s))
  • DTU: Desktop Unit; refers to the client station
  • pseudo session or pseudo token: a session or token associated with a device instead of a smart card. Most users will be using pseudo sessions unless we give everyone smart cards.

Current Implementation

The Sun Ray infrastructure managed by the Computer Systems Lab currently consists of 4 FOGs across 10 systems, and approximately 150 DTUs of various types (some DTUs from the previous FY08Q2 Sun Grant are still in the process of being deployed). The server infrastructure was initially provisioned to fully redundantly support 180 concurrent users (i.e. able to comfortably support 180 users in the event only four of the five servers in the primary FOG were available). The actual number of DTUs that can be deployed is much higher as very few system resources are consumed by an idle DTU, it is not common for all deployed DTUs to be concurrently used, and it is very rare for a server to be out of service. In other words, the system could be considered overprovisioned to allow for future growth, in the meantime providing higher performance and legroom for existing users.


All Sun Ray servers are connected to CSL VLAN 1 (TJHSST VLAN 22) and TJHSST VLAN 9 (CSL VLAN 909).

Sun Rays are primarily connected to TJHSST VLAN 9. Some CSL Sun Rays connect to the Sun Ray servers over CSL VLAN 1, but this is mostly a legacy situation prior to CSL VLAN 909 being implemented (see below). Non-legacy connections over CSL VLAN 1 are Sun Ray at Home VPN users (see section below).

Previously, each Sun Ray server was connected to VLAN 9 over a 100 Mbps link through a patch panel installed in the top rack unit of the CSL networking rack which connected to the E hub.

In the spring of 2008, a third 1 Gbps fiber uplink to the central Cisco 6509 switch was provisioned for dedicated VLAN 9 communication between the CSL switch and the TJ core network. Servers no longer use the patch panel to connect to VLAN 9. Instead, they plug into gigabit ports on the main CSL 4506 switch and are logically connected to VLAN 909. CSL VLAN 909 is a layer 2 VLAN which is connected to TJHSST VLAN 9. This new configuration allows for much greater flexibility as any CSL switch port may be connected to the Sun Ray VLAN as needed. Additionally, the Sun Ray servers share a higher total aggregate bandwidth to service the rest of the school, and are logically closer to the TJHSST core network (in the past this was less of a concern as both the Sun Ray servers and the only Sun Ray lab connected to the E hub).

A wireless network also exists for VLAN 9 for use by wireless Sun Rays (such as those on the music cart and potentially for some kiosk deployments), and also to support a potential future deployment of portable form-factor Sun Rays such as laptops or tablets. The SSID and security mechanisms in use will not be listed on this page for security reasons.

With a planned TJ network infrastructure upgrade to 10 Gbps, the Sun Ray servers will be better able to support video to DTUs should there be a need to.

TJHSST VLAN 6 has occasionally been used for testing a new Sun Ray deployment. It is currently unused and shut down.


Failover groups add redundancy to Sun Ray servers. When a session is initiated (either pseudo or smart card), the server that the DTU is currently connected to will run a weighted random (based on server specs, which can vary within a FOG) algorithm to select the Sun Ray server that the DTU should be load-balanced to, which may be itself. This means that, under normal usage, each server should own an approximately equal number of sessions (both active and idle).

In the event a server is taken offline for maintenance, all of its attached DTUs will be reset and connect to another one of the servers. If a server fails hard, the DTUs will need to time out or be reset before they will find another server. After that server comes back up, it will not have any sessions until existing DTUs are reset so that they are loadbalanced. This also means that if all the servers are down (e.g. from a power outage) and one comes up before the rest do, the Sun Rays will all find that server and connect to it. If at all possible, in this situation, manually terminate a bunch of sessions so that they can be distributed to other servers before users start logging in.

While technically FOGs must have more than one server to be a FOG, we often just use the term to also refer to single-server groups that have a distinct group signature (so that they are not part of the same FOG as other servers).

The four current FOGs at TJ:

Security and Encryption

Encryption is not enabled for most Sun Rays at this time.

Say what? Why not? At least with the Sun Ray 1 generation of devices, a severe performance impact was noticed when encryption was enabled due to the nature of the processors that are used on the DTUs. Encryption is being phased in with all new installations as of June 2009. The GL FOG is the first server group to use upstream encryption. Downstream encryption is not enabled due to the performance impact of decoding the data on the Sun Ray end.

But doesn't that mean using a Sun Ray is insecure? Not really. TJ's network is fully switched all the way to the drop, so short of using an inline packet capture device, only a TJ network administrator would be able to intercept your packets. If you don't trust them...well there are other things you should be worrying about, then.

"Server authentication" is enabled. While we're not really sure how it works, it theoretically makes the connection process less vulnerable to a man-in-the-middle attack. Even if it doesn't actually help, turning it on doesn't degrade performance, and connecting DTUs show a green check instead of a red X, which is more reassuring for users to see.

Only authorized and registered DTUs and smart cards can connect to the TJ Sun Ray network. If an unauthorized DTU or smart card attempts to connect, you will see either of two icons:

  • "Do Not Enter" icon, similar to the one found on traffic signs (pre-SRSS 4.2)
  • A smart card with an X, icon code 48 (SRSS 4.2 and later)

See "SRSS Troubleshooting Icons" link at the bottom of this page for images (only the new one will be available).

Starting with the next release of Sun Ray Software (currently in beta testing), "client authentication" is available and is enabled by default.

By secure design, Kerberos tickets and AFS tokens always expire after a set amount of time, usually less than one day from when they were obtained or renewed. This may cause issues for users that do not log out at the end of the day. Without valid non-expired AFS tokens, you cannot read or write your own home directory, which will effectively end up dead-locking your session, requiring it to be hard terminated. To avoid this, users will need to do at least one of the following:

  • Simplest: Log out at the end of the day
  • Recommended for smart card users that wish to keep their sessions or use Sun Ray at Home: Ensure that you have a screensaver that locks your screen, either manually or automatically. Every time you unlock your screen using XScreenSaver or xlock, the tickets and tokens associated with your session will be refreshed.
  • Periodically run a manual kinit;aklog to refresh tickets and tokens.
  • Set lifetimes of both tickets and tokens to be a long time (not recommended or necessarily possible).

USB Flash Drives

All flash drives should work with Sun Rays. Some external hard drives should also work, but they may need a separate power source apart from the Sun Ray USB port. The drives that do not work are probably formatted with NTFS, which is not supported on Solaris (you need to use the FAT16 or FAT32 filesystem). Certain types of hard drives are also not compatible with Sun Rays.

USB performance through a Sun Ray is not all that fast, so we recommend using a non-thin client at this time for large file transfers.

To use a drive, simply plug it in to the Sun Ray. It will automatically be mounted at /tmp/SUNWut/mnt/{username}. It should also show up on your desktop automatically (we use a modified usbdrived, originally from http://blogs.sun.com/danielc/entry/a_usb_drive_daemon_for1). Symlinks to the flash drives (for command-line users, to browse to the flash drive from an application file chooser, and for Windows via uttsc/rdesktop) can be found in USBDRVS, a subdirectory in the home directory. Icons on the Desktop and scripts in USBDRVS are also created to "eject", or safely prepare for removal, the flash drive. NOTE: this is more important on a Sun Ray than it is on other computers.


Audio should Just Work. However, a current limitation in the Sun Ray audio driver is that software mixing is not supported, although hardware mixing is. That means only one audio application can output to a single utaudio instance at a time. To take advantage of hardware mixing, then, we use tjutaudiowrap, based on a script provided by Kent Peacock at Sun. The scripts are located in /usr/local/bin_override and are executed instead of the real application that outputs audio. The script then quietly sets up a utaudio instance just for the application being started before running the actual application itself so that hardware mixing can still work. Note that a wrapper script for each application we want to audiowrap must be created.

Automated Printer Selection

Inspired by the Follow-Me Printing concept.

  • Upon a user logging in, login script 0101.sunray_setprinter is run. It will check if the login is from a Sun Ray, and if it is, it will look up the DTU's MAC address in the utdesktop database. The "Location" field in the utdesktop database is not the location, but is actually the default printer that the DTU should use. It then sets the PRINTER variable to that name. In the event there is no default printer for the DTU or the specified default printer does not exist, the variable will not be set and the server default of Please_Select_A_Printer will be used.
  • Smart card users are more complicated. We don't have logic to fully handle them. A smart card user's default printer will be set to what the default printer for the DTU that he/she logged in from was set to. The default printer will not change until the user logs out. In other words, if I log in to a library DTU with my smart card, my default printer will be "Library" regardless of where I hotdesk until I log out and log back in.

Hotdesking/Smart Cards

Hotdesking allows users to move their session from station to station while keeping their applications and documents running. This is an unusual concept for many people because of the prevalence of desktop computing which does not have this ability (at least as far as I have seen). Try thinking of it like this: it's just like leaving your laptop on all the time and carrying it with you...except you can only use your laptop where there is a Sun Ray, and there is no laptop, just the Sun Ray.

Hotdesking on Sun Rays can be achieved with or without a smart card. To hotdesk without a smart card, non-smartcard mobile (NSCM) sessions must be enabled. We tried this a few years ago, but we decided not to enable it realizing it meant that lots of people would just never log out, consuming system resources and impacting active users.

Smart card

At TJ, smart cards are used primarily for hotdesking. In some cases they are used for AMGH (see section below). At the Department of Defense and at other security-minded locations, when used with Sun Rays, smart cards are likely used for both two-factor authentication and hotdesking.

Currently smart cards are issued only to admins that request them. We are also beginning to issue them to some teachers and students, but a formal process and "cheatsheet" for users have not been completely worked out yet.

Upon inserting a smart card that does not have a session yet, a user is greeted with the usual login screen. If the smart card already has a session, the user should see a password dialog and/or be required to unlock their screensaver. This ensures that a session isn't automatically compromised if someone loses their smart card.

  • With the current release of Sun Ray server software, this security mechanism relies entirely on the screensaver and sometimes fails to trigger upon removal of the smart card. Because of this, we highly recommend that smart card users configure their screensavers to lock after a short amount of time.

Labeling Guidelines

For consistency, we have a basic standard for labeling smart cards. Here are the steps.

Common guidelines:

  • Place the card horizontally with the reader contact to the right and away from you. Labels go on the side without the contact.
  • Text is all CAPS.
  • Place the primary label at the top of the card, a bit from the top edge and left-aligned but not covering or barely covering the word "Sun."

Primary label:

  • User cards: first and last name using the large font size. If the name is long, use the medium font size.
  • AMGH/lab use: techlab or course name using jagged ends outline with the medium font size.
  • Music cards: music genre using the box outline with the medium font size.
    • If card is not a genre but for a user's music directory (e.g. mkremer or bjones): use lowercase.

Secondary label (ONLY if this is a smart card that will connect to a FOG other than the main one):

  • Medium font size
  • Alligator outline for HPC or GL/Graphics, train outline for Testing
  • Use keyword for FOG: TESTING, HPC, or GL
  • Align label with:
    • left edge of primary label if it is HPC
    • centered with primary label if it is Testing
    • right edge of primary label if it is GL


AMGH is short for Automatic Multi-Group Hotdesking. It is sometimes referred to as Regional Hotdesking.

AMGH allows a user to access a session that is in a FOG other than the one that the Sun Ray is currently connected to. On Sun's corporate network, Sun Ray relies on AMGH when a user inserts a smart card to always redirect the Sun Ray to the user's local office server group. For instance, if a user from the McLean office took a business trip to the Santa Clara headquarters, the Sun Ray would redirect to the McLean server to handle the user's session. AMGH is not handled by the smart card or DTU, but by a logic script on the Sun Ray server, so at this time it is not possible to use AMGH to connect, for instance, to the TJ Sun Ray servers from a Sun office.

It is important that all of the Sun Ray servers in every FOG that can be switched have the same logic, otherwise a Sun Ray may become "stranded" in a FOG. For instance, if the Main FOG knows that a smart card should trigger a switch to the HPC FOG, but the HPC FOG doesn't know about that smart card, no session will be initialized. Or if the HPC FOG doesn't know that the Sun Ray without a smart card should operate in the Main FOG instead of staying in the HPC FOG, it will not send the Sun Ray back to the Main FOG after the HPC FOG smart card is removed.

TJ Configuration

We use a logic script, located at /usr/local/amgh/tjamgh, to tell the Sun Ray servers how to look up the AMGH information.

The actual information on what tokens should be redirected to which FOG is handled by the utuser database. We use the "server" field (which doesn't appear to be used by Sun Ray software itself) to store the name of a server in another FOG that the Sun Ray should connect to. For instance, to send a smart card to the GL FOG, this attribute is set to "copernicus.sun.tjhsst.edu" for that registered token. Tokens without a server specified (i.e. the field is empty) will cause the Sun Ray to switch back to the first server it connected to on boot, which should always be a server in the Main FOG. All pseudo sessions currently have an empty server field; that is, the only way at this time to use a FOG that isn't Main is to use a smart card.

Limitations of this system:

  • If the specified server in the FOG is down, the Sun Ray may fail to switch over, even if other servers in that FOG are up.
  • The utuser database is only replicated within the servers of a single FOG. The database must be updated in each FOG to ensure consistent AMGH behavior.
  • To overcome these limitations, it is recommended to use a FOG-neutral database such as LDAP to keep information on how to redirect. It is also recommended to store information on all the servers in every FOG in this database, and then to change the tjamgh script so that it returns all of them (so the Sun Ray can try multiple addresses if prior ones fail). However, this doesn't seem to be immediately needed as the systems have been reliable thus far.

An unsupported workaround in use:

AMGH was never designed to be used with private interconnects; by the time it was introduced, Sun Ray had added support for and preferred running traffic over a public interconnect. A Sun Ray on a non-routed private interconnect cannot reach "copernicus.sun.tjhsst.edu" because the hostname refers to the primary routed interface of the server. Since all of the Sun Ray servers follow IP assignment guidelines of 198.38.17.X on the primary network and 10.0.0.X on the private network, it is possible to have the script easily handle AMGH properly for both Sun Rays on the public and private networks. If AMGH sees that the Sun Ray is coming from the private interconnect based on its IP, instead of returning the hostname of the destination server, it will return the private interconnect IP.


  • Sun Ray commands are prefixed with "ut", referring to the Ultra Thin client nature that is a DTU.
  • In the 2.0 era of Sun Ray, the DTU firmware would display a newt mouse cursor when it couldn't reach an X server on the Sun Ray server (roughly equivalent to a present-day 26D hang). This was a reference to a preliminary name for Sun Rays, Network Terminal.
  • tftp filenames of firmware for first generation Sun Rays begins with "Corona", a reference to the R&D stage project name, Project Corona.
  • Some interesting history from Sun Labs: http://research.sun.com/features/tenyears/volcd/papers/nrthcutt.htm

Sun Ray at Home

Users must establish a connection to the CSL network to use a Sun Ray remotely. The Sun Ray servers can not be directly reached through the internet for security reasons. The easiest way to connect is to use the IPSec VPN (click for details; it is easiest to have an administrator preconfigure your Sun Ray before checking it out). OpenVPN may also be used, but requires configuring an additional computer or device to route or bridge as the Sun Ray firmware does not support it (yet).

The round-robin addresses sunray-config-servers.sun.tjhsst.edu and sunray-servers.sun.tjhsst.edu are configured for the benefit of Sun Ray at Home users. These DNS entries needs to be updated when the primary FOG Sun Ray servers change.

Sun Ray at Home users are required to use a smart card as part of security policy. This is enforced by not authorizing/registering a SR@H DTU such that, without using a smart card, a pseudo session will not be initialized and the user should see a red "no" sign, similar to the standard highway "Do Not Enter" signs (it has been reported some routed home connections will not display this symbol, but will simply wait forever attempting to start a pseudo session until a smart card is inserted).

See Also