[Beowulf] Security issues

[Geoff Jacobs]

Robert G. Brown wrote:
> On Fri, 24 Oct 2008, Jon Aquilina wrote:
> 
>> true but if there is something that isnt in there i would be more then
>> willing to add it to the repo.
> 
> But what is the ADVANTAGE of reducing the number of packages in a
> warehouse from which one pulls packages, when the filled warehouse
> already exists and is free?
> 
> I don't know about Debian so much, but with RPM repos one can set up the
> primary full-distro repo, and create as many "local" repos as one wishes
> on the side (or link in to e.g. livna -- other repos other humans
> maintain and that you trust).  I can only presume that Debianish distros
> can do the same.
Yes, very much so. Many, many updated packages or packages of dubious
legality (libdvdcss anyone?) are available in ancillary repositories.

> So create a "cluster distro" as an OVERLAY on TOP of an existing distro.
> That way you do far, far less work.  All the distro packages are there
> if you need them.  Most of the cluster packages you might need are
> already there.  If you need to rebuild them, augment them with
> non-distro packages, or e.g. add some custom kernels, build the
> replacement/augmentations, package them, pop them in an overlay.  Yum
> will (if told to nicely) use them instead of the ones in the regular
> distro.
Or package the source packages and submit them upstream. Volunteer for a
life of servitude!

> Don't forget, of course, that then YOU are responsible for maintaining
> the update stream of any packages you replace -- if the upstream version
> is patched, you'd better (re-re-)patch your augmented version.
> 
> This keeps the amount of work to the theoretical minimum required to
> achieve your goals, costs you "nothing" (what does disk cost per GB
> these days -- $0.20 or thereabouts? -- so keeping a full distro costs
> you a few dollars, literally), and makes it extremely easy to track
> updates and upgrades without YOU doing a ton of work.
Usually when I build a cluster, I make local builds of MPICH2 for each
compiler. This does not fit well with the paradigm of really any distro
I've ever seen, which is why I leave it as a custom layer on top of e.g.
Debian and do not package it.

I have yet to see a distro do multiarch really well, so for the moment I
try to work around (or perhaps above) the system and avoid using APT/YUM
for handling multiple architectures/compiler toolchains.

> 
>     rgb
> 
<snip>

-- 
Geoffrey D. Jacobs