[Balug-admin] Any good words as to the gathering of data from the old balug website ?

[Michael Paoli]

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.