Stanford University, Academic Computing

Owned by Former user (Deleted)
Last updated: Nov 20, 2007Version comment
3 min read

CourseWork team:

  • Management
    • Makoto Tschuanti
  • Developoment
    • Lydia Li, Dev Team Manager - Samigo Lead, CWC->CW5 Assessment Migration, CW Classic, Stand-alone Syllabus developer
    • Jing Wei - CW Classic, CW Classic-Archive, CW5 Syllabus, Stand-Alone Syllabus developer, CourseForum (Term contractor, term is expiring Winter 07-08)
    • Daisy Flemming - Samigo, iTunes, CW5 Syllabus developer (retired)
    • Karen (Hui) Tsao - Samigo
    • Former user (Deleted) - Integration Lead developer (direct report to Makoto)
    • Annika Rogers - long time Stanford Contractor, Migration "anchors" and 1st content pass. (not currently engaged)
  • Quality Assurance / Second Tier Support
    • Mary Mak - QA Lead
    • Huong Quinn - part time QA, various bits of Samigo
    • Margaret Petit - QA (UserX)
    • Laura Burchard - QA, Load, Build, Automated testing (UserX) (not currently engaged)
    • Nora Fong - QA, CM, Sync, Realms, Permissions, Builds
    • Jeff Vance - QA/Dev (very part time) BIRT, Load, Automated testing, "SOPI", Python maven (Floats Around Looking For Work)
    • Asoko - part time QA, migration, Languages
  • Operations
    • Julian Morley - sysadmin, very busy
    • Sandor Sklor - sysadmin, backup to Julian, Oracle hardware sysadmin, fractional engagement
    • Sam N - Oracle sysadmin/DBA, fractional engagement
    • KAM - fractional engagement, SAN
  • User X / Second Tier support
    • Marc Brierley - User X manager
    • Jackie Mai - Support and Marketing and Design (UserX)
    • Julie Mai - Support and Marketing and Design (UserX)
    • Christine Doherty - Support Czarina / First Tier Support

Status:

We are running a vendor drop of 2.4.0, with many 2.4.x patches manually applied. We've implemented an almost stock Course Management 2.4. We have modified Worksite Setup and the Login sequence a great deal. Modifying the Login sequence was necessary to avert total system meltdown during Fall 2007.

Integration Points:

Stanford University's Academic Computing department has Sakai integration points of:

  • Authentication in production, excluding Shibboleth
    • WebAuth to Kerberos (K5), using Sakai container authentication in production
      • allows for quick sysadmin mods to .htaccess type files for security changes
      • basic Sakai container auth is a well known practice.
    • direct K5 auth SKrbLDAP in production
      • provides Auth for WebDav, for non-Apache/WebAuth deployments (such as my MacBook Pro)
      • the DAN comes from Sakai's bundled Kerberos UserDirectoryProvider (UDP)
    • LDAP lookup in UDP in production
      • maps LDAP attributes to Sakai user type, populates additional Sakai user properties
      • allows us to drop WebAuth Apache from our service stack, fewer moving parts
      • define LDAP attrs to pull in prop file
      • why?
        • Stanford users can have multiple email accounts. They don't have to use the one associated w/their Kerberos identity (foo@stanford.edu). Base accounts won't even have Stanford email services.
        • to map Stanford Workgroups to Sakai User type templates; this means custom user My Workspace pages based on the users affiliation to the University.
      • does K5 auth via keytab
    • Shibboleth ( currently unscheduled )
      • planned grabbing of REMOTE_USER and additional remote affiliation information from HTTP request, mapping to Sakai User Template types, stuffing into User properties.
        this is rather a simplistic view, and we'll probably have to be tricker, with call backs to the IDP or whatever it's called (wink)
        However, since this design has our SSO WebAuth in front, and another team is going to implement the WebAuth / Shibboleth hooks, I'm not going to worry about it. Identity and transience of Identity will be a common issue for all Stanford Shibbolized Sites.
  • Stanford Groups
    • AFS PTS groups, various needs
      • K5 remctl interface to existing enterprise API
    • Majordomo mailing list groups
      • K5 remctl interface to existing enterprise API
  • Stanford PHPBB CGI service aka CourseForum
    • K5 remctl interface to existing enterprise API
    • projection of Sakai Realms -> AFS PTS groups
    • projection of Sakai Rellms -> Apache .htaccess / .htadmin files
  • Bulk Load of Classes into Course Management API in production
      • on demand load of Instructors/Courses/Classes/Sections, digested into Course Management 2.4 tables
      • Quartz scheduled synchronization of Stanford CourseClass/Offering/Sections & all associated fleshy units
    • XML Feeds of Registry Course Information
      • custom Course doc format
        • membership
          • sunetid, name, university id, registry id, enrollment status
        • basic roles (instructor/student/TA)
        • cross listings
        • official sections
        • location, times
        • organizational ownership percentages
        • enrollment state (open, closed)
      • certificate based HTTPS transaction
      • ad hoc and scheduled
  • Integration with Legacy CMS (CourseWork)
    • bulk import of historical data
      • extended roles (above, plus TA, Course Designer, course admin, department admin)
      • syllabus
      • schedule
        • Stanford, being a Quarter based school, has an easily re-usable "year to year" Class schedule tool. It's based on numbered weeks...
      • content, all types
        • content copyright state
        • content release vis course schedule
      • assessments, past grades
      • ad-hoc sections (very useful)
      • ad-hoc cross listings
  • Nagios in production
    • surface monitoring
    • transaction viability monitoring
  • CourseWork grade notification and logging abandoned
    • internal fatal errors to newgroups and pager lists
    • intrasystem 'touchpoint' failure alerts
    • logging of administrative activities
    • logging of authentication
  • Stanford Email services
    • play-fair in production
    • get spam filtering for inbound
  • Stanford news groups
    • use existing newsgroups Summer 07
    • needs remctl and roster info, no biggie now.
  • existing Stanford WWW
    • (not much to do here, external links. content management instruction is the issue here. the remctl APIs above will take care of the brute mechanics.)
  • Indigo Project (iTunes)
    • secure rich media w/DRM\
  • Stanford Event Feed Spring 08
    • changes in SIS are paralleled with event postings to custom enterprise backplane (which is due for replacement)
    • changes in CourseWork-Sakai should publish to same backplane long term
    • mucho delay from enterprise group.