[Balug-Admin] BALUG web site update (infrastructure, etc.)

[Michael Paoli]

I think it's been a while since I put a bit of information on the list
about some of the infrastructure updates.  Anyway, though perhaps a bit
slow, some of the plans are continuing to well progress.

Most notably, as of quite recently (this weekend), at least a fair
number of the earlier plans have now been implemented (though I should
still round out and catch up on some documenting of it, but hopefully
it's mostly relatively self documenting (e.g. those that have the
access to change the relevant stuff generally also have the access to
at least read the configurations to see how most, or nearly all of the
pieces are tied together)).

Anyway, webmaster (I'll use webmaster to refer to webmaster(s)) should
have significantly improved access to be able to change stuff -
including the production [www.]balug.org - at least indirectly, anyway.

Starting from production [www.]balug.org and working backwards ...
There's now in place a crontab driven rsync script, which propagates
appropriate changes from [www.]new.balug.org to [www.]balug.org.
[www.]new.balug.org is essentially pre-production staging area - stuff
dropped there gets propagated to production ([www.]balug.org.) within
approximately 15 minutes or less.  webmaster has rather free reign over
the contents of [www.]new.balug.org.  Also, to avoid unintentionally
clobbering legacy stuff in production (from which we still wish to
extract some important content), various filters are in place on the
rsync to prevent accidental clobbering, and also, in the DocumentRoot
for [www.]new.balug.org, various ownerships/permissions are set such
that webmaster can't place something where it couldn't be (safely)
propagated to production.

So, ... effectively, webmaster has relatively free reign in
[www.]new.balug.org and that automagically propagates to production.
This also affords a fair amount of safety and security, as the present
production environment is rather fragile (there's no easy way to
separate out webmaster and sysadmin roles in the present production,
and the effective sysadmin access could easily by accident or intention
destroy lots of stuff there that would be infeasible to impossible to
restore/correct - we hope to more fully correct that situation in the
future, but that's at least where we still stand presently - at least in
part).

Then there's also [www.]beta.balug.org.  There are actually multiple
levels of webmaster - one level that has access to do stuff that
propagates to production, and one that doesn't.  Only the lower level
of access is required (at least presently) to change stuff in
[www.]beta.balug.org.  At least presently, similar to
[www.]new.balug.org. it has various ownerships/permissions in place
such that webmaster can't place something where it couldn't be
replicated to [www.]new.balug.org and propagated to production.
[www.]beta.balug.org may also be highly suitable for placing stuff we
don't presently want propagated to production - e.g. for larger
archival materials (such as audio recordings of past meetings) where
due to space it may not be advisable presently to copy those to
production - but we can well accommodate those larger items in
[www].beta.balug.org.

There's also [www.]test.balug.org - a scratch/test area.  webmaster has
even fewer limitations there - e.g. permissions/ownership allow
webmaster almost completely free reign in the DocumentRoot of
[www.]test.balug.org.

Anyway, much of this is done via the following various mechanisms:
* Apache NameVirtualHost configurations
* appropriate separation of roles/users/groups, use of sudo, etc.,
  e.g. the DocumentRoot for one of the webmaster IDs/roles:
  $ id; ls -ld .
  uid=10742(balugwm2) gid=10742(balugwm2) groups=10742(balugwm2)
  drwxrwsr-t  4 root balugwm2 4096 Nov 11 20:39 .
  $
* along with carefully crafted IDs, access, and ssh configurations, some
  carefully crafted crontab driven rsync scripting, e.g.:
  http://www.balug.org/.www.balug.org_rsync.txt
  (it's not actually run from that location, but the script is readable
  from there to aid webmaster in understanding exactly what's happening
  in production and how things propagate from [www.]new.balug.org to
  [www.]balug.org)

A fair bit of the communication has also taken place off-list, but
here's some more bits of earlier on-list communication references:
http://lists.balug.org/pipermail/balug-admin-balug.org/2007-September/000409.html
http://lists.balug.org/pipermail/balug-admin-balug.org/2007-September/000410.html