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 12:45, 16 December 2008 by William Yang (talk | contribs) (Current Implementation: Out of date!)
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 shutdown.


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

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.

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

For the most part, flash drives work with Sun Rays. A few do not; we are working with Sun to hopefully get them working. Hard drives also appear to not work, probably because they require a larger power draw than the Sun Ray is able to supply, so they may work if an external powered USB hub is used.

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 flash drive, simply plug it in to the Sun Ray. It will automatically be mounted at /tmp/SUNWut/mnt/{username}. It doesn't show up on your desktop automatically, so we've added a few scripts to make this easier. Using these scripts, you can:

  • Create shortcut to flash drives on desktop (recommended way to access flash drives)
  • Open window to directory with flash drives (using GNOME/JDS nautilus file browser)
  • Safely prepare flash drive for removal (NOTE: this is more important on a Sun Ray than it is on other computers)

To use these scripts, from:

  • JDS or KDE
    • Click on the menu ("Launch" or "K")
    • You will see the actions in the main section
  • Fluxbox, Fvwm, menuless window managers: see "Terminal/Command line"
  • Other window managers
    • The location in the menu will vary; the items may be located in either a GNOME or KDE subsection, but should be obvious once found.
  • Terminal/Command line
    • cd `cdusbdrive` to switch to the directory containing the flash drive mountpoints.
    • cdusbdrive nautilus to view the directory using nautilus (or change "nautilus" to your favorite file browser to view the directory using that).
    • linkusbdrive to create a link to the directory containing the flash drive mountpoints in ~/Desktop.
    • ejectusbdrive to unmount a flash drive for safe removal.

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. This is also the reason we decided not to give everyone a smart card.

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/realamgh, to tell the Sun Ray servers how to look up the AMGH information. Note that when configuring Sun Ray server, /usr/local/amgh/tjamgh should be referenced instead; it seems that the AMGH component will read the script into memory when the policy is first configured and when services are restarted instead of reading the script at runtime. By having tjamgh simply call realamgh, we can make changes to the AMGH script without reloading the AMGH script into Sun Ray by restarting Sun Ray services.

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

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

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