[ale] New Twiki topic LinuxInGASchools

[Charles Marcus]

> From: Jeff Hubbs [mailto:hbbs at attbi.com]
> Sent: Tuesday, August 13, 2002 10:45 AM
>
>>> Yeah!  LTSP, if nothing else, can be used as a study case
>>> for a more elegant solution or it can be implemented as-is
>>> with modifications; I took a shot at getting LTSP to work
>>> (diskless P/90 client) and found that any KDE user can shut
>>> down the server (a non-starter, for sure!).

>> This is trivial to fix, and not even worth mentioning...

> That was but *one* serious security flaw I found - one that
> would kill all user sessions at once but could even be
> triggered by accident by a well-meaning user.

OK, I guess I should have been more clear... sorry.

This is not even an LTSP issue, it is a KDE issue in the way your Distro
installs KDE by default.  If you had taken the time to check it out, ALL
user sessions were like this, whether local OR LTSP sessions.

Again, it is not even an LTSP issue, it is a DISTRO/KDE issue - and it is
simple to fix.

> My point was that LTSP takes a single-headed GUI desktop
> system and makes it multi-headed, multi-user, etc.,

Uhhhhhhh --- huh?

*All* Linux systems are multi-user by their very nature.  Yes, you can have
a 'Desktop Environment', but the system itself is still very multi-user.

> and due attention must be paid to the fact that there are
> limits and restrictions that have to be determined and
> enforced.  That's not as trivial as you appear to be
> making it sound, and it's also not trivial to create and
> sustain the kind of configuration control necessary to
> ensure that those controls are in place and properly
> configured each and every time you generate a server.

No, but LTSP is not KDE.  these are two sompletely separate applications.
You do *not* need KDE to run LTSP.  It works great with Gnome, or any of the
other dozens of Window Managers out there.

All of your points are true, but irrelevant.  The issues you are discussing
are SYSTEM issues, and have to be dealt with the the SYSTEM ADMINISTRATOR.

>>> and the level of machinery on hand runs the gamut.
>>> The sticking point is going to be creating useful
>>> server hardware, but it's pretty clear that the
>>> range of PCs that people are casting off for being
>>> too slow for use with Win2K and WinXP are the ones
>>> that begin to make good servers.

>> Maybe entry level servers, but if you want a server
>> that can handle 30, 40, 50 or more clients, it will
>> have to be much more powerful - as always, depending
>> on what the clients will be running.

> Yes - it will all depend on what you're trying to do.
> I know that with multiple instances of Mozilla running
> on one machine, that first instance takes a big chunk
> of RAM but subsequent instances do not.  I can't say
> that I've done this on an LTSP rig with 50 clients, no,
> but what I have already observed on single machines
> and my one-client LTSP rig suggests that with some
> apps, you may be able to bear a counterintuitively
> large load on a piddly server.

Yes, I agree.  Some apps are much more friendly to LTSP as Server apps (like
Mozilla) and some are not.

A key here is to *not* let the Server ever hit swap - if it does, the system
will slow to a crawl for *all* users - this is the downside to centralized
serving (single point of failure).

> Also, recall what I said about the typically bursty CPU
> usage of desktop apps and how those bursts from many
> different users can interleave with very little
> perceptible collateral impact up until you start really
> having no idle CPU time left.

Agreed again.  RAM and Disk speed are far more important than CPU/Processor
speed, although these are cheap enough that I wouldn't use anything less
than a 1GHZ unless I absolutely had to.

>> If you want to be able to use these low powered servers,
>> then we will have to become proficient with how to
>> configure the Clients that are capable to run local
>> apps, to relieve the load from the server.  The low-
>> powered clients can run their apps on the server.

> Sure, that can be pursued, but know that you're
> instituting an additional "product line" for client
> machines with a configuration that has to be
> maintained. If you've got dozens of client machines
> and they all have lots of RAM and fast disk, then
> it's worth considering to take advantage of that.
> But, as I've indicated before, would you be
> relieving a server of load that it can actually bear
> without too much strife?

It goes more to extending the Servers Client load capability - and I don't
think Local apps are nearly as big an issue as you indicate - and they will
be even less of an issue once the LDAP backend stuff is completed, which
shouldn't be too much longer (few months?).

>> RAM and HD speed are the two most critical things on
>> an LTSP server. 15000rpm SCSI drives and maxed memory
>> are always preferred, but not always sellable to the
>> Customer.

> In this context, as long as I'm not counting on heavy,
> heavy disk I/O, all I care about regarding disk is
> capacity and RAID.

This ignores the FACT that LTSP servers can and do hit the disk drive very
hard.

> I figure that one may simply not have a CHOICE of even
> 10,000RPM drives; one may have to simply work with what's
> available.

Um, I believe that is what I said above?  I said 'preferred', no?  In other
words, you should always *try* to sell the customer on one or two very
high-powered Servers with redundant Power Supplies, Dual CPU's, Dual NICs,
15000RPM SCSI RAID - then work your way *down* from there.  Explain it to
them that this is the *ideal* server, then work within their budget.  The
fact is, for the cost of 3 or 4 reasonably powered workststaions, you can
have this kick-ass server that can handle a hundred or more Clients, if
properly configured.

> I feel more strongly about getting as much RAM as
> possible; more RAM means less swap and that eases up
> on the drive situation, whatever it happens to be.

I would agree that RAM is first in order of priority.

>>> Any and all infrastructure hardware MUST MUST MUST
>>> go on a UPS.  THAT's where the money that would go
>>> for MS licenses should go.

>> Goes without saying for *any* server installation.

> Well, you'd be surprised.  I've worked in places where
> the IT folks just didn't believe in them.

There are morons everywhere you go, no?

>>> I feel that WinXX on the client side is inevitable.

>> I totally disagree.  Although you are correct that there
>> are many apps that are available for WinXX that are not
>> for Linux, this does *not* mean that we can't use Linux
>> for the Clients.

> Perhaps I should have said SOME WinXX on the client side
> is inevitable. I would tend not to push the issue because
> when new COTS software is found by the user community to
> serve their needs, it is very likely to be Win32 software.
> Yes, you can decide to take on the emulation or quasi-
> emulation concept every time, but you're likely to lose
> as much as win, and the user community probably won't
> settle for that.

Win4Lin is *not* 'emulation'.  You are running a real Windows session.  The
only drawback it has is it only supports Win9x currently, although my
understanding is this is gonna change in the next year.

Using Linux/Win4Lin/Tarantella is a win/win situation for everyone.  Users
can run any Windows software they want, and you can easily restore their
windows install to a default config if they ever mess it up.

> If integration/infiltration of the status quo is
> desired, then WinXX and Mac clients have to be
> presumed from the get-go with Linux clients
> coming into play *when they can* without causing
> an ongoing sticking point.

Of course, I never presumed that the idea would be to *replace* every
workstation with LTSP immediately.  The bottom line, though, is if we do a
good enough job of setting it up in the first place, they will *ask* for
more and more, because they are cheap, fast, and safe (as long as we are
using proper disaster recovery techniques).

> With Linux clients, your biggest problem area is
> going to be accommodating new user requirements
> in both hardware (hey, I just got this new cool
> WinScanner!) and software.

Sure enough - you will have to train them to check with their LTSP support
team before buying new hardware, but that shouldn't be too hard...

> > The best solution for this particular issue is the use of a
> > Linux/Win4Lin/Tarantella server, which can then serve up
> Win9x sessions to
> > the LTSP clients - even over a WAN.  It works *really* well
> - the Win4Lin
> > guys will even let you connect to a Demo server to see it
> in action for
> > yourself.  All you need is a browser that supports Java.
>
> I'd like to see that; haven't yet.

I have.  Its way cool.  I ws actually accessing a Windows session over a
DIAL-UP connection, and the speed was reasonable - definitely usable.  The
recommended bandwidth per client is 64k, but like I said, it is usable over
dial-up.


Charles


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.