Note | ||
---|---|---|
| ||
Until tag prod-016-RC2 has passed, the sakai properties can be found at: |
Note | ||
---|---|---|
| ||
This deployment plan is a preliminary plan to deploy: SAK-2720, SAK-2683, SAK-2625, and SAK-2743 |
Personnel
- Programmer is James Renfro
- DBA is Prabhu Pilli
- QC is Sandra
...
- (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:
- 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:
- We ask the UserDirectory for an edit object, if we get it:
- 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.
- 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.
- 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.