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... http://lists.balug.org/pipermail/balug-admin-balug.org/2007-September/000410...