Implementation Plan May 19, 2009

Owned by Mike Wenk
Last updated: May 19, 2009 by James RenfroVersion comment
3 min read

Sakai Properties

Until tag prod-016-RC2 has passed, the sakai properties can be found at:
https://mware.ucdavis.edu/svn/ucd-sakai/sakai-properties/tags/sakai-properties-2-5-x-prod-016-RC2/




Personnel

  • Programmer is James Renfro
  • DBA is Prabhu Pilli
  • QC is Sandra

Preparation work

During maintenance window : May 19, 2009 : 05:00-07:00 - Time S is the starting time
  • (S + 0m Programmer) Put smartsite into maintenance mode and shutdown Sakai on all 7 application servers
  • (S + 2m DBA) Backup SAKAI_USER_PROPERTY, SAKAI_USER, and SAKAI_USER_ID_MAP tables from sakai internal schema
  • (S + 10m Programmer) Deploy sakai_2-5-x-prod-016 tag on sakaiprod1 via setup-sakai-node.sh
  • (S + 20m Programmer) Startup sakaiprod1 and check for errors - Specifically looking between the line beginning with: "Starting update of data for first sponsor" and the line beginning with: "Finished with updating of data for first sponsor." Please see the below notes for what this update does.
  • (S + 22m Programmer/QC) Veriifcation
  1. QC will view Melvin George's Grazing Managementand Carl Whithaus on Writing for numbers 2 and 3 below.
  2. Guest Activation view - to be sure all the same guests are still present
  3. Guest Management view - to be sure it works and shows the new fields.
  4. Make sure the Guest Management tool shows up in the course and project sites, for which
    there are guests.  QC will use Knowledge Base project site for this review.
  5. Make sure the roles that have permissions to be sponsors can view all the guests on a site via
    Guest Management.  QC will use Knowledge Base project site for this review.
  • (S + 37m Programmer) uncomment "ucd-guest.firstupdate=false" in sakai.properties in config-staging directory
  • (S + 38m Programmer) Stop sakaiprod1
  • (S + 39m Programmer) Redeploy sakaiprod1 using setup-sakai-node.sh
  • (S + 42m Programmer) Startup Sakaiprod1 - Check log for errors,
  • (S + 43m Proogrammer) Deploy sakai_2-5-x-prod-016 tag on the remaining 6 app servers via setup-sakai-node.sh
  • (S + 47m Programmer) Startup sakaiprod2, ..., sakaiprod6, sakaiprodmail1
  • (S + 49m Programmer) Take smartsite out of maintenance mode
  • (S + 50m) Check in production version of sakai.properties(with line uncommented)
Fall-back Procedure (If needed) Time D is the decision time made to fallback
  • (D + 0m Programmer) Shutdown Sakai on all 7 application servers
  • (D + 5m DBA) Restore SAKAI_USER_PROPERTY, SAKAI_USER, and SAKAI_USER_ID_MAP tables from backup
  • (D + 2m Programmer) Run ~/config-staging/tomcatclean.sh on sakaiprod1
    • rm ~/config-staging/sakai.properties
    • mv ~/config-staging/sakai.properties.015 ~/config-staging/sakai.properties
  • (D + 5m Programmer) Run mvn sakai:deploy from ~/src/sakai_2-5-x-prod-015 directory on sakaiprod1
  • (D + 15m Programmer) Deploy sakai_2-5-x-prod-015 tag on all 7 app servers via setup-sakai-node.sh
  • (D + 20m Programmer) Hold for DBA to finish restore of tables. New Time DH is the starting point of when the restore is finished
  • (DH + 0m Programmer) Startup sakaiprod1 and check for errors
  • (DH + 2m Programmer/QC) Check sakaiprod1 for proper tag/guest functionality.
  • (DH + 10m Programmer) Startup sakaiprod2, ..., sakaiprod6, sakaiprodmail1
  • (DH + 12m Programmer) Take smartsite out of maintenance mode
Notes on ucd-guest.firstupdate=false

Update process:

  • We push a security advisor allowing us to modify any user in the system.
  • For each local user in the system as returned by the user directory service we do:
    1. Check if its a guest access guest. This means the user type is not null, the user type is equal to "guest", and there are 1 or more properties that start with the key "ucd-guest:sponsorship:for:" If it is:
    2. We ask the UserDirectory for an edit object, if we get it:
    3. We scan the user properties that start with "ucd-guest:sponsorship:for:" for the sponsor that created the user initially(what I refer to as first sponsor) We then get the status that the guest is in relation to that sponsor.
    4. We then iterate though each user property that begins with "ucd-guest:sponsorship:for:", and set the state to be the state we found in #3.
    5. We then commit the edit to UDS.
  • After all users have been processed, we pop the security adviser we created.

Potential(known) exception points:

On calling UDS.editUser():

  • UserNotDefinedException - This would occur if the guest did not exist. Since we had just gotten this from the UDS, it should be impossible.
  • UserPermissionException - This would occur if the process had insufficient permissions to modify users. The security advisor we have pushed will take care of this.
  • UserLockedException - This would occur if some other process had called for an edit but didn't cancel or commit.
    • If this occurs, what will happen is the user will be skipped. A note will be made in the log. If the cluster is down, corrective action would be: Remove lock from SAKAI_LOCKS table, rerun update process via restart.

On calling UDS.commitEdit():

  • UserLockedException - I believe this is generated if you request to commit a new user(user ID is null) with an EID that already exists in the table. Since we are editi
    ng existing users, and not creating them, we should be OK.