Upgrading to Grouper v1.6.2 from Grouper v1.6.1
You should just need to use the latest grouper.jar in the module you are using (WS, loader, etc), replace the existing grouper.jar, and restart the service. For the UI if you want GRP-496, you will need to rebuild the UI.
Upgrading from Grouper v1.5.*
- You should get the latest v1.6 (e.g. v1.6.2) versions of the Grouper API, Grouper UI, Grouper WS, Grouper Daemon, etc. You will need to merge configuration files and JARs. See the change log for more information. The rest of this document focuses on upgrading the database.
- Once you prevent users from making updates to your Grouper instance, run the changeLogTempToChangeLog daemon to clear out the temp changelog using the v1.5 API. Here's an example using GSH.
- Before performing any upgrade steps, export your Grouper registry. Options include performing a database backup or using the xmlexport utility in Grouper. However this utility in v1.5 of the API does not support exporting and importing of the attribute framework introduced in v1.5, including permission management related objects. You can run the utility like this: ./bin/gsh.sh -xmlexport GrouperSystem backup.xml
- Using the 1.6.0 API, perform a registry check using GSH to create an SQL file that will contain the DDL to update your database. To do this, run: gsh -registry -check For instance..
- In this example above, an SQL script called /srv/grouper/ddlScripts/grouperDdl_20100604_15_41_14_838.sql was created.
- Review the script to make sure it looks okay. The script will be backing up, dropping, and recreating the table GROUPER_ATTRIBUTE_ASSIGN_VALUE. It will also drop and recreate views, some constraints, and some indexes.
- If using postgres, you should see foreign keys being dropped at the top of the script. If not, try setting the ddlutils.schema grouper.properties setting and run again. If you still dont see foreign keys being dropped at the top of the script, manually drop all foreign keys before running the script.
- If using postgres or hsql and 1.6.0, you might want to manually drop all your grouper views, since some depend on others, and the script wont do it
- If using postgres or hsql and 1.6.1+, you should backup any non grouper views that depend on Grouper views, run the grouper script (which deletes those views due to drop view cascade), and then you should recreate those non grouper views.
- If you are using mysql with certain international character sets, then change:
CREATE INDEX attribute_field_value_idx ON grouper_attributes (field_id, value);
CREATE INDEX attribute_field_value_idx ON grouper_attributes (field_id, value(960));
- If you are okay with the SQL script, execute using GSH again. To do this, run: gsh -registry -runsqlfile /path/to/sql/file.sql For instance..
- At this point, your DDL has been upgraded to v1.6.0. It should be safe to enable access to your Grouper instance now (UI, WS, etc). However, you should complete this next step before starting the Grouper Loader. Starting with v1.6.0, we're now populating a flat memberships table (along with other new dependent tables) to prevent duplicate notifications if a subject is a member of a group in multiple ways.
- First be sure you have merged your copy of grouper-loader.properties with the v1.6.0 copy and make sure that the changeLogTempToChangeLog daemon is enabled.
- Analyze your tables. At minimum, be sure to analyze grouper_group_set, grouper_memberships, grouper_groups, and grouper_stems.
- And finally, populate the flat tables. Here's an example using GSH.
- If the flat table sync appears to hang after starting to populate flat memberships, you may need to re-analyze your tables. This time, include grouper_flat_memberships as well.
- If you haven't in the past, you should probably enable the Grouper Report to run daily. The changeLogTempToChangeLog daemon will update the flat tables, but among other things, the Grouper Report this will sync the flat tables if they get out of sync.
- Start the Grouper Loader.