On 01/21/2014 12:59 PM, Colin Tulloch wrote:
Thanks for those answers Rich - I forgot to change the subject line
from the naming conflict issue mail I sent!
I will try bumping the limits some and hitting some immediate ldap
searches.
It seemed to me that it went from err=11 to err=53 once I tried the
anonlimitsdn change. But I reverted that, and it stayed with err=53.
Any errors in the errors log?
Replications were ongoing, but at that time I made no other config
changes.
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Rich
Megginson
*Sent:* Tuesday, January 21, 2014 1:33 PM
*To:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] Naming conflict on hub/consumer
If the answers given below are not satisfactory, please file tickets
for all of these issues at https://fedorahosted.org/389/newticket.
Also, since you appear to be a Red Hat DS customer, please open cases
with RH support.
On 01/21/2014 12:19 PM, Colin Tulloch wrote:
Hi All –
I’ve got another one today.
We have 1 attribute in our infrastructure that’s extremely large –
it’s a PKI CRL that’s around 15MB. It sits in an entry that has
about 6300 sub entries.
That shouldn't necessarily be a problem. We have customers with 100MB
CRL entries.
We had some previously mentioned issues running out of file
descriptors on our consumers.
That's usually a matter of tuning.
After resolving those, we were getting err=11s on searches under that
entry, returning nentries=699,700,701. 700 didn’t make sense, but I
thought that the issue might be the search limit – these are
anonymous, so I tried the anonlimitsdn setting with a template, and
set it higher than 700. That wasn’t it.
err=11 is usually related to either 1) look through limit 2)
nsslapd-idlistscanlimit 3) unindexed searches.
We then started getting err=53s searching that entry – we don’t even
seem to get the err=11s anymore.
What changed? Something must have changed. Or are you saying that
for no reason, the exact same search under the exact same
circumstances began returning a different result?
These searches ARE showing up un-indexed. We have indexes for the
attributes though
The indexes are related to the search filter:
filter="(&(|(objectClass=cRLDistributionPoint)(objectClass=pkiCA))(cn=CRL*8))"
In this case, the objectclass equality index, and the cn substring
indexes. Both of these are indexed by default.
So it is likely due to nsslapd-idlistscanlimit being set too low for
this search.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes.html#About_Indexes-Overview_of_the_Searching_Algorithm
The nsslapd-idlistscanlimit is "the configured ID list scan limit".
– is it because of the ;binary versions?
Definitely not.
Example;
[21/Jan/2014:13:32:28 -0500] conn=37952 op=1 SRCH base="ou=Entrust
Managed Services SSP CA,ou=Certification Authorities,o=Entrust,c=US"
scope=2
filter="(&(|(objectClass=cRLDistributionPoint)(objectClass=pkiCA))(cn=CRL*8))"
attrs="authorityrevocationlist;binary authorityRevocationList
certificaterevocationlist;binary certificateRevocationList"
[21/Jan/2014:13:32:28 -0500] conn=37952 op=1 RESULT err=53 tag=101
nentries=0 etime=0 notes=U
--
389 users mailing list
[email protected] <mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users
