~kjcole/edubuntu.cookbook-delete/wip : revision 27

1

<html>

2

<head>

3

<title>Thin-client computing</title>

3

<title>Moved to Chapter 4</title>

4

</head>

5

6

<body>

7

<h1>Thin-client computing</h1>

8

9

10

an Edubuntu lab computer laboratory consists of a classroom full of

11

thin client workstations communicating with a classroom

12

server. The specific implementation of thin client computing

13

used in Edubuntu labs is discussed in Section 6.2.

14

_________________________________________________________

15

16

17

6.1. What is Thin Client Computing?

18

19

20

Thin client and fat client (also called "thick" or "rich"

21

client) are mostly marketing terms for different

22

configurations of computer. A thin client asks a central

23

server to do most of its processing, and keeps as little

24

hardware and software as possible on the workstation side.

25

Ideally, the user of a thin client should have only a screen,

26

keyboard, mouse and enough computing power to handle display

27

and network communications --- you don't even need (or want) a

28

hard drive. The less you have, the less there can go wrong.

29

30

31

A fat client does as much processing as possible itself and

32

only passes data required for communications and storage on to

33

the server. A standalone PC is the typical fat client with

34

which everyone is familiar.

35

36

37

38

Fat client

39

40

41

A thin client may be a software program executing on a generic

42

PC, or it may be a hardware device, called a terminal,

43

designed to provide only user input and display functions.

44

Because old PCs (whether retired, written off, obsolete or

45

just out of fashion) are easier to find than specialised thin

46

client hardware, Edubuntu labs uses them as thin clients, with the

47

appropriate software. Because they don't do much work

48

themselves, the hardware requirements for these "old" PCs are

49

very basic. Since every client in a thin client network asks a

50

central server to do its work, all the individual workstations

51

look the same: they all share the same server, and they all

52

behave exactly like the server would if you were using it

53

directly.

54

55

56

In addition, although everyone who uses the lab can have their

57

own computing environment stored on the server, with their own

58

files, desktop, and so on, the individual workstations can't

59

get viruses or be misconfigured by curious learners --- there

60

simply isn't anything to configure! The thin client doesn't

61

have enough brains to get confused.

62

63

64

This means that the lab computers are trivial to keep up and

65

maintenance is restricted to the server in the back room.

66

67

68

Thin clients are cheaper and require less administration than

69

fat clients. On the other hand, they tend to require far

70

greater network bandwidth, as display data will probably need

71

to be passed to the thin clients. They can't do a single thing

72

on their own --- for each and every action, they need to talk

73

to the server. This means that a server for a room full of

74

thin clients must be much more capable than a server used by

75

fat clients.

76

77

78

One of the advantages that this configuration entails, is that

79

all the software resides on the server, and so you only have

80

to upgrade it once. In a fat client configuration, every

81

workstation has its own copies of the software, and so any

82

upgrade needs to be rolled out to every workstation.

83

84

85

86

_________________________________________________________

87

88

89

6.2. Linux Terminal Server Project

90

91

92

The Linux Terminal Server Project ( LTSP) is a configuration

93

of Linux that allows you to connect lots of low-powered thin

94

client terminals to a Linux server. The LTSP provides a simple

95

way to utilise low cost workstations as either graphical or

96

character-based terminals on a GNU/Linux server.

97

98

99

K12LTSP is based on RedHat Fedora Linux and the LTSP terminal

100

server packages (see Section 7.1.1 for more detail). It's easy

101

to install and configure. It's distributed under the GNU

102

General Public License. That means it's free and it's based on

103

Open Source software.

104

105

106

Once installed, K12LTSP lets you boot (see Section 16.4)

107

diskless workstations from an application server.

108

_________________________________________________________

109

110

111

6.3. How the lab works

112

113

114

There is a shorter version of this in Section 13.2.2.

115

116

117

1. "Power On Self Test" ( POST). When you turn on the

118

workstation, it will go through its Power On Self Test (

119

POST; for this and other acronyms, see Section 16.4).

120

2. Find the boot ROM. During the self test, the BIOS will

121

search for expansion ROMs. The network card contains an

122

Etherboot boot-ROM, which is an expansion ROM. The BIOS

123

will detect the ROM on the network card (it doesn't know

124

about the network card, it only notices the ROM).

125

3. Boot. Once the POST is complete, execution will jump into

126

the Etherboot code.

127

4. Find the network card. The Etherboot code will scan for a

128

network card. Once it detects the card, the card will be

129

initialized.

130

5. DHCP request. The Etherboot code will then broadcast a

131

DHCP request to the local network. The request will

132

include the MAC address of the network card.

133

6. DHCP request received. The dhcpd daemon on the server will

134

see the broadcast request from the workstation, and look

135

in its configuration file for an entry that matches the

136

MAC address of that workstation.

137

7. DHCP request reply. The dhcpd daemon will construct a

138

reply packet, containing several pieces of information.

139

This packet will be sent back to the workstation. The

140

reply information includes:

141

+ an IP address for the workstation,

142

+ the netmask setting (see Section 16.4) for the local

143

network,

144

+ the pathname of the kernel to download (this is a

145

filesystem path on the server),

146

+ the pathname of the root filesystem (see Section

147

16.4) to mount as the root of the client filesystem,

148

+ optional parameters to be passed to the kernel, via

149

the kernel command line.

150

8. Boot ROM configures TCP/IP interface. The Etherboot code

151

will receive the reply from the server, and it will

152

configure the TCP/IP interface in the network card with

153

the parameters that were supplied. Once this is done, the

154

client computer has an IP address on the network.

155

9. Download the kernel using TFTP. Using TFTP (Trivial File

156

Transfer Protocol), the Etherboot code will contact the

157

server and begin downloading the kernel.

158

10. Kernel downloaded. Once the kernel has been completely

159

downloaded to the workstation, the Etherboot code will

160

place the kernel into the correct location in memory.

161

11. Control passes to kernel. Control is then passed to the

162

kernel. The kernel will initialise the entire system and

163

all of the peripherals that it recognizes.

164

12. Mount temporary boot filesystem as RAM disk. This is where

165

the fun really begins. Tacked onto the end of the kernel

166

is a filesystem image. This is loaded into memory as a RAM

167

disk, and temporarily mounted as the root filesystem. A

168

kernel command line argument of root=/dev/ram0 tells the

169

kernel to mount the image as the root directory.

170

13. Kernel boot sequence calls linuxrc shell script (before

171

the normal boot sequence starts). Normally, when the

172

kernel is finished booting, it will launch a program

173

called init. But, in this case, we've instructed the

174

kernel to load a shell script (see Section 16.4) instead.

175

We do this by passing init=/linuxrc on the kernel command

176

line.

177

14. Identify kernel module for network card. The linuxrc

178

script begins by scanning the PCI bus, looking for a

179

network card. For each PCI device it finds, it does a

180

lookup in the /etc/niclist file, to see if it finds a

181

match. Once a match is found, the name of the NIC driver

182

module is returned, and that kernel module is loaded. For

183

ISA cards, the driver module MUST be specified on the

184

kernel command line, along with any IRQ or address

185

parameters that are required.

186

15. Load kernel module for network card. Once the network card

187

has been identified, the linuxrc script will load the

188

kernel module that supports that card.

189

16. linuxrc makes DHCP query. dhclient will then be run, to

190

make another query from the DHCP server. We need to do

191

this separate user-space query. We cannot depend on the

192

query that comes from Etherboot, because it gets swallowed

193

up when the kernel uses it. The kernel will also ignore

194

any NFS server that might have been specified in the

195

root-path. This is important if you want the NFS server to

196

be different from the TFTP server.

197

17. Configure eth0. When dhclient gets a reply from the

198

server, it will run /etc/dhclient-script, which will take

199

the information retrieved, and configure the eth0

200

interface.

201

18. Mount the root filesystem from the server via NFS. Up to

202

this point, the root filesystem has been a RAM disk. Now,

203

the linuxrc script will mount a new root filesystem via

204

NFS. The directory that is exported from the server is

205

typically /opt/ltsp/i386. The new filesystem can't just be

206

mounted as / immediately. It must first be grafted into

207

the local filesystem by mounting it, typically on the path

208

/mnt. Then, the client can do a pivot_root. pivot_root

209

will swap the current root filesystem for a new

210

filesystem. When it completes, the NFS filesystem will be

211

mounted on /, and the old root filesystem will be mounted

212

on /oldroot.

213

19. Hand off to the normal init program (non-LTSP boot

214

sequence continues). Once the mounting and pivoting of the

215

new root filesystem is complete, we are done with the

216

linuxrc shell script and we need to invoke the real init

217

program.

218

219

220

Note

221

222

223

Note: from this point, all file paths (except those starting

224

with /oldroot, of course) refer to files that are served from

225

the server via NFS.

226

20. init processes /etc/inittab. init will read the

227

/etc/inittab file and begin setting up the workstation

228

environment.

229

21. LTSP starts in runlevel 2. init works in terms of

230

runlevels. A runlevel has a number, and specifies a set of

231

services that should be available while the system is

232

running in that runlevel. The LTSP workstation starts in

233

runlevel 2. That is set by the initdefault line in the

234

inittab file.

235

22. Run rc.local. One of the first items in the inittab file

236

is the rc.local command that will be run while the

237

workstation is in the sysinit state.

238

a. rc.local creates a RAM disk for volatile data during

239

bootup. The rc.local script will create a 1MB RAM

240

disk to contain all of the things that need to be

241

written to or modified in any way.

242

b. RAM disk mounted as /tmp. The RAM disk will be

243

mounted as the /tmp directory. This directory exists

244

in order to hold files that need to be written during

245

the boot process. We don't want to write to these

246

files on the hard disk, because then we'll change

247

them for all other clients as well, and the changes

248

pertain only to our client while it's booting.

249

Any files that need to be written will actually exist

250

in the /tmp directory. On the hard disk of the

251

server, there are only symbolic links pointing to

252

these files.

253

c. The /proc filesystem is mounted. This is a virtual

254

filesystem that exposes information about all the

255

currently running processes as a hierarchy of

256

textfiles that may be read exactly as any other file

257

on disk.

258

d. Network swap enabled. If the workstation is

259

configured to swap over NFS, the

260

/var/opt/ltsp/swapfiles directory will be mounted as

261

/tmp/swapfiles. Then, if there isn't a swap file for

262

this workstation yet, it will be created

263

automatically. The size of the swap file is

264

configured in the lts.conf file. For more detail

265

about this file, see Section 13.5.

266

The swap file will then be enabled, using the swapon

267

command.

268

e. Configure loopback interface. The loopback network

269

interface is configured. This is the networking

270

interface that has 127.0.0.1 as its IP address.

271

f. Mount /home. If LOCAL_APPS is enabled (see below),

272

then the /home directory will be mounted, so that

273

running applications can access the users' home

274

directories.

275

g. Create /tmp. Several directories are created in the

276

/tmp filesystem for holding some of the transient

277

files that are needed while the system is running.

278

Directories such as:

279

i. /tmp/compiled

280

ii. /tmp/var

281

iii. /tmp/var/run

282

iv. /tmp/var/log

283

v. /tmp/var/lock

284

vi. /tmp/var/lock/subsys

285

will all be created.

286

h. Configure X Windows. The X Windows system will now be

287

configured. In the lts.conf file, there is a

288

parameter called XSERVER. If this parameter is

289

missing, or set to "auto", then an automatic

290

detection will be attempted. If the workstation has a

291

PCI video card, then we will get the PCI Vendor and

292

Device id, and do a lookup in the /etc/vidlist file.

293

If the card is supported by XFree86 31.X, the

294

pci_scan routine will return the name of the driver

295

module. If it is only supported by XFree86 32.3.6,

296

pci_scan will return the name of the X server to use.

297

The rc.local script can tell the difference because

298

the older 33.3.6 server names start with XF86_.

299

i. Generate XF86Config. If XFree86 34.x is used, then

300

the /etc/rc.setupx script will be called to build an

301

XF86Config file for X4. If XFree86 35.3.6 is used,

302

then /etc/rc.setupx3 will be called to build the

303

XF86Config file, based on entries in the

304

/etc/lts.conf file.

305

j. rc.local resumes, start_ws created. When the

306

rc.setupx script is finished, it will return to

307

rc.local. Then the /tmp/start_ws script will be

308

created. This script is responsible for starting the

309

X server.

310

k. Configure syslogd. The /tmp/syslog.conf file will be

311

created. This file tells the syslogd daemon where to

312

send logging information (this may be any host on the

313

network). Any program, including the kernel, that

314

wants to record information for the purposes of

315

monitoring, auditing, debugging or later reference

316

can make use of syslogd, which sees to it that this

317

information is written to a file, and that the logged

318

information is eventually cleaned up.

319

320

321

Tip

322

323

324

The syslog host is specified in the lts.conf file. There is a

325

symbolic link from /etc/syslog.conf to the /tmp/syslog.conf

326

file.

327

l. Start syslogd. The syslogd daemon is started, using

328

the config file created in the previous step.

329

23. init resumes, changes to default runlevel. Control is then

330

passed back to init, which will look at the initdefault

331

entry to determine which runlevel to enter. As of

332

lts_core-2.37, the value of initdefault is 2.

333

24. What the different runlevels do. A runlevel of 2 will

334

cause init to run the set_runlevel script which will read

335

the lts.conf file and determine what runlevel the

336

workstation will run in.

337

338

339

Tip

340

341

342

The standard runlevels for LTSP are 3, 4 and 5.

343

344

345

3

346

This will start a shell. This is very useful for

347

debugging the workstation.

348

349

350

4

351

This will run one or more Telnet sessions in

352

character mode. This is great if you are just

353

replacing old serial terminals.

354

355

356

5

357

GUI mode. This will bring up X windows, and send

358

an XDMCP query to the server, which will bring up

359

a login dialogue box to let you log into the

360

server. You will need a display manager listening

361

on the server, such as XDM, GDM or KDM.

362

_________________________________________________________

363

364

365

6.4. Benefits

366

367

368

6.4.1. Easy maintenance

369

370

371

If a user reconfigures a workstation in a fat client computer

372

lab, all the other users of that workstation will have to cope

373

with these changes. This means that if someone inadvertently

374

sets the workstation to use black type on a black background,

375

for example, then no-one will be able to see what's going on.

376

377

378

In contrast, in a thin client lab, every user has their own

379

files, their own email, and their own desktop environment that

380

they can change to their liking without influencing anyone

381

else, all stored on the classroom server. A configuration

382

mistake like the above will inconvenience only themselves. [8]

383

_________________________________________________________

384

385

386

6.4.2. Cheap hardware

387

388

389

Most of the equipment in a computer lab are workstations for

390

learners to use. There may be one or two printers, network

391

switches and a server, but they are far outnumbered by between

392

20 and 40 client workstations.

393

394

395

In an Edubuntu lab, these can all be really old, used,

396

previous-generation computers. This is because the demands on

397

these machines is so slight that almost anything will do. All

398

those stacks of old computers everywhere that no one knows

399

what to do with are suddenly useful, and saving schools vast

400

amounts of cash that they would normally have to outlay on

401

relatively new equipment so they can run contemporary

402

software.

403

404

405

The thin client paradigm also means that requirements for

406

uniformity among terminals is relaxed. As long as they conform

407

to a couple of basic requirements (network boot, SVGA graphics

408

card, enough RAM) it doesn't matter if they have idiosyncratic

409

hardware. Only the server configuration needs to be

410

maintained. Heterogeneous hardware doesn't make life difficult

411

for the admin.

412

413

414

The thin-client network in the lab ensures that each terminal,

415

no matter what its own computing characteristics, behaves with

416

all the speed and capability of the server, so each user has

417

an experience of top quality, smooth, fast computing.

418

Unfortunately, this does mean that if some of your client

419

workstations are powerful, modern machines, they may not be

420

fully utilised in a default Edubuntu lab configuration, as they will

421

still be letting the server do all the work.

422

_________________________________________________________

423

424

425

6.4.3. Less theft

426

427

428

In an Edubuntu lab, the most accessible hardware is also the easiest

429

to replace and the hardest to use outside the lab. an Edubuntu lab

430

client workstation on its own, without the classroom server,

431

is more or less useless. It's too bulky for a doorstop, and it

432

can't run modern software. It doesn't even have a hard drive.

433

[9]

434

_________________________________________________________

435

436

437

6.4.4. Mobile desktops

438

439

440

As the terminals only serve to display a session from the

441

classroom server, it doesn't matter which one you use. If one

442

breaks while you've using it, you can move to the next one,

443

log on, and pick up where you left off. If someone is using

444

the workstation where you were working, go to another one and

445

log in there to regain access to your desktop.

446

_________________________________________________________

447

448

449

6.4.5. Data easy to back up

450

451

452

All the data in an Edubuntu lab resides on the disk array of the

453

classroom server. Instead of having to backup 20 or 40

454

individual hard drives, it's possible to backup only one, and

455

still get a complete backup of everyone's data.

456

_________________________________________________________

457

458

459

6.5. Drawbacks

460

461

462

Every solution will have some drawbacks, and an Edubuntu lab is no

463

exception. I'll just mention a few in passing.

464

465

466

Unreal Tournament will be lethargic or lag in response rate

467

Graphics-intensive applications such as games will not

468

perform well, as all the display information will have

469

to be pushed over the network by the server. This is

470

hundreds of times slower than driving a local graphics

471

card. Playing action games, however, is not a goal of

472

the Edubuntu lab project.

473

474

475

All the clients run the same OS

476

Since it's really only one instance of Linux serving

477

all the desktops and applications, all the clients in

478

the lab will necessarily offer a Linux environment. It

479

is possible for the server to run software such as Wine

480

(which enables many Windows programs to run under

481

Linux) or VMWare (which allows the server to run

482

instances of other operating systems), but in these

483

cases the underlying system will still be Linux, and

484

the server will still be doing all the work.

485

486

487

Single point of failure

488

While it's very convenient that the thin-client

489

workstations are interchangeable and that you can

490

access your desktop from anywhere, it does mean that a

491

catastrophic failure of the server will put all client

492

workstations out of commission.

493

_________________________________________________________

494

495

496

6.6. Hardware

497

498

499

6.6.1. Minimum specifications

500

501

502

Server

503

Memory--- The server should have 2GB RAM or more (512MB

504

for the base system, and 50MB for each additional

505

client). As long as you're using it all up, more RAM

506

means more speed (it doesn't help to have RAM that you

507

don't use). Too little RAM will bring your server to a

508

crawl as it starts swapping memory to the hard drive.

509

If you run out of memory, performance will be

510

unacceptable.

511

512

513

Hard drive--- SCSI is faster than IDE: We've seen LTSP

514

servers slow to a crawl when more than 10 clients are

515

running from IDE drives. SCSI drives are better

516

equipped to handle the multiple read/write requests.

517

518

519

Network--- Your server will have at least one Ethernet

520

card to create a private network ( 192.168.0.x). This

521

card connects to a switch for terminals. If there is a

522

school network to which you need to connect, or if the

523

school has a internet connection via the server, it

524

will have a second Ethernet card, which will get an IP

525

address on the second network.

526

527

528

Clients

529

Memory--- Client workstations should have at least 32MB

530

of RAM. Clients aren't that dependent on swap space for

531

extra memory capacity, since memory usage on them is

532

reasonably constant because they don't execute

533

applications: they only display them.

534

535

536

Hard drive--- Client workstations should not have hard

537

drives.

538

539

540

Network--- Each client workstation should have one

541

network card with a boot ROM to enable booting from the

542

network.

543

544

545

Switch

546

An Ethernet hub is not acceptable (see Section 8.2.1),

547

it's too slow for network boot and NFS. Having a fast

548

Ethernet switch will make your life better and more

549

colorful.

550

551

552

The number of ports on the switch must be enough for

553

your clients and server. If you have more than 24 NICs,

554

2 or more 12-port/16-port fast Ethernet switches are

555

recommended. The client ports should be 100 megabit,

556

and there should be a gigabit port for the server.

557

Since all clients get their display from the server, a

558

slow link to the server would be a bottleneck for the

559

whole lab.

560

561

562

563

564

565

The front panel of the switch shows a light for every

566

network cable that's been plugged in. The light shows

567

whether the link is up, whether there is traffic and

568

what its speed is.

569

570

571

572

573

574

The cables from the workstations all terminate at the

575

switch. If you don't label them, they get very hard to

576

tell apart!

577

_________________________________________________________

578

579

580

6.6.2. Things to look out for

581

582

583

Monitors

584

The display size should be at least 15", and the

585

monitor must be capable of SVGA video modes. It should

586

also be compatible with the video card of the client.

587

588

589

Uniform equipment

590

If you use the same equipment throughout your Edubuntu lab,

591

it becomes easier to buy in bulk and to swap out

592

components. It also makes it easier for Edubuntu labs to

593

assist each other with skills and equipment.

594

595

596

Heterogeneous boxes, in comparison, are harder to keep

597

running, and more likely to be "throw-away" --- not

598

worth trying to resurrect. As long as they don't cost

599

you anything, this is worth it, but you have to guard

600

against them becoming a drain on your time and

601

resources.

602

_________________________________________________________

603

604

605

6.6.3. Sources for second hand equipment

606

607

608

Locally, FreeCom supplies tested refurbished computers.

609

Because of the high volume of hardware required by the large

610

number of Edubuntu labs installed, the Shuttleworth Foundation has

611

procured the client workstations from international

612

distributors such as Computer Aid. Other workstations have

613

been donated by private industry.

614

_________________________________________________________

615

616

617

6.7. Thin Client configuration

618

619

620

While there is little to do for the installation of the thin

621

client workstations, there are a couple of things you can pay

622

attention to.

623

624

625

Network cards

626

All the client computers need to get a network card

627

with space for a boot PROM (see Section 16.4), so that

628

they can start looking for the server on the classroom

629

network as soon as they are switched on. The server

630

also needs a network card, and it needs to be a fast

631

one (gigabit Ethernet), as the link between the server

632

and the switch is ten times quicker than the link

633

between the switch and the client workstations.

634

635

636

Boot PROMs

637

Depending on the network cards you managed to get, the

638

correct Etherboot image may need to be written to the

639

network cards. The Diskless Remote Boot in Linux

640

project has made available an Etherboot NIC Detection

641

Disk which can help you to determine what you need to

642

write to the card.

643

644

645

Dual-booting

646

The BIOS in the client workstations normally needs to

647

be configured to boot from the network. To do this,

648

watch the workstation screen after turning the power on

649

--- for a couple of seconds, the BIOS will display a

650

notice that you may press a key (such as DEL or F8,

651

depending on the BIOS) to enter setup mode. This will

652

enable you to specify where the computer should look

653

for boot records during startup; for example on a CD, a

654

floppy disk, a hard disk, or the network card. In the

655

event that you have a relatively capable workstation

656

with a hard drive, you may want to boot the workstation

657

as a standalone computer from time to time. To do this,

658

you may configure the BIOS to look for a boot record on

659

a floppy disk before trying the network card.

660

661

662

One kind of scenario where this may be useful, is where

663

you have an existing computer lab with software

664

installed at each workstation. Boot from hard disk to

665

access the standalone workstations, and boot from the

666

network to have an Edubuntu lab! It is even possible for the

667

standalone workstations to access the Edubuntu lab network,

668

and to use the classroom server as a file server, and

669

the Wizzy server as an internet proxy. Since an Edubuntu lab

670

is implemented using standard protocols, this will work

671

no matter what operating system is installed on the

672

workstation computers.

673

674

675

Other resources

676

This cookbook can do no more than scratch the surface.

677

Some of the other resources regarding thin-client

678

computing available on the web include:

679

680

681

+ Diskless Remote Boot in Linux (DRBL) for Redhat 8.0,

682

9, Fedora Core 1, 2, Mandrake 9.2, 10

683

+ Root over NFS clients & server HOWTO, if your

684

workstations have disks, and you don't want to

685

delegate processing to the classroom server.

686

+ Network Boot and Exotic Root HOWTO This document

687

explains how to quickly setup a Linux server to

688

provide what diskless Linux clients require to get up

689

and running, using an IP network. It is based on the

690

Diskless-HOWTO, the Diskless-root-NFS-HOWTO, the

691

Linux kernel documentation, the Etherboot project's

692

documentation, the Linux Terminal Server Project's

693

homepage, and the author (Brieuc Jeunhomme)'s

694

personal experience.

695

_________________________________________________________

7

<h1>Moved to Chapter 4</h1>

8

9

10

This is now just a placeholder. The original content has been

11

shuffled between Chapter 4, Chapter 13, and the new Appendix (A? 1?

12

I?)

13

696

14

697

15

</body>

698

16

</html>