[volunteers] brie
Paul Reiber
reiber at gmail.com
Tue Apr 24 10:25:55 PDT 2007
I wrote:
> > If you'd like to hold onto it for a while, while you're working with
> > it (Moin! Woo Hoo!) just say the word & I'll wait for an "OK, I'm
> > done; you can have it now" email.
Heather replied:
> Yes, definitely. The list of TODO is brief but tasty:
I know I've already said this, but thanks again for your help with
this! It's great to see this becoming a team effort.
> * RAID config smarter setup + notes in /etc/sysadmin/README.brie
> -> avoid: hang on startup due to RAID outages or workbench time
Cool...
> * delink swaps so it's two of them => more vmem system bang for the buck
Yes, swap's currently mirrored. My thought was that this would allow
the machine to survive the failure of one or the other swap drives.
But I agree that the vmem gain is
probably worth it.
> * delink root fs => alternate root available quick rather than depend on
> RAID for it if RAID itself goes sour
> + including basic "obvious" sysadmin tools like less and vim..
> + faster than finding a RAID capable liveCD in a hurry, or at least
> only requiring one that can chroot you into this partition and whose
> kernel isn't a total loss...
Totally sensible. Two independent bootable root partitions... Sure!
> * examine what it's trying to do for firewalling/service defenses
> + first with a mind to knowing/finding what they already are
> + Daniel told me what he considers some of the defenses
> + other comments/preferences welcome *please* speak up if you
> have a strong opinion on this!
> + second to plan them for a service-defends-itself view
> e.g. cymru style config + chroot for DNS, smart settings for apache
> + third so we're all agreed on what they ought to be before really
> nailing it down and shoving it back in the cage
> -> avoid: locking ourselves out of our own box.
We've taken no special steps so far regarding security/defense. It's
a straight debian install. Yes, there have been brute-force attacks
against brie but AFAIK none have succeeded. A solid defense plan is
REALLY important for this. And, yes, let's ensure
that we can connect remotely before we reinstall it!
> * iff you folks are interested I can check the imprinted version on the
> motherboard and see if it can take more memory than it presently owns [...]
If you'd like to... sure, see what it can handle. We will need to run
a memtest on whatever you're adding though - hopefully letting it test
for a day or two before we return it to the colo.
> * which services are supposed to be on this thing? I can checklist through
> them all while I've got it.
> * proper python, current moin, yes Rick I will make sure there's a bloody
> easy and obvious upgrade path. /usr/bin/update-moin possibly :)
> * Other than obviously mailman* did we want other webby apps in?
It'd be cool to have some sort of web-based system monitoring. The
first goal is to duplicate/replace what's being served on
svlug.svlug.org using brie and the linode host.
I talked with Lisa about this - she seemed to think it was
straighforward, so maybe it is... I'd love to see us use either the
old machine or one of the new ones (or all of the above) as
virtualization servers. If we could get to the point that we have
lab1.svlug.org lab2.svlug.org and lab3.svlug.org as virtual hosts
that'd be awesome. Then people can install various "webby apps" on
there with relative impunity.
> Good weather willin' and the creek don' rise it may be feasible to get it
> back in the cage this weekend*. [...]
This weekend or next is awesome. No rush - let's get it done well
rather than fast.
> Hey, it's fun, and needs doing :)
Yup! It is fun... and even more fun with a team helping out. Thanks again!
-Paul
More information about the volunteers
mailing list