[Beowulf] SGI to offer Windows on clusters

[Greg Kurtzer]

As much as I love distribution debates, I have been really trying to  
just let it happen and not get drawn in. I think I did a pretty good  
job too! ... Well, as of 5 minutes ago.

How can anyone really take a distribution that does not support its  
own packages for any reasonable amount of time seriously as a cluster  
solution? Discounting the simple to fix openssh type bugs, what  
happens when the core OS has a vulnerability or major bug? None of  
the options seem acceptable to me:

    1. let it go and don't fix
    2. create the fix ourselves from either a supported src.rpm from  
a different distro
    3. back-port the fix myself
    3. merge a binary fix from a newer OS revision
    4. hope that someone else will do #2 or #3 and share their work
    5. upgrade the entire cluster several times during its lifetime

Maybe single (or very low count user systems) can find this model  
reasonable, but for any multiuser system (especially not at an *.edu)  
it is unreasonable. A break-in on a system being maintained like this  
can get people fired for very bad decisions and weak sysadmin  
practices. About the only saving excuse is "the postdoc or scientist  
did it!".

Regarding hardware support, John you hit the nail on the head. Much  
easier to update the kernel or modules then support a non-upstream- 
supported version of glibc (or other core library). Also when  
purchasing a cluster from a hardware integrator, we always add a  
comment about the system must be compatible with a default install of  
the distribution that we plan on using (with needed exclusions  
specified).

Tracking Fedora releases is masochistic both for IHV/ISV's as well as  
the administrators who care about security and stability.

Greg



On Apr 16, 2007, at 1:05 AM, John Hearns wrote:

> Robert G. Brown wrote:
>> On Sun, 15 Apr 2007, John Hearns wrote:
>>> And re. the future version of Scientific Linux, there has been  
>>> debate on the list re. co-operating with CENTos and essentially  
>>> using CENTos
>
>> IMO, most cluster builders will find it more advantageous to track  
>> the
>> FC releases instead of using RHEL or Centos or things derived  
>> therefrom.
>> Hardware support is key, and Centos can get long in the tooth pretty
>> quickly in a cluster environment with any sort of annual turnover.
> Bob,
>    at long last I can take issue with you.
> I don't agree re. Fedora.    We as cluster builders have to support  
> machines for at least three years, and are commonly requested to  
> extend support. I don't see how we can support a distribution which  
> has a 'live' lifetime of six months (not sure how long updates are  
> for after that). After three years the distro is far, far out of date.
>
>
> Your point re. hardware support of course is correct, and refutes  
> my argument above. We deal with this by backporting up-to-date  
> kernels and drivers, (and other packages such as dhcp server to RH  
> 7.3 recently!)
>
>
> If you reply that 'rolling updates' a la Debian would be possible,  
> that would be OK if well engineered (*) on academic sites.
> But on commercial and secure Government sites machines are very  
> often operated on an isolated LAN, and stability (read 'don't  
> change things unnecessarily')  is a key requirement there too.
>
>
>
> (*) Ha. Well engineered?
> Take the recent SuSE update which killed system logging on one of  
> our clusters. SuSE update RPM for syslog-ng now requires that the  
> syslog-ng.conf file is present (not present on the default install).
> Yast quietly updates the RPM during the night last November.
> System is rebooted a couple of weeks ago. We're asked to diagnose a  
> problem - and lo and behold no system logs.
> (The fix is to use SuSE-config to create the syslog-ng.conf file  
> and restart syslog)
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit  
> http://www.beowulf.org/mailman/listinfo/beowulf

--
Greg Kurtzer
gmk at lbl.gov