HELP NEEDED SATURDAY: Installing Terminal Server

[Warren Togami]

----- Original Message -----
From: <epsas at inflicted.net>
To: "Linux & Unix Advocates & Users" <luau at list.luau.hi.net>
Sent: Thursday, November 01, 2001 8:30 PM
Subject: [luau] Re: HELP NEEDED SATURDAY: Installing Terminal Server


> > I'm leaning more towards automating fdisk and "mke2fs -j /dev/hdaX".
This
> > would be necessary, especially in the future when we wont have uniform
> > hardware.  Even a slightly different hard drive size would complicate
the dd
> > method.
>
> Good plan, forward thinking.
> What does mke2fs -j do?

That is creating the ext2 partition with ext3 journal.  This way people will
never need to wait for a fsck during bootup.

>
> > Step four may not be entirely needed, because the XTerminals toolkit
takes
> > care of this in for another reason. Maybe we could integrate ours into
their
> > system... although I'm still debating whether I should use the
XTerminals
> > toolkit or LTSP.
>
> I am still trying to get my head around the LTSP - are these going to be
diskless clients?
>

The minimum hardware requirements for pure diskless thin client operation
would be a 486 or Pentium with PCI bus, decent video board and PCI NIC.  Our
machines are Micron P166 with 64MB RAM, decent video boards, and 3c905 PCI
10/100 cards.  This is sufficient muscle to run some applications locally,
while most run on the server.  I plan on running Galeon with browser plugins
locally on each machine.

Running applications locally requires at least a small hard drive for /tmp
and swap space, so these can't be completely diskless.  Perhaps later pure
thin client machines (weaker Pentiums) may be added to the network.  These
machines would run the web browser on the server.

It would be a lot simpler to configure this for pure thin client operation,
but two things stop me from doing this.
1. Flash plugin for Linux crashes (Segmentation fault) when attempting to
use over remote X.  Works fine locally and via Xvnc though.  I wrote several
e-mail to Macromedia about this a few months ago, but they never responded.
A few folks at Red Hat are annoyed by the same problem.  (And yes, end users
EXPECT Flash to work.)
2. Bandwidth utilization of most Flash and Java animations would easily
overwhelm the network.

Much later when we start to use more powerful multimedia machines with sound
cards, local applications will be a necessity for stuff like Quicktime, Gimp
and sound applications.

Doh!  I need to figure out the remote floppy disk daemon before Saturday
too.  End users will expect to be able to pop their floppy into their local
terminal, and open or save documents from StarOffice that is actually
running on the remote server.