[ale] New Twiki topic LinuxInGASchools

[Mike Panetta]

Let me start by saying that I think the solution to the problem is a
custom distro..  See below...

On Tue, 2002-08-13 at 11:45, Charles Marcus wrote:
> > From: Jeff Hubbs [mailto:hbbs at attbi.com]
> > Sent: Tuesday, August 13, 2002 1:49 PM
> >
[snip of apples oranges blah blah...]

> There are a *lot* of things the implementer of *any* production Linux
> environment must address, but that doesn't mean that each app must address
> *all* of the separate issues.

No but who ever designs the distribution should.  Or atleast put in
place "reasonable defaults". (Whatever that may be).

> 
> Your original post suggested that the fact that KDE would allow any user to
> reboot the server was an *LTSP* problem - all I did was point out that it
> was indeed a problem, but a *KDE* problem *not* an LTSP problem.

I say its neither.  I say its a distribution problem.  The default
distro of kde has that "feature" enabled, through some config file I
would imagine (I am no KDE expert).  Thus it would be a "fix" (for both
of you) if the distro had that feature turned off by default.  What I
mean by distro in this sense is the KDE RPM or whatever package installs
it (if its installed from source then its the source tar ball and the
guy that installs the config files).  Or if the package was installed by
a distribution installer (say redhats installer) and then the config was
manipulated prior to installation (possible) then the distro is the
whole shebang (IE the redhat foo.bar cd install set).  


> 
> > I'm more than well aware of that.  However, the fact
> > remains that distros and their implementations of window
> > managers allow ordinary users to do very untoward things
> > if one instead thinks of the machine being used as a
> > "session server" whose operation must be protected from
> > user-initiated impacts.
> 
> And again, this is *not* an LTSP issue, it is a *KDE* issue.  The *only*
> thing I was *ever* arguing was your assertion that somehow this was a
> *failing* on the part of LTSP.  *IT* *IS* *NOT* !  That is all I'm saying.

No its not an LTSP issue, or a KDE issue (:P) its a distribution
issue.   See above.

> 
> >> 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.
> 
> > I'm more than well aware of this, too.  However...
> 
> >> 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.
> 
> > ...my points are hardly irrelevant.
> 
> This is getting ridiculous - yes, they *are* irrelevant - TO THE QUESTION -
> as to whether or not they are the fault of LTSP.  They are *very* relevant
> *to any production Server environment*.

They are even more relevant to a distribution designer.  (Thats what I
call Jeff's "System designer" in this case).

> 
> This conversation got started because you made the statement that *LTSP* had
> serious problems because *KDM* would allow any user to reboot.
> 
> Is this a serious issue?  Yes!  Is it an issue of LTSP? *NO!!!!!!*
> 
> > Any LTSP-like environment that is going to actually
> > be proposed as a solid, viable, secure, robust, and
> > REPLICABLE solution has to have every last one of
> > these issues addressed in its BASELINE configuration,
> > NOT as an "I'll twiddle this and I'll twiddle that"
> > matter but as an "this has ALREADY been designed,
> > twiddled, and set up the way it needs to be for
> > production use prior to installation" matter.
> 
> This is probably the only paragraph I disagree with completely.  There is
> absolutely no way for the LTSP developers to determine all of the possible
> ways people mighht wanna use LTSP.  There are some things that are simply
> the domain of the System Administrator, plain and simple.

No but there are some things that apply to the way LTSP is going to be
used in a School environment, and thus can be planned for in advance and
put into a default config that the distribution installs.  If the sys
admin for a particular school wants to change the defaults, then let
him.  If the sys admins of all schools want to change all the defaults,
then we programmed the defaults wrong and the distribution manager needs
to change them.

> 
> What if you install LTSP and KDE hasn't been installed yet?  There are just
> too many variables.

Then your not installing from a distribution, and your doing it the
wrong way anyways. :P  

> 
> > Receiving a litany of showstopping issues from end
> > users and responding with "I can fix that, I'm the
> > SYSTEM ADMINISTRATOR...I can fix that, I'm the SYSTEM
> > ADMINISTRATOR..." isn't going to make a very good
> > impression.  The person who does the design, does the
> > testing, finds the problems, implements the fixes,
> > and releases working, good, solid "re-distributions"
> > is the SYSTEM DESIGNER.
> 
> OK, well, lets talk semantics then.  Give me a break.  A *good* system
> administrator *also* performs the functions of what you have just termed the
> 'System 'Designer'.

No he does not.  The distribution designer does.   A good distribution
is set up with the correct defaults for the situation in place, so that
its easier for the sys admin to customize the machine to what he wants
it to do.  I would argue that the school environemnt is probably going
to be standardized somewhat (atleast as far as what the computers are
actually used for) so I think it should be reasonably easy to come up
with some defaults for the distribution to use.  On default is "KDE does
not allow users to shut the machine down" or something similar.  Another
may be "Disable all non LTSP services on boot" or whatever.  It all
depends on how the machine is to be used when its in place.  I will
admit that I have not done much with LTSP (hell I have not done ANYTHING
with it), but I have taken part in designing a custom distribution for a
system when I last had a job...  We were based on redhat, and I will
tell you that EVERY RPM that we installed was customized.  Every single
one.  We changed default config files, took out docs (it was an
"embedded" distribution), stripped all the libraries.  We did all sorts
of things, even replaced the installer with one that only asked like 3
questions of the end user (please press enter to start, what raid level
do you want your drives set up as, and press enter to finish, were
basicly the only prompts that came up during the install).  Everything
else was handled automatically during install, or handled by the mods we
performed to the packages.  Things like the name of the machine and
stuff like that were tweaked by the sys admin AFTER install using a
special tool that ran on a web server.


> 
> This conversation is getting more and more ridiculous.
> 
> All I wanted to point out was that a misconfigured KDM is *not* the fault of
> LTSP.

No its not.  Its a fault of the distribution manager (in this case).

[ Snip of everything else that is irrelevent to MY point ]

> 
> Charles
> 


Mike


---
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.