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 10:41, 17 August 2008 by William Yang (talk | contribs) (Current Implementation: Completed section.)
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 100 DTUs of various types (DTUs are still in the process of being deployed from the previous FY08Q2 Sun Grant). 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.

USB Flash Drives

  • How to use
  • Some don't work

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.

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.

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.


  • General
  • Use
  • Script
    • Unsupported workaround


  • 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 under certain conditions (probably 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