[Beowulf] centos5 as cluster os

[Robert G. Brown]

On Fri, 15 Feb 2008, Joe Landman wrote:

>
>
> Mark Hahn wrote:
>>> whats everyones take on centos as a cluster os.
>> 
>> works fine for me, but I also don't think distros are very important.
>> the critical things are:
>>
>>     - must have a decent package system.  yum is; I'm not familiar enough
>>     with urpmi or apt to know them.  I think both provide appropriate
>>     management of dependencies.
>
> Yum is good, so is apt.  I still have a problem with yum wanting to install 
> i386 binaries as well as the x86_64 ones.  Haven't learned how to stop that 
> yet (probably simple too).

Usually when it does this it is installing the i386 libraries, not the
binaries per se.  That's for backwards compatibility.

Space is cheap.  I just ignore it.  Besides, I do sometimes forget and
run an i386 binary -- easy to do from an NFS mount.

> There is much I do not like about rpm.  However it has a few nice features. 
> I can't live without
>
> 	rpm -qa
> 	rpm -ql package
> 	rpm -qf file
>
> and am going through withdrawl as apt does not seem to provide these (or if 
> they do, it isn't at all obvious how/where).

Yeah.  What you said.

> As few things as possible installed.  Keep it simple.  Fewer things means 
> less of an attack surface, a smaller management base, and hopefully smaller 
> emergent complexity.

Awwww, but then you don't have any fun!  And this last exploit merely
required the right binary built from source, not one on your system
anyway.  Minimalism is again a matter of cost benefit.  Different people
or organizations will have different comfort zones or goals.  Minimalism
on the desktop means giving up a lot of possibly useful stuff.
Minimalism in a cluster means having to spend more time putting stuff
back when it turns out that you need it after all.  Both of these are
costs; you have to balance them agains the perceived risk benefit, which
in turn depends on your estimate of the risk of attack, the likely
window of opportunity for an attack, your degree of vigilance, the cost
of putting things right again.

I personally prefer high vigilance (as it has historically ALWAYS been
the case for me that vigilance reveals cracking attempts or successes,
and there are ALWAYS going to be holes I don't get closed, at least not
right away or maybe in time) coupled with a robust and easily restored
backup and installation system.  If a host gets cracked, reinstall it
via kickstart/PXE and forget it.  No local data on a host.  Backup
everything.  Protect the servers with far greater vigilance than nodes
or clients.  Then don't worry so much about the periphery.

But there are places where cracking has a much higher up-front cost, or
a higher risk.  So I don't argue that this recipe is right for all.

> * I have been bashed/castigated in 2 fora recently for daring to suggest that 
> some technology may have alternatives that one might wish to consider, or 
> there may be known issues, or whatever.  Shooting the messenger.  Not a wise 
> move.  You don't have to believe me, though I do recommend that you make a 
> backup of your Rocks system if you do choose to run yum.  You can run yum 
> safely on it, though it takes some work. And the Rocks folks have recently 
> formed a user group to help make sure it is safe going forward (cudos to the 
> Rocks folks for doing this).

What?  You said technology has alternatives?

Well no WONDER you got bashed.  I'd have bashed you here if only I'd
known.   Look:

<bash>

There.  Now it's three out of three;-)

    rgb

-- 
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977