Untitled Document

Rich,

We tried setting the dnaMagicRegen variable to a number outside of our range for all of the servers; this did not work. Here's a full excerpt of the error and access logs when we try to create a user.

==> errors <==
[27/Mar/2013:09:58:17 +0800] - Event id 1e40250 called at 1364349497 (scheduled for 1364349497)
[27/Mar/2013:09:58:17 +0800] - Event id 20825d0 called at 1364349497 (scheduled for 1364349497)
[27/Mar/2013:09:58:17 +0800] - cos_cache_vattr_types: failed to get class of service reference
[27/Mar/2013:09:58:17 +0800] - cos_cache_vattr_types: failed to get class of service reference
[27/Mar/2013:09:58:17 +0800] - cos_cache_vattr_types: failed to get class of service reference
[27/Mar/2013:09:58:17 +0800] - cos_cache_vattr_types: failed to get class of service reference
[27/Mar/2013:09:58:17 +0800] NS7bitAttr - ADD begin
[27/Mar/2013:09:58:17 +0800] NS7bitAttr - ADD target=uid=sc,ou=Organizations,dc=test,dc=net
[27/Mar/2013:09:58:17 +0800] NS7bitAttr - ADD subtree=dc=test,dc=net
[27/Mar/2013:09:58:17 +0800] NS7bitAttr - 7-bit checking begin
[27/Mar/2013:09:58:17 +0800] NS7bitAttr - 7 bit check result = 0
[27/Mar/2013:09:58:17 +0800] NSUniqueAttr - ADD begin
[27/Mar/2013:09:58:17 +0800] NSUniqueAttr - ADD parameter untagged: uid
[27/Mar/2013:09:58:17 +0800] NSUniqueAttr - ADD target=uid=sc,ou=Organizations,dc=test,dc=net
[27/Mar/2013:09:58:17 +0800] NSUniqueAttr - SEARCH baseDN=dc=test,dc=net attr=uid target=uid=sc,ou=Organizations,dc=test,dc=net
[27/Mar/2013:09:58:17 +0800] NSUniqueAttr - SEARCH filter=uid=sc
[27/Mar/2013:09:58:17 +0800] NSUniqueAttr - SEARCH complete result=0
[27/Mar/2013:09:58:17 +0800] NSUniqueAttr - SEARCH result = 0
[27/Mar/2013:09:58:17 +0800] dna-plugin - dna_pre_op: failed to allocate a new ID!!
[27/Mar/2013:09:58:17 +0800] dna-plugin - dna_pre_op: operation failure [1]
[27/Mar/2013:09:58:17 +0800] roles-plugin - --> roles_post_op
[27/Mar/2013:09:58:17 +0800] roles-plugin - --> roles_cache_change_notify
[27/Mar/2013:09:58:17 +0800] roles-plugin - <-- roles_post_op
[27/Mar/2013:09:58:17 +0800] roles-plugin - --> roles_post_op
[27/Mar/2013:09:58:17 +0800] roles-plugin - --> roles_cache_change_notify
[27/Mar/2013:09:58:17 +0800] roles-plugin - <-- roles_post_op
[27/Mar/2013:09:58:20 +0800] - Event id 255b7c0 called at 1364349500 (scheduled for 1364349500)
[27/Mar/2013:09:58:20 +0800] - Event id 256a290 called at 1364349500 (scheduled for 1364349500)
[27/Mar/2013:09:58:20 +0800] - Event id 25583f0 called at 1364349500 (scheduled for 1364349500)
[27/Mar/2013:09:58:20 +0800] - Event id 2569b80 called at 1364349500 (scheduled for 1364349500)
[27/Mar/2013:09:58:20 +0800] - Event id 258bbb0 called at 1364349500 (scheduled for 1364349500)
[27/Mar/2013:09:58:20 +0800] - Event id 258a290 called at 1364349500 (scheduled for 1364349500)
[27/Mar/2013:09:58:27 +0800] - Event id 20825d0 called at 1364349507 (scheduled for 1364349507)

==> access <==
[27/Mar/2013:10:04:12 +0800] conn=4018 op=23 SRCH base="ou=Organizations,dc=test,dc=net" scope=0 filter="(objectClass=*)" attrs=ALL
[27/Mar/2013:10:04:12 +0800] conn=4018 op=23 RESULT err=0 tag=101 nentries=1 etime=0
[27/Mar/2013:10:04:12 +0800] conn=4018 op=24 SRCH base="o=TestCompany,ou=Organizations,dc=test,dc=net" scope=0 filter="(objectClass=*)" attrs=ALL
[27/Mar/2013:10:04:12 +0800] conn=4018 op=24 RESULT err=0 tag=101 nentries=1 etime=0
[27/Mar/2013:10:04:12 +0800] conn=4018 op=25 SRCH base="ou=Users,o=TestCompany,ou=Organizations,dc=test,dc=net" scope=0 filter="(objectClass=*)" attrs=ALL
[27/Mar/2013:10:04:12 +0800] conn=4018 op=25 RESULT err=0 tag=101 nentries=1 etime=0
[27/Mar/2013:10:04:12 +0800] conn=4018 op=26 SRCH base="ou=HAM,ou=Users,o=TestCompany,ou=Organizations,dc=test,dc=net" scope=0 filter="(objectClass=*)" attrs=ALL
[27/Mar/2013:10:04:12 +0800] conn=4018 op=26 RESULT err=0 tag=101 nentries=1 etime=0
[27/Mar/2013:10:04:12 +0800] conn=4018 op=27 ADD dn="uid=sc,ou=HAM,ou=Users,o=TestCompany,ou=Organizations,dc=test,dc=net"
[27/Mar/2013:10:04:12 +0800] conn=4018 op=27 RESULT err=1 tag=105 nentries=0 etime=0
[27/Mar/2013:10:04:12 +0800] conn=4018 op=28 DEL dn="uid=sc,ou=HAM,ou=Users,o=TestCompany,ou=Organizations,dc=test,dc=net"
[27/Mar/2013:10:04:12 +0800] conn=4018 op=28 RESULT err=32 tag=107 nentries=0 etime=0
[27/Mar/2013:10:04:22 +0800] conn=4025 op=-1 fd=159 closed - B1
[27/Mar/2013:10:04:22 +0800] conn=4028 op=-1 fd=302 closed - B1
[27/Mar/2013:10:04:22 +0800] conn=4030 op=-1 fd=304 closed - B1
[27/Mar/2013:10:04:24 +0800] conn=4026 op=-1 fd=274 closed - B1
[27/Mar/2013:10:04:24 +0800] conn=4027 op=-1 fd=295 closed - B1
[27/Mar/2013:10:04:24 +0800] conn=4029 op=-1 fd=303 closed - B1

Untitled Document

Best Regards

Scott Crooks
Systems Engineer

scott.crooks@mcon.net
Phone: +86 10 8587 7441
Mobile: +86 138 1089 8314
http://www.mcon.net

MCON China Ltd.
Suite 1202, e-Tower
12C Guanghua Road
Chaoyang District
Beijing 100020

埃蒙坎信息系统集成技术(北京)有限公司
中国北京市朝阳区光华路丙12号
数码01大厦1202室
邮编：100020

Member of mcon group: Australia • Austria • China • Czech Republic • Germany • India • Japan • Malaysia • Russia • South Korea • Switzerland • USA

On 03/26/2013 01:46 AM, Rich Megginson wrote:

On 03/25/2013 10:07 AM, Soeren Malchow wrote:

Untitled Document

Hi Rich,

we tried the methods described in Nathans post, specifically indexing the nummer assingned through DNA including the nsMatchingRule, when indexing, the index processes exactly 1000 entries and 98% and stops though there are 1017 entries in the database.

Does the index process hang? Or does it just report 98% and complete normally? You can use dbscan to find out exactly what's in the index.

The nsslapd-idlistscanlimit is at the default of 4000 (though we also tried increasing it inbetween)

To

From dse.ldif

<- snip->

nsslapd-idlistscanlimit: 4000

nsslapd-pagedidlistscanlimit: 0

<-snip->

That isn't used for creating indexes.

The other four databases have much less entries and there is no problem.

Increasing the loglevel does not give anymore information, I think I even found the code somewhere the is responsible for the error message and for me it does not really help.

The only other numbr that is “1000” is the dnaThreshold but that should not have anything to do with it, nevertheless I tried increasing it to 2000 to see if anything changes.

This is the DNA onfiguration from dse.ldif

ß snip à

dn: cn=organization-employeeNumbers,cn=Distributed Numeric Assignment Plugin,c

n=plugins,cn=config

objectClass: top

objectClass: extensibleObject

dnaNextValue: 220380

dnaMaxValue: 249999

dnaSharedCfgDN: cn=organizations-employeeNumbers,ou=Ranges,ou=Organizations,dc

=XXX,dc=XXX

dnaThreshold: 2000

dnaType: employeeNumber

dnaScope: ou=Organizations,dc=XXX,dc=XXX

dnaFilter: (objectclass=inetOrgPerson)

dnaMagicRegen: magic

This is a problem, but not perhaps the only problem. If employeeNumber is INTEGER syntax, "magic" is not a valid value for an integer. Pick a number that cannot possibly be in your range.

cn: organization-employeeNumbers

creatorsName: cn=directory manager

modifiersName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo

t

createTimestamp: 20120831184744Z

modifyTimestamp: 20130322022625Z

ß snip à

Unfortunately we are stuck and can’t find anymore to go on.

I already tried deleting a lot of users (approximately 50 with the DNA attribute) trying to index again still tells me it indexed 1000 entries (98%)

And still it is not possible to create users, the Apache Directory Studio displays the following error

ß snip à

Error while creating entry

- [LDAP: error code 1 - Allocation of a new value for range cn=organization-employeenumbers,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed.]

java.lang.Exception: [LDAP: error code 1 - Allocation of a new value for range cn=organization-employeenumbers,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed.]

               at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1271)

               at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:110)

               at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$6.run(DirectoryApiConnectionWrapper.java:926)

               at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1173)

               at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkConnectionAndRunAndMonitor(DirectoryApiConnectionWrapper.java:1107)

               at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.createEntry(DirectoryApiConnectionWrapper.java:948)

               at org.apache.directory.studio.ldapbrowser.core.jobs.CreateEntryRunnable.createEntry(CreateEntryRunnable.java:224)

               at org.apache.directory.studio.ldapbrowser.core.jobs.CreateEntryRunnable.run(CreateEntryRunnable.java:124)

               at org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:113)

               at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

[LDAP: error code 1 - Allocation of a new value for range cn=organization-employeenumbers,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed.]

ß snip à

Any hint how to pinpoint the problem

Can you post the excerpt from the directory server access and errors log from around the time of the apache ds error showing the corresponding 389 ds errors?

Thanks

Soeren

From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Montag, 25. März 2013 23:24
To: Scott Crooks
Cc: General discussion list for the 389 Directory server project.; Soeren Malchow
Subject: Re: [389-users] Distributed Numeric Assignment plugin fails with indexing

On 03/24/2013 10:08 PM, Scott Crooks wrote:

Rich,

Here's the information you requested.

389-ds-base-1.2.11.15-12.el6_4.x86_64 is the version, from the EPEL 6 repositories.

To be more specific, the indexes for that particular database (ou=Organizations,dc=test,dc=net) are exactly at 1000,

I'm still not sure what you mean by 1000 - where does this number come from?

Nathan's post had some good information for getting more information about DNA.
but the database has 1017 entries. There are 953 users (inetOrgPerson's) in the tree (ou=Organizations,dc=test,dc=net) that also have the employeeNumber attribute that are managed by DNA.

The database for ou=Organizations,dc=test,dc=net is actually comprised of 4 databases. It's set-up like this:

1. Company 1: o=Company1,ou=Organizations,dc=test,dc=net has it's own database
2. Company 2: o=Company2,ou=Organizations,dc=test,dc=net has it's own database
3. Company 3: o=Company3,ou=Organizations,dc=test,dc=net has it's own database
4. All other companies fall within the ou=Organizations,dc=test,dc=net database.

The database mentioned above that has 1017 entries is just the ou=Organizations,dc=test,dc=net one.

If you want I can provide exact numbers for the others.

Best Regards

Scott Crooks
Systems Engineer

scott.crooks@mcon.net
Phone: +86 10 8587 7441
Mobile: +86 138 1089 8314
http://www.mcon.net

MCON China Ltd.
Suite 1202, e-Tower
12C Guanghua Road
Chaoyang District
Beijing 100020

埃蒙坎信息系统集成技术(北京)有限公司
中国北京市朝阳区光华路丙12号
数码01大厦1202室
邮编：100020

Member of mcon group: Australia • Austria • China • Czech Republic • Germany • India • Japan • Malaysia • Russia • South Korea • Switzerland • USA

On 03/22/2013 11:57 PM, Rich Megginson wrote:
On 03/22/2013 03:24 AM, Scott Crooks wrote:

Greetings,

We're using 389-ds on CentOS 6.4

What version of 389-ds-base? rpm -q 389-ds-base

with 3 master LDAP servers in different locations. All three master servers have a problem adding new users in our organization database using the DNA plugin.

We receive the following (unhelpful) error message in the log files:

[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD begin
[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD parameter untagged: uid
[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD target=cn=testuser01,ou=Organizations,dc=test,dc=net
[22/Mar/2013:09:54:37 +0800] dna-plugin - dna_pre_op: failed to allocate a new ID!!
[22/Mar/2013:09:54:37 +0800] dna-plugin - dna_pre_op: operation failure [1]
[22/Mar/2013:09:54:37 +0800] roles-plugin - --> roles_post_op
[22/Mar/2013:09:54:37 +0800] roles-plugin - --> roles_cache_change_notify
[22/Mar/2013:09:54:37 +0800] roles-plugin - <-- roles_post_op

We've tried indexing the uidNumber and employeeNumber attributes as described here: http://www.spinics.net/linux/fedora/389-users/msg10796.html

One curious fact: there are exactly 1000 users in our database for ou=Organizations,dc=test,dc=net. When following the instructions for the above link, the log outputs the following

organizations: Indexing attribute: employeenumber
organizations: Indexed 1000 entries (97%).
organizations: Finished indexing.

Our organization uses employeenumber rather than uidNumber, but they're the same in the end. We find it strange that the user creation fails at exactly 1000 entries.

What do you mean "user creation fails at exactly 1000 entries"? Do you mean "after adding the 1000th user entry"? The error above is from attempting to add cn=testuser01 - was that the 1000th user entry?
Any ideas on where the configuration is wrong? We assume it's a configuration problem.

Best Regards

Scott Crooks
Systems Engineer

scott.crooks@mcon.net
Phone: +86 10 8587 7441
Mobile: +86 138 1089 8314
http://www.mcon.net

MCON China Ltd.
Suite 1202, e-Tower
12C Guanghua Road
Chaoyang District
Beijing 100020

埃蒙坎信息系统集 成技术(北京)有限公司
中国北京市朝阳区光华路丙12号
数码01大厦1202室
邮编：100020

Member of mcon group: Australia • Austria • China • Czech Republic • Germany • India • Japan • Malaysia • Russia • South Korea • Switzerland • USA
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users