Quoting Larry Platzek:

Any good words as to the gathering of data from the old balug website ?

Not worried as to the putting up on new site just knowing we have the data would be very good news.

Well, here's a bit of status update on that and related website/list/wiki stuff (mostly relative to information noted earlier on: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-May/000369.html )

In not necessarily any particular order:

It seems, at least, we've regained access to the raw data, and should have the access necessary to fix the broken stuff.

Any PHP and MySQL volunteers? If anyone wants to volunteer a bit of consulting advice with PHP and/or MySQL, that could speed some things up slightly. Nothing all that major to do, but those aren't exactly my expert fields and I'll otherwise manage to muddle my way through them anyway. Mostly just need to dump some MySQL data - and preferably in most useful/portable format(s) feasible - e.g. we(/I) may not be reloading that data into MySQL, but may want to process and pull out relevant bits via perl or other means ... though reloading into MySQL might also be a possibility. There's also some (slightly) broken PHP stuff to fix (or diagnose and make a "fix" recommendation). Presumably (my best guess) the PHP stuff was all working with the same, or a slightly older version of PHP, and changes in PHP version and/or some minor goofs in some PostNuke PHP web data have gotten the "old" stuff to the point where it's effectively quite non-functional ... but it's probably not all that horribly difficult to fix ... at least enough to usefully extract information - which is key objective. Anyway, if some person(s) want to volunteer a bit of assistance/consulting on MySQL and/or PHP, that might speed the processes up slightly.

Other bits and pieces. List archives and subscribers - I've generally been backing that up monthly (have backed up through April - need to also backup June to be a bit more caught up). That covers us *fairly* well for the lists - but doesn't cover subscriber passwords, their preferences/configurations, etc. Some of that can be gotten via administrative web interface, other bits (if we can and want to go to the trouble) are probably tucked away inside of MySQL (since the list software can e-mail subscribers their current passwords, those passwords - or decryptable form thereof - must reside in there somewhere).

DNS is coming along fairly well - infrastructure is in place, have one solid slave service in place, and good offers for additional slaves - will probably add about two more slaves or sets of slaves. Will also have to make registrar delegation changes at some point ... will probably start working towards that soonish - so delegation can be transitioned smoothly, and so that we'll know we can fully move off of DreamHost when we're fully set to do so (or sooner if we end up having to, for any reason).

Wiki - thus far I haven't really set up much new wiki stuff - I think it's important we do so at some point, but mostly not among the highest priorities. I did set up at least a "temporary" location and URL for a BALUG speaker coordination wiki page - as that is of rather immediate use - and doesn't matter a whole lot if the URL for it changes later. The rest of the wiki stuff can probably wait.

I've been fairly busy the last couple weeks - so progress on moving from the "old" to the "new" hasn't been moving along quite as swiftly (e.g. development on the "new" happened quite a bit in much of May, but hasn't moved quite so swiftly most of this month).

e-mail - lots of @balug.org e-mail addresses/aliases were set up, most notably there are a few contact ones noted on the main BALUG web page which are quite functional and now very well under our control.

Rough synopsis of "to do" items, and approximate order/priority to attack them:

catch list backups up through May

snag "just in case" backups of the old balug stuff (much less work to fix the broken stuff in place, and suck out what we want from the old web pages once fixed - but a "just in case" backup should be made in case we lose access, so we at least have the data to potentially extract the stuff from).

set up the "new" target e-mail infrastructure

set up the "new" target list infrastructure (e-mail infrastructure is prerequisite)

get regular automated off-site backups in place and operational

move list stuff off of DreamHost - retaining archives, subscribers, and as much backwards compatibility as feasible (URLs to archives, subscriber preferences and passwords, etc.)

"fix" old web stuff, suck out all the pieces we're interested in (e.g. meeting writeups of past several years, and other useful pages of information), then complete migration off of DreamHost.