Re: Naming conflict on hub/consumer

Colin Tulloch <Colin.Tulloch@xxxxxxxxxxx> · Tue, 21 Jan 2014 22:54:51 +0000

I bumped idlistscanlimit from 8000 to 15000.  12000 didn’t quite do it.

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 – just hoping they won’t come back.

From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx]
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@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx]
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@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx]
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@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx]
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users