Cache Refresh - Can't load Cache Refresh scripts. Using default script

By: marc caron user 30 Aug 2016 at 2:45 p.m. CDT

13 Responses
marc caron gravatar
Hello So multiple issues it seems but likely related to the same underlying issue. I've watched the videos, had a 1hour with Mike, etc. So cache refresh seems pretty straight forward to setup. However Setup Windows AD for LDAP we want to use as identity source. Have used this same AD for user directories from Jira, etc. and all work fine. But the setup for this doesn't seem to want to work. Based off the below 3 things I believe it may be some goofy permissions or something on the server (we have our own image of centos of course <sigh>) and I think it's having issues saving some values into the configs. that said. problem 1: when setting the "bind password" it hangs with the entry screen up and "Request in progress please wait....." displayed. I can click off it and it acts like nothing happened. problem 2: Update and validate script always displays "Can't load cache refresh scripts. Using default script" problem 3: it just doesn't work as a result. Log below. 2016-08-30 14:41:21,798 ERROR [org.gluu.oxtrust.action.ConfigureCacheRefreshAction] (ajp-bio-127.0.0.1-8009-exec-49) Can't load Cache Refresh scripts. Using default script 2016-08-30 14:42:09,866 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-3) Failed to connect to LDAP server using configuration MY_LDAP 2016-08-30 14:42:09,890 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-3) Skipping cache refresh due to invalid server configuration Thoughts? Ideas? Any other logs I can look at? thanks
CentOS72
closed

Answers

By Aliaksandr Samuseu staff 30 Aug 2016 at 3:37 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Marc. 1. Have you disabled selinux at this box? 2. You specified that machine has 4GB+ of RAM, but have you specified enough RAM for Tomcat when you were running setup.py? It must be at least 3GB. Best regards, Alex.

By Michael Schwartz Account Admin 30 Aug 2016 at 3:56 p.m. CDT

Copy
Michael Schwartz gravatar
The error message is pretty specific: `Failed to connect to LDAP server` I would try to `ldapsearch` AD just to make sure the network port is open from the Gluu Server to AD. For example ``` # /opt/opendj/bin/ldapsearch -h ad.example.com -p 636 \ -D "cn=manager" -j ~/.adpw -X -Z -b "dc=example,dc=com" \ -s base "objectclass=*" ``` (Write the AD manager password to `~/.adpw` and delete it when you're done... that way the PW won't show in the bash_history) If you can't connect with LDAPsearch, it's probably a network problem. Or your creds are wrong. Check the AD access logs also to see if you're seeing the request.

By marc caron user 06 Sep 2016 at 3:17 p.m. CDT

Copy
marc caron gravatar
So after much working on this it appears the ldap issues are it's internal db and it is trying to sync over 11k users. So based off other posts we're going to uninstall and re-install to see if we can correct the internal ldap problems. And this is our initial testing instance so not a big deal. Thanks for the suggestions.

By William Lowe user 06 Sep 2016 at 3:27 p.m. CDT

Copy
William Lowe gravatar
Thanks for the update, Marc. Let us know if you want to re-open this ticket. Or feel free to create a new one as needed.

By Aliaksandr Samuseu staff 06 Sep 2016 at 3:29 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Gluu has been verified to be able to handle hundreds of thousands of user entries, so 11k should be nothing for it. Please try to diagnose it a bit thoroughly, you could set connections to both internal and external directories to use unencrypted channels, and then check with Wireshark what is being sent back and forth.

By marc caron user 06 Sep 2016 at 3:33 p.m. CDT

Copy
marc caron gravatar
Sorry I should have been more clear. The issues is it having issues accessing and writing to it's own internal ldap. So not a volume issue. And I want to run through a new clean setup now anyway to ensure we have a good process before progressing to our non-production instance for development use since this one has been screwed up a little bit now.

By Aliaksandr Samuseu staff 06 Sep 2016 at 3:37 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
> The issues is it having issues accessing and writing to it's own internal ldap. So not a volume issue. Do you mean something like file system permissions or LDAP access controls were set incorrectly, so it couldn't write to its own database? Was it like that out of the box, or do you think you could have caused it inadvertently?

By marc caron user 06 Sep 2016 at 3:41 p.m. CDT

Copy
marc caron gravatar
I'm guessing it was an inadvertent change on our end. I had a couple admins helping because of how our VM security is configured I coulnd't do all the operations myself and so I don't know what they may have run. Also it WAS working initially against it's own ldap fine. It HAS written many things to its internal ldap. And now I get a mixure of errors. So I'm thinking it's better to start from scratch and i'm trying to get more access so I can control what is done at every step and have it documented. So no sense chasing this ghost further since I can't say for sure what exactly was done.

By Aliaksandr Samuseu staff 06 Sep 2016 at 3:44 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Understood, thanks, Marc. Please let us know whether you'll be able to make it work as expected.

By marc caron user 08 Sep 2016 at 3:52 p.m. CDT

Copy
marc caron gravatar
Leaving closed but adding commentary for future people. We have a rather screwed up ldap configuration as a whole right now. So the service account first used, although can access AD ldap from a windows server just fine would cause the "Change Bind Password" to hang when trying to set. When trying my personal account the same thing would occur. When one of our Unix admins used his account/pwd it worked just fine. Had a new account created just for the purpose and it worked just fine. So when in doubt just create all new to test with so you know exactly what you're dealing with.

By Michael Schwartz Account Admin 08 Sep 2016 at 4:32 p.m. CDT

Copy
Michael Schwartz gravatar
Yes, that's why I suggested to use ldapsearch to test the creds in my first comment.

By marc caron user 08 Sep 2016 at 4:35 p.m. CDT

Copy
marc caron gravatar
Yep, permissions issues on how our Unix boxes are setup that prevented me from executing those commands. I tried but local permissions fail not ldap permissions fail. Again, it's our infrastructure that becomes our own bottleneck. I appreciate the quick responses.

By William Lowe user 08 Sep 2016 at 4:40 p.m. CDT

Copy
William Lowe gravatar
Thanks, Marc. I'm sure your comments will be useful to others in the community as well.

Post an answer