RE: CCIWG: 52 OSU OpenSource Labs (OSL) Planning Work - CORE SERVICES FOUNDATION
sp...@tenbus.co.uk
A lot to read & consider - I'll get my comments & ideas to you in the next day or so if that's ok?
-----Original Message-----
From: deborah shaddon
Sent: 16/12/2010, 18:02
To: CrisisCommons Infrastructure Working Group
Subject: CCIWG: 52 OSU OpenSource Labs (OSL) Planning Work - CORE SERVICES FOUNDATION
Looking for group feedback and thoughts on the proposed move approach
for OSL:
As you probably read in the CrisisCommons announcement, we will be
partnering with Oregon State Universities OSL for hosting of some of
our key CrisisCommons capabilities (outlined in the sloan proposal as
well as listed here). This is expected to be a long term engagement,
and our migration to this will happen 'over time'.
http://osuosl.org/about/news/crisis-commons-joins-osl
We've started some initial conversations with the OSL work to
establish the partnership and begin to understand their processes.
Essentially, we will supply some 'hardware' that they can virtualize
and manage for us (and allow us to manage if we want too), and support
capabilities for hosting of opensource projects (such as crisiscommons
itself as well as other 'true' opensource projects), and development/
staging servers, etc. I see this as a model of they will manage the
OS level resources, we can still manage our application level
resources and configurations. This will also allow us to put some
structure into our design and deployment processes by staging into
production, to achieve some stability.
To plan to utilize their environment properly and build a platform to
support our future efforts, some thoughts and considerations, and I
wanted to pose some of this to the community (again, this aligns with
some of the infrastructure-strategic model in the sloan proposal):
Our first order will be to establish and migrate some 'core' services
over, including
1) crisiscommons.org,
2) wiki.crisiscommons.org and
3) crisiscommons.org email.
*(crisiscamp.org will remain a redirect at this time).
But rather than take these 'as is', I want to incorporate the
following high level changes, as building block to the future. PLEASE
provide some thoughts and steps that you can think of for this, this
is meant to be JUST A START, but is focused on some
SystemAdministration sort of activities:
Highlevel Plan/Approach - CORE SERVICES FOUNDATION:
1. The Hardware/OS allocation: Planning for level of virtualization
and capacity (the hardware approach):
*Match of some capacity models against hardware we need to purchase
and how we allocate this (with consideration for future scalability)
*Decision on which linux variation we want (preferences? what do we
have today?)
*basic administration model we want at the OS level (we need to retain
some, but look to delegate as much as possible to them, but retain
some 'merit based' model of administration and control.
*Will identify monitoring and backup strategies.
*Leveraging some models of other OS projects in the OSL.
2. Some application 'services':
*We spoke of application management and common-ids. As such, we want
to leverage (most likely) an LDAP repository that our other components
(via apache basic auth configuration and plug-in integration
components for wordpress and mediawiki to sync ids). This will allow
SSO, and single-id, and we can leverage this for future components
*We can design this appropriately to allow 'seeding' (ie, conversion)
of the IDs from our current systems.
*Consideration also for LDAP and OpenID integration as well (ie, your
LDAP can be your openID).
*crisiscommons.org emails hosted as well, and ALSO tied into the LDAP
(?), but not everyone here would have an email (so policies as well).
*Anybody have any thoughts or conderations for this?
3. The 'Application Software' allocation - SETUP:
*So, we would have a central LDAP above, our own email hosted services
with integration, as initial platform.
*We spoke of breaking up DB servers from App-Servers (a common
practice, even of other OS projects in this lab).
*Continue with Wordpress and MediaWiki environment to start. Plugins
for LDAP, and Apache specific configurations for basic-auth and ldap.
*Do we want to do SSL on some of the pages, namely the login? Need
certificate management then too (and verisign, etc.).
4. CONVERSION and MIGRATION PLANNING:
*We will have to plan on how to do the conversion properly without
loosing content, and allowing for the integration of all this.
*database or export level conversions? What about other content or
settings (non-db?)
*We will want to setup a 'sandbox' of this environment above, to
represent our staging environment, and discover how to get to stage
from pre-prod to prod.
*And integrate into SCM system (which they also provide some basic
procedures and processes for locally).
5. ACTUAL CUTOVER.
*We should do just one system at a time instead of all-at-once (get
our feet wet with their processes and policies).
*How to 'cut off' content updates, etc.
6.ETC
