I’ll run it.
Now that the scan limits are higher, err=53s went away, but I’m back to err=11.
numResponses is 700, numEntries is 699, from an ldapsearch.
I found a whole mess of conflicted replication entries in that DN, which explains why we
went from err=11 to 53 – once the number of total entries went above the scan limit.
My size limits are 2000, and I tried an anonlimitsdn with a higher limit, but I’m either
doing that wrong, or theres something else. Why would it be limited to 700?
From: 389-users-bounces(a)lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, January 21, 2014 3:12 PM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Naming conflict on hub/consumer
On 01/21/2014 01:48 PM, Colin Tulloch wrote:
Nothing related to this except the search result errors.
I tinkered with the limits and got a search to give me returns. I made them massively
large (100k). I’ll work on tuning it down, but that looks like it was it. Thanks for the
help Rich!
What I can’t reconcile is that we have the same limits on the master directories, but
those don’t have issues. They must not be receiving anonymous searches on these DNs, or
even non-anonymous SEARCHES on them I guess.
You can use the logconv.pl tool to analyze the usage from your access logs.
They get written to and replicate from them just fine though – I need to understand LDAP
better ☺.
Now just on to the replication conflict issue, but I do have a ticket with redhat open for
that.
From:
389-users-bounces@lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org>
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, January 21, 2014 2:30 PM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Naming conflict on hub/consumer
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:
389-users-bounces@lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org>
[mailto:389-users-bounces@lists.fedoraproject.org] 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_Serv...
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
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users