[389-users] Naming conflict on hub/consumer

Tue Jan 21 23:23:57 UTC 2014

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 at lists.fedoraproject.org 
> [mailto:389-users-bounces at 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 at lists.fedoraproject.org 
> <mailto:389-users-bounces at lists.fedoraproject.org> 
> [mailto:389-users-bounces at 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 at lists.fedoraproject.org 
> <mailto:389-users-bounces at lists.fedoraproject.org> 
> [mailto:389-users-bounces at 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 at lists.fedoraproject.org 
> <mailto:389-users-bounces at lists.fedoraproject.org> 
> [mailto:389-users-bounces at 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_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
> 389-users at lists.fedoraproject.org  <mailto:389-users at lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org  <mailto:389-users at lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org  <mailto:389-users at lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org  <mailto:389-users at lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20140121/4581cc72/attachment.html>