Re: [389-users] Naming conflict on hub/consumer

[Colin Tulloch]

No, not showing up un-indexed anymore

From: 389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf

Re: [389-users] Naming conflict on hub/consumer

[Rich Megginson]

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-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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 fi

Re: [389-users] Naming conflict on hub/consumer

[Colin Tulloch]

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: 389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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

Re: [389-users] Naming conflict on hub/consumer

[Rich Megginson]

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-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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

Re: [389-users] Naming conflict on hub/consumer

[Rich Megginson]

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-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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

Re: [389-users] using passwd with 389

[Paul Robert Marino]

Are you using Kerberos?If so then the host needs a valid host keytab, a correct krb5.conf file and pam_krb5 configured.The documentation for doing this with Kerberos is common you should be able to find it easily.If its strait LDAP with no Kerberos that's a longer more drawn out conversation-- Sent from my HP Pre3On Jan 21, 2014 15:30, Chaudhari, Rohit K.  wrote: Hello,I want to be able to use the Unix "passwd" command to reset a LDAP user's password from the command line.  However, I keep getting an authentication token manipulation error whenever I try to reset the password using that command.  What do I need to do in the 389 DS or on Unix in order to get this command to work?Thanks,Rohit
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Naming conflict on hub/consumer

[Colin Tulloch]

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-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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 

Re: [389-users] Naming conflict on hub/consumer

[Rich Megginson]

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-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@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@lists.fedoraproject.org  
https://admin.fedoraproject.org/mailman/listinfo/389-users




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



--
389 users mailing list
389-users@lists.fedoraproject.org
htt

Re: [389-users] Naming conflict on hub/consumer

[Colin Tulloch]

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.  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-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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-boun...@lists.fedoraproject.org
 [mailto:389-users-boun...@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@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users





--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users

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

[389-users] using passwd with 389

[Chaudhari, Rohit K.]

Hello,

I want to be able to use the Unix "passwd" command to reset a LDAP user's 
password from the command line.  However, I keep getting an authentication 
token manipulation error whenever I try to reset the password using that 
command.  What do I need to do in the 389 DS or on Unix in order to get this 
command to work?

Thanks,

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

Re: [389-users] Naming conflict on hub/consumer

[Rich Megginson]

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-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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@lists.fedoraproject.org  
https://admin.fedoraproject.org/mailman/listinfo/389-users



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


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

Re: [389-users] Naming conflict on hub/consumer

[Colin Tulloch]

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.

Replications were ongoing, but at that time I made no other config changes.



From: 389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@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@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users

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

Re: [389-users] Naming conflict on hub/consumer

[Rich Megginson]

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


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

Re: [389-users] Naming conflict on hub/consumer

[Colin Tulloch]

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.

We had some previously mentioned issues running out of file descriptors on our 
consumers.

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.

We then started getting err=53s searching that entry - we don't even seem to 
get the err=11s anymore.  These searches ARE showing up un-indexed.  We have 
indexes for the attributes though - is it because of the ;binary versions?


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
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Naming conflict on hub/consumer

[Colin Tulloch]

RHDS 9.1
389-ds-base-1.2.11.15-30.el6_5.x86_64

From: 389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, January 21, 2014 11:55 AM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Naming conflict on hub/consumer

On 01/21/2014 10:47 AM, Colin Tulloch wrote:
Hi All –

We had a bundle of problems with our MM/consumer setup.  Ran of out FDs on the 
consumers, had the slapd process on a master die, etc.

Platform?  389-ds-base version?  rpm -q 389-ds-base


We’re getting things back up and running properly, but having some replication 
issues now.  We’ve got it mostly cleaned up – the masters are in sync, and all 
consumers but 1 hub.

However, 1 hub has 3 naming conflicts on an entry.  How can we resolve these?  
Since it’s read-only, the normal documented processes won’t work of course.  
The non-conflicted entry isn’t receiving updates from the masters.  We use the 
directory for PKI, and the entry contains a CRL that is going to expire – not 
good.

Do we need to just wait, and the actual entry will get updated at some point?  
With the errors we had, it seemed to take a long time for the directories to 
replicate around and catch up.




--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users

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

Re: [389-users] Naming conflict on hub/consumer

[Rich Megginson]

On 01/21/2014 10:47 AM, Colin Tulloch wrote:


Hi All –

We had a bundle of problems with our MM/consumer setup.  Ran of out 
FDs on the consumers, had the slapd process on a master die, etc.




Platform?  389-ds-base version?  rpm -q 389-ds-base


We’re getting things back up and running properly, but having some 
replication issues now.  We’ve got it mostly cleaned up – the masters 
are in sync, and all consumers but 1 hub.


However, 1 hub has 3 naming conflicts on an entry.  How can we resolve 
these?  Since it’s read-only, the normal documented processes won’t 
work of course.  The non-conflicted entry isn’t receiving updates from 
the masters.  We use the directory for PKI, and the entry contains a 
CRL that is going to expire – not good.


Do we need to just wait, and the actual entry will get updated at some 
point?  With the errors we had, it seemed to take a long time for the 
directories to replicate around and catch up.




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


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

[389-users] Naming conflict on hub/consumer

[Colin Tulloch]

Hi All -

We had a bundle of problems with our MM/consumer setup.  Ran of out FDs on the 
consumers, had the slapd process on a master die, etc.

We're getting things back up and running properly, but having some replication 
issues now.  We've got it mostly cleaned up - the masters are in sync, and all 
consumers but 1 hub.

However, 1 hub has 3 naming conflicts on an entry.  How can we resolve these?  
Since it's read-only, the normal documented processes won't work of course.  
The non-conflicted entry isn't receiving updates from the masters.  We use the 
directory for PKI, and the entry contains a CRL that is going to expire - not 
good.

Do we need to just wait, and the actual entry will get updated at some point?  
With the errors we had, it seemed to take a long time for the directories to 
replicate around and catch up.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Replication error

[Diego Woitasen]

On Mon, Jan 20, 2014 at 9:17 PM, Diego Woitasen  wrote:
> Hi,
>  I have a replication error with 389DS. If I try a full resync,
> replication works. But if I modify something after that, it fails. The
> only lines that I see in the logs are:
>
> [20/Jan/2014:21:12:50 -0300] - _csngen_adjust_local_time: gen state
> before 52ddb8ec0001:1390262479:0:29
> [20/Jan/2014:21:12:50 -0300] - _csngen_adjust_local_time: gen state
> after 52ddbb9f:1390263170:0:29
> [20/Jan/2014:21:12:50 -0300] NSMMReplicationPlugin -
> ruv_add_csn_inprogress: successfully inserted csn 52ddbb9f0063
> into pending list
> [20/Jan/2014:21:12:50 -0300] NSMMReplicationPlugin - Purged state
> information from entry
> uid=zzj,ou=People,ou=branch,ou=branches,dc=site,dc=ar up to CSN
> 52d47e6b0063
> [20/Jan/2014:21:12:50 -0300] NSMMReplicationPlugin - ruv_update_ruv:
> successfully committed csn 52ddbb9f0063
> [20/Jan/2014:21:12:50 -0300] NSMMReplicationPlugin - agmt="cn=main to
> cmald" (ldap:389): State: stop_fatal_error -> stop_fatal_error
>
> Not very helpful for me. The last line shows an error, but it's not
> very descriptive. What can I do to debug this? Or do you have a hint?
>
> Regards,
>   Diego
>

I've found the problem. Someone (may be me, not sure :) ) disabled the
changelog!




-- 
Diego Woitasen
Linux and Open Source solutions architect at www.vhgroup.net
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users