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

[jim stockford]

tho'ts re the current box, its policies and maintenance:
* there's a new box a-comin': ETA about three weeks. this
will be a 1 U to replace the tower that's there and it gives
us an opportunity to tighten up the policies and user
access to reduce possible threats to up-time.
* ServePath allows on-site maintenance, including carts
with KVM and tools. Only three persons are allowed on
the access list, but their names can be changed with
about 24 hour notice. Response to problems is on us,
and if we have three persons who're willing to respond
quickly and have the abilities to remedy problems, we're
"cool".
* there's yet another new box a-comin' to be available
for shell accounts for the unwashed. That'll reduce the
threat of someone inadvertently wedging the system and
provide a backup machine in a different physical location
(box-2 won't be at ServePath but probably at SFCCP).
* I might be able to get BALUG onto the host that provides
an alternate site for SF-LUG. My promise to the alt site
is polite citizenry and low CPU requirement: SF-LUG
has a single, static page on the alt box that is a copy
of the top-level page on the ServePath box, but that's
good enough to keep us visible in the case of problems
with the colo box.
* and, best of all, this move provides an opportunity for
simplifying the BALUG web site, just in case anyone
likes the idea of simplicity.
jim



On Sep 5, 2007, at 5:19 AM, Michael Paoli wrote:

> 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 -----
>
>
> _______________________________________________
> Balug-Admin mailing list
> Balug-Admin@lists.balug.org
> http://lists.balug.org/listinfo.cgi/balug-admin-balug.org
>