Adv Admin Guide

8/6/2019 Adv Admin Guide

1/66

901 San Antonio Road

Palo Alto, CA 94303-4900 USA

650 960-1300 Fax 650 969-9131

Sun Ray

Enterp rise ServerSoftw are 1.1 Ad vanced

Administrator s Guide

Part No. 806-4181-10

Apr il 2000, Revision A

Sun Microsystems , Inc.

Send comments about this document to: [email protected]


2/66


3/66

i

Contents

Preface v

1. Switches on the Sun Ray Interconnect 1

Sun Ray System Comp uting Mod el 1

Qu ality of Service 3

Sw itch Technical Requirements 4

Constraints 5

Auto-Negotiation 5

Tur n-On Time 6

Band w idth Limitation and Packet Loss 7

Examp le Topo logies 7

Sw itching Scenarios 10

String ing Switches Together 10

Using Add itional Netw ork Interface Cards 13

Multiplexing 14

Replacing H ubs With Sw itches 15

2. Failover 17

Failover Overview 17

Setting Up IP Add ressing 19


4/66

ii Sun Ray Enterprise Server Software 1.1 Advanced Administrators Guide April 2000

Setting Up Class C Add resses 20

Server Ad dresses 20

Client Ad dresses 20

Configuring DH CP 22

Coexistence of the Sun Ray DH CP Server With Other DH CP

Servers 22

Ad ministering Other Clients 23

w

To Set Up IP Ad dressing on Mu ltiple Servers Each With One Sun RayInterface 23

Group Manager 25

Redirection 26

utselect 26

w To Redirect to a Different Server 27

utswitch 27

w To Man ually Redirect an App liance 28

w To List Available H osts 28

w To Select a Different Current Server 28

Group Man ager Configuration 29w To Restart the Auth entication Manager 31

Load Distribution 32

w To Tur n Off the Load D istribution Feature 32

Setting Up an Adm inistered Group 32

Primary Server 33

w To Specify a Primary Server 33

Replication Setup 34

w To Specify Each Secondary Server 34

Removing Replication Configuration 34

w To Remove the Replication Configu ration 34


5/66

iii

Other Scenarios 35

Primary/ Second ary Pair 35

Primary/ Multiple SecondariesUnconfiguring a Second ary 35

Primary/ Multiple SecondariesUnconfiguring the Prim ary 35

Viewing th e Ad ministration Status 35

w To Show Current Ad ministration Configurat ion 35

Recovery Issues an d Procedu res 36

Secondary Server Recovery 36

Primary Server Recovery 36

w To Rebuild the Primary Server Ad ministration Data Store 36

Setting Up a Trusted Group 37

w To Create the Grou p Man ager Signa tu re File 38

3. Customiz ing the Window Manager 39

Wind ow Man ager Functionality 39

Customizing CDE 40

w To Remove an Icon From th e Front Panel 40

Kiosk Mode 42

Alternate Window Managers 42

w To Specify an Alterna te Wind ow M anager 42

4. Citrix and Windows N T 45

Microsoft Windows NT on Sun Ray SystemGuidelines 45

NT Term inal Server 45

Citrix MetaFrame 46

ICA Client 46

User Accoun ts on NT 46

Unix Settings 46


6/66

iv Sun Ray Enterprise Server Software 1.1 Advanced Administrators Guide April 2000

Glossary 49

Index Index-53


7/66

v

Preface

The Sun Ray Enterprise Server Software 1.1 Advanced Administrators Guide extend s the

information provided in the Sun Ray Enterprise Server Software 1.1 Administrators

Guide so that pow er users can customize their servers.

This guide is intended for system ad ministrators who are already fam iliar with the

Sun Ray computing paradigm and have substantial networking knowledge.

Before You Read This Book

Read th e Sun Ray Enterprise Server Software 1.1 Installation Guide, the Sun Ray

Enterprise Server Software 1.1 Administrators Guide, and the Sun Ray Enterprise Server

Software 1.1 Product Notes.

This guide assum es that you ha ve installed the Sun Ray server software on your

server from the Sun Ray Enterp rise Server Software 1.1 CD and that you have ad ded

the required patches.

How This Book Is Organized

Chapter 1 describes the requirements of switches to be used on the Sun Ray

interconnect and describes how to configure switches for specific scenarios.

Chapter 2 describes the new failover option, wherein two or more Sun Ray servers

may back-up each other so that in th e event of a Sun Ray server failure, a reserve

Sun Ray server is available.


8/66

vi Sun Ray Enterprise Server Software 1.1 Advanced Administrators Guide April 2000

Chapter 3 describes customizing the Sun Ray enterp rise server software and

alternate window managers.

Chapter 4 d escribes the use of Citrix ICA Client for Solaris, Citrix MetaFram e, and

WindowsNT.

Using UNIX Commands

This docum ent d oes not contain information on basic UNIX comm and s andprocedures, such as shutting d own the system, booting the system, or configuring

devices.

For this informa tion, see the AnswerBook2 online docum entation for the

Solaris 2.6 or 7 operat ing env ironm ent or http://docs.sun.com (see Sun

Documentation on the Web on page viii).

This docum ent d oes contain information abou t un ique Sun Ray system comm and s.


9/66

vii

Typographic Conventions

Shell Prompts

TABLE P-1 Typographic Conventions

Typeface or

Symbol Meaning Examples

AaBbCc123 The nam es of command s, files,

and directories; on-screen

computer output.

Edit your .login file.

Use ls -a to list all files.

% You have mail.

AaBbCc123 What you type, when

contrasted w ith on-screen

computer output.

% su

Password:

AaBbCc123 Book titles, new w ord s or terms,

words to be emp hasized.

Comm and -line variable; replace

with a real name or value.

Read Chapter 6 in the Users Guide.

These are called class options.

You mustbe root to do this.

To d elete a file, type rm filename.

TABLE P-2 Shell Promp ts

Shell Prompt

C shell machine_name%

C shell sup eruser machine_name#

Bourn e shell and Korn shell $

Bourn e shell and Korn shell superu ser #


10/66

viii Sun Ray Enterprise Server Software 1.1 Advanced Administrators Guide April 2000

Related Documentation

Sun Welcomes Your Comments

Sun is interested in improving its documen tation and welcomes your comments

and suggestions. Email your comm ents to:

[email protected]

Please includ e the p art nu mber of your docum ent in the su bject line of your email.

Sun Documentation on the Web

The docs.sun.comSM web site enables you to access Sun technical documentation

on the Web. You can browse the docs.sun.com archive or search for a specific booktitle or su bject at:

http://docs.sun.com

TABLE P-3 Related Docum entation

Application Title Part Number

Installation Sun Ray Enterprise Server Software 1.1

Installation Guide (English)

805-7916-11

AdministrationSun Ray Enterprise Server Software 1.1

Administration Guide (English) 805-7915-11

Product Notes Sun Ray Enterprise Server Software 1.1

Product Notes (English)

805-7918-12


11/66

1

CHAPTER 1

Switches on the Sun RayInterconnect

On the Sun Ray interconnect, the optima l way to han dle netw ork traffic is throu gh

switch technology, wh ich su pp orts mu ltiple transm issions simultaneously and

increases available band wid th. Netw ork ad ministrators must verify the

configuration of each netw ork d evice and that its configuration m atches its

performance.

This chapter d escribes the requirements of switches to be u sed on the Sun Ray

interconnect and describes how to configure switches for specific scenarios.

Sun Ray System Computing Mod elThe Sun Ray enterpr ise system employs a highly network-depend ent compu ting

mod el where all actual comp uting is done at a server and d isplay data is passed

back and forth, instant by instant, between the Sun Ray enterpr ise server and the

Sun Ray 1 enterprise appliances. Traffic in this environment (which is isolated from

the LAN) can be h eavy, and any n etwork bottlenecks are immed iately reflected at

the u sers desktops. Thus a p owerful, well-designed interconnect between server

and app liances is essential for p roviding high qu ality of service to u sers.


12/66

2 Sun Ray Enterprise Server Software 1.1 Advanced Administrators Guide April 2000

FIGURE 1-1 The Sun Ray Enterp rise System and the LAN

Legend:

1. Managed environment

2. Local area network (LAN)existing connection to intranet or Internet

3. Servers

4. Sun Ray serverexecutes applications

5. Dedicated interconnectusing H ot Desk protocol

6. Switch

7. Sun Ray 1 enterprise appliances

To boost the power of the interconnect and shield Sun Ray 1 appliance users from

the netw ork interaction taking p lace at every display u pd ate, 100 Mbps sw itches are

preferred.

There are two basic types of 100 Mbps switches:

s Low-capacity sw itchesThese sw itches hav e 10/ 100 Mbps in terfaces for each

port.

s High-capacity switchesThese switches h ave 10/ 100 Mbp s interfaces for each

terminal p ort, but one or m ore gigabit interfaces to attach to th e server.

2

1

3

4 6

7

5


13/66

Chapter 1 Switches on the Sun Ray Interconnect 3

Either of these switches can be u sed in the interconnect. They m ay be m anaged or

unm anaged. H owever, managed switches usually require some basic configuration

to use on a Sun Ray network. For details, refer to the Sun I/ O Technologies web

page at:

http://www.sun.com/sunray1

Server-to-switch band wid th shou ld be scaled based on end -user mu ltiplexing n eeds

so that th e server-to-switch link does n ot become overly saturated. Gigabit up link

ports on the sw itch p rovide high-bandw idth connections from server, thus

increasing th e nu mber of supp ortable clients.

To ensure high-speed tran smission of th e H ot Desk p rotocol, the interconnect mu st

be completely dedicated and private (that is, not part of the corporate LAN). To thisend, the Sun Ray server uses at least tw o netw ork interfaces: one for the enterp rise

LAN, the other for the Sun Ray interconnect. With its own dedicated interface, the

interconnect is isolated from other LAN activity and is, therefore, private.

Category 5 cables are required on the Sun Ray interconnect. It is importan t to m ake

sure that your tw isted p air wiring meets the CAT 5 standard s.

It is also imp ortan t to p lan for a 100BASE-T, full-du plex netw ork. Half-du plex

services, or 10 Mbps, redu ce the sup ported num ber of Sun Ray 1 enterpriseapp liances and d egrade th e quality of service on th e interconnect.

Note You can extend the d istance between you r Sun Ray server and switch byusing gigabit fiber-optic cabling.

Qu ality of Service

In the Sun Ray enterprise system, the interconnect between the enterprise appliances

and the service providers is a p rivate commu nications channel. The ap plication-

specific protocol depend s on a reasonable level of assuran ce that a defined Quality

of Service (QOS) level is provided . This level of assuran ce is directly related to the

following elements:

s Switch latency and buffering

s Available ban dw idth


14/66


Switch Technical Requ irements

Although the Sun Ray enterprise system leverages comm odity network equ ipment,

not any switch can be used in the interconnect. The interaction betw een the

Sun Ray 1 enterprise appliance, the server, and th e switch m ust m eet the following

qualifications.

TABLE 1-1 Switching Features Required on the Sun Ray Interconnect

Switch Feature Requirement Notes

A ut o-n eg ot ia tio n En ab led A ll n et wo rk eq uip m en t m u st a ut o-n eg ot ia te

flawlessly with a Sun Ray 1 enterprise

app liance. Sun Ray 1 appliances have no state

and therefore have no m eans to configure link

param eters. If there are any au to-negotiation

problems, the switches cannot be u sed.

Buffering High-capacity Do not use cut through switches. Use store andforwardswitches.

Sup port for full-

du plex connections

En ab led Sw it ch es sh ou ld su p p or t fu ll-d u p lex

connections to the Sun Ray 1 enterprise

app liance and to the server. Half-du plex

connections reduce the appliance number and

performan ce on the interconnect.

Latency Low Switches add latency, or delay, to network

traffic. Latency mu st be low to ensu re qua lity ofservice to ap pliance users.

Lin k-u p t im e M in im u m Th e lin k-u p t im e of cer ta in sw it ch es in clu d es a

dead time during which all packets from an

active link are ignored. This affects appliance

startup.

Mu lticastin g En abled Th e Au th en tication Man ager u ses m u ltica stin g

to enable commun ication between Sun Ray

servers over their Sun Ray netw ork interfacesin a failover environment. If the Sun Ray

network switches do not support multicast

add ressing, the sw itches falsely determine th at

the Sun Ray interfaces have timed out.

Consequently, m anu al red irection fails, and

other Sun Ray servers are not d isplayed in the

utselect or utswitch utilities.

Sp an nin g tree Disa bled Sp an nin g tree p olicies d efa ult to v ery

conservative values that affect app liance

startup.


15/66


Refer to the web p age at http://www.sun.com/sunray1 for detailed descriptions

on how to configure switches to meet these requirements.

Constraints

The Sun Ray 1 enterprise app liance is designed to w ork w ell with an y standard

Ethernet switch and relies solely on Level 2 switching support.

In the rare case that a switch did not test satisfactorily within the Sun Ray 1

enterprise app liance environment, it could be tra ced back to one of the following

issues:s Auto-Negotiation on page 5

s Turn-On Time on page 6

s Band wid th Limitation an d Packet Loss on page 7

Auto-Negotiation

Note All switches used in the interconnect should be configured to Auto-Negotiateinstead ofHard Coded Direct Connect.

Note You cannot h ard code the speed / du plex rate on the Sun Ray 1 enterpr iseappliances.

The Sun Ray 1 enterprise app liance contains n o internal state, and so it cannot be

configured for a specific Ethernet interface setting. The appliance relies on auto-

negotiation. With a small num ber of switching p rodu cts, there have been

mismatches in th e results of auto-negotiation, from complete failure to operate to

negotiation of op eration a t less than 100 Mbp s full-du plex. You can t est a sw itch by

connecting the Sun Ray 1 enterprise app liance to the switch and observing th e

results of the connection. Extensive testing with more clients gives a greater degree

of confidence.

To prevent negotiation problems for a fast connection, configure both sides of a

connection to au to-negotiate. This requirem ent is d escribed in th e IEEE 802.3z

(Gigabit system) au to-negotiation sp ecification.


16/66


FIGURE 1-2 Problematic Switches and Auto-Configuration

Legend:

1. 10/ 100 Mbps N IC (network interface card) w ith port configured for auto-negotiation

2. Sun Ray enterprise server

3. End nod e configured for 100 Mbp s/ full-du plex or 10 Mbps/ full-du plex (not au to-

negotiation)

4. Sun Ray 1 enterpr ise appliances

For exam ple, if a switch is configured t o auto-negotiate an d th e attached en d n ode is

configured to 100 Mbps/ full-du plex, the 802.3z specification req uires th at th e switch

not allow the 100 Mbps/ full link to be established.

In FIGURE 1-2, after failing to auto-negot iate, the switch correctly senses the 100 Mbp s

speed. Since the end node was configured for a specific speed and du plex state, it

does n ot au to-negotiate; consequently, the d own stream sw itch chooses the

comm un ication mod e specified by 802.3u (the specification for the 100-Mbp s system)

standard , which is half-dup lex.

This connection works reasonably well at low levels of traffic. However, at higher

levels (many en d u sers accessing the intern et) the full-d up lex dev ice (in this case the

dow nstream sw itch) experiences redu ced band wid th. The configuration of each

network device must be verified, and its configuration shou ld m atch its

performance.

Turn-On Time

The Sun Ray 1 enterpr ise appliance is design ed to tu rn on an d be fully operationa l in

a very short timetypically less than 10 seconds.

Some sw itches hav e initial configurations that cause this tur n-on time to be

considerably longer, often taking as long as 30 second s to achieve full working sta te.

Turn-on times typically are longer because the Ethernet switch is configured to

implement capabilities not need ed in th e Sun Ray 1 enterpr ise applianceenvironment. The most common of these capabilities is enabling Spanning Tree

1

2

3

4


17/66


protocols, which are d esigned to d etect and compensate for loops in the connection

between sw itches. Disable or defer Spann ing Tree protocols for Sun Ray 1 enterp rise

app liance operation.

If Spann ing Tree is disabled a nd the tu rn-on t ime is still excessive, contact th e switchman ufacturer to determine if there are other options that might be interfering w ith

the Sun Ray 1 enterpr ise appliance. Some sw itches m ight have features designed

into the sw itch that cann ot be changed ; if this is the case, then it m ay not be p ossible

to reduce the turn-on time.

Band width Limitation and Packet Loss

The Sun Ray 1 enterprise app liance dep ends on low latency, low p acket loss

delivery of the inform ation u sed to create th e screen image. Packet losses are visible

to the user as horizontal bands in the d isplay, where display up date information has

been lost. Add itionally, the loss of informa tion is noticed by th e server, which slows

dow n tran smissions to compensate. This causes wind ows on the screen to display

more slowly. These problems are tem porary and not critical. The d ropped

information is redisplayed quickly.

If this behavior occurs frequently, the cause for d ropp ing p ackets m ay be either a

misconfigured switch or an oversubscribed switch. If a switch is not capable of

transferring data at the maximum rate on all interfaces simultaneously, it is

oversubscribed. This is not a p roblem in a norm al LAN environment because m ost

networks are underused, and dropped packets are recovered by higher level

protocols requesting retran smission of the informa tion. In a seriously oversubscribed

environment, the Sun Ray 1 enterprise app liance performance m ay become

unsatisfactory.

Recently m anu factured switches cannot be oversubscribed; that is, there should

never be any p ackets drop ped with these sw itches. If you have older sw itches

installed, primarily in mainframe configurations, the band wid th m ay be qu ite low.

In this situation, there may be significant oversubscription and the possibility of

packet loss du ring high p eak band wid th u sage. With these switches, carefully

review the m anu facturer s specifications on sw itching backplane or backplane

bandwidth for further information on bandwidth limitation and packet loss.

Example Topologies

The following figures illustrate topologies for two different sizes of the Sun Ray

interconnect.


18/66


s In the Med ium Interconnect Examp le, a Sun Enterpr ise 450 server supports 48

Sun Ray 1 appliances through tw o 24-port sw itches.

s In the Large Int erconnect Examp le, a Sun Enterp rise 4500 sup por ts 204 Sun Ray 1

app liances through two 48-port sw itches and three 36-port sw itches.

Details on server resources and wiring are show n in th e figures.

FIGURE 1-3 Medium Interconnect Example

Legend:

1. Sun Enterprise 450 server configured as follows:s Four 300 MHz UltraSPARC processors

s 2 Gigabytes DRAM

s 16 Gigabytes disk space

s One GEM n etwork interface card

2. Cabling to provide 1000 BASE-SX

3. 24-port switch with 1000 BASE-SX ports

4. Cabling to p rovide 100 Mbps bandw idth


Enterprise 450

4x300 MHz CPU2 GB DRAM16 GB Disk

3 3

1 x gem

5 5

100 Mbps

x2

1000 BASE-SX

... ... ... ...x48

1

2

4 4


19/66


FIGURE 1-4 Large Interconnect Examp le

Legend:

1. Sun Enterpr ise 4500 server configured as follows:

s Eight 333 MH z U ltraSPARC p rocessors

s 6 Gigabytes DRAM

s 8 Gigabytes disk space

s

Two GEM network interface cards

2. Cabling to provide 1000 BASE-SX





Enterprise 4500

8x333 MHz CPU6 GB DRAM8 GB Disk

3

2 x gem

6 6

100 Mbps

1000 BASE-SX

... ... ... ...x96

3

4

4

4

x108

1

22

5 5


20/66


Switching Scenarios

When p lanning the d evelopm ent of the interconnect, take into account both required

and available bandw idth. Bottlenecks are more likely to d evelop in the comp onents

connected to the LAN than within the interconnect itself. Carefully select a

compatible switch. In w orkgroup compu ting, meet the continuously rising d emand

for bandw idth by u sing switches and hubs carefully.

Stringing Switches Together

A cascading sw itch u tilizes the connection of twisted p air hubs by run ning tw isted

pa ir cable from one sw itch to another w ithin the interconn ect fabric. You can also

cascade or string several switches together via CAT 5 cable. Unfortunately, this

technique can redu ce the overall performance of the interconnect.

Rather than cascade switches (FIGURE 1-5), it is recommended that you connect them

using 1-Gigabit fiber-optic cable. The best approach is to connect multiple switchesvia a Gigabit core (FIGURE 1-6). Another p referred a pp roach is to daisy chain the

switches (FIGURE 1-7). See th e figures below.


21/66


FIGURE 1-5 Cascading Switches

Legend:

1. Local area netw ork (LAN)

2. Category 5 cable


4. Gigabit switch


6. Switches


4

1

3

66

2

100 Mbps5 5

7 7


22/66


FIGURE 1-6 Cascading Gigabit SwitchesPreferred

Legend:

1. Local area network (LAN)

2. Category 5 cable


4. Gigabit core switch

5. Cabling to provide gigabit (1000 Mbps) bandw idth

6. Gigabit switches


4

1

3

66

2

1000 Mbps5 5

7 7


23/66


FIGURE 1-7 Daisy-Chained SwitchesPreferred

Legend:

1. Local area netw ork (LAN)

2. Category 5 cable


4. Cabling to provide gigabit band wid th

5. Daisy-chained gigabit switches


Using Ad ditional Network Interface Cards

Additional network interface cards (NICs) can increase the size of the interconnect.

Additional cards increase bandwidth and support more users or features.

1

3

55

2

4

66


24/66


FIGURE 1-8 Add itional Networ k Interface Cards: 10 Users With 1 Card , 20 Users with 2Cards

Legend:

1. Local area network (LAN)

2. Category 5 cable

3. O ne or more netw ork interface cards

4. Gigabit sw itches (10:1 ratio)


MultiplexingMultiplexing is the p rocess of transmitting two or m ore signals over a single

channel. This process is sometimes referred to as muxing. Since the interconnect

fabric is constructed using shared or switched LAN technology, you can assume a

mod erate d egree of statistical m ultiplexing is p resent. The Sun Ray 1 enterpr ise

ap pliance conn ects to the interconnect v ia its 100BASE-T inter face. The enterp rise

app liance is capable of displaying app roximately 35 Mbps of virtual d esktop

44

1

3

5

2

5


25/66


protocol. This reflects a multip lexing ra tio of 3 to 1 (withou t any d egrad ation). Using

statistical multiplexing ratios as high as 10 to 1 are possible with little chance of

packet loss (due to congestion). Ratios of 25 to 1 are a good rule of thumb.

Note Always assum e that mod erate am ounts of statistical traffic multiplexingexists (10:1 is a very conservative ratio; for example, 100 appliances can be connected

via one g igabit link).

Replacing H ubs With Switches

While it is possible to u se 100 Mbps h ubs on th e interconnect, hubs provide shared

bandw idth rather than switchedband wid th. Select a switch over a hu b wh enever the

condition allows. If you plan to distribute video to the Sun Ray 1 clients in the near

future, higher-capacity switches (designed to han dle the large requirements of high

bandwidth) should also be considered.

By replacing existing hubs in your interconnect with switches, switching functions

can be provided at the w orkgroup level. Hubs are ha lf du plex; switches are fulldu plex. Use hu bs only to get fan ou t (between sw itches and app liances). Allocate

generous band wid th at the switch when using hu bs. Make sure the switch is

configured to full bandw idth. Refer to you r sw itch d ocumentation for specific

details.


26/66



27/66

17

CHAPTER 2

Failover

The single point of failure scenarios discussed in Chapter 1 can be mitigated by

instituting a failover group consisting of mu ltiple servers. This chap ter describes this

failover option, which is new in this release.

This chapter covers these topics:

s Setting U p IP Add ressing on page 19

s Configuring DH CP on p age 22

s Group Ma nager on p age 25

s Setting Up an Ad ministered Group on pa ge 32

s Viewing the A dm inistration Status on p age 35

s Recovery Issues and Procedu res on p age 36

Failover Overview

The Sun Ray enterprise server software version 1.1 provides clients with a higher

level of availability of service w hen a h osting server becomes un available d ue to a

network or m achine failure. See FIGURE 2-1.


28/66


FIGURE 2-1 An Examp le Sun Ray System w ith Failover Feature

Legend:

1. Local area network (LAN) existing connection to intranet or Internet

2. Sun Ray servers execute X wind ows servers a nd X app lications

3. Interconnect fabric private netw ork d edicated to Sun Ray 1 app liances (not

part of the LAN)

4. Switches

5

1

2

4

3

5

42


29/66

Chapter 2 Failover 19

5. Sun Ray 1 appliances

When a server fails, each Sun Ray 1 appliance that w as u sing that server reconnects

to one of the oth er servers in the failover group. The ap pliance connects to a

prev iously existing session for that token if there is one on an other server. If there isno existing session, the app liance conn ects to a server selected by a load-d istribution

algorithm. This server creates a new session and presents a login screen to the user.

The user must relogin to create a new session. The state of the session on the failed

server is lost.

The principal compon ents needed to implement failover are:

s Multiple, coexisting Dynamic Host Configuration Protocol (DHCP) serversAll

servers configured to assign IP addresses to Sun Ray clients have a non-overlapping subset of the a vailable add ress pool. See FIGURE 2-2.

s Group ManagerA mod ule that monitors the availability (liveness) of the

configured servers a nd facilitates redirection w hen n eeded.

s Firmw are enhancemen ts to allow red irection of clients if the au then ticating server

does not ow n the u sers active session.

The Sun Ray interconnect fabric is a dedicatedan d private network. Each Sun Ray 1

enterprise appliance must be connected to the interconnect fabric via its built-innetwork interface. This mean s that the Sun Ray 1 app liances are attached to a

ded icated sw itch.

Caution The Sun Ray interconnect fabric is not a corporate LAN. It is not to beshared w ith the corporate LAN or to be used in place of a corporate LAN. Do not

connect Sun Ray 1 enterpr ise appliances to networks w ith other d evices.

Setting Up IP Ad dressing

The utadm tool guides you in setting u p a DH CP server. The d efault DHCP setup

configures each interface for 225 hosts and uses pr ivate network add resses for the

Sun Ray interconnect fabric. For more information on using the utadm command,

see the Sun Ray Enterprise Server Software 1.1 Administrators Guide or the man page

for utadm in /opt/SUNWut/man .

Before setting u p IP ad dressing, you mu st decide on an add ress scheme. The

following examp les discuss setting u p Class C add resses.


30/66


Setting Up Class C Addresses

The loss of a server usually implies the loss of its DHCP service. Therefore, more

DHCP ad dresses must be available from the group of servers than there are Sun Ray

app liances. For examp le, if there are 5 servers a nd 100 app liances and one of the

servers fails, the remaining DH CP servers must h ave enough add resses so that all

the appliances get a working address. In this case, each would need to serve 100/ (5-

1) = 25 addresses. To deal with the case of the loss of two servers, each DHCP must

be given a ra nge of 100/ (5-2) = 34 add resses.

These calculations represent the m inimum nu mber of add resses required p er server.

Since clients can get addresses from different servers each time they reboot, more

add resses may be required even thou gh only one of these add resses is in use at anygiven time. Since these u nused add resses are not released u ntil 24 hours after they

are allocated, sup ply enou gh ad dresses so that a single DH CP server can service all

of the clients. For example, with 2 servers and 100 clients, each server would have

100 IP addresses, which fits into a single class C network.

Note For larger add ress ranges, use class B add resses since class C ad dressessupp ort only 256 add resses in a single subnet.

Server Addresses

In the following example (see FIGURE 2-2), the server addresses are 192.168.128.1,

192.168.128.2, and 192.168.128.3.

Client Addresses

For client add resses in the following example, on the first server choose an ad dress

range for clients that wont overlap the addresses for the other servers; for example,

192.168.128.16 to 90.

On th e second server, choose an ad dress range for clients that w ont overlap the

add resses for the servers andthe first client ran ge; for examp le, 192.168.128.91 to 165.

On th e third server, choose an ad dress range for clients that w ont overlap the

add resses for the servers or the first and second client ranges; for examp le,

192.168.128.166 to 240.


31/66


FIGURE 2-2 Client Ad dress Ranges and Failover Scenario on Multiple DHCP Servers

Legend:

1. Sun Ray DHCP servers, including server an d client IP add resses

2. Switching netw ork

3. Sun Ray 1 appliances

When th e user logs onto a Sun Ray, the app liance sends a DH CP broadcast request

to all possible servers on th e netw ork interface. One or m ore responds w ith an IP

add ress allocated from its non-overlapp ing ran ge of add resses. The ap pliance

accepts the first IP add ress that it receives and configu res itself to send and receive at

that ad dress. The accepted DHCP respon se also contains information abou t the IP

add ress and port n um ber of the Authen tication Manager on the server that sent the

response. The ap pliance then attemp ts to establish a TCP connection to the

Authen tication Manager on th at server. If it is unable to connect, it goes through

another simp le broadcast protocol similar to DHCP in w hich it asks Au thentication

Managers on th e servers to identify them selves. The ap pliance then attempts to

connect to the servers that respond ed in the ord er the responses were received.

Once a TCP connection to the Auth entication Manager on a server has been

established, the ap pliance presents its token to th e Au thentication Manager. The

token is either a pseud o-token representing the ind ividu al app liance (its un ique

Ethernet ad dress) or a smart card . Each token can be bound to an X wind ows session

on each of the servers and possibly have a session on m ore than on e server.

However, a token can only be connected to one session at a time; that is, one server

at a time. Therefore, to switch among existing sessions, the appliance must be

redirected from one server to a nother.

192.168.128.1 192.168.128.2 192.168.128.3

192.168.128.16-90 192.168.128.91-165 192.168.128.166-240

1

2

1 1

3


32/66


For example, a smart card is inserted in a Sun Ray appliance. The appliance is

connected to one of the servers and is running a session bound to the pseud o-token

for that ap pliance. First, the Auth entication Manager on the server d isconnects the

ap pliance from the pseud o-token session. Then it looks for the app rop riate server for

the new ly inserted sm art card token by send ing a query to all of the otherAuth entication Managers on the sam e subnet that th e app liance is on and asks for

information about existing sessions for the token. The other Authentication

Managers respond , ind icating w hether there is a session for the token an d the last

time the token was conn ected to the session. The requesting Aut hent ication Mana ger

selects the server with the latest connection time and redirects the ap pliance to that

server. Each time the u ser inserts the smart card, the u ser is connected to the sam e

session. If no session is found for the token, the requesting Authentication Manager

selects the server with the lightest load and redirects the ap pliance to that server.The new server creates a new session for the token.

The Authentication Manager allows both implicit (smart card) and explicit

switching. For exp licit sw itching, see Group Manager on page 25.

Configuring DHCP

In a large IP netw ork, a Dynam ic Host Configur ation Protocol (DH CP) server h ouses

the IP add resses and other configuration information for individu al comp uters on

that network.

Coexistence of the Sun Ray DHCP Server With Other DHCP

ServersWhen you introduce a Sun Ray enterp rise system into an existing corporate

network, you must isolate Sun Ray DHCP services from other DHCP services on the

network. Und er no circum stances should a n on-Sun Ray DHCP server reside on th e

same su bnet as the Sun Ray interconnect. The Sun Ray interconnect is not intend ed

to be shared w ith any other netw ork traffic.

The Sun Ray DHCP server can coexist with DH CP servers on other su bnets,

provided you isolate it from other DH CP traffic by verifying that all routers on thenetwork are configured not to relay DHCP requests. (This is the default behavior for

most rou ters.)


33/66


Administering Other Clients

The Sun Ray interconn ect is intend ed to be priva te. No other clients shou ld reside on

the interconn ect itself. Ho wev er, if the Sun Ray server h as mu ltiple interfaces (one of

which is the Sun Ray interconnect), the Sun Ray DHCP server should be able toman age both the Sun Ray interconnect and the other interfaces without

cross-interference.

Strictly speaking, DHCP requests from the Sun Ray 1 enterprise appliances could be

resolved by a a nother DH CP server. How ever, because the interconnect is intended

to be comp letely private, this situa tion shou ld not ar ise. The utadm utility configures

the Sun Ray DH CP server sp ecifically to adm inister Sun Ray 1 app liances. Any oth er

DHCP server w ould be cum bersome to configure.

w To Set Up IP Ad d ressing on Mu ltip le Servers

Each With One Sun Ray Interface

1. On each server, type:

where -a is add and < interface_name> is the name of the Sun Ray network

interface to be configu red ; for examp le, hme[0-9], qfe[0-9], or gem[0-9].

The following table lists the options available for this command.

Note You m ust be logged on as root to run this comm and .

# /opt/SUNWut/sbin/utadm -a

TABLE 2-1 Available Options

Option Definition

-c Create a fram ew ork for the Su n Ray interconnect

-r Remove all Sun Ray interconnects

-a Ad d as Sun Ray interconnect

-d Delete as Sun Ray interconnect

-p Print current configuration


34/66


The utadm script configures the interface (for example, hme1) at the su bnet (in

this example, 128). The script displays default values, such as the following:

2. When you are asked to accept the default values, type:

3. Change the s erver IP address by typ ing the new address , in this case 192.168.128.2.

4. Accept the default values for netmask, host name, and net name.

5. Change the client ranges for the interconnect by typing the new addresses.

Selected values for interface "hme1"

host address: 192.168.128.1

net mask: 255.255.255.0

net address: 192.168.128.0

host name: ray-231-128

net name: SunRay-128

first unit address: 192.168.128.16

last unit address: 192.168.128.240

firmware server: 192.168.128.1

Accept as is? ([Y]/N): n

new host address: [192.168.128.1] 192.168.128.2

new netmask: [255.255.255.0]

new host name: [ray-231-128]

new net name: [SunRay-128]

new first Sun Ray address: [192.168.128.16] 192.168.128.91

new last Sun Ray address: [192.168.128.240] 192.168.128.165

6 A h d f l fi l


35/66


6. Accept the default firmw are server value.

The selected values for interface hme1 are displayed.

7. If these are correct, accept the new values .

8. Reboot the server and power cycle the appliances.

Group ManagerEvery server has a group man ager m odu le that m onitors availability, facilitates

redirection, and is coupled with the Au thentication Manager. For more information

on the Au thentication Manager, see Chapter 1 in the Sun Ray Enterprise Server

Software 1.1 Administrators Guide.

In setting policies, the Authentication Manager, using the selected authentication

mod ules, decides what tokens are valid a nd wh ich u sers have access.

Warning The same policy should exist on every linked server or un desirableresults may occur. For information on policies, refer to the Sun Ray Enterprise Server

Software 1.1 Administrators Guide.

The group m anagers each create ind ividual ma ps of the topology of the failover

group by exchanging keepalive messages among th emselves. Each group man ager

periodically sends a broad cast or m ulticast keepalive message to a w ell-knownUDP p ort (typ ically 7009) on all of its configured netw ork int erfaces. The

new firmware server: [192.168.128.2]

host address: 192.168.128.2

net mask: 255.255.255.0

net address: 192.168.128.0

host name: ray-231-128

net name: SunRay-128

first unit address: 192.168.128.91

last unit address: 192.168.128.165

firmware server: 192.168.128.2

Accept as is? ([Y]/N): y

k li t i h i f ti f h t t t li t


36/66


keepalive message contains enough information for each server to construct a list

of servers and the common subnets that each server can access. In add ition, the

group manager remembers the last time that a keepalive message w as received

from each server on each interface.

The keepalive messages contain th e following information about the server:

s Server s hostnam e

s Server s primary IP add ress

s Elapsed time since it was booted

s IP information for every interface it can be reached on

s Machine information (num ber and speed of CPUs, configured RAM, and so on)

s Load information (CPU/ memory utilization, num ber of sessions, and so on )

Note The last two entries are used to facilitate load distribution. See LoadDistribution on page 32.

The information maintained by the grou p m anager is used p rimarily to perform

server selection w hen a token is presented. The server an d subnet information is

used to determ ine the list of servers a given ap pliance can connect to, and these are

the ones qu eried about sessions belonging to the token. Servers w hose last

keepalive messages on the app liances netw ork w ere received after the timer

expires are deleted from the list since either the network connection or the server is

probably dow n.

RedirectionIn ad dition to au tomatic redirection at au thentication time, manu al redirection can

be accomp lished using the utselect graphical user interface (GUI) or utswitch

from the command -line interface.

Note The utselect graphical user interface (GUI) is the preferred method to usefor server selection. The utswitch command is to be used as a backup method.

utselect

For the u ser, the serv er select GUI (see FIGURE 2-3) provides an easy and preferred

method for server selection.

w To Red irect to a Differen t Server


37/66


w To Red irect to a Differen t Server

q Type

The selections in the window are sorted in order of the last connection time with the

latest first.

FIGURE 2-3 The Server Select Graphical User Interface

In the above illustration, the Server column lists the servers accessible from theapp liance being used. The Session column reports the X session nu mber on the

server if one exists or None if there is no session. In the Status column , Up ind icates

that the server is available. The third server is highlighted by default to facilitate

switching between servers. In FIGURE 2-3 server ray-181 is highlighted. Since Non e

app ears un der Session, a new session will be started.

The Refresh button reloads the window, which is not dynamic, with the most current

information. The OK button changes to the h ighlighted server.

See the ma n p age for utselect in /opt/SUNWut/man .

utswitch

The utswitch command provides the comm and line interface to redirection.

# /opt/SUNWut/bin/utselect

w To Manually Redirect an Appliance


38/66


w To Manually Redirect an Appliance

q Type:

Where host is a host nam e or IP ad dress to which the selected ap pliance is redirected .

In the n ormal case, the optional argum ents are not specified, and the selected

app liance is the one on w hich the comm and is entered. If-k token is given, then th e

selected appliance is the one connected to the tokens session on the current server.

Similarly, if-s SID is given, the selected a pp liance is the one conn ected to the session

with session ID SID on the cur rent server. In both cases, an ap pliance may not beconnected to the specified session; in which case, the command does nothing.

w To List Available H osts

q To list hosts that are available from the given Sun Ray unit, type:

w To Select a Different Current Server

This variant of the comman d, not n ormally invoked d irectly by the user, runs the

server selection protocol that is executed when a token is presented to a server.

When a user logs out from the current session, this comm and is executed so that the

timestamp of the session the user is logging out from will be artificially modified

backward in time. If there are existing sessions on other servers associated with thetoken, the user will be redirected to whatever existing session has the latest connect

time. The -k token an d -s sidoptions are used to identify the selected appliance in the

same w ay as they are in the -h version of the command .

q To redirect the selected appliance to the server with the latest session connect

time, type:

See the man page for utswitch in /opt/SUNWut/man .

# /opt/SUNWut/bin/utswitch -h host [ -k token] [ -s sid ]

# /opt/SUNWut/bin/utswitch -l

# /opt/SUNWut/bin/utswitch -t [ -k token] [ -s sid ]

Group Manager Configuration


39/66


Group Manager Configuration

The Authentication Man ager ha s a configuration file that contains p arameters u sed

by the group man ager at ru ntime. The file is /etc/opt/SUNWut/auth.props . By

default, the param eters are comm ented ou t. To change the d efault param eter values,

remove the hash m ark (#) in front of the para meter and set the param eter to the

desired valu e. For examp le:

The following p aram eters, discussed below, are configurable by the ad ministrator

though , in m ost cases, the d efaults can be left unchanged :

s gmport

s gmKeepAliveInterval

s enableGroupManager

s enableLoadBalancing

s enableMulticast

s multicastTTL

s gmSignatureFile

s gmDebug

Excerpt from the auth.props file:

The group m anager p ort only needs to be changed if another process is already

using the same p ort nu mber. Every host u sed in the failover scheme mu st use the

same group manager port.


# gmDebug

# flag to turn on group manager debugging

gmDebug = 2

# Group Manager Port

# The group manager uses this port to send and receive keepalive/

# discovery messages from other auth managers.# gmport = 7011

# Group Manager keep alive interval

# The group manager uses this as the time in seconds between

# broadcast keepalive messages

# gmKeepAliveInterval = 20

The keepalive interval may be changed to make the group m anagers comm unicate


40/66


y g g p g

with each other more or less often. Although it is not essential, the

gmKeepAliveInterval value shou ld be identical on every server.


This flag m ust alwa ys be on in a mu ltiple server configuration. It may be turn ed off

(that is, set to false) if only one server is used. However, if a second server is addedto the group, the group manager must then be enabled and the Authentication

Manager restarted before the ad ditional server is recognized.


The group ma nager attemp ts to distribute the session load evenly among the

available servers. This capability does result in authenticating servers sometimes

redirecting a Sun Ray appliance to a different server even when there is no existing

session for the token, which results in an increased u se of bandw idth resources.

The add itional resource use shou ld be negligible; however, this feature m ay be

turned off (that is, set to false) if desired.


Note Some switches have multicast capability disabled by default although it canusu ally be turn ed on. If you d o not w ant to u se mu lticast in the Sun Ray

interconnect, set this parameter to "false."

# enableGroupManager

# flag to turn on the group manager function

# enableGroupManager = true

# enableLoadBalancing

# flag to turn on group manager load balancing

# enableLoadBalancing = true

# Enable Multicast

# Flag to enable/disable use of multicast in group manager

# If disabled, group manager will use broadcast

# enableMulticast = true



41/66


Note This feature is only needed in sophisticated Sun Ray network configurationswh ich contain routers.


The gmSignatureFile property controls the location of the group man ager

signature file. The group man ager signature file is used to create a trusted grou p of

Sun Ray server s. See Setting Up an Adm inistered Group on p age 32.


By default, the group manager does not output any debugging information.

How ever, if problems occur wh ere add itional debu gging information is desired, the

gmDebug parameter can be raised to a positive value. The higher the value, the more

information th at is printed. Ou tpu t is written to th e file /var/opt/SUNWut/log/

auth_log.

w To Restart the Authentication Manager

If any p arameter is mod ified w hile the Au thentication Manager is runn ing, the

change will not take effect until the authd is restarted.

# Multicast Time-to-Live

# Time-to-live parameter for forwarding multicast packets

# If set above one, keepalive messages can pass through routers

# multicastTTL = 1

# gmSignatureFile - Group Manager Signature File

# The group manager can "sign" messages to other group managers

# based on the contents of a signature file. Other group managers

# with the same signature file contents are "trusted". To be

# usable, the file must be owned by root and must not be readable,

# writable, or executable by anyone else; it must contain at least

# 8 bytes, at least two of which are letters and at least one which# is a non-letter.

# gmSignatureFile = /etc/opt/SUNWut/gmSignature

# gmDebug

# flag to turn on group manager debugging

# gmDebug = 0

q To restart the Authentication Manager, type:


42/66


Load Distribution

At the time of a server failure, the Group Manager on each remaining server

attemp ts to distribute the failed server s sessions evenly among the remaining

available servers. This method takes into account each servers capacity (number

and speed of its CPUs) and load so that larger or less heavily loaded servers host

more sessions. When the Group Manager receives a token from a Sun Ray and finds

that no server owns an existing session for that token, it redirects the Sun Ray to the

server in the grou p w ith the lightest load. If a different server is the least loaded , the

Sun Ray is instru cted to reau then ticate on that server. Thu s, in some instances, a Sun

Ray appears to au thenticate twice, once on the server that answ ered its DHCP

request and a second time on a server that w as less loaded than the first.

w To Turn Off the Load Distribution Feature

q In the auth.props file set:

Setting Up an Ad ministered Group

An ad ministered group is one in which there are two or more group servers which

utilize a policy other than Zero Adm in. In such a grou p you mu st configure

Lightw eight Directory Access Protocol (LDAP) to enable rep lication of the

adm inistered d ata across the group . Such a grou p is composed of a pr imary server

and one or m ore seconda ry servers. If the p rimary server fails, the secondary servers

assume th e adm inistration data of the p rimary server, such as users, smart cards,

and so on.

With th e Zero Ad min p olicy, it is possible to hav e a grou ping of systems w ithout

having to adm inister them; that is, without run ning utconfig on each system.

# /etc/init.d/utsvc restart

enableLoadBalancing = false

The utreplica command s are only required for an adm inistered system; that is, a

t th t h h d th t fi d it Th t fi d


43/66


system that has had the utconfig command run on it. The utconfig command

sets up the LDAP server for a single system initially.

Note This procedure m ay only be performed afterrunning utconfig on eachindividual server.

Note The value entered for @(ROOTPW) mu st be the same value used on all thesecondar y servers at utconfig time. See the Configura tion Worksh eet in Chap ter 3,

Configuring the Software, in the Sun Ray Enterprise Server Software 1.1 Administrators

Guide.

The LDAP server stores registered token inform ation on stable storage. In a mu ltiple

host group, the d istributed LDAP server u ses a master-slave setup .

For more information on LDAP, see the documentation for SunDS.

Primary Server

The layered ad ministration of the group takes place in the prim ary server in the

group. Using the utreplica command , designate a prima ry server, advise it of its

Adm inistration Primary statu s, and inform it of the hostnam es of all the secondar y

servers in the group .

Note You mu st configure the p rimary server before any of the seconda ry servers.

Note Each failover server in the interconnect fabric must h ave a un ique hostnam e.

w To Specify a Primary Server

q Type:

Where secondary_admin_pw is the value for @(UTPASSWD) entered w hen utconfig

was ru n on each secondary server and secondary_server [secondary_server ...] is a list of

the hostnames the second ary servers in the group.

# /opt/SUNWut/sbin/utreplica -p secondary_admin_pw \

secondary_server [secondary_server ...]

Note To includ e an ad ditional second ary server to an already configured p rimary


44/66


Note To includ e an ad ditional second ary server to an already configured p rimaryserver, repeat the comm and includ ing the ad ditional secondary server in the new

complete list of secondary servers.

Replication Setup

The secondary servers in the group hold a rep licated version of the prim ary server

adm inistration data. Use the utreplica command to advise each secondary server

of its secondar y status an d also the hostname of the primary server for the group.

w To Specify Each Second ary Server

q Type:

Where primary_admin_pw is the value for @(UTPASSWD) entered w hen utconfig

was run on the primary server and is the hostname of the primary

server.

Removing Replication Configuration

w To Remove the Rep lication Configura tion

q Type:

This leaves the server as a standa lone server from an ad ministration p erspective.

Note This comm and mu st not be run withou t also reconfiguring/ un configuringthe other servers involved in th e failover group.

# /opt/SUNWut/sbin/utreplica -s primary_admin_pw

# /opt/SUNWut/sbin/utreplica -u

Other Scenar ios


45/66


Other scenarios include u nconfiguring a primar y/ second ary pa ir and a p rimary

with m ultiple secondary servers.

Primary/ Second ary Pair

In the case of a pr imar y/ secondar y pair, the replication context is eliminated . In this

instance, both servers mu st be un configured.

Note Unconfigure the p rimary server first.

Primary/ Mu ltiple Second ariesUnconfiguring a Second ary

In this instance, first reconfigure the primary to replicate to all the secondaries

except th e one m arked for removal. Then u nconfigure that second ary.

Primary/ Multiple Second ariesUnconfiguring the Prim ary

Do not u nconfigure the p rimary u nless your intent is to reconfigure one of the

secondar ies as a prim ary, such as in a recovery scenar io. In this case, all servers mu st

be unconfigured and reconfigured .

Viewing the Ad ministration Status

w To Show Current Administration Configuration

q Type the command:

The result indicates wh ether the server is Stand alone, Primary (with the slave

hostnames), or Second ary (with th e Primary h ostname).

# /opt/SUNWut/sbin/utreplica -l


46/66


Recovery Issues and Procedures

If one of the mem bers of a group of services fails, the surviving group mem bers

should on ly operate from th e adm inistration data as it existed pr ior to the failure.

The recovery procedure requ ired dep ends on th e severity of the failure and wh ether

a pr imary or secondary server h as failed.

Note When the primary server has failed, it is not possible to make administration

changes to the system as all changes mu st be successful on th e prim ary server forreplication to w ork.

Secondary Server Recovery

Where a secondary server h as failed, adm inistration of the group may continue. A

log of up dates w ill be maintained that is app lied au tomatically to the second aryserver w hen it is recovered. If the secondar y server n eeds to be reinstalled, repeat

the steps ou tlined in the set u p as though it were being initially configured. See the

Sun Ray Enterprise Server Software 1.1 Installation Guide.

Primary Server Recovery

There are several strategies for recovering the primary server.

w To Rebuild the Primary Server Administration Data Store

1. On one of the secondary servers, capture the current data store in a file called

store:

This provides an LDIF format file of the current database.

2. FTP this file to /tmp on the newly installed primary server.

See th e Sun Ray Enterprise Server Software 1.1 Installation Guide.

# /opt/SUNWconn/sbin/ldmcat /var/opt/SUNWconn/ldap/dbm.ut \/id2entry.dbb > /tmp/store

3. Configure the primary server and type the following at the end of Step 4 in the

installation procedure:


47/66


p

This popu lates the primar y server and synchronizes its data w ith the seconda ry

server.

4. Stop and start the servers:

5. Confirm that the data store i s repopulated:

6. Continue the remaining steps of primary server configuration.

Setting Up a Tru sted Grou p

A group of servers form a tru sted group wh en the servers have identical contents in

their group man ager signature files. The group man ager signature file isconventionally placed in:

/etc/opt/SUNWut/gmSignature

How ever, the location can be changed by changing the gmSignatureFile

property in the auth.props file. See Group Manager Configuration on p age 29.

To form a fully functional trusted group, the signature file must:

s be owned by root and mu st not be readable, writable, or executable by anyone

else

s contain at least 8 bytes, at least two of which are letters and at least one which is

a non-letter

Note For a dd itional security, use long password s.

# /opt/SUNWconn/sbin/ldif2ldbm -c -n 2 -j 10 -i /store

# /etc/init.d/dsserv stop

# /etc/init.d/dsserv start

# /opt/SUNWut/sbin/utuser -l

w To Create the Group Manager Signatu re File


48/66


1. Type:

You w ill be promp ted for the signature.

2. Enter it twice identically for acceptance.

Note It is important that the signature be entered via this command now an d notbe created in any other way since the comman d also ensures that LDAP replication

occurs properly.

In that case in wh ich all the Sun Ray servers are in the sam e group , any functions

wh ich d epend on the d atabase are unavailable. For example, the registration and the

Adm inistration app lication w ould be un available in the Zero Adm in mode.

# utgroupsig

CHAPTER 3


49/66

39

Customizing the Wind ow Manager

This chap ter provides notes on customizing the w indow man ager used by the Sun

Ray clients. The benefits of changing or stripping d own wind ow man agers includ e

redu ced training for new users and a more sup portable installation.

Topics include:

s Wind ow Manager Fun ctionality on page 39

s Customizing CDE on p age 40

s

Kiosk Mode on page 42s Alternate Wind ow Man agers on pa ge 42

Window Manager Functionality

A wind ow m anager p rovides the user with the graph ical icons and controls neededto organize applications on the desktop. The types of hand les and the d egree of

control afforded by the wind ow m anager d etermine the look and feel of the desktop.

For examp le, the w indow man ager controls:

s The appearance of window frame components

s The behavior of window s, includ ing their stacking ord er and focus behavior

s Key bindings and button bindings

s The appearance of minimized windowss Desktop and window m enus

It is possible to run app lications withou t a wind ow m anager, and this mode m ay be

desirable for certain single-function applications. However, if an application

launches multiple windows, a window manager is needed to maintain a clear

worksp ace. Otherw ise, every time a new wind ow is launched it displaces the current

window.

The Solaris Comm on Desktop Environment (CDE) is the default wind owing

environment used by the Sun Ray desktops. Solaris CDE includes n ot only a

i d dt (d kt i d ) b t l l i


50/66


window managerdtwm (desktop wind ow m anager)but also a login m anager, a

session man ager, and app lications such as a m ail tool and calendar.

The following sections provide n otes on m odifying th e CDE environment for you r

Sun Ray users: customizing CDE, stripping down CDE for kiosk mode, or replacing

CDEs dtwm with a different window manager.

Customizing CDEDetails for customizing CDE are p rovided in the Solaris CDE Advanced Users and

System A dministrators Guide, wh ich is in the Solaris 7 User Collection available at:

http://docs.sun.com

CDE provid es tw o basic levels of configuration: system-level and user-sp ecific.

System-level configurations apply to one Solaris system, whereas user-specific

configurations app ly to one user account. In general, CDE customizations for theSun Ray enterprise should be m ade a t the system level (on the Sun Ray enterprise

server), as these changes are autom atically ap plied to all Sun Ray users wh en they

log into the server via a Sun Ray 1 appliance. However, user-level changes are

app ropriate if you w ant to customize the desktop for ind ividu al users.

The following is an examp le procedu re you w ould u se if your Sun Ray users

required only two or three app lications and you w anted to remove all other

application icons from the CDE Front Panel.

w To Rem ove an Icon From the Front Panel

1. Create a front panel configuration file (.fp file):

s For the Sun Ray enterp rise server:

/etc/dt/appconfig/types/language/name.fps For a sp ecific user:

HomeDirectory/.dt/types/name.fp

2. Copy the definition of the control yo u w ant to del ete into the new file.

If the control is b uilt-in, its definition is in /usr/dt/appconfig/types/


51/66

Chapter 3 Customizing the Window Manager 41

language/dtwm.fp.

You d o not need to copy the entire definition. How ever, the portion you copy mu st

include the fields CONTAINER_NAME an d CONTAINER_TYPE.

3. Add the D elete field to the definition:

DELETE True

For example, the following control definition placed in the file TrashCan.fp

removes the Trash Can control from the front panel.

4. Save the configuration file.

The change is applied w hen each user restarts the w indow man ager or logs out and

logs in.

In the figure below, all icons have been removed from the d efault CDE front p anel

except the following:

s StarOffice

s Default web browser

s Screen lock

s Exit

s Workspace switches

Legend:

1. Staroffice icon

2. Default web browser icon

CONTROL Trash{

CONTAINER_NAME Top

CONTAINER_TYPE BOX

DELETE True

}

1 2

Ki k M d


52/66


Kiosk Mod e

The central ad ministration m odel of the Sun Ray enterp rise makes it w ell-suited to

kiosk d eployments. For example, one type of kiosk w ould be a pu blic comp uter

terminal that m ight run a single, interactive ap plication or browser to p rovide users

with site-specific information, such as city maps or airline schedules.

Kiosk mod e is characterized by the lack of a login m anager and session man ager.

The master ap plication is also the session m anager for the system. When th e user

exits the master application, a new session is started immediately.

This can be implemented using features and p aragrap h scripting with CDE. If you

are unfamiliar with how to do this, please see your system p rovider about obtaining

examples or assistance.

Alternate Wind ow ManagersCDEs wind ow m anager, dtwm, can be replaced by an alternate w indow man ager to

change the look and feel of the Sun Ray desktop.

In add ition, dozens of wind ow man agers exist in the p ublic domain for Solaris and

Linu x environm ents. Theoretically, any of them w ill work in the Sun Ray enter pr ise.

You can find information on m any of them on the w eb or in trade m agazines.

w To Specify an Alternate Wind ow Manager

The alternate w indow man ager should be installed on the Sun Ray enterpr ise server.

1. Create or open the alternate w indow manager configuration file:

s For the Sun Ray enterp rise server:

/etc/dt/config/language/sys.resources

s For a sp ecific user:

HomeDirectory/.Xdefaults

2. Specify the ful l path name and options fo r the alternate w indow manager with

the Dtsession*wmStartupCommand resource.

For instructions on setting op tions for the w indow man ager see Adm inistering


53/66

Chapter 3 Customizing the Window Manager 43

For instructions on setting op tions for the w indow man ager, see Adm inistering

Application Resources, Fonts, and Colors in the Solaris CDE Advanced Users and

System A dministrators Guide, wh ich is in th e Solaris 7 User Collection av ailable at:

http://docs.sun.com.

3. Save your changes.

The changes are app lied w hen each user logs out and logs in.

Note Not all window man agers han dle 24-bit color or drag-and -drop proficiently.

You m ay also experience problem s with fonts, localized fonts, and cut/ copy/ pastekey functionality.


54/66


CHAPTER 4


55/66

45

Citrix and Windows NT

Citrix software is one way a Sun Ray user can access Microsoft Windows NT

applications.

Microsoft Wind ow s NT on Sun Ray

SystemGuidelines

To run NT sessions on the Sun Ray 1 appliance, you need:

s An N T server (x86 platform) or other app ropriate hard ware

s Citrix ICA Client for Solaris, or Java available at the Citrix w ebsite

http://www.citrix.com

s Microsoft Windows NT Terminal Server (may be purchased from Microsoft or asoftware reseller)

s Citrix MetaFrame (may be purchased from Citrix or software reseller)

NT Term inal Server

For this connectivity, a Window s NT Term inal server is installed on a x86-basedmachine and configured to join the n etwork using TCP/ IP.

For instructions on how to install Microsoft Windows NT Terminal Server, please

refer to the d ocumentation includ ed w ith the software. You m ust d ecide in ad vance

wh ether to configure the machine as a stand -alone server or d omain controller and

wh ether to use N TFS or FAT partitions. Please consult your NT ad ministrator

regarding th ese issues.


56/66


57/66


58/66



59/66

Glossary 49

Glossary

bps Bits per second.

category 5 The most common type of wiring used in LANs. It is approved for both voice

and data (at up to 100Mhz). Also called cat 5.

client-server A common way to describe network services and the user processes

(program s) of those services.

DHCP Dynam ic Host Configuration Protocol. DHCP is a means of distributing IP

addresses and initial parameters to the appliances.

domain A set of one or more system boards that acts as a separate system capable of

booting the OS and running independently of any other board.

Ethernet sw itch A un it that redirects packets from input ports to outp ut p orts. Can be a

compon ent of the Sun Ray interconnect fabric.

Ethernet Physical and link-level commu nications m echanism d efined by th e IEEE 802.3

family of standards.

Ethernet address The unique hardware address assigned to a computer system or interface

board when it is manufactured. See MAC address.

fan out Connections that radiate out from a hub or switch.

FTP File Transfer Protocol. The nam e of the Internet p rotocol and th e progr am used

to tran sfer files between hosts.

GEM Gigabit Ethernet.

hot key A pre-defined key that causes something to appear on your screen. A hot key

is used to bring up the Settings screen on the Sun Ray enterprise appliance.

hot-pluggable A prop erty of a hardware component th at can be inserted into or removed

from a system that is p owered on. USB devices connected to Sun Ray

appliances are hot-pluggable.

Interconnect fabric All the cabling, switches, or hu bs that conn ect Sun Ray servers network

interface cards to th e Sun Ray app liances.

internet A collection of netw orks interconnected by a set of rou ters that en able them to

function as a single, large virtual netw ork.

Internet (Note the capital I) The largest internet in the w orld consisting of large

i l b kb ( h S d C ) d i d


60/66


national backbone n ets (such as MILNET, NSFNET, and CREN) an d a m yriad

of regional and local campu s networ ks all over the world . It is a globalcollection of networks connecting a wid e range of comp uters u sing a common

protocol to comm un icate and share services.

intranet Any network that provides similar services within an organization to those

provided by the Internet outside it but which is not necessarily connected to

the Internet.

IP address A unique number that identifies each host or other hardware system on a

network. An IP address is composed of four integers separated by periods.Each decimal integer must be in the range 0-255 (for example, 129.144.0.0).

IP address l ease The assignm ent of an IP add ress to a comp uter system for a sp ecified length of

time, rather than permanently. IP address leasing is managed by the Dynamic

Host Con figur ation Protocol (DHCP). Sun Ray app liance IP ad dresses are

leased.

LAN Local area network . A group of comp uter system s in close proximity that can

communicate with one another via some connecting hardware and software.

LDAP Lightw eight d irectory access protocol.

local ho st The CPU or computer on which a software application is running.

local server From the clients persp ective, the most imm ediate server in the LAN.

login The process of gaining access to a comp uter system.

login name The name by w hich the compu ter system know s the user.

multicasting The process of enabling commu nication betw een Sun Ray servers over their

Sun Ray network interfaces in a failover environm ent.

multiplexing The process of transm itting mu ltiple chann els across one commu nications

circuit.

network Technically, the hard ware conn ecting v arious comp uter systems enabling th em

to comm un icate. Inform ally, the systems so connected.

N IC Network interface card.

OSD On-screen d isplay. The Sun Ray app liance uses sm all OSD icons to alert th e

user of potential start-up problems.

policies Authentication Manager, using the selected authentication modules, decides

what tokens are valid and which users have access.

server A computer system that supplies computing services or resources to one or

more clients.

service For the pu rposes of the Sun Ray software, any ap plication that can directly

t t th S R li It i l d di id X


61/66

Glossary 51

connect to the Sun Ray appliance. It can includ e au dio, video, X servers,

access to other m achines, and d evice control of the app liance.

session A grou p of services associated w ith a single user.

spanning tree The spann ing tree protocol is an intelligent algorithm that allows brid ges to

map a redundant topology and eliminates packet looping in Local Area

Networks (LAN).

subnet A w orking scheme that divides a single logical network into smaller ph ysical

networks to simplify routing.

token In the Sun Ray system, a token m ust be p resented by th e user. It is required b y

the Au thentication Manager to consider allowing a user to access the system. It

consists of a type and an ID. If the u ser inserted a sm art card, the sm art cards

type and ID are used as the token. If the user is not using a smart card, the

enterp rise appliances built-in typ e (pseud o) and ID (the un its Ethernet

address) are supplied as the token.

thin client Thin clients remotely access some resources of a compu ter server, such as

compu te pow er and large memor y capacity. The Sun Ray app liances rely on

the server for all compu ting power and storage.

time-out value The maximum allowed time interval between communications from an

appliance to the Authentication Manager.

TCP-IP Transm ission Con trol Protocol/ Internet Protocol (TCP/ IP) is a netw orking

protocol that provides communication across interconnected networks,

between computers w ith diverse hardware architectures and operating

systems.

URL Uniform Resource Locator. A stand ard for writing a textual reference to an

arb itrary piece of data in the World Wide Web (WWW). The syntax of a URL is

protocol://host/localinfo where protocol specifies a protocol to use

to fetch the object (like HTTP or FTP), host specifies the Internet na me of the

host on which to find it, and localinfo is a string (often a file name) pa ssed

to the protocol handler on the remote host.

user name The name a computer system uses to identify a particular user. Under UNIXthis is a text string of up to eight characters composed of letters (a-z and A-Z),

digits (0-9), hyphens (-), and underscores (_) (for example, jpmorgan). The first

character mu st be a letter.

virtual frame buffe r A region of memory on the Sun Ray server that contains the current state of a

user s d isplay.

work group A collection of associated users w ho exist in near p roximity to one an other. A

set of Sun Ray app liances that are connected to a Sun Ray server p rovides

comp uting services to a w ork group.


62/66



63/66

Index 53

Index

AAlternate window manager, 42

Authentication man ager, 25

Auto-negotiation, 4, 5

Availability, 17

BBackplane bandwidth, 7

Bandw idth limitation, 7

Buffering, 4

Button bindings, 39

CCables

category 5, 3

fiber optic, 3

CDE, 40

Citrix ICA Client for Java, 45

Citrix ICA Client for Solaris, 45

Citrix MetaFrame, 45, 46

Citrix software, 45

Client add resses, 20

Common Desktop Environment, 40

Customizing the window m anager, 39

DDaisy-chain switches, 10

Dedicated private network, 19

Desktop menus, 39

Desktop window manager, 40

DHCP servers, 19

Domain controller, 45

dtwm, 40

Eenterprise appliance, 2, 19

FFailover, 17

FAT partitions, 45

Fiber optic cables, 3

Full-du plex connections, 4

GGigabit core, 10

Group manager, 19, 25, 32

H

Half-duplex connections, 4

Hot Desk protocol, 3

Hubs, 15

interface card, 13

NIC, 13

NT server, 45

NT user accounts, 46
http://-/?-http://-/?-


64/66


IICA client, 46

Icon, remove, 40

Interconnect, 1, 3, 23

Interconnect fabric, 14, 19

IP add resses, 19

KKeepalive, 25

Key binding s, 39

Kiosk mode, 40, 42

LLAN, 14, 19example interconnect system, 2, 18

Latency, 4

Link-up time, 4

Load distribution, 32

Low latency, 7

MMaster recovery, 36

MetaFrame, 46

Microsoft Window s NT, 45

Microsoft Window sNT Terminal Server, 45

Multicasting, 4

Multiplexing, 14Muxing, 14

NNetwork

failure, 17

full-duplex, 3

half-duplex, 3

NTFS par titions, 45

PPacket loss, 7

Private network, 19

QQOS, 3

Quality of service, 3

S

Server add resses, 20Server-to-switch bandwidth, 3

Single point of failure, 17

Slave recovery, 36

Spanning tree, 4, 7

Subnet, 22

Sun Ray interconnect, 1

Switch, 1

cascading, 10daisy-chaining, 10

high-capacity, 2

low-capacity, 2

requirements, 4

Switching backplane, 7

TTCP/ IP, 45

Terminal Server, Microsoft WindowsNT, 45

Turn-on time, 6

U

Uplink ports, 3

utad m utility, 23

utselect, 26

utswitch, 27
http://-/?-http://-/?-


65/66

Index 55

VVirtual desktop p rotocol, 15

WWindow

frame comp onents, 39menus, 39

Window sNT, 45


66/66


Adv Admin Guide

Documents

Transcript of Adv Admin Guide