Cache Refresh Not finding users

By: Matt Ferry user 14 Dec 2017 at 8:45 a.m. CST

4 Responses
Matt Ferry gravatar
This is extremely similar to: https://support.gluu.org/identity-management/3181/cache-refresh-not-finding-users/ But I am experiencing this issue. Gluu oxtrust_cache_refresh.log ``` 2017-12-13 21:15:05,730 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:316) - Attempting to load entries from source server 2017-12-13 21:15:05,731 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:325) - Found '0' entries in source server 2017-12-13 21:15:05,731 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:328) - Found '0' unique entries in source server 2017-12-13 21:15:05,731 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:377) - Found '0' changed entries 2017-12-13 21:15:05,732 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:382) - Loaded '0' problem entries from problem file 2017-12-13 21:15:05,738 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:395) - Updated '0' entries 2017-12-13 21:15:05,739 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:397) - Failed to update '0' entries 2017-12-13 21:15:05,739 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:437) - Removed '0' persons from target server 2017-12-13 21:15:05,741 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:452) - There are '0' entries before updating inum list 2017-12-13 21:15:05,741 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:456) - There are '0' entries after removal '0' entries 2017-12-13 21:15:05,741 INFO [ForkJoinPool.commonPool-worker-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:460) - There are '0' entries after adding '0' entries ``` I have disabled cache refresh , deleted the contents of /var/ox/identity/cr-snapshots , and then re-enabled cache refresh with no change. I can perform the following queries via the gluu container command line successfully: ``` ./ldapsearch -h 10.200.147.144 -b "ou=People,dc=gluuserver,dc=vsurv,dc=com" uid=* ./ldapsearch -h 10.200.147.144 -b "ou=People,dc=gluuserver,dc=vsurv,dc=com" '(&(uid=*)(objectclass=person))' ``` Results of the above queries: ``` dn: cn=Developer User 1,ou=People,dc=gluuserver,dc=vsurv,dc=com cn: Developer User 1 givenName: Developer gidNumber: 500 homeDirectory: /home/users/devuser1 sn: User 1 loginShell: /bin/sh objectClass: inetOrgPerson objectClass: posixAccount objectClass: top uidNumber: 1000 uid: devuser1 dn: cn=Developer User 2 User 2,ou=People,dc=gluuserver,dc=vsurv,dc=com cn:Developer User 2 User 2 givenName: Developer User 2 gidNumber: 502 homeDirectory /home/users/devuser2 sn: User2 loginShell: /bin/sh objectClass: inetOrgPerson objectClass: posixAccount objectClass: top uidNumber: 1001 uid: devuser2 ``` I have made sure that "Load Source data with limited search" is NOT checked, and I have also tested a cycle with it being checked. I also ran the additional two queries that were in the linked thread: 1. /opt/opendj/bin/ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D 'cn=directory manager' -w 'YOUR_LDAP_PASS' -b 'o=gluu' -z 5 '(objectclass=oxtrustconfiguration)' oxTrustConfCacheRefresh 2. /opt/opendj/bin/ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D 'cn=directory manager' -w 'YOUR_LDAP_PASS' -b 'o=gluu' -z 5 '(objectclass=gluuappliance)' gluuVdsCacheRefreshPollingInterval gluuVdsCacheRefreshEnabled gluuIpAddress With the following results: First Query: ``` dn: ou=oxtrust,ou=configuration,inum=@!DAB1.B61D.A39A.9813!0002!BC25.3735,ou=appliances,o=gluu oxTrustConfCacheRefresh: {"sourceConfigs":[{"configId":"source","bindDN":"cn=admin,dc=gluuserver,dc=vsurv,dc=com","bindPassword":"PnbQ1Io8pgrdTZpWT6vyOg==","servers":["gluuserver.vsurv.com:389"],"maxConnections":3,"useSSL":false,"baseDNs":["ou=people,dc=gluuserver,dc=vsurv,dc=com"],"primaryKey":null,"localPrimaryKey":null,"useAnonymousBind":false,"enabled":false,"version":0,"level":0}],"inumConfig":{"configId":"local_inum","bindDN":"cn=directory manager,o=site","bindPassword":"PnbQ1Io8pgrdTZpWT6vyOg==","servers":["localhost:1636"],"maxConnections":10,"useSSL":true,"baseDNs":["o=site"],"primaryKey":null,"localPrimaryKey":null,"useAnonymousBind":false,"enabled":true,"version":0,"level":0},"targetConfig":{"configId":null,"bindDN":null,"bindPassword":null,"servers":[],"maxConnections":0,"useSSL":false,"baseDNs":[],"primaryKey":null,"localPrimaryKey":null,"useAnonymousBind":false,"enabled":false,"version":0,"level":0},"ldapSearchSizeLimit":1000,"keyAttributes":["uid"],"keyObjectClasses":["People"],"sourceAttributes":["givenName","sn","cn","userPassword"],"customLdapFilter":"","updateMethod":"copy","defaultInumServer":false,"keepExternalPerson":true,"useSearchLimit":false,"attributeMapping":[{"source":"givenName","destination":"givenName"},{"source":"uid","destination":"uid"},{"source":"sn","destination":"sn"},{"source":"userPassword","destination":"userPassword"},{"source":"cn","destination":"cn"}],"snapshotFolder":"/var/ox/identity/cr-snapshots","snapshotMaxCount":10} ``` Second Query: ``` dn: inum=@!DAB1.B61D.A39A.9813!0002!BC25.3735,ou=appliances,o=gluu gluuIpAddress: 10.200.147.144 gluuVdsCacheRefreshPollingInterval: 5 gluuVdsCacheRefreshEnabled: enabled ``` Still researching and digging on this, but at this point unsure as to why this is happening, and what I am missing. EDIT for adding additional content: Just noticed that when "Load Source data with limited search" is checked that the gluu server is now registering "Last Run" information in the Cache Refresh page (this is something that I had not noticed before). If I uncheck this setting the information is not updated on the next cycle. So Load Source Data with limited search, checked = updating Cache Refresh page information Load Source Data with limited search, unchecked = Cache Refresh page information no longer being updated. However, with that, none of the existing users from the external ldap server (all 2 of them, which can be queried from the gluu container as posted above), are being updated into the gluu database.
Ubuntu 16.04
closed

Answers

By Michael Schwartz Account Admin 14 Dec 2017 at 12:18 p.m. CST

Copy
Michael Schwartz gravatar
Alex can you comment on this?

By Aliaksandr Samuseu staff 14 Dec 2017 at 12:46 p.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Matt. A couple of questions. 1) Why your `gluuIpAddress` property is equal to ip address of your backend LDAP directory you run searches against here? ``` ./ldapsearch -h 10.200.147.144 -b "ou=People,dc=gluuserver,dc=vsurv,dc=com" uid=* ./ldapsearch -h 10.200.147.144 -b "ou=People,dc=gluuserver,dc=vsurv,dc=com" '(&(uid=*)(objectclass=person))' ``` Do you run it on the same host as your Gluu Server? 2) Why do you specify "People" as "Object class" filter element on "Customer backend/key attributes" CR tab (judging by `"keyObjectClasses":["People"]` part of your configuration dump), while from the output of your search commands it seems your backend doesn't have such objectclass in its entries, only next 3: ``` objectClass: inetOrgPerson objectClass: posixAccount objectClass: top ``` I would suggest to use "inetOrgPerson" instead of "People" there. Please let me know whether this helpful.

By Matt Ferry user 14 Dec 2017 at 1:38 p.m. CST

Copy
Matt Ferry gravatar
1) Yes, same host .... just a basic ubuntu vm that I setup for sandbox testing 2) Thank you, People instead of inetOrgPerson is what was wrong, and cache refresh just pulled users out of the external ldap.

By Aliaksandr Samuseu staff 14 Dec 2017 at 1:57 p.m. CST

Copy
Aliaksandr Samuseu gravatar
Good. Thank you as well for your thoughtfulness and pro-active approach to the issue, your detailed report saved a lot of time on troubleshooting for us.

Post an answer