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.
and
include all of the information about your platform, version, and steps
to reproduce.
*==> 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
>>
>