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.
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: [email protected] [mailto:[email protected]] 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] 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: [email protected]<mailto:[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]<mailto:[email protected]> https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list [email protected]<mailto:[email protected]> https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list [email protected]<mailto:[email protected]> https://admin.fedoraproject.org/mailman/listinfo/389-users -- 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
