| Sun Ray Server Software 4.0 Administrator’s Guide for Linux |    
|
| Sun Ray Server Software 4.0 Administrator’s Guide for Linux |
|
| C H A P T E R 1 |
|
Sun Ray System Overview |
The Sun Ray thin client computing model, originally developed for Sun’s Solaris
Operating System, is the first thin client implementation to offer both workstation-like user functionality and sufficient speed and reliability for mission-critical applications. Sun Ray Server Software now supports Sun Ray thin clients on two flavors of Linux--Red Hat Enterprise Linux Advanced Server 4 and SuSE Linux Enterprise Server 9--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 OS offers easy to manage connections from Sun Ray DTUs to user sessions running on Microsoft Windows Terminal Servers.
In contrast to other client-server models, which typically utilize combinations of remote and local operating systems, applications, memory, and storage, the Sun Ray computing model moves all computing to a server. Instead of storing data and doing computation on the desktop, the Sun Ray model simply passes input and output data between Sun Ray Desktop Units (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.0 Release Notes for the most up-to-date list of supported operating systems and versions.)
Every Sun Ray DTU includes a smart card reader, a keyboard, and a mouse. Sun Ray DTUs have no local disks, operating systems, or applications; they are therefore considered stateless. This is what makes them true, or “ultra” thin clients. They are inexpensive to maintain because they require no hands-on service by administrators or technicians to install, upgrade, or configure software or to replace mechanical components on the desktop. They are also extremely secure. With the use of USB mass storage devices administered centrally, at the server or group level, sites with particular security or intellectual property concerns can remove the risk imposed by PCs and other fat clients, whose reliance on local operating systems and applications permits data loss when physical devices are stolen.
Most large 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 Chapter 11 and in the Sun Ray Server Software 4.0 Installation and Configuration Guide.
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. Again, 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. In addition, regional hotdesking lets users access their sessions from increasingly remote locations.
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 addresses. 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 pointer. 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 Linux X11 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.0 Installation and Administration Guide). Third-party applications running on the Sun Ray server can also provide access to Microsoft Windows NT 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 a smart card is inserted in the DTU, the smart card’s type and ID are used as the token. If not, the DTU’s Ethernet address is used as a pseudo-token.
3. If the Authentication Manager runs through the entire list of modules and no module takes responsibility for the request, the user’s access request is denied.
4. If the user’s access request is accepted, the Authentication Manager starts an X Windows session which takes the user to the login screen.
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.
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.
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, X servers, and device control of the DTU. For example, dtmail is not a service because it is accessed through an X server.
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 steps below describe how the process starts and ends:
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. The Authentication Manager determines that the session associated with a token should be disconnected from a DTU. The Authentication Manager notifies the Session Manager which, in turn, notifies all the services in the session to disconnect.
5. 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.
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 X server 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.
Sun Ray Server Software has both a command-line interface (CLI--see Chapter 2) and a graphical user interface (GUI) for administrative functions. The Sun Ray Administration Tool (Admin GUI) has been 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. It is described in Chapter 3.
Sun Ray Server Software 4.0 provides a private data store service, the Sun Ray Data Store (SRDS), for access to SRSS administration data across failover groups.
Sun Ray DTUs are becoming increasingly popular in public locations, such as airports, where anonymous users have limited access to specific applications. Sun Ray Kiosk mode software, revised and improved for the 4.0 release, is described in Chapter 10. Instructions for migrating configuration data from the previous Controlled Access Mode (CAM) can be found in the Sun Ray Software 4.0 Installation and Configuration Guide.
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.0 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 can be found on blogs such as http://blogs.sun.com/ThinGuy and http://blogs.sun.com/bobd.
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.
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.
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).
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 servers 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.0 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 Hotdesking (Mobile Sessions).
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.
| Sun Ray Server Software 4.0 Administrator’s Guide for Linux | 820-0412 |
|
Copyright © 2007, Sun Microsystems, Inc. All Rights Reserved.