Is this with the search
filter="(&(|(objectClass=cRLDistributionPoint)(objectClass=pkiCA))(cn=CRL*8))"
?
How many entries should match this filter?
*From:*389-users-bounces@lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] *On Behalf Of *Rich
Megginson
*Sent:* Tuesday, January 21, 2014 6:07 PM
*To:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] Naming conflict on hub/consumer
On 01/21/2014 04:38 PM, Colin Tulloch wrote:
We are, and it returns 699/700 entries with the err=11. Not sure
why that number, but I have a ticket with redhat going on it.
Focusing on the replication conflicts for now, but the 700 is odd.
Are you still getting notes=U in the access log for those searches?
Deleting these ones on the master – they’re separate from the 3
conflict entries on one of our read only hubs.
I followed the redhat solutions article on resolving replication
conflicts –
https://access.redhat.com/site/solutions/204783
Had to use some perl to replace part of the sed to get it working
properly.
*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 5:24 PM
*To:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] Naming conflict on hub/consumer
On 01/21/2014 03:54 PM, Colin Tulloch wrote:
I bumped idlistscanlimit from 8000 to 15000. 12000 didn’t quite
do it.
Are you still getting err=11?
That entry has 6170 conflicted entries, which basically doubled it. I
should’ve known, but I didn’t even realize that entry had any
conflicts. Once I got the ldapsearch on the nsds5replConflict
attribute working, that explained why the scan limit had to be
increased so much.
I’ve got those conflicts deleting now
How? This is on the read-only replica?
– just hoping they won’t come back.
*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 4:46 PM
*To:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] Naming conflict on hub/consumer
On 01/21/2014 02:45 PM, Colin Tulloch wrote:
I’ll run it.
Now that the scan limits are higher,
which scan limits, and how high are they?
Do you still have notes=U in the access log for the search?
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@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 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 J.
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(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users