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(a)mcon.net <mailto:scott.crooks@mcon.net> Phone: +86 10 8587 7441 Mobile: +86 138 1089 8314 http://www.mcon.net Logo 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(a)mcon.net <mailto:scott.crooks@mcon.net> >> Phone: +86 10 8587 7441 >> Mobile: +86 138 1089 8314 >> http://www.mcon.net >> >> Logo >> >> >> >> 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(a)mcon.net <mailto:scott.crooks@mcon.net> >> Phone: +86 10 8587 7441 >> Mobile: +86 138 1089 8314 >> http://www.mcon.net >> >> Logo >> >> >> >> 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(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> >> >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >