| Sun Ray Server Software 4.1 Administrator’s Guide for Linux |    
|
| C H A P T E R 1 |
|
Sun Ray System Overview |
Sun Ray computing, originally developed to run on the Solaris
Operating System, is the first, perhaps the only, thin client implementation to offer both workstation-like user functionality and sufficient speed and reliability for mission-critical applications. Sun Ray Server Software supports Sun Ray thin clients, or desktop units (DTUs) on two flavors of Linux--Red Hat Enterprise Linux 5 and SuSE Linux Enterprise Server 10--as well as Solaris 10, including Solaris Trusted Extensions.
Sun Ray Server Software supports LAN and low-bandwidth WAN deployment, integrated VPN capability, and many USB peripheral devices, even when the Sun Ray DTU is located behind a NAT gateway.
The Sun Ray Connector for Windows Operating Systems manages connections from Sun Ray DTUs to user sessions running on Microsoft Windows Terminal Servers, including enhancements for improved video playback. It is described in the Sun Ray Connector for Windows Operating Systems 2.1 Installation and Administration Guide.
When used in conjunction with both the Sun Ray Connector for Windows and the Sun Virtual Desktop Connector, Sun Ray Server Software helps to enable access to multiple virtual desktops from Sun Ray DTUs. This capability is described in the Sun Virtual Desktop Connector 1.0 Installation and Administration Guide.
Other client-server models typically utilize combinations of remote and local operating systems, applications, memory, and storage, but the Sun Ray computing model moves all computing to a server. Instead of running applications, storing data and doing computation on a desktop device, like a PC, the Sun Ray model simply passes input and output data between Sun Ray DTUs and the Sun Ray server, where the operating system and applications are located.
Nearly any Sun server with sufficient capacity can be configured as a Sun Ray server so long as it runs a supported version of the Solaris operating system or one of the supported flavors of Linux. See the Sun Ray Server Software 4.1 Release Notes for the most up-to-date list of supported operating systems and versions.
Every Sun Ray DTU includes a smart card reader.
Sun Ray DTUs have no local disks, applications, or general purpose operating systems[1]; they are therefore considered stateless. This is what makes them true thin clients. Stateless devices are inexpensive to maintain because they require no hands-on service by administrators or technicians, whether to install, upgrade, or configure software or to replace mechanical components on the desktop. They are also extremely secure. For instance, central administration of USB mass storage devices--the ability to enable or disable their use--at the server or group level allows sites with particular security or intellectual property concerns to eliminate many of the risks imposed by PCs and other fat clients. The fact that fat clients rely on local operating systems, local applications, and local data caches means that critical data can easily be compromised when a physical device is lost or stolen.
Sun Ray sessions--groups of services controlled by the Session Manager and associated with a user through an authentication token--reside on a server rather than on the desktop. Because Sun Ray DTUs are stateless, a session can be directed, or redirected, to any Sun Ray DTU on the appropriate network or subnetwork when a user logs in or inserts a smart card. While the session continues to reside on a server, it appears to follow the user to the new DTU. This functionality, called session mobility, enables hotdesking--the ability of users to access their sessions from any DTU on their network. Hotdesking, including non-smart card session mobility (NSCM), is discussed in Chapter 5. In addition, regional hotdesking promotes hotdesking among server groups, letting users access their sessions across a wider domain. A new security enhancement, called Remote Hotdesk Authentication (RHA), requires SRSS-based authentication before users can reconnect to existing sessions.
Most large Sun Ray implementations include at least one failover group to ensure uninterrupted service whenever a server goes off-line. Once a failover group is set up, Sun Ray Server Software provides automatic load balancing to optimize performance by spreading the computing load among the servers in the group. Failover groups and related concepts are addressed in Failover Group Scenario, in Chapter 11, and in the Sun Ray Server Software 4.1 Installation and Configuration Guide.
The Sun Ray system consists of Sun Ray DTUs, servers, server software, and the physical networks that connect them.
The Sun Ray desktop unit (DTU) delivers and may exceed the full functionality of a workstation or a multimedia PC. The key features include:
compliance
The DTU acts as a frame buffer on the client side of the network. Applications run on the server and render their output to a virtual frame buffer. Sun Ray server software formats and sends the rendered output to the appropriate DTU, where the output is interpreted and displayed.
From the point of view of network servers, Sun Ray DTUs are identical except for their Ethernet MAC address. If a DTU ever fails, it can easily be replaced.
An IP addresses is leased to each Sun Ray DTU when it is connected and can be reused when the DTU is disconnected. IP address leasing is managed by the Dynamic Host Configuration Protocol (DHCP). In cases where they already exist on a network that will support Sun Ray DTUs, separate DHCP servers may be useful for tasks such as assigning IP addresses and network parameters to the DTUs. The use of separate DHCP servers is not required; however, because they require static IP addresses, Sun Ray Servers cannot be DHCP clients. These considerations are discussed in Chapter 7.
Sun Ray Server Software supports the use of multiple displays connected to a single keyboard and mouse. This functionality is important for users who need to monitor many applications or systems simultaneously or to accommodate a single application, such as a large spreadsheet, across multiple screens. To use multiple screens, the administrator sets up multihead groups, consisting of two or more DTUs, for those users who need them. Administration of multihead groups is explained in Chapter 9.
A small firmware module in each Sun Ray DTU can be updated from the server. The firmware module checks the hardware with a power-on self test (POST) and initializes the DTU. The DTU contacts the server to authenticate the user, and it also handles low-level input and output, such as keyboard, mouse, and display information. If there is a problem with the DTU, the module displays an on-screen display (OSD) icon to make it easier to diagnose. OSD icons are described in Appendix B.
An enhanced version of the DTU firmware allows configuration parameters to be entered and modified locally through a Pop-up user interface (see Pop-up GUI). This new functionality can be especially useful in implementations such as Sun Ray at Home, which allows employees to connect remotely to the same sessions they use in their offices. Because it is not suitable for certain other implementations, however, such as public libraries or secure government sites, this feature must be dowloaded explicitly and enabled by the administrator. The default version of the DTU firmware cannot be configured locally.
The administrator can configure network connections, select an authentication protocol, administer authentication tokens, define desktop properties, and perform troubleshooting.
Sun Ray server software includes:
Sun Ray server software enables direct access to all LinuxX11 applications. The Sun Ray Connector for Windows enables Sun Ray users to access applications running on remote Windows Terminal Servers (see the Sun Ray Connector for Windows Operating Systems 2.1 Installation and Administration Guide). Third-party applications running on the Sun Ray server can also provide access to Microsoft Windows applications and a variety of legacy (mainframe) applications.
The Authentication Manager implements the chosen policies for identifying and authenticating users on Sun Ray DTUs, using pluggable components called modules to verify user identities and implements site access policies defined by the administrator. It also supplies an audit trail of the actions of users who have been granted administrative privileges over Sun Ray services. The Authentication Manager is not visible to users.
The interaction between the Authentication Manager and the DTU is depicted in FIGURE 1-1. It works as follows:
2. The DTU sends the user’s token information to the Authentication Manager and requests access. If the user inserts a smart card in the DTU, the card’s type and ID are used as the token. If not, the DTU’s Ethernet address is used as a pseudo-token.
3. Based on the policy defined by the system administration, the Authentication Manager accepts or denies the access request.
4. If the user’s access request is accepted, the Authentication Manager tells the Session Manager to start an X Windows session, which takes the user to the login screen. Solaris implementations use the dtlogin screen. Linux implementations use the Gnome Display Manager (GDM).
FIGURE 1-1 Authentication and Session Manager Interaction
Normally, the Sun Ray DTU looks for the AuthSrvr DHCP option and contacts that address. If that field has not been supplied, or if the server does not respond, the DTU sends a broadcast request for any Authentication Manager on its subnet.
As an alternative, the administrator can supply a list of servers. If the authentication list is specified, only addresses on the list are checked. The Authentication Manager addresses are tried in order until a connection is made.
The site administrator can construct a combination of the different modules and their options to implement a policy tailored to the site’s needs.
Commonly used modules include:
Any type of token is accepted. Users are automatically passed through to the login window. This module is designed primarily for implementations in which Sun Ray DTUs replace workstations or PCs.
Any type of token is accepted. A temporary, transitional session is created for authentication purposes. This is used for login and hotdesking with Non-Smart Card Mobility (NSCM) and for hotdesking when a Remote Hotdesk Authentication (RHA) policy is used.
The token is accepted only if the token has been registered in the Sun Ray Data Store and the token is enabled. If the token does not meet these conditions, it is rejected. If the token is accepted, the user is passed through to the login window. This module is designed for sites that want to restrict access to only certain users or DTUs.
Users can be registered in two ways, reflecting two possible policy decisions for the administrator:
The administrator assigns smart cards and/or DTUs to authorized users and registers users’ tokens in the Sun Ray Data Store.
Users register themselves in the Sun Ray Data Store. If this mode is enabled and the Authentication Manager is presented with an unregistered token, the user is prompted with a registration window. In this case, the user provides the same information a site administrator would request.
If self-registration is enabled, users can still be registered centrally. If a token has been registered but disabled, the user cannot re-register the token; the user must contact the site administrator to re-enable the token.
A session consists of a group of services controlled by the Session Manager.
The session is associated with a user through an authentication token. A service is any application that can connect directly to the Sun Ray DTU. This can include audio, video, Xservers, and device control of the DTU. For example, dtmail is not a service because it is accessed through an Xserver rather than directly.
The Session Manager (see FIGURE 1-1) interacts with the Authentication Manager and directs services to the user. The Session Manager is used at start up for services, for managing screen real estate, and as a rendezvous point for the Authentication Manager.
The Session Manager keeps track of sessions and services by mapping services to sessions and binding and unbinding related services to or from a specific DTU. The Session Manager takes authentication only from authorized Authentication Managers listed in the /etc/opt/SUNWut/auth.permit file.
The sequence below describes how the process starts, ends, and restarts:
1. After a user’s token is authenticated, the Authentication Manager determines whether a session exists for that token. If a session does not exist, the Authentication Manager asks the Session Manager to create a session and then starts the appropriate service(s) for the session according to the authentication policy decisions taken by the administrator. Creating a session usually involves starting an Xserver process for the session.
2. When services are started, they join the session explicitly by contacting the Session Manager.
3. The Authentication Manager informs the Session Manager that the session associated with the token is to be connected to a specific Sun Ray DTU. The Session Manager then informs each service in the session that it should connect directly to the DTU.
4. At this point, the user can interact with the session. The Session Manager mediates control of the screen real estate between competing services in a session and notifies the services of changes in screen real estate allocation.
5. When the user removes the smart card or power cycles the DTU, or is inactive for longer than the screen lock idle timeout interval--the Authentication Manager determines that the session associated with that token should be disconnected from that DTU. The Authentication Manager notifies the Session Manager, which in turn notifies all the services in the session, and any USB devices, to disconnect.
6. When the user inserts the smart card again, the Authentication Manager’s default behavior is to ask the Session Manager to create a temporary new session and use it to authenticate the user. This is known as Remote Hotdesk Authentication (RHA). After the user has been successfully authenticated, the Sun Ray DTU is connected directly to the user’s session.
| Note - RHA does not apply to anonymous Kiosk Mode or to token readers. Sun Ray Server Software can be configured to turn this security policy feature off if desired. See Remote Hotdesk Authentication (RHA). |
The Session Manager is consulted only if the state of the session changes or if other services are added. When a user’s token is no longer mapped to a DTU (for example, when a card is removed), the Session Manager disconnects the services from the DTU, but the services remain active on the server. For example, programs attached to the Xserver continue to run although their output is not visible. The Session Manager daemon must continue running all the time.
To verify that the Session Manager daemon is running, use the ps command and look for utsessiond.
If the Authentication Manager quits, the Session Manager disconnects all the sessions it authorized and tells them that they have to be re-authenticated. These services are disconnected but still active. If the Session Manager is disrupted, it restarts automatically. Each service contacts the Session Manager to request reattachment to a particular session.
SRSS 4.1 now includes a new Xserver process, Xnewt, as the default Xserver. Xnewt, which supports all the latest multimedia enhancements below, is based on the release 7.2 of the Xorg Community source. For information on how to configure different Xservers, see the utxconfig(1) man page.
Sun Ray media extensions improve playback of certain kinds of video by adding support for H.264 and VC-1 codec directly in Sun Ray 2 DTUs. H.264 is the video compression standard used by MPEG-4 part 10. VC-1 is the common video compression standard used by Windows Media Player 10 and 11.
H.264 or VC-1 video playback on a Sun Ray 1 series DTU, which does not have a hardware decoding capability, uses software decoding and the accelerated YUV path. Sun Ray 2 series DTUs can decode H.264 or VC-1 videos smaller than a certain size (352*288 at 30 fps). Videos larger than this size use the same software decoding and path as the Sun Ray 1 series DTUs.
For video formats such as MPEG-1 and MPEG-2, an accelerated YUV video path enables improved playback by reducing the bandwidth required to deliver the decoded video to the Sun Ray DTU. The accelerated YUV path is used automatically so long as the correct software decoders are available for the video format required and the software is configured to make use of the XVideo extension. For example, RealPlayer and MPlayer on Solaris support the XVideo extension to utilize the accelerated YUV path. Users can ensure that the accelerated YUV path is used by selecting the Use XVideo check box in the player’s interface. The following YUV formats are supported:
For information on video playback on Windows sessions on a Sun Ray DTU, see the Sun Ray Connector for Windows Operating Systems 2.1 Installation and Administration Guide.
Sun Ray Server Software has both a command-line interface (CLI--see Chapter 2) and a graphical user interface (GUI--see Chapter 3) for administrative functions. The Sun Ray Administration Tool (Admin GUI) was completely rewritten for the 4.0 release to present a clearer view of administrative functions, with a tab-based navigational model and context-sensitive help.
Sun Ray Server Software 4.1 provides a private data store service, the Sun Ray Data Store (SRDS), for access to SRSS administration and configuration data, useful for maintaining consistency across failover groups.
Sun Ray DTUs are often used to provide anonymous users with limited access to specific applications. Sun Ray Kiosk mode software, revised and improved for the 4.0 release, is described in Chapter 10.
In addition to the servers, server software, DTUs, smart cards, and peripheral devices, such as local printers, the Sun Ray system needs a well-designed network, configured in one of several possible ways, including:
Various types of network configuration are discussed in depth in Chapter 7. For basic instructions on configuring different types of networks for Sun Ray implementation, see Basic Network Topology of the Sun Ray Server Software 4.1 Installation and Configuration Guide.
The physical connection between the Sun Ray server and Sun Ray clients relies on standard switched Ethernet technology. To boost the power of the interconnect and shield Sun Ray DTU users from the network interaction taking place at every display update, 100 Mbps switches are preferred.
There are two basic types of 100 Mbps switches:
Either type of switch can be used in the interconnect. They can be managed or unmanaged; however, some managed switches may require basic configuration in order to be used on a Sun Ray network.
Server-to-switch bandwidth should be scaled based on end-user multiplexing needs so that the server-to-switch link does not become overly saturated. Gigabit uplink ports on the switch provide high-bandwidth connections from the server, thus increasing the number of supportable clients. The distance between the server and the switch can also be extended using gigabit fiber-optic cabling.
The interconnect may be completely dedicated and private, or a VLAN, or it may be part of the corporate LAN. For private interconnects, the Sun Ray server uses at least two network interfaces: one for the corporate LAN, the other for the Sun Ray interconnect.
Even in a LAN deployment, two server network interfaces are recommended: one to connect to the general LAN and one to connect the server to back-end services, such as file servers, compute grids, and large databases.
There is no physical or logical limit to the ways that a Sun Ray system can be configured. The following sections offer some elementary examples. In addition, detailed discussions of actual deployment scenarios and other Sun Ray-related information can be found on blogs such as:
For smaller deployments, such as those with between five and 50 Sun Ray DTUs, the Sun Ray server uses a single 100BASE-T card to connect to a 100BASE-T switch. This switch, in turn, connects to the Sun Ray DTUs. With five or fewer DTUs, a wireless interconnect works acceptably at 10 Mbytes.
For larger departments with groups consisting of hundreds or thousands of Sun Ray DTUs, the Sun Ray server uses a gigabit Ethernet card to connect to large 10/100BASE-T switches. Especially with recent low-bandwidth enhancements, there is no performance need to have more than one gigabit link from the server to the Sun Ray DTU’s network.
A 100-user departmental system, for example, consisting of a Sun Enterprise server, one gigabit Ethernet card, and two large (48-port and 80-port) 10/100BASE-T switches delivers services to the 100 Sun Ray DTUs (see FIGURE 1-2).
FIGURE 1-2 Typical Medium to Large Deployment Scenario
For example, a Sun Enterprise server with a Sun 10/100BASE-T card and a 24-port 10/100BASE-T switch can easily support 23 users performing standard desktop activities.
Sun Ray servers are often bound together to create failover groups. A failover group, comprising two or more servers, provides users with a higher level of availability in case one server become unavailable due to a network or system failure.
When a server in a failover group goes down, whether for maintenance, a power outage, or any other reason, each Sun Ray DTU connected to it reconnects to another server in the failover group and to a previously existing session for the current token, if there is one, on that server. If it can find no existing session for the current token, the DTU connects to a server selected by the load balancing algorithm. This server presents a login screen to the user, who then logs in to create a new session. The session on the failed server is lost. Failover groups are discussed in Chapter 11 as well as in the Sun Ray Server Software 4.1 Installation and Configuration Guide.
FIGURE 1-3 Simple Failover Group
Enterprises with multiple failover groups and users who move from one location to another--such as between corporate headquarters and various branch offices--may wish to configure regional hotdesking. This feature provides users with access to their sessions across a wider domain and longer distance than a single failover group. It is described in Chapter 5.
Using switched network gear for the last link to the DTUs makes it difficult for a malicious PC user or network snooper at one of the network ports to obtain unauthorized information. Because switches send packets only to the proper output port, a snooper plugged into another port receives no unauthorized data. If the server and wiring closet are secure, the last step is switched, and the DTU is plugged directly into the wall jack, then it is very difficult to intercept communications between the server and the DTU. Sun Ray Server Software encryption features also help to protect sensitive data by providing options to encode keyboard input and display traffic. In addition, Remote Hotdesk Authentication (RHA), requires SRSS-based authentication before users can reconnect to existing sessions.
| Sun Ray Server Software 4.1 Administrator’s Guide for Linux | 820-3769 |
|
Copyright © 2008 Sun Microsystems, Inc. All Rights Reserved.