Cache refrest not importing users
By: Vreixo Luis Gonzalez Caneda user 29 Apr 2021 at 11:08 a.m. CDT
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,
Answers
By Aliaksandr Samuseu staff 29 Apr 2021 at 12:54 p.m. CDT
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
Ok, great, thanks for your investigations Aliaksandr
By Vreixo Luis Gonzalez Caneda user 20 Jun 2021 at 12:19 p.m. CDT
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
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
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
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
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
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 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
Hi Vreixo,
Got chance to test new pyz file?
By Vreixo Luis Gonzalez Caneda user 09 Aug 2021 at 9:36 a.m. CDT
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
Warning
I have detected that you have been inactive for 10 minutes.
I got sleepy so I've taken a nap!
