[Beowulf] Security issues

[Alan Ward]

Kubuntu-derived? Would Debian not be a better way to go, as in not installing any graphical stuff unless the user needs it? 

As for testing, if you have a workstation with 1-2 Gigs of RAM, perhaps you could consider a "virtual cluster".

Cheers,
-Alan

 

-----Original Message-----
From: beowulf-bounces at beowulf.org on behalf of Jon Aquilina
Sent: Fri 10/24/2008 11:23 AM
To: Kilian CAVALOTTI
Cc: Nifty niftyompi Mitch; beowulf
Subject: Re: [Beowulf] Security issues
 
now i see why the sudo approach adopted by debian and the kubuntu line is a
good way to go. this is providing me with real motivation to start the
development of my own kubuntu derived cluster distro. thing is i would need
someone to give lists of pkgs that is used in a cluster and also testers and
programmers to help me out seeing as i dont have a cluster.

On Fri, Oct 24, 2008 at 10:55 AM, Kilian CAVALOTTI <
kilian.cavalotti.work at gmail.com> wrote:

> Jon Aquilina wrote:
>
>> did this person use the ssh exploit that red hat found a few months ago?
>>
>
> Apparently not. From what Joe wrote, "the entry point was via a shared user
> account". This account has been compromised, either with brute-force ssh
> login attempts, or was socially engineered, it's not clear.
>
> Nothing seems to indicate (as far as I can tell) that the entry point was
> due to some weakness in one of the Rocks components. I second Mitch in
> saying that this break-in isn't Rocks specific, but rather the result of
> poor (lack of?) administration practices (especially from what I could read
> here: http://scalability.org/?p=905, and assuming it's about the same
> customer).
>
> On the other hand, it's true that Rocks' philosophy (which I'm not a big
> proponent of) doesn't make updates easy, nor encourage keeping systems
> up-to-date. It tends to focus on the Windowsian "reinstall the whole
> machine" approach in case of problem. Which makes perfect sense in specific
> contexts, where no dedicated administration resources are available, or
> where compute time is critical and understanding the root cause of technical
> problems not so important.
>
> But this can also lead to the kind of security problem Joe described, even
> if here, I don't think one can blame any of the system's component being
> outdated for this intrusion.
>
> Cheers,
> --
> Kilian
>



-- 
Jonathan Aquilina


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.scyld.com/pipermail/beowulf/attachments/20081024/3a0bcd2f/attachment.html