Page Comparison

Personnel

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

Preparation work

• (Programmer) Create final prod 16 tag from lastest Release Candidate
• (Programmer) Build sakai_2-5-x-prod-016 on sakaiprod1
• (Programmer) Deploy correct initial sakai.properties to config-staging
  • mv ~/config-staging/sakai.properties ~/config-staging/sakai.properties.015
  • svn export https://mware.ucdavis.edu/svn/ucd-sakai/sakai-properties/tags/sakai-properties-2-5-x-prod-016/sakai.properties
• Please see https://confluence.ucdavis.edu/confluence/x/moOb for general build instructions
  • https://mware.ucdavis.edu/svn/ucd-sakai/sakai-properties/tags/sakai-properties-2-5-x-prod-016/sakai.properties

...

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.