Grouper Users - Open Discussion List

[Scott Koranda <>]

Hi,

I have not upgraded from 2.2.x to 2.5.x, but I did just successfully
complete an upgrade from 2.3.x to 2.5.x.

The strategy I used was to begin by fully patching 2.3.x. I then did an
"in place" upgrade to 2.4.x using the grouperInstaller.jar. Once I was
running a fully patched 2.4.x I then converted from using a subject
sources.xml file to a subject.properties file and make sure my 2.4.x
still worked. Next I converted to using the database to store
configuration, so that the only remaining configuration in files is
grouper.hibernate.properties and morphString.properties.  At that point
transitioning to running the 2.5.x container was straightforward.

There were a few issues to watch out for during the conversion:

- I found it worked better to "fix" any collation/character set issues
  before the upgrade process began. The 2.3.x deployment was not using
  character set utf8 and collation utfb_bin (this is a MySQL/Maria DB
  deployment) so I made those changes first.

- I found that after upgrading the core I needed to be careful during
  the UI and WS upgrades to make sure I did not ask the installer to
  schema check the database. While it seems that the schema
  check/upgrade process should be idempotent, I ran into unexplained
  errors. The process was smooth when I just did that initially with the
  core and then was careful to skip it with the UI and WS.

- After the 2.3.x to 2.4.x the UI would not initially work because the
  installer created an extra 'grouper' directory in the UI layout under
  
  .../dist/grouper/WEB-INF/lib

  I had to move the files in that directory up one directory before the
  UI would run.

- After the 2.4.x upgrade before you start to upload configuration files
  into the database you will probably have to edit grouper-ui.properties
  and add the line

  grouperUi.configurationEditor.sourceIpAddresses = <your CIDR here>

  to give yourself permission to use the configuration editor.

- I found I needed to copy the file grouper-ws.properties from the WS
  part of the 2.4.x deployment tree into the UI part of the 2.4.x
  deployment tree in order for the configuration editor in the UI to
  work. I think this is a known issue and will be fixed in an upcoming
  release.

- You can use the grouperInstaller.jar to do the conversion of
  sources.xml to subject.properties.

- This deployment used LDAP as a subject source and the details about
  that deployment (bind DN, and so on) survived from sources.xml to
  subject.properties, but after the upload of subject.properties into
  the database configuration I needed to make some adjustments because
  the way an LDAP subject source is configured is different now. You
  need to enter the LDAP connection details in
  grouper-loader.properties in the section "LDAP connections", probably
  using the "personLdap" server ID (one of the defaults). Then you need
  to go back to subject.properties and "link" to that configuration.

- I found that I needed to evolve my JDBC connection URL in
  grouper.hibernate.properties from the simple

  jdbc:mysql://localhost:3306/grouper

  to the more sophisticated

  
jdbc:mysql://localhost:3306/grouper?CharSet=utf8&useUnicode=true&characterEncoding=utf8

- To just make sure the transition to the container was working I did
  not want to bother immediately with the full Shibboleth SP
  configuration, so I edited grouper.hibernate.properties and added


  grouper.is.ui.basicAuthn = true
  grouper.is.ws.basicAuthn = true
  grouper.is.scim.basicAuthn = true

  Then I started the container 

  GROUPER_UI=true
  RUN_APACHE=true
  RUN_SHIB_SP=false
  RUN_TOMEE=true

  I broke into the container and did

  ./bin/gsh.sh
  grouperPasswordSave = new GrouperPasswordSave();
  
grouperPasswordSave.assignUsername("GrouperSystem").assignPassword("XXXXXXXX").assignEntityType("username");
  grouperPasswordSave.assignApplication(GrouperPassword.Application.UI);
  new Authentication().assignUserPassword(grouperPasswordSave);

  Then I could use basic auth to login as GrouperSystem and look around
  easily to make sure the container appeared to be working and the 2.5.x
  upgraded worked.

- After running the container I wanted to be sure that the schema was
  fully upgraded so I broke into the container and ran

  ./bin/gsh.sh -registry -check -deep

  Not all of the output from that command goes to the stdout of the
  shell you are running after you break in, so you need to also look
  at the stdout of the container for the "success" message that your
  schema is up-to-date (or not). Chris Hyzer is aware and has already
  patched that I think...

HTH,

Scott K

> > Looking at the release notes for Grouper 2.5, I noticed that there
> > are no instructions for upgrading from pre-2.4 versions.  As we're
> > currently running version 2.2.2, we are considering upgrading at
> > some point in the near future, and so I was wondering what the
> > correct process would be.  Is it possible to jump straight from 2.2
> > to 2.5, or would we need to upgrade via Grouper 2.3 and 2.4 first?
> >
> 
> Has anyone else tried upgrading 2.2.2 to 2.5 yet?