[ale] New Twiki topic LinuxInGASchools

Charles Marcus CharlesM at Media-Brokers.com
Wed Aug 14 17:44:16 EDT 2002


Jeff,

I try not to engage in personal insults either.  The fact is, I do not
consider the act of pointing out fallacious statements to be an insult to
anyone.  I may be a bit abrupt at times, but thats just me...I don't have
much patience for people who say something, then refuse to own up to what
they said.  When I speak out of turn, and someone corrects me, I acknowledge
it, apologize if necessary, and move on.  I expect the same from others.

> I did not BLAME LTSP or anything else for the problems
> I noted.

Well, lets see.  Here's what you actually said:

| ************************************************
|
| Dow said:
| Focus on LTSP as a leverage for old hardware.
|
| To which Jeff again replied:
| 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!).
|
| To which Charles replied:
| This is trivial to fix, and not even worth mentioning...
|  [here, I *meant* in context of an eval of LTSP]
|
| To which Jeff responded:
| 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.  I didn't
| even *begin* to explore what others may be in there.  My
| point was that LTSP takes a single-headed GUI desktop
| system and makes it multi-headed, multi-user, etc., 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.
|
| ************************************************

That's it.  Now, from what you said: You "took a shot at getting LTSP to
work and found that any KDE User can shut down the server".  You made this
statement, Jeff, in the context of EVALUATING LTSP, when the problem was
obviously a mis-configured KDM, which would be somthing that the System
Administrator - YOU, in this case - should have *already* taken care of, if
you were concerned about any User being able to reboot the server.

Next, you compounded your error by saying "This was but *one* serious
security flaw I found" - security flaw?  The security flaw, Jeff, was in the
way KDM was configured.

Again, to understand my criticism of your criticism, you must remember that
you are saying these things in the context of an EVALUATION of LTSP.

LTSP environments can be very diverse.  LTSP, per se, has NEVER been
intended to be a point-n-click install, as each installation can be very
different.  On the other hand, the K12 LTSP project (www.k12ltsp.org) would
have been a much better choice, if you intended to evaluate LTSP as a
candidate for this discussion.  If you had spent any time at all on the LTSP
mailing list or web site, or done a few rudimentary Google searches, you
would have found this out.

> As I recall from the LTSP docs, it presupposes a distro
> installation, takes up from there, and then leaves off
> with no follow-through.  LTSP as presented by its creators,
> whether in documentation or in software, does not leave you
> with a production-ready platform

Not immediately after installation, no.  How many Linux Server applications
(like, for example, BIND) do?

>  - it's a demo, at best.

Well, there are probably many thousands of LTSP users who would differ.

> I'm just STATING that; I'm not making a BLAME or FAULT issue
> out of it.

Saying that you weren't laying blame doesn't change the words you used, or
the context they were rendered in, Jeff.

<snip>

> It's important to understand that the mere EXISTENCE of
> the solution being proposed makes someone somewhere *look
> bad* for not having already implemented it or at least
> instigated exploring it.

The only one who looked bad from your LTSP attempt was you, since *you* were
the Sys Admin doing the install, and didn't take the 30 seconds (or maybe 5
or 15 minutes, if you had to read some man pages) to modify the KDM
configuration so it didn't allow non-root users to reboot the computer.
This very issue has been discussed more than once on the LTSP mail list, and
they will tell you the same thing - it is not the job of the LTSP install
script to configure KDM (you may not even be USING KDM), or BIND.  It does
provide an example dhcp.conf file, but it certainly doesn't presume to
change your existing one.

I still cannot believe that you don't see the error in thinking when you
claim that a misconfigured KDM, which is part of KDE, which is a totally
separate program, is a problem of LTSP.

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.






More information about the Ale mailing list