Hello, I understand that with the pcacheOffline TRUE and the cache contents can be use indefinitely but its cache data never get refresh with remote DSA. It's not really useful once user is login 1st time and their user attributes would not get refresh with DSA after that.
But the default configuration option of pcacheOffline FALSE, pcache would use the local cached data, refresh with remote DSA and continues to response with its cached data when the DSA is cut off/unreachable. However if remote DSA is offline and the existing cached is expired, the client would get the respond with error "Proxy operation retry failed" as "cache is stale", pcache is checking with remote DSA for refresh but remote DSA is unreacheable offline.
Can we continue to use the existing expired cached data (the cache contents to be used indefinitely) with pcacheOffline FALSE until remote DSA is back online (days/weeks later)?
Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: conn=1115 op=0 do_bind Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: >>> dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com> Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: <<< dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com>, <uid=userX,ou=employees,o=mycompany.com> Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: conn=1115 op=0 BIND dn="uid=userX,ou=employees,o=mycompany.com" method=128 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: do_bind: version=3 dn="uid=userX,ou=employees,o=mycompany.com" method=128 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => bdb_entry_get: ndn: "uid=userX,ou=employees,o=mycompany.com" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => bdb_entry_get: oc: "(null)", at: "(null)" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: bdb_dn2entry("uid=userX,ou=employees,o=mycompany.com") Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => bdb_entry_get: found entry: "uid=userX,ou=employees,o=mycompany.com" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: bdb_entry_get: rc=0 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: str2filter "(uid=userX)" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: begin get_filter Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: EQUALITY Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: end get_filter 0 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: Lock QC index = 0x562be57eb700 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: QUERY ANSWERABLE (answered 115 times) Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => hdb_search Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: bdb_dn2entry("uid=userX,ou=employees,o=mycompany.com") Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => access_allowed: search access to "uid=userX,ou=employees,o=mycompany.com" "entry" requested Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: <= root access granted Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => access_allowed: search access granted by manage(=mwrscxd) Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: base_candidates: base: "uid=userX,ou=employees,o=mycompany.com" (0x00000003) Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => test_filter Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: EQUALITY Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => access_allowed: search access to "uid=userX,ou=employees,o=mycompany.com" "uid" requested Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: <= root access granted Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => access_allowed: search access granted by manage(=mwrscxd) Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: <= test_filter 6 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: pc_bind_search: cache is stale, reftime: 1655318380, current time: 1655318385 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: send_ldap_result: conn=1115 op=0 p=3 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: send_ldap_result: err=0 matched="" text="" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: =>ldap_back_getconn: conn=1115 op=0: lc=0x7f2644105d10 inserted refcnt=1 rc=0 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: activity on 1 descriptor Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: activity on: Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=7 active_threads=0 tvp=zero Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=9 active_threads=0 tvp=zero Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=10 active_threads=0 tvp=zero Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=11 active_threads=0 tvp=zero Jun 15 18:39:55 prd-ldap1-euc1 slapd[12041]: conn=1115 op=0 ldap_back_retry: retrying URI="ldaps://dsa.mycompany.com" DN="" Jun 15 18:40:05 prd-ldap1-euc1 slapd[12041]: send_ldap_result: conn=1115 op=0 p=3 Jun 15 18:40:05 prd-ldap1-euc1 slapd[12041]: send_ldap_result: err=52 matched="" text="Proxy operation retry failed" Jun 15 18:40:05 prd-ldap1-euc1 slapd[12041]: send_ldap_response: msgid=1 tag=97 err=52 Jun 15 18:40:05 prd-ldap1-euc1 slapd[12041]: conn=1115 op=0 RESULT tag=97 err=52 text=Proxy operation retry failed Jun 15 18:40:06 prd-ldap1-euc1 slapd[12041]: daemon: activity on 1 descriptor Jun 15 18:40:06 prd-ldap1-euc1 slapd[12041]: daemon: activity on:
Thanks
--On Wednesday, July 13, 2022 4:04 PM +0000 Tri Tu mtritu@yahoo.com wrote:
Hello,
I understand that with the pcacheOffline TRUE and the cache contents can be use indefinitely but its cache data never get refresh with remote DSA. It's not really useful once user is login 1st time and their user attributes would not get refresh with DSA after that.
But the default configuration option of pcacheOffline FALSE, pcache would use the local cached data, refresh with remote DSA and continues to response with its cached data when the DSA is cut off/unreachable. However if remote DSA is offline and the existing cached is expired, the client would get the respond with error "Proxy operation retry failed" as "cache is stale", pcache is checking with remote DSA for refresh but remote DSA is unreacheable offline.
Can we continue to use the existing expired cached data (the cache contents to be used indefinitely) with pcacheOffline FALSE until remote DSA is back online (days/weeks later)?
Hello,
You fail to note what version of OpenLDAP you're using which is an important piece of information to provide.
Regards, Quanah
Quanah Gibson-Mount wrote:
--On Wednesday, July 13, 2022 4:04 PM +0000 Tri Tu mtritu@yahoo.com wrote:
Can we continue to use the existing expired cached data (the cache contents to be used indefinitely) with pcacheOffline FALSE until remote DSA is back online (days/weeks later)?
Hello,
You fail to note what version of OpenLDAP you're using which is an important piece of information to provide.
The version is irrelevant here since he's basically asking for an enhancement.
The current version that I'm using is openldap-servers-2.4.44-23 but I guess that is not relevant to the features of the current pcache feature.
It would be great that if we have this as an enhancement feature so that when remote DSA is offline, pcache should ignore the refresh and continue to use the cached data indefinitely and refresh only if remote DSA is back online. Thanks
On Wednesday, July 13, 2022 at 10:25:29 AM PDT, Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, July 13, 2022 4:04 PM +0000 Tri Tu mtritu@yahoo.com wrote:
Can we continue to use the existing expired cached data (the cache contents to be used indefinitely) with pcacheOffline FALSE until remote DSA is back online (days/weeks later)?
Hello,
You fail to note what version of OpenLDAP you're using which is an important piece of information to provide.
The version is irrelevant here since he's basically asking for an enhancement.
--On Wednesday, July 13, 2022 9:05 PM +0000 Tri Tu mtritu@yahoo.com wrote:
It would be great that if we have this as an enhancement feature so that when remote DSA is offline, pcache should ignore the refresh and continue to use the cached data indefinitely and refresh only if remote DSA is back online.
File the feature request at https://bugs.openldap.org/
Regards, Quanah
openldap-technical@openldap.org
-
Howard Chu -
Quanah Gibson-Mount -
Tri Tu