Grouper Users - Open Discussion List

[Baron Fujimoto <>]

I finally got our change logs copied over, and the grouperInstaller reports
a successful upgrade for the api: Grouper is upgraded from 2.2.1 to 2.2.2

When I try to upgrade the ui next though, I run into the following:
=====
[...]
Where is the grouper UI installed? /home/grouper/grouper/grouper.ui-2.2.1
Cant find Grouper UI properties files or libs, looked in the directory, 
/classes/ , /conf/ , /WEB-INF/classes/ , /lib/ , /WEB-INF/lib/ , 
/lib/grouper/ , /dist/lib/
=====
As far as I know that is the correct location where the UI is installed.

I don't know what it's looking for specifically, but I have

$ find /home/grouper/grouper/grouper.ui-2.2.1 -name lib
/home/grouper/grouper/grouper.ui-2.2.1/dist/grouper/WEB-INF/lib
/home/grouper/grouper/grouper.ui-2.2.1/contrib/penn-auth/java/lib
/home/grouper/grouper/grouper.ui-2.2.1/contrib/yale-cas-auth/java/lib
/home/grouper/grouper/grouper.ui-2.2.1/build/grouper/WEB-INF/lib
/home/grouper/grouper/grouper.ui-2.2.1/java/lib

and

find /home/grouper/grouper/grouper.ui-2.2.1 -name "*.properties"
[...lots of results under /webapp, /dist, /misc, /build, and /conf...]

FWIW, the grouperInstaller also complains:

Error: Java should be version 6 or 7 (1.6 or 1.7), but is detected as: 
1.8.0_66

but I'm assuming this is not actually a problem?

Aloha,
-baron

On Thu, Oct 29, 2015 at 07:52:36PM +0000, Chris Hyzer wrote:
>Let me know if you are able to complete the upgrade... I would run the 
>loader even if you aren't provisioning...  I will see about updating the 
>docs about it after discussing it at the next dev call and let you know how 
>it does.
>
>Thanks,
>Chris
>
>-----Original Message-----
>From: Baron Fujimoto 
>[mailto:]
> 
>Sent: Thursday, October 29, 2015 3:42 PM
>To: Chris Hyzer
>Cc: Grouper Users
>Subject: Re: [grouper-users] Upgrade errors 2.2.1 -> 2.2.2
>
>On Thu, Oct 29, 2015 at 06:49:47PM +0000, Chris Hyzer wrote:
>> 
>>> After patching 2.2.1, downloading, and unpacking the new
>>> grouper.apiBinary-2.2.2, I accepted the recommendation to run a script
>>> that copies change log temp records to the change log. This ran for hours,
>>> and was still running when I left for the day.
>>> 
>>> When I returned this morning, I was greeted with the error below[*],
>>> followed by the advisory that,
>>> 
>>> =====
>>> You need to revert all patches to upgrade
>>> 
>>> ################ Checking patch grouper_v2_2_1_api_patch_21
>>> Patch: grouper_v2_2_1_api_patch_21: was applied on: 2015/08/10 13:41:24"
>>> =====
>>> 
>>> I'm unsure what remedial steps are actually needed now. grouperInstaller
>>> looks like it wants to resume from or retry grouper_v2_2_1_api_patch_21.
>>> Should I just let it continue, or do I need to "revert *all* patches" as
>>> displayed and start over?
>>
>>Do you run the grouper loader which copies change log temp to change log 
>>continuously?  Were there a lot of records unprocessed in grouper change 
>>log temp table?  You need to run a grouper loader process for grouper to 
>>function correctly.  It is part of the standard upgrade to uninstall all 
>>2.2.1 patches to get to 2.2.2.  So let it revert all the 2.2.1 patches, you 
>>can answer yes to each one or revert all at once.
>
>Hmm, no we're not running a grouper loader. I wasn't aware of this
>requirement. Did I miss it in the documentation somewhere? The wiki
>page for Grouper Loader seems to describe it in terms of a provisioning
>system, and not something needed for regular/ongoing operation. We've been
>provisioning and maintaining all of our groups via the WS.
><https://spaces.internet2.edu/display/Grouper/Grouper+-+Loader>
>
>Where is this maintenance aspect of the change logs described?
>
>>> Is the amount of time being taken to copy the change logs reasonable? I
>>> think our db goes down nightly for a backup. If the the copy change log
>>> process can't complete before that happens, will it resume from a previous
>>> partial completion, or does it need to start all over from the beginning?
>>> I'm concerned about the possibility that may never complete given the
>>> db's backup downtime constraint.
>>
>>I don't know, how many records were there?  Yes, it is not one large 
>>transaction, it will make progress, and if you stop it and restart it will 
>>pickup from where it left off.  Do some record counts while it runs and see 
>>it making progress.
>
>Are these the right tables?
>
>select count(*) from grouper_change_log_entry;      ->  419750
>select count(*) from grouper_change_log_entry_temp; -> 3988004
>
>So, maybe yikes.
>
>Could this also be the reason why we occasionally see audit log requests
>time out? 
>
>Aloha,
>-baron
>-- 
>Baron Fujimoto 
><>
> :: UH Information Technology Services
>minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

-- 
Baron Fujimoto 
<>
 :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum