[Balug-Admin] Fwd: beta.balug.org. (?) and other useful ideas?

[Michael Paoli]

Originally sent to the BALUG contact, webmaster, and sysadmins aliases,
presented here slightly redacted:

----- Forwarded message from Michael Paoli <Michael.Paoli@cal.berkeley.edu> -----
    Date: Fri, 31 Aug 2007 20:10:35 -0700
    From: Michael Paoli <Michael.Paoli@cal.berkeley.edu>
Reply-To: balug-sysadmins@balug.org
 Subject: beta.balug.org. (?) and other useful ideas?
      To: balug-contact@balug.org, balug-sysadmins@balug.org
      Cc: balug-webmaster@balug.org

Anyway, a couple of (random?) thoughts/ideas that may be rather to
quite useful - or perhaps at least so in part.

A) beta.balug.org.?  One of the issues that's been going on for a
while is the "tension" between:
Preserve/restore all the useful old stuff as much as feasible (and
move it to new appropriate manageable home) - even if it means lots
of newer/spiffier stuff is deferred for quite a while
and:
The heck with that, let's run from that old unmanageable mess as fast
as possible even if we have to give up trying to save any of the old
stuff, just start fresh, and kiss the old stuff bye-bye.
One possible approach (there may be other approaches that would do
similarly) on that that may rather substantially well cover *both* of
the "competing"/"/conflicting" objectives might be roughly as follows:
a) create beta.balug.org.  We can mention/promote it on
www.balug.org. (e.g.  link to cool stuff on beta.balug.org. that
isn't available/feasible to do (yet anyway) on www.balug.org.) - but
continue to present core useful information on www.balug.org. (and
presumably likewise include that or quite similar content on
beta.balug.org.)  We can create a separate beta.balug.org (highly
analogous to how we've created new.balug.org ... doesn't even have to
be on the same system ... could be anywhere).  We could go
*relatively* hog wild on beta.balug.org., but we'd want to observe a
few "restrictions" ... just enough that would
1) allow us to later smoothly integrate www.balug.org. and
beta.balug.org into a smooth homogeneous unified www.balug.org. and
2) provide *reasonably* consistent information between www.balug.org.
and beta.balug.org. (e.g. we don't want them providing conflicting
information)
1) would mostly involve some relatively simple rules on URL
construction, such that in the future we could redirect
http[s]://beta.balug.org/<whatever> to
http[s]://www.balug.org/<whatever> and users(/bookmarks/search
engines) would find essentially that same content they were looking
for at the beta URL that would be then getting (301 "permanent")
redirected (at some future post-unification date and time).
Using this type of a beta.balug.org. approach could help us well
cover both of the "competing" (save, preserve, and move, vs. drop and
run) approaches on dealing with the "old" (DreamHost.com hosted)
stuff.  The name(s) used needn't be specifically and precisely
beta.balug.org., but we would want to pick exactly what name(s) we'd
be using quite carefully and with due technical and other
considerations.  Our DNS limitations with DreamHost.com impose some
slight restrictions (we can't pick completely arbitrary names), but
as long as we avoid name conflict with DreamHost.com DNS names (that
are more-or-less effectively "mandatory" with a domain hosted there),
we're relatively free to pick a name, and can delegate it via DNS -
quite like the case is presently with new.balug.org.

B) Additional colo box(es)?  <redacted> may have a bit
more to say on this.  There was some talk(/offer?) of providing a
(possibly virtual) new/additional host for BALUG (presumably in a
colo, or other reliably hosted infrastructure/location).  While at
first reaction I may have stated/thought "Naw, we really don't need
that, have the old stuff we're moving off of, and have stuff we can
share and do on the SF-LUG.com box", since then my thinking and
opinion has shifted, mainly because
a) once we're finally and completely moved off of all DreamHost.com
hosted, that would leave us with exactly one system ... though we may
have backups of stuff elsewhere, it doesn't give us a highly reliable
infrastructure (one significant booboo <redacted> or a significant
hardware problem, or long maintenance outage, etc.), and that box
could be effectively blown out of the water for days or more - and it
could be quite a while before BALUG on-line infrastructure was
operational again (approximately up to days or more).
b) It would be quite nice to have BALUG have a much more robust
infrastructure set-up.  E.g. two independent systems (either or both
of which could be virtual, or shared resources on a common box, so
long as the two systems were highly independent (not both on same box
or at same location)), so that BALUG infrastructure could continue to
function at least reasonably, and perhaps identically or nearly so,
if either system were to suddenly become unavailable for a while
(even a fairly long while).  As a random comment, I'll also note that
this is (or will be) much more an issue for BALUG, than SF-LUG, as
SF-LUG has two systems (SF-LUG.com and SF-LUG.org - highly
independent and separate systems).
Anyway, being able to reasonably gain a substantially independent
system, that could be used for redundancy, failover, etc. could be a
really good thing for BALUG - especially as and when we move fully
clear of DreamHost.com

----- End forwarded message -----