Current state of affairs -

As of 5/25/07:
As the rollout date firms up, discussions with the Software Release Team regarding release of new versions of Gaim/Pidgin and Adium X clients resume.

As of 4/17/07:
New content for service web-page sent to Heather Harrison

As of 4/11/07:
Mapping between kerberos principles and JIDs complete.
Auto-creation of accounts for new, authenticated users complete.

As of 3/21/07:

Java authentication complete.  Greg and Dennis working through the legal agreements for passing the code back upstream.

Conversation with Library about Click-for-Chat support solution promising for roadmap.   

As of 3/7/07:
    A Jabberd2 service is currently up and running, and Gaim clients available to the MIT community for Windows, Mac, and linux operating systems.  This system has not been extensively load-tested, but adoptin rates have not been high.
    Jabberd2 has no upstream support.  This makes it a poor candidate for future development of additional features.
    Investigation of several alternatives led to the acceptance of Jive Wildfire/Openfire as an acceptable XMPP server for MIT, and a sandbox has been set up for the pyurpose of development and testing.

Tasks for Migrating from jabberd2 to Wildfire/Openfire (Times are Greg's esitmates of calendar time):

  1. Creation of pure Java password authentication.
    • (time: approx 1 week) - Complete
  2. Define and implement a mapping between Kerberos principals and JIDs.  For regular users, this is trivial (ghudson@ATHENA.MIT.EDU maps to ghudson@mit.edu), but for principles like host/small-gods.mit.edu we have to pick a corresponding XMPP node ID.  So far, no standard for this has been discovered.
    • (time: Approx 1 week) - Complete
  3. Develop a local change to auto-create Wildfire accounts for new users who have successfully authenticated.
    • (time: Approx 2 weeks) - Complete
  4. Develop a script for data migration of the jabberd2 database to the Wildfire, and back again.
    • (time: Approx 4 weeks, unless database-savvy resources become available)
  5. Perform some basic scaling tests, for number of connections, cycling connections, chat rooms with large numbers of participants, and so on.  This might be done in parallel with (4), if sufficient resources are available.
    • (time: unknown, as QA of such is not a specialty in-house)
  6. Other acceptance tests?
  7. Identify any last-minute details that have to be dealt with (using the right TLS certificate, etc)
  8. Pick a low-useage window for the migrations.
  9. Attempt the migration, and see if the world falls over.
  10. Expected hand-off to operations - mid-July 2007
  • No labels