[SAC] Backup and migration ideas

[Tyler Mitchell (OSGeo)]

Hi all,
There are a couple systems related ideas on my mind for a while and I 
wanted to put them past you for your thoughts, ideas, critique.  In 
general, I've been digging into our options for hosting at 
http://www.osuosl.org and a few ways we could capitalise on the 
opportunity without making too much work in the short term.

1 - Migrate services from osgeo2 to OSL.
This is likely the simplest server to move over and has the added 
benefit of reducing our costs by around 50%.  In some ways we've maxed 
out osgeo2 and upgrading is not cheap.  I suggest we focus on building 
on a new secondary server
 * Systems affected: wiki, planet, rsync backups from other servers, 
development Drupal sites, others?
 * Challenges:  LDAP auth back to osgeo1 needed?, others?

2 - Mirror project websites onto OSL.
If successful, then potentially switch over to the new server where 
appropriate.  My particular interest here is to have all main OSGeo 
project websites served in a managed server environment.  Hosting these 
onto osgeo1 typically opens up security questions.  We may be able to 
get VMs for each project or use LDAP shell authentication (like on some 
xblades) to handle the various projects in the same VM.  Could also open 
this up to include projects not hosted on OSGeo infrastructure, even 
just static mirrors.
 * Sites affected: gdal, grass, qgis, geotools, mapserver (?), 
geonetwork, mapbender, ?
 * Challenges: several different platforms, shell authentication, ?

3- Build upgraded osgeo.org site on OSL machine.
Wolf and I have discussed a Drupal upgrade over the next few months that 
should fix a few things.  Building it on a new system has some 
advantages when upgrading all our modules, etc.  I already have an 
account and Drupal set up on an OSL machine for testing.
 * Sites affected: www.osgeo.org, mapguide, fdo, mapbender
 * Challenges: tbd

This is probably enough for now.  Here's my summary:
 #1 is less critical but can save some money right away.  It's 
moderately difficult to complete but fortunately is a small set of services.
  #2 is the most critical in my mind.  It may also be the hardest to 
implement, needing a pretty clearly laid out set of dependencies and 
some get sysadmin assistance.   Depending on how it's realised, some 
project leads may be able to handle their own needs if we get the 
relationship with OSL set up well enough (and have LDAP auth stuff 
working from there)
 #3 is already pretty much set up and will be on Wolf and I's plate to 
handle anyway.

Anyone interested in helping or pursuing or debating these?  I'm mainly 
just brainstorming, but trying to envision some compartmentalized ideas 
out for discussion.  Obviously we'd need owners for each part.  The 
value I see in doing some of the switches is worth it for me to help, 
but obviously I cannot maintain it over the long term.  Perhaps others 
might like to join SAC to help see some of these through if there isn't 
enough volunteer power??

Looking forward to your thoughts,
Tyler