Grouper Users - Open Discussion List

[Darren Boss <>]

Some discussion occured just between Chris and myself. It does appear that not all patches are getting applied when building the Grouper UI Docker image. The Dockerfile does the war build and applies patching using this grouper.installer-ui.properties file:

grouperInstaller.autorun.useDefaultsAsMuchAsAvailable = true

grouperInstaller.autorun.continueAfterDeleteUiWorkDirectory = true

grouperInstaller.autorun.actionEgInstallUpgradePatch = patch

grouperInstaller.autorun.tarballDirectory = /tmp/grp-ui

grouperInstaller.autorun.appToUpgrade = ui

grouperInstaller.autorun.grouperWhereInstalled = /opt/apache-tomcat-6.0.44/webapps/grouper/

grouperInstaller.autorun.patchAction = install

grouper.version = 2.3.0

download.server.url = "http://software.internet2.edu/grouper

Right off the bat there is a problem appling a the first api patch:

Downloading from URL: http://software.internet2.edu/grouper/release/2.3.0/patches/grouper_v2_3_0_api_patch_0.tar.gz to file: /tmp/grp-ui/patches/grouper_v2_3_0_api_patch_0.tar.Cannot apply patch since this patch file:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil$2.class

  /tmp/grp-ui/patches/grouper_v2_3_0_api_patch_0/new/classes/edu/internet2/middleware/grouper/util/GrouperUtil$2.class

  is supposed to be new, but it already exists:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil$2.class

Problem applying patch since this file:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil$MaskingThread.class

  should not exist yet

  Do you want to force install this patch (t|f)? [f]: 

<using default which is blank due to grouperInstaller.autorun.useDefaultsAsMuchAsAvailable and grouperInstaller.autorun.forceInstallPatch>: 

Cannot apply patch since this patch file:

  /tmp/grp-ui/patches/grouper_v2_3_0_api_patch_0/new/classes/edu/internet2/middleware/grouper/util/GrouperUtil$MaskingThread.class

  is supposed to be new, but it already exists:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil$MaskingThread.class

Problem applying patch since this file:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil.class

  should not exist yet

  Do you want to force install this patch (t|f)? [f]: 

<using default which is blank due to grouperInstaller.autorun.useDefaultsAsMuchAsAvailable and grouperInstaller.autorun.forceInstallPatch>: 

Cannot apply patch since this patch file:

  /tmp/grp-ui/patches/grouper_v2_3_0_api_patch_0/new/classes/edu/internet2/middleware/grouper/util/GrouperUtil.class

  is supposed to be new, but it already exists:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil.class

Problem applying patch since this file:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil.java

  should not exist yet

  Do you want to force install this patch (t|f)? [f]: 

<using default which is blank due to grouperInstaller.autorun.useDefaultsAsMuchAsAvailable and grouperInstaller.autorun.forceInstallPatch>: 

Cannot apply patch since this patch file:

  /tmp/grp-ui/patches/grouper_v2_3_0_api_patch_0/new/classes/edu/internet2/middleware/grouper/util/GrouperUtil.java

  is supposed to be new, but it already exists:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil.java

Problem applying patch since this file:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil$DaemonThreadFactory.class

  should not exist yet

  Do you want to force install this patch (t|f)? [f]: 

<using default which is blank due to grouperInstaller.autorun.useDefaultsAsMuchAsAvailable and grouperInstaller.autorun.forceInstallPatch>: 

Cannot apply patch since this patch file:

  /tmp/grp-ui/patches/grouper_v2_3_0_api_patch_0/new/classes/edu/internet2/middleware/grouper/util/GrouperUtil$DaemonThreadFactory.class

  is supposed to be new, but it already exists:

  /opt/apache-tomcat-6.0.44/webapps/grouper/WEB-INF/classes/edu/internet2/middleware/grouper/util/GrouperUtil$DaemonThreadFactory.class

 - added to end of property file: grouper_v2_3_0_api_patch_0.state = error

Does someone understand what might be happening? Are the patches being applied but detected as errors because of the force installation and then subsequent patches not being applied because it's detected that previous dependent patches have not applied?

On Mon, Sep 18, 2017 at 10:13 AM Hyzer, Chris <> wrote:

> Full disclousure, I'm running Grouper in containers under Kubernetes with an nginx ingress

> controller which is terminating TLS at the ingress. When I use "kubectl port-forward pod-name"

> and access the ui over localhost:8080 I have no issues in accessing the interface.

 

So you are saying it works when you are not load balancing?  But it doesn’t work with load balancing?  Is the load balancing sticky by cookie?  Does it work if it is load balancing with one node in the pool?

 

What the X-Grouper-path response http header coming back from the server?

 

Are you sure there are no errors in any of the logs?

 

Thanks

Chris

 

 

From: [mailto:] On Behalf Of Darren Boss
Sent: Monday, September 18, 2017 9:58 AM
To:
Subject: [grouper-users] New UI problems with reverse proxy

 

Question about the New UI and OWASP csrfguard and accessing the UI behind a nginx reverse proxy.

 

Took me a little while to figure out the additions to make to Tomcat to fix the major issue of accessing the UI after which the admin ui works. This is a common solution when running tomcat behind a reverse proxy. I have another tweak for Jetty that accomplished the same.

 

<Valve className="org.apache.catalina.valves.RemoteIpValve"

        internalProxies="my.nginx.proxy.address"

        remoteIpHeader="x-forwarded-for"

        requestAttributesEnabled="true"

        protocolHeader="x-forwarded-proto"

        protocolHeaderHttpsValue="https"/>

 

Now when I click on any link in the new ui I end up in an infinite redirect loop with &csrfExtraParam=xyz being added to the existing url on every redirect. I've tried to search through the mailing list to find a resolution. I know there are lots of deployments behind reverse proxies so this should be a solved issue.

 

Full disclousure, I'm running Grouper in containers under Kubernetes with an nginx ingress controller which is terminating TLS at the ingress. When I use "kubectl port-forward pod-name" and access the ui over localhost:8080 I have no issues in accessing the interface.

 

I'm also incredably new to deploying grouper but had been using the deployment at Duke when I was a staff member there and I believe their deployment was running under OpenShift so probably a similar deployment to what I'm doing now.

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

(o) 416.228.1234 x 230

(c) 919.525.0083

155 University Ave, Suite 302 Toronto, ON M5H 3B7
www.computecanada.ca / www.calculcanada.ca 
@ComputeCanada 

--

Darren Boss

Senior Programmer/Analyst
Programmeur-analyste principal

(o) 416.228.1234 x 230

(c) 919.525.0083

155 University Ave, Suite 302 Toronto, ON M5H 3B7
www.computecanada.ca / www.calculcanada.ca 
@ComputeCanada