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
- 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)
- 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