disadvantages of linux cluster - admin -- very serious

[alvin at Maggie.Linux-Consulting.com]

hi ya


On Thu, 7 Nov 2002, Bogdan Costescu wrote:

> On Wed, 6 Nov 2002 alvin at Maggie.Linux-Consulting.com wrote:
> 
> > 	- harden the server from the user standpoint
> > 		- remove passwd command, remove tar, remove make/gcc...
> 
> I don't think that you are too serious here. I remember several years ago 

very very serious ...

users are restricted to what they can and cannot do ...
	- nobody will have passwds, unless they are "on call 24x7"

users, managers, admins all sit around and work out an acceptable
cluster/pc user policy so that it maximizes productivity and usage
of ALL computer and people resources with the minimum of interruption
from one or two (rogue) user that wants to play around...

-- i say its all "policy controllable"...
	- users might need a little hand holding and scolding
	if they mess up ...but usually everybody wants the systems
	to work flawlessly... 

> when the Ping-Of-Death was discussed on Bugtraq, somebody said that admins 
> should remove (or remove access for users to) the "ping" program - yeah, 
> sure, like nobody would be able to copy another ping binary or even 
> compile its own.

most of the security break or system downtown is due to internal users
playing around ... untested releases ... etc...etc..
	- thats what the automated-admin should be doing... 
	preventing it..  and restoring back to what it should be if
	somebody changed it

-- changing user passwds at will and sending out junkmail that foo machine
   is broken being the most common user training problems..
	-- remove/rename  passwd command and problem solved

> As you have to let users:
>  - log on to the cluster to launch jobs
>  - be able to copy files to/from cluster (otherwise you do need _infinite_ 
> storage space attached to the cluster),
> you can't forbid installing their own versions of the same programs in 
> their own home dir. It's usually as simple as:
> 
> ./configure --prefix=/home/bogdan

installing any whacky app into their own home directory is worthless
as its probably a waste of time
	- some apps need to be installed as root
	- probably more than one user needs that "app" 
	- the apps need to be in the .bashrc search path and their
	  local copy is not ... users do NOT get to modify ~/.bashrc
		( solves lots of remote login issues that way )

> Having make/gcc/... unavailable is sometimes impossible - when development 

use a set of sub-cluster machines for just "make/gcc" and leave the rest
of the cluster w/o it.... make/gcc causes too many problems and support
issues

> You probably missed the whole paragraph in RGB's message that was talking 
> about users - I can only say that my experience here is perfectly 
> described by this paragraph. Yeah, shoot them :-)

cant shoot um ??? only can reduce their "privilidges" of what they can do

> I'm constantly amazed at the prolonged support contracts (like 2-3 years) 

support contracts is not necessary ... 95% of the time ???
	-- something else is wrong if it is needed ..
	-- also depends on what the terms/conditions and type of support
	   one is supposedly getting...

> when, as you stated earlier, HW is out-of-stock or discontinued so fast. 
> Do these people keep huge stocks of whatever parts they put in your 
> system ? Even DIY approach of keeping spare (OK, let's say more than 1) 
> parts seems a bit too much to me, unless the cluster _must_ be homogenous.

if clusters must be homgeneous.....  you will have a hard time keeping
it in that state 3-mon or 6mon down the road ... soemthing will break...
and files on each box is definitely different withing the first few weeks
because changes are not propagating
 
have fun
alvin


btw.. think we all agree and see the problems ....

	- maintainance and admin can be the least expensive issues
	if one has the proper "computer usage" policy that is
	agreed upon by users, managers, admin
		( its relatively trivial tosolve compared to finding
		( the right spare parts thats been discontinued
		( and the apps/tests/env requires certain pieces of hw