Cache refrest not importing users

By: Vreixo Luis Gonzalez Caneda user 29 Apr 2021 at 11:08 a.m. CDT

10 Responses
Vreixo Luis Gonzalez Caneda gravatar
Hi, I have installed Gluu with docker using pygluu-compose and configured cache refresh for our active directory with the configuration in screenshots below. https://www.dropbox.com/s/y72qiu10crgg56r/Capture%20d%E2%80%99%C3%A9cran%20de%202021-04-26%2016-49-51.png https://www.dropbox.com/s/i88k3b2zrypay9r/Capture%20d%E2%80%99%C3%A9cran%20de%202021-04-29%2016-30-51.png https://www.dropbox.com/s/u1t3kkqaokyr7bb/Capture%20d%E2%80%99%C3%A9cran%20de%202021-04-26%2016-49-43.png https://www.dropbox.com/s/bn7zgotpxntjugj/Capture%20d%E2%80%99%C3%A9cran%20de%202021-04-29%2016-42-10.png CR_ROTATE is active and ip is set to the container one from docker (is not the ip shown in the screenshots) because if no value is set we have this crash in logs of CR_ROTATE: ``` File "/app/scripts/entrypoint.py", line 62, in get_configuration "oxTrustCacheRefreshServerIpAddress": entry["oxTrustCacheRefreshServerIpAddress"][0], File "/usr/lib/python3.8/site-packages/ldap3/abstract/attribute.py", line 84, in __getitem__ return self.values[item] IndexError: list index out of range ``` The issue is that no users are being imported and in oxtrust this error appears: ``` 2021-04-29 16:00:33,182 ERROR [ForkJoinPool.commonPool-worker-7] [org.gluu.service.config.ConfigurationFactory] (ConfigurationFactory.java:306) - WELD-001334: Unsatisfied dependencies for type CacheRefreshConfiguration with qualifiers @Default org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type CacheRefreshConfiguration with qualifiers @Default at org.jboss.weld.bean.builtin.InstanceImpl.checkBeanResolved(InstanceImpl.java:241) ~[weld-core-impl-3.1.4.Final.jar:3.1.4.Final] at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:113) ~[weld-core-impl-3.1.4.Final.jar:3.1.4.Final] at org.gluu.service.config.ConfigurationFactory.destroy(ConfigurationFactory.java:314) ~[oxtrust-service-4.2.3.Final.jar:?] at org.gluu.oxtrust.service.config.ConfigurationFactory$Proxy$_$$_WeldSubclass.destroy(Unknown Source) ~[classes/:?] at org.gluu.oxtrust.service.config.ConfigurationFactory.destroryLoadedConfiguration(ConfigurationFactory.java:75) ~[classes/:?] at org.gluu.oxtrust.service.config.ConfigurationFactory$Proxy$_$$_WeldSubclass.destroryLoadedConfiguration(Unknown Source) ~[classes/:?] at org.gluu.service.config.ConfigurationFactory.createFromDb(ConfigurationFactory.java:297) [oxtrust-service-4.2.3.Final.jar:?] at org.gluu.service.config.ConfigurationFactory.reloadConfiguration(ConfigurationFactory.java:223) [oxtrust-service-4.2.3.Final.jar:?] at org.gluu.service.config.ConfigurationFactory.reloadConfigurationTimerEvent(ConfigurationFactory.java:175) [oxtrust-service-4.2.3.Final.jar:?] at org.gluu.oxtrust.service.config.ConfigurationFactory$Proxy$_$$_WeldSubclass.reloadConfigurationTimerEvent$$super(Unknown Source) [classes/:?] at jdk.internal.reflect.GeneratedMethodAccessor137.invoke(Unknown Source) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.1.4.Final.jar:3.1.4.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.1.4.Final.jar:3.1.4.Final] at org.gluu.service.cdi.async.AsynchronousInterceptor$1.get(AsynchronousInterceptor.java:36) [oxcore-service-4.2.3.Final.jar:?] at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700) [?:?] at java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692) [?:?] at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?] at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) [?:?] at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) [?:?] at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) [?:?] at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183) [?:?] ``` Regards,
Gluu 4.2.3 Ubuntu 18.04
closed

Answers

By Aliaksandr Samuseu staff 29 Apr 2021 at 12:54 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi. Taking over this ticket, as it's related to another one I'm working on

By Vreixo Luis Gonzalez Caneda user 29 Apr 2021 at 2:20 p.m. CDT

Copy
Vreixo Luis Gonzalez Caneda gravatar
Ok, great, thanks for your investigations Aliaksandr

By Vreixo Luis Gonzalez Caneda user 20 Jun 2021 at 12:19 p.m. CDT

Copy
Vreixo Luis Gonzalez Caneda gravatar
Cache refresh is working now, just not being updated the IP at all times with cr-rotate. The problem is that there are no errors in the logs further than not possible to connect to the old ip. Cr-rotate itself does not log any errors.

By Aliaksandr Samuseu staff 21 Jun 2021 at 2:37 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Luis. Could you elaborate? >The problem is that there are no errors in the logs further than not possible to connect to the old ip If it's working now, then what errors do you expect to see there? Also keep in mind that OOTB Gluu Server has log verbosity set to show only errors and warnings, to prevent huge log files create issues in production under load. So if you just want to see a more detailed log, set "loggingLevel" property to ERROR or even TRACE on "Configuration" > "JSON Configuration" > "oxTrust" page.

By Vreixo Luis Gonzalez Caneda user 21 Jun 2021 at 3:22 p.m. CDT

Copy
Vreixo Luis Gonzalez Caneda gravatar
Hi, Now it's actually working ok, just sometimes cr-rotate does not seem to update ip of oxtrust container. When this happens we see errors in cache refresh logs from oxtrust not able to reach the server. When updating ip in oxtrust with values of ip from docker inspect for oxtrust container it starts working again. When this happens there isn't any error in cr-rotate just this standard logs: ``` INFO - pygluu.containerlib.wait - 2021-06-20 13:16:06,542 - Config is ready INFO - pygluu.containerlib.wait - 2021-06-20 13:16:06,594 - Secret is ready WARNING - pygluu.containerlib.wait - 2021-06-20 13:16:07,633 - LDAP is not ready; reason=socket connection error while opening: [Errno 111] Connection refused; retrying in 10.0 seconds WARNING - pygluu.containerlib.wait - 2021-06-20 13:16:17,665 - LDAP is not ready; reason=socket connection error while opening: [Errno 111] Connection refused; retrying in 10.0 seconds WARNING - pygluu.containerlib.wait - 2021-06-20 13:16:27,700 - LDAP is not ready; reason=socket connection error while opening: [Errno 111] Connection refused; retrying in 10.0 seconds INFO - pygluu.containerlib.wait - 2021-06-20 13:16:38,835 - LDAP is ready INFO - pygluu.containerlib.wait - 2021-06-20 16:37:56,172 - Config is ready INFO - pygluu.containerlib.wait - 2021-06-20 16:37:56,215 - Secret is ready INFO - pygluu.containerlib.wait - 2021-06-20 16:37:56,646 - LDAP is ready ``` How can I actually see the value which is being used for cr-rotate? The value shown in the GUI of oxtrust is the one that is being used when cr-rotate has updated it?

By Aliaksandr Samuseu staff 22 Jun 2021 at 6:52 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
> just sometimes cr-rotate does not seem to update ip of oxtrust container Ah, got it. I saw you rising this issue in the other ticket, and preparing an aswer for you there. As for your question about the log cr-rotate produce, Isman (the author of this service) should provide more insight. I'll ask him to have a look.

By Aliaksandr Samuseu staff 22 Jun 2021 at 7:22 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
By the way - may be it will make it easier to handle for now - instead of providing an actuall ip address on that CR configuration page, my tests showed that if `255.255.255.255` is used, it works just as well, and later the correct ip address appears there anyway. So at least you won't need to run `# docker inspect` each time to resolve the issue. Hope this helps.

By Aliaksandr Samuseu staff 22 Jun 2021 at 11:03 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
I had a talk with Isman, and he confirmed that cr-rotate image in the package you use is outdated and doesn't have patch we added recently. He's prepared a new [pygluu-compose.pyz](https://github.com/GluuFederation/community-edition-containers/releases/download/v1.6.1/pygluu-compose-linux-amd64.pyz) executable that employs cr-rotate image with this fix added, so if you wish, you could use it to deploy a new setup where CR should behave as expected. Isman also thinks you could actually just pull only the new cr-rotat image (`cr-rotate:4.2.3_04`), thus preserving your current configuration - should fix it as well.

By Mohib Zico Account Admin 06 Jul 2021 at 12:13 a.m. CDT

Copy
Mohib Zico gravatar
Hi Vreixo, Got chance to test new pyz file?

By Vreixo Luis Gonzalez Caneda user 09 Aug 2021 at 9:36 a.m. CDT

Copy
Vreixo Luis Gonzalez Caneda gravatar
Hi, Using image of cr-rotate directly and it does work ok. When we are going to update Gluu version we will check for new pyz. Thanks

Post an answer