[Incubator] Infrastructure Migration

[Howard Butler]

On Sep 24, 2006, at 3:09 PM, Jo Walsh wrote:

> dear Frank, incubators, your patience ongoingly is appreciated.
> On Sun, Sep 24, 2006 at 12:28:10AM -0400, Frank Warmerdam wrote:
>> 1) The tables don't address how we will manage DNS.  Will we aim to
>>    preserve the large set of subdomains we have now?  Will we use  
>> some
>>    sort of DNS front end?  Any idea if there are issues on DNS  
>> management
>>    while we are transitioning?
>
> Hobu suggested that DNS should be managed entirely by a third party,
> OSGeo delegated people have web admin access to manage subdomains.
> and I would agree with that completely. I definitely want to
> rationalise the subdomain sprawl now existing but attempt to preserve
> what is there. One small element I want to contribute to this is a
> simple domain / URI audit tool of what OSGeo is now running and where
> things get moved to. http://wiki.osgeo.org/index.php/URI_Migration_Map
> is an aging sketch of what I envisioned moving where.
>

I think the phrase I used when describing this to Jo was "GoDaddy,"  
but that was to merely express the sentiment, not prescribe the  
cure :)  Maintaining our own DNS would be a PITA, and it would be  
much easier to have more than one person point DNS aliases if we have  
some sort of web admin to do it with.   This approach also gives us  
some redundancy in the event that our server were to blow up or a  
water pipe were to break ;)

> DNS is in Gary's name, Jason B was happy to become technical contact.
>
>> 2) You show handling LDAP and DNS near the end of the transition
>>    strategy.  It seems to me we will need some sort of DNS handling
>>    mechanism pretty soon (perhaps just depend on CollabNet till  
>> later?)
>>    Further, if we are serious about "single signon" it seems like we
>>    should be handling LDAP before the services that depend on it  
>> (CMS,
>>    bug tracker, svn).  Perhaps your LDAP item is when we migrate  
>> it to
>>    OSL?
>

Most of the services to be provided depend heavily on DNS... virtual  
servers in apache, LDAP schema locations, maillists, etc.  A clean  
migration will be very challenging with the tight DNS integration in  
CN... The new services would probably need to be built up on some  
other domain and slowly migrated back to osgeo.org as we ween  
ourselves away from CN.  It has potential to be highly disruptive,  
needs to be thought through carefully, and be started earlier rather  
than later (isn't this true for all things :)

One thing the document doesn't discuss is the prioritization of  
rollout.  Here's my rankings:

1) DNS
2) Maillists (+ migration of lists, archives, and subscriptions)
3) LDAP (+ some sort of web administration facilities)
4) Apache + SVN + LDAP Authentication (SSL for SVN only unless there  
is a use case for using it pervasively like CN does)
5) CMS (creating a user in the CMS also needs to create an LDAP user)
6) Wiki (just a DNS alias for now, leave it on Terrestris.de for the  
time being)
7) Bug tracking (how big of a load is the migration of stuff from  
Issue Tracker in CN?)
8) Downloads, smoke testing, etc.

1) DNS
Host this somewhere else.  Identify a hosting provider and acquire a  
temporary (and similar) DNS name we can use for bootstraping the  
migration

2) Maillists
We need mboxes of all of the lists for the message archives to drop  
into mailman.  Need subscription lists (unless we are willing to have  
everyone resubscribe, which is not always a bad thing) to feed into  
mailman if we are going to automatically resubscribe everyone.

3) LDAP
Out-of-the-box OpenLDAP+SSL.  Need unix (posix) account schema and a  
LDAP group layout.

4) Apache + SVN + LDAP Authentication
Easy once 1-3 are up and running.

5) CMS
Special considerations for authentication and database(s) used for  
CMS.  Otherwise, should be fairly straightforward.

6) Wiki
Hold off on moving this until things stabilize (other than move a DNS  
record)

7) Bug tracking
Some folks hold their bug trackers very dear.  I have experience with  
Bugzilla->Trac migration and Trac customization.  Any bug tracker  
that is chosen will have an administration load that is probably the  
second or third largest item on the admin's duty list (Maillists  
being #1 and CMS babysitting being #2).

8) Hold off on these until everything else is up and stabilized (and  
DNS is migrated).

Backup, redundancy, and off-site synchronization needs to also be  
discussed (I assume TelaScience is the first home for this stuff...  
could be as crude as a simple rsync to start).


> Nod, depending on CN until in a position to move the zone files.
> Imagining some osgeostaging.org type domain to mirror the setup with.
>
>> 3) Is the design/interaction development someone to work on Drupal  
>> addons
>>    and so forth? Is the system administrator doing essentially  
>> everything
>>    else?
>
> I hope this would result in a generic design/layout plus CSS, UI
> elements etc that can be reused across different OSGeo affiliated  
> sites -
> for projects hosting themselves, for the wiki, for local chapters.
> It wouldnt be drupal focused though that provides an easy environment
> to sketch things out in.
>
> Despite the fact that this plan includes a couple months sysadmin time
> (overkill) to work on setup, security, fiddly integration issues, that
> wouldn't prevent anyone else who felt like mucking in from adding to
> or working on any resulting toolset. Right? Or am i such a mug?
>
>> The plan looks promising, and I hope we can get it launched soon.
>
> Thanks, Frank; regrets that this is coming down so close to the  
> wire...
>
> cheers,
>
>
> jo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>
>
>