FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 04-29-2011, 01:44 PM
Reinhard Nappert
 
Default Referral errors ....

Hi,
*
I have the following
setup:
*
I have a 2
multimaster replication setup, where both masters also have a number of
shadowing agreements to other consumers. The data gets replicated to all boxes
and there are no issues. When I try to perform an update on the slaves, it works
on all, but one. Meaning, the server sends back err=10, with the referral to one
of the masters and the client automatically follows the referrals.
Unfortunately, it does not works with one box:
*
When there is an
attempt to write to the db, the server returns an error-code 1, with the
following message:
javax.naming.NamingException: [LDAP: error code
1 - Mapping tree node for o=base is set to return a referral, but no referral is
configured for it];
*
This can also be seen in the access
file:

[26/Apr/2011:05:35:45 -0300]
conn=3418 op=13256 ADD dn="ou=test,o=base"
[26/Apr/2011:05:35:45 -0300] conn=3418
op=13256 RESULT err=1 tag=105 nentries=0 etime=0

When I have a look at the
configuration, it looks exactly like the others:
dn: cn="o=Base",cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: "o=Base"
nsslapd-state: referral on update
nsslapd-backend: userRoot
modifiersName: cn=server,cn=plugins,cn=config
modifyTimestamp: 20100721202730Z
nsslapd-referral: ldap://master-ld01:389/o=Base
nsslapd-referral: ldap://master-ld02:389/o=Base
numSubordinates: 1dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
nsDS5ReplicaBindDN: cn=replication,cn=config
nsDS5ReplicaRoot: o=Base
nsDS5Flags: 0
nsDS5ReplicaType: 2
nsds5ReplicaPurgeDelay: 43200
objectClass: top
objectClass: nsDS5Replica
cn: replica
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
modifyTimestamp: 20110421052744Z
nsDS5ReplicaId: 65535
nsState:: //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
nsDS5ReplicaReferral: ldap://master-ld02:389/o=Base*I was wondering if someone has seen this kind of issue. Everything looks fine to me and I can not explain this behavior. *Right now, I can not reproduce this issue. I only see it in this one setup.*Thanks,-Reinhard
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-04-2011, 03:50 PM
Reinhard Nappert
 
Default Referral errors ....

No replies so far. Does this mean nobody has seen this issue
before?
*
-Reinhard



From: 389-users-bounces@lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Reinhard
Nappert
Sent: Friday, April 29, 2011 9:44 AM
To:
389-users@lists.fedoraproject.org
Subject: [389-users] Referral errors
....



Hi,
*
I have the following
setup:
*
I have a 2
multimaster replication setup, where both masters also have a number of
shadowing agreements to other consumers. The data gets replicated to all boxes
and there are no issues. When I try to perform an update on the slaves, it works
on all, but one. Meaning, the server sends back err=10, with the referral to one
of the masters and the client automatically follows the referrals.
Unfortunately, it does not works with one box:
*
When there is an
attempt to write to the db, the server returns an error-code 1, with the
following message:
javax.naming.NamingException: [LDAP: error code
1 - Mapping tree node for o=base is set to return a referral, but no referral is
configured for it];
*
This can also be seen in the access
file:

[26/Apr/2011:05:35:45 -0300]
conn=3418 op=13256 ADD dn="ou=test,o=base"
[26/Apr/2011:05:35:45 -0300] conn=3418
op=13256 RESULT err=1 tag=105 nentries=0 etime=0

When I have a look at the
configuration, it looks exactly like the others:
dn: cn="o=Base",cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: "o=Base"
nsslapd-state: referral on update
nsslapd-backend: userRoot
modifiersName: cn=server,cn=plugins,cn=config
modifyTimestamp: 20100721202730Z
nsslapd-referral: ldap://master-ld01:389/o=Base
nsslapd-referral: ldap://master-ld02:389/o=Base
numSubordinates: 1dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
nsDS5ReplicaBindDN: cn=replication,cn=config
nsDS5ReplicaRoot: o=Base
nsDS5Flags: 0
nsDS5ReplicaType: 2
nsds5ReplicaPurgeDelay: 43200
objectClass: top
objectClass: nsDS5Replica
cn: replica
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
modifyTimestamp: 20110421052744Z
nsDS5ReplicaId: 65535
nsState:: //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
nsDS5ReplicaReferral: ldap://master-ld02:389/o=Base*I was wondering if someone has seen this kind of issue. Everything looks fine to me and I can not explain this behavior. *Right now, I can not reproduce this issue. I only see it in this one setup.*Thanks,-Reinhard
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-04-2011, 03:57 PM
Richard Megginson
 
Default Referral errors ....

> No replies so far. Does this mean nobody has seen this issue before?

I have not seen this.

Any errors in the errors log?
*
> -Reinhard
>
>
> From: 389-users-bounces@lists.fedoraproject.org
> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
> Reinhard Nappert
> Sent: Friday, April 29, 2011 9:44 AM
> To: 389-users@lists.fedoraproject.org
> Subject: [389-users] Referral errors ....
>
>
>
> Hi,
> *
> I have the following setup:
> *
> I have a 2 multimaster replication setup, where both masters also have
> a number of shadowing agreements to other consumers. The data gets
> replicated to all boxes and there are no issues. When I try to perform
> an update on the slaves, it works on all, but one. Meaning, the server
> sends back err=10, with the referral to one of the masters and the
> client automatically follows the referrals. Unfortunately, it does not
> works with one box:
> *
> When there is an attempt to write to the db, the server returns an
> error-code 1, with the following message:
> javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node
> for o=base is set to return a referral, but no referral is configured
> for it];
> *
> This can also be seen in the access file:
>
>
> [ 26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 ADD dn="o u = test
> ,o= base "
> [26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 RESULT err=1 tag=105
> nentries=0 etime=0
>
> When I have a look at the configuration, it looks exactly like the
> others: dn: cn="o=Base",cn=mapping tree,cn=config objectClass: top
> objectClass: extensibleObject objectClass: nsMappingTree cn: "o=Base"
> nsslapd-state: referral on update nsslapd-backend: userRoot
> modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp:
> 20100721202730Z nsslapd-referral: ldap://master-ld01:389/o=Base
> nsslapd-referral : ldap://master-ld02:389/o=Base numSubordinates : 1
> dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
> nsDS5ReplicaBindDN: cn=replication,cn=config nsDS5ReplicaRoot: o=Base
> nsDS5Flags: 0 nsDS5ReplicaType: 2 nsds5ReplicaPurgeDelay: 43200
> objectClass: top objectClass: nsDS5Replica cn: replica modifiersName:
> cn=Multimaster Replication Plugin,cn=plugins,cn=config
> modifyTimestamp: 20110421052744Z nsDS5ReplicaId: 65535 nsState::
> //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
> nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
> nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
> nsDS5ReplicaReferral : ldap://master-ld02:389/o=Base * I was wondering
> if someone has seen this kind of issue. Everything looks fine to me
> and I can not explain this behavior. * Right now, I can not reproduce
> this issue. I only see it in this one setup. * Thanks, -Reinhard
> --
> 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
 
Old 05-04-2011, 04:00 PM
Reinhard Nappert
 
Default Referral errors ....

No, errors looks fine and as you see below the configuration looks fine as well.

When is this specific error description (Mapping tree node for <db> is set to return a referral, but no referral is configured for it) thrown?

-Reinhard

-----Original Message-----
From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Richard Megginson
Sent: Wednesday, May 04, 2011 11:57 AM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Referral errors ....

> No replies so far. Does this mean nobody has seen this issue before?

I have not seen this.

Any errors in the errors log?
*
> -Reinhard
>
>
> From: 389-users-bounces@lists.fedoraproject.org
> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
> Reinhard Nappert
> Sent: Friday, April 29, 2011 9:44 AM
> To: 389-users@lists.fedoraproject.org
> Subject: [389-users] Referral errors ....
>
>
>
> Hi,
> *
> I have the following setup:
> *
> I have a 2 multimaster replication setup, where both masters also have
> a number of shadowing agreements to other consumers. The data gets
> replicated to all boxes and there are no issues. When I try to perform
> an update on the slaves, it works on all, but one. Meaning, the server
> sends back err=10, with the referral to one of the masters and the
> client automatically follows the referrals. Unfortunately, it does not
> works with one box:
> *
> When there is an attempt to write to the db, the server returns an
> error-code 1, with the following message:
> javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node
> for o=base is set to return a referral, but no referral is configured
> for it];
> *
> This can also be seen in the access file:
>
>
> [ 26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 ADD dn="o u = test
> ,o= base "
> [26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 RESULT err=1 tag=105
> nentries=0 etime=0
>
> When I have a look at the configuration, it looks exactly like the
> others: dn: cn="o=Base",cn=mapping tree,cn=config objectClass: top
> objectClass: extensibleObject objectClass: nsMappingTree cn: "o=Base"
> nsslapd-state: referral on update nsslapd-backend: userRoot
> modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp:
> 20100721202730Z nsslapd-referral: ldap://master-ld01:389/o=Base
> nsslapd-referral : ldap://master-ld02:389/o=Base numSubordinates : 1
> dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
> nsDS5ReplicaBindDN: cn=replication,cn=config nsDS5ReplicaRoot: o=Base
> nsDS5Flags: 0 nsDS5ReplicaType: 2 nsds5ReplicaPurgeDelay: 43200
> objectClass: top objectClass: nsDS5Replica cn: replica modifiersName:
> cn=Multimaster Replication Plugin,cn=plugins,cn=config
> modifyTimestamp: 20110421052744Z nsDS5ReplicaId: 65535 nsState::
> //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
> nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
> nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
> nsDS5ReplicaReferral : ldap://master-ld02:389/o=Base * I was wondering
> if someone has seen this kind of issue. Everything looks fine to me
> and I can not explain this behavior. * Right now, I can not reproduce
> this issue. I only see it in this one setup. * Thanks, -Reinhard
> --
> 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
 
Old 05-04-2011, 09:32 PM
Reinhard Nappert
 
Default Referral errors ....

Rich,

I was able to get one box in this situation (not sure, how though). Do you want me do change some accesslog-levels or errorlog-levels?

Now would be a good time to gather more information

-Reinhard

-----Original Message-----
From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Richard Megginson
Sent: Wednesday, May 04, 2011 11:57 AM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Referral errors ....

> No replies so far. Does this mean nobody has seen this issue before?

I have not seen this.

Any errors in the errors log?
*
> -Reinhard
>
>
> From: 389-users-bounces@lists.fedoraproject.org
> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
> Reinhard Nappert
> Sent: Friday, April 29, 2011 9:44 AM
> To: 389-users@lists.fedoraproject.org
> Subject: [389-users] Referral errors ....
>
>
>
> Hi,
> *
> I have the following setup:
> *
> I have a 2 multimaster replication setup, where both masters also have
> a number of shadowing agreements to other consumers. The data gets
> replicated to all boxes and there are no issues. When I try to perform
> an update on the slaves, it works on all, but one. Meaning, the server
> sends back err=10, with the referral to one of the masters and the
> client automatically follows the referrals. Unfortunately, it does not
> works with one box:
> *
> When there is an attempt to write to the db, the server returns an
> error-code 1, with the following message:
> javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node
> for o=base is set to return a referral, but no referral is configured
> for it];
> *
> This can also be seen in the access file:
>
>
> [ 26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 ADD dn="o u = test
> ,o= base "
> [26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 RESULT err=1 tag=105
> nentries=0 etime=0
>
> When I have a look at the configuration, it looks exactly like the
> others: dn: cn="o=Base",cn=mapping tree,cn=config objectClass: top
> objectClass: extensibleObject objectClass: nsMappingTree cn: "o=Base"
> nsslapd-state: referral on update nsslapd-backend: userRoot
> modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp:
> 20100721202730Z nsslapd-referral: ldap://master-ld01:389/o=Base
> nsslapd-referral : ldap://master-ld02:389/o=Base numSubordinates : 1
> dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
> nsDS5ReplicaBindDN: cn=replication,cn=config nsDS5ReplicaRoot: o=Base
> nsDS5Flags: 0 nsDS5ReplicaType: 2 nsds5ReplicaPurgeDelay: 43200
> objectClass: top objectClass: nsDS5Replica cn: replica modifiersName:
> cn=Multimaster Replication Plugin,cn=plugins,cn=config
> modifyTimestamp: 20110421052744Z nsDS5ReplicaId: 65535 nsState::
> //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
> nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
> nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
> nsDS5ReplicaReferral : ldap://master-ld02:389/o=Base * I was wondering
> if someone has seen this kind of issue. Everything looks fine to me
> and I can not explain this behavior. * Right now, I can not reproduce
> this issue. I only see it in this one setup. * Thanks, -Reinhard
> --
> 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
 
Old 05-04-2011, 09:42 PM
Rich Megginson
 
Default Referral errors ....

On 05/04/2011 03:32 PM, Reinhard Nappert wrote:
> Rich,
>
> I was able to get one box in this situation (not sure, how though). Do you want me do change some accesslog-levels or errorlog-levels?
Try 4 Heavy trace output debugging
http:http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting//directory.fedoraproject.org/wiki/FAQ#Troubleshooting


> Now would be a good time to gather more information
>
> -Reinhard
>
> -----Original Message-----
> From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Richard Megginson
> Sent: Wednesday, May 04, 2011 11:57 AM
> To: General discussion list for the 389 Directory server project.
> Subject: Re: [389-users] Referral errors ....
>
>> No replies so far. Does this mean nobody has seen this issue before?
> I have not seen this.
>
> Any errors in the errors log?
>
>> -Reinhard
>>
>>
>> From: 389-users-bounces@lists.fedoraproject.org
>> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
>> Reinhard Nappert
>> Sent: Friday, April 29, 2011 9:44 AM
>> To: 389-users@lists.fedoraproject.org
>> Subject: [389-users] Referral errors ....
>>
>>
>>
>> Hi,
>>
>> I have the following setup:
>>
>> I have a 2 multimaster replication setup, where both masters also have
>> a number of shadowing agreements to other consumers. The data gets
>> replicated to all boxes and there are no issues. When I try to perform
>> an update on the slaves, it works on all, but one. Meaning, the server
>> sends back err=10, with the referral to one of the masters and the
>> client automatically follows the referrals. Unfortunately, it does not
>> works with one box:
>>
>> When there is an attempt to write to the db, the server returns an
>> error-code 1, with the following message:
>> javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node
>> for o=base is set to return a referral, but no referral is configured
>> for it];
>>
>> This can also be seen in the access file:
>>
>>
>> [ 26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 ADD dn="o u = test
>> ,o= base "
>> [26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 RESULT err=1 tag=105
>> nentries=0 etime=0
>>
>> When I have a look at the configuration, it looks exactly like the
>> others: dn: cn="o=Base",cn=mapping tree,cn=config objectClass: top
>> objectClass: extensibleObject objectClass: nsMappingTree cn: "o=Base"
>> nsslapd-state: referral on update nsslapd-backend: userRoot
>> modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp:
>> 20100721202730Z nsslapd-referral: ldap://master-ld01:389/o=Base
>> nsslapd-referral : ldap://master-ld02:389/o=Base numSubordinates : 1
>> dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
>> nsDS5ReplicaBindDN: cn=replication,cn=config nsDS5ReplicaRoot: o=Base
>> nsDS5Flags: 0 nsDS5ReplicaType: 2 nsds5ReplicaPurgeDelay: 43200
>> objectClass: top objectClass: nsDS5Replica cn: replica modifiersName:
>> cn=Multimaster Replication Plugin,cn=plugins,cn=config
>> modifyTimestamp: 20110421052744Z nsDS5ReplicaId: 65535 nsState::
>> //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
>> nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
>> nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
>> nsDS5ReplicaReferral : ldap://master-ld02:389/o=Base I was wondering
>> if someone has seen this kind of issue. Everything looks fine to me
>> and I can not explain this behavior. Right now, I can not reproduce
>> this issue. I only see it in this one setup. Thanks, -Reinhard
>> --
>> 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 mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-04-2011, 09:59 PM
Reinhard Nappert
 
Default Referral errors ....

I actually tried even a bit more 1+2+4+65536=65543.

I tried to add the object uid=stibbons,ou=admins,o=operator
s,o=UMC.

I tried to add it at (from access file):
[04/May/2011:17:40:32 -0400] conn=83 op=51 SRCH base="uid=stibbons,ou=admins,o=o
perators,o=UMC" scope=0 filter="(objectClass=*)" attrs=ALL
[04/May/2011:17:40:32 -0400] conn=83 op=51 RESULT err=32 tag=101 nentries=0 etim
e=0
[04/May/2011:17:40:32 -0400] conn=83 op=52 ADD dn="uid=stibbons,ou=admins,o=oper
ators,o=UMC"
[04/May/2011:17:40:32 -0400] conn=83 op=52 RESULT err=1 tag=105 nentries=0 etime
=0

Here is what you see in errors:

[04/May/2011:17:40:32 -0400] - mapping tree release backend : userRoot
[04/May/2011:17:40:32 -0400] - do_search
[04/May/2011:17:40:32 -0400] - SRCH base="uid=stibbons,ou=admins,o=operators,o=UMC" scope=0 deref=3 sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs=ALL
[04/May/2011:17:40:32 -0400] - => get_ldapmessage_controls
[04/May/2011:17:40:32 -0400] - <= get_ldapmessage_controls no controls
[04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.3)
[04/May/2011:17:40:32 -0400] - <= slapi_control_present 0 (NO CONTROLS)
[04/May/2011:17:40:32 -0400] - mtn_lock : lock count : 1
[04/May/2011:17:40:32 -0400] - mapping tree selected backend : userRoot
[04/May/2011:17:40:32 -0400] - mtn_unlock : lock count : 0
[04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c678, handle=2
[04/May/2011:17:40:32 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c678, handle=1
[04/May/2011:17:40:32 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[04/May/2011:17:40:32 -0400] - => compute_limits: sizelimit=2000, timelimit=3600
[04/May/2011:17:40:32 -0400] - Calling plugin 'ACL preoperation' #1 type 403
[04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.12)
[04/May/2011:17:40:32 -0400] - <= slapi_control_present 0 (NO CONTROLS)
[04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.18)
[04/May/2011:17:40:32 -0400] - <= slapi_control_present 0 (NO CONTROLS)
[04/May/2011:17:40:32 -0400] - Calling plugin 'Legacy replication preoperation plugin' #3 type 403
[04/May/2011:17:40:32 -0400] - Calling plugin 'Multimaster replication preoperation plugin' #4 type 403
[04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c678, handle=0
[04/May/2011:17:40:32 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[04/May/2011:17:40:32 -0400] - => find_entry_internal (dn=uid=stibbons,ou=admins,o=operators,o=umc) lock 0
[04/May/2011:17:40:32 -0400] - => dn2entry "uid=stibbons,ou=admins,o=operators,o=umc"
[04/May/2011:17:40:32 -0400] - => index_read( "entrydn" = "uid=stibbons,ou=admins,o=operators,o=umc" )
[04/May/2011:17:40:32 -0400] - indextype: "eq" indexmask: 0x2
[04/May/2011:17:40:32 -0400] - <= index_read 0 candidates
[04/May/2011:17:40:32 -0400] - <= dn2entry 0
[04/May/2011:17:40:32 -0400] - => dn2ancestor "uid=stibbons,ou=admins,o=operators,o=umc"
[04/May/2011:17:40:32 -0400] - => dn2entry "ou=admins,o=operators,o=umc"
[04/May/2011:17:40:32 -0400] - <= dn2entry f0cdb0
[04/May/2011:17:40:32 -0400] - <= dn2ancestor f0cdb0
[04/May/2011:17:40:32 -0400] - <= find_entry_internal_dn not found (uid=stibbons,ou=admins,o=operators,o=umc)
[04/May/2011:17:40:32 -0400] - => send_ldap_result 32u=admins,o=operators,o=umc:
[04/May/2011:17:40:32 -0400] - <= send_ldap_result
[04/May/2011:17:40:32 -0400] - mapping tree release backend : userRoot
[04/May/2011:17:40:32 -0400] - do_add
[04/May/2011:17:40:32 -0400] - do_add: dn (uid=stibbons,ou=admins,o=operators,o=UMC)
[04/May/2011:17:40:32 -0400] - slapi_entry_add_values: using an AVL tree to detect duplicate values
[04/May/2011:17:40:32 -0400] - => get_ldapmessage_controls
[04/May/2011:17:40:32 -0400] - <= get_ldapmessage_controls no controls
[04/May/2011:17:40:32 -0400] - mtn_lock : lock count : 1
[04/May/2011:17:40:32 -0400] - mtn_unlock : lock count : 0
[04/May/2011:17:40:32 -0400] - => send_ldap_result 1::Mapping tree node for o=umc is set to return a referral, but no referral is configured for it
[04/May/2011:17:40:32 -0400] - <= send_ldap_result
[04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c8a8, handle=3
[04/May/2011:17:40:33 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c790, handle=3
[04/May/2011:17:40:33 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE
[04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c678, handle=3


Let me know what you see.....

Thanks,
-Reinhard

-----Original Message-----
From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Reinhard Nappert
Sent: Wednesday, May 04, 2011 5:32 PM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Referral errors ....

Rich,

I was able to get one box in this situation (not sure, how though). Do you want me do change some accesslog-levels or errorlog-levels?

Now would be a good time to gather more information

-Reinhard

-----Original Message-----
From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Richard Megginson
Sent: Wednesday, May 04, 2011 11:57 AM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Referral errors ....

> No replies so far. Does this mean nobody has seen this issue before?

I have not seen this.

Any errors in the errors log?
*
> -Reinhard
>
>
> From: 389-users-bounces@lists.fedoraproject.org
> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
> Reinhard Nappert
> Sent: Friday, April 29, 2011 9:44 AM
> To: 389-users@lists.fedoraproject.org
> Subject: [389-users] Referral errors ....
>
>
>
> Hi,
> *
> I have the following setup:
> *
> I have a 2 multimaster replication setup, where both masters also have
> a number of shadowing agreements to other consumers. The data gets
> replicated to all boxes and there are no issues. When I try to perform
> an update on the slaves, it works on all, but one. Meaning, the server
> sends back err=10, with the referral to one of the masters and the
> client automatically follows the referrals. Unfortunately, it does not
> works with one box:
> *
> When there is an attempt to write to the db, the server returns an
> error-code 1, with the following message:
> javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node
> for o=base is set to return a referral, but no referral is configured
> for it];
> *
> This can also be seen in the access file:
>
>
> [ 26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 ADD dn="o u = test
> ,o= base "
> [26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 RESULT err=1 tag=105
> nentries=0 etime=0
>
> When I have a look at the configuration, it looks exactly like the
> others: dn: cn="o=Base",cn=mapping tree,cn=config objectClass: top
> objectClass: extensibleObject objectClass: nsMappingTree cn: "o=Base"
> nsslapd-state: referral on update nsslapd-backend: userRoot
> modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp:
> 20100721202730Z nsslapd-referral: ldap://master-ld01:389/o=Base
> nsslapd-referral : ldap://master-ld02:389/o=Base numSubordinates : 1
> dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
> nsDS5ReplicaBindDN: cn=replication,cn=config nsDS5ReplicaRoot: o=Base
> nsDS5Flags: 0 nsDS5ReplicaType: 2 nsds5ReplicaPurgeDelay: 43200
> objectClass: top objectClass: nsDS5Replica cn: replica modifiersName:
> cn=Multimaster Replication Plugin,cn=plugins,cn=config
> modifyTimestamp: 20110421052744Z nsDS5ReplicaId: 65535 nsState::
> //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
> nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
> nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
> nsDS5ReplicaReferral : ldap://master-ld02:389/o=Base * I was wondering
> if someone has seen this kind of issue. Everything looks fine to me
> and I can not explain this behavior. * Right now, I can not reproduce
> this issue. I only see it in this one setup. * Thanks, -Reinhard
> --
> 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 mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-04-2011, 10:28 PM
Rich Megginson
 
Default Referral errors ....

On 05/04/2011 03:59 PM, Reinhard Nappert wrote:
> I actually tried even a bit more 1+2+4+65536=65543.
>
> I tried to add the object uid=stibbons,ou=admins,o=operator
> s,o=UMC.
>
> I tried to add it at (from access file):
> [04/May/2011:17:40:32 -0400] conn=83 op=51 SRCH base="uid=stibbons,ou=admins,o=o
> perators,o=UMC" scope=0 filter="(objectClass=*)" attrs=ALL
> [04/May/2011:17:40:32 -0400] conn=83 op=51 RESULT err=32 tag=101 nentries=0 etim
> e=0
> [04/May/2011:17:40:32 -0400] conn=83 op=52 ADD dn="uid=stibbons,ou=admins,o=oper
> ators,o=UMC"
> [04/May/2011:17:40:32 -0400] conn=83 op=52 RESULT err=1 tag=105 nentries=0 etime
> =0
>
> Here is what you see in errors:
>
> [04/May/2011:17:40:32 -0400] - mapping tree release backend : userRoot
> [04/May/2011:17:40:32 -0400] - do_search
> [04/May/2011:17:40:32 -0400] - SRCH base="uid=stibbons,ou=admins,o=operators,o=UMC" scope=0 deref=3 sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs=ALL
> [04/May/2011:17:40:32 -0400] - => get_ldapmessage_controls
> [04/May/2011:17:40:32 -0400] -<= get_ldapmessage_controls no controls
> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.3)
> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
> [04/May/2011:17:40:32 -0400] - mtn_lock : lock count : 1
> [04/May/2011:17:40:32 -0400] - mapping tree selected backend : userRoot
> [04/May/2011:17:40:32 -0400] - mtn_unlock : lock count : 0
> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c678, handle=2
> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit() returning NO VALUE
> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c678, handle=1
> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit() returning NO VALUE
> [04/May/2011:17:40:32 -0400] - => compute_limits: sizelimit=2000, timelimit=3600
> [04/May/2011:17:40:32 -0400] - Calling plugin 'ACL preoperation' #1 type 403
> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.12)
> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for 2.16.840.1.113730.3.4.18)
> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
> [04/May/2011:17:40:32 -0400] - Calling plugin 'Legacy replication preoperation plugin' #3 type 403
> [04/May/2011:17:40:32 -0400] - Calling plugin 'Multimaster replication preoperation plugin' #4 type 403
> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c678, handle=0
> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit() returning NO VALUE
> [04/May/2011:17:40:32 -0400] - => find_entry_internal (dn=uid=stibbons,ou=admins,o=operators,o=umc) lock 0
> [04/May/2011:17:40:32 -0400] - => dn2entry "uid=stibbons,ou=admins,o=operators,o=umc"
> [04/May/2011:17:40:32 -0400] - => index_read( "entrydn" = "uid=stibbons,ou=admins,o=operators,o=umc" )
> [04/May/2011:17:40:32 -0400] - indextype: "eq" indexmask: 0x2
> [04/May/2011:17:40:32 -0400] -<= index_read 0 candidates
> [04/May/2011:17:40:32 -0400] -<= dn2entry 0
> [04/May/2011:17:40:32 -0400] - => dn2ancestor "uid=stibbons,ou=admins,o=operators,o=umc"
> [04/May/2011:17:40:32 -0400] - => dn2entry "ou=admins,o=operators,o=umc"
> [04/May/2011:17:40:32 -0400] -<= dn2entry f0cdb0
> [04/May/2011:17:40:32 -0400] -<= dn2ancestor f0cdb0
> [04/May/2011:17:40:32 -0400] -<= find_entry_internal_dn not found (uid=stibbons,ou=admins,o=operators,o=umc)
> [04/May/2011:17:40:32 -0400] - => send_ldap_result 32u=admins,o=operators,o=umc:
> [04/May/2011:17:40:32 -0400] -<= send_ldap_result
> [04/May/2011:17:40:32 -0400] - mapping tree release backend : userRoot
> [04/May/2011:17:40:32 -0400] - do_add
> [04/May/2011:17:40:32 -0400] - do_add: dn (uid=stibbons,ou=admins,o=operators,o=UMC)
> [04/May/2011:17:40:32 -0400] - slapi_entry_add_values: using an AVL tree to detect duplicate values
> [04/May/2011:17:40:32 -0400] - => get_ldapmessage_controls
> [04/May/2011:17:40:32 -0400] -<= get_ldapmessage_controls no controls
> [04/May/2011:17:40:32 -0400] - mtn_lock : lock count : 1
> [04/May/2011:17:40:32 -0400] - mtn_unlock : lock count : 0
> [04/May/2011:17:40:32 -0400] - => send_ldap_result 1::Mapping tree node for o=umc is set to return a referral, but no referral is configured for it
> [04/May/2011:17:40:32 -0400] -<= send_ldap_result
> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c8a8, handle=3
> [04/May/2011:17:40:33 -0400] -<= slapi_reslimit_get_integer_limit() returning NO VALUE
> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c790, handle=3
> [04/May/2011:17:40:33 -0400] -<= slapi_reslimit_get_integer_limit() returning NO VALUE
> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit() conn=0xfd42c678, handle=3
>
>
> Let me know what you see.....
I don't see anything unusual. Does this problem persist after a server
restart?
> Thanks,
> -Reinhard
>
> -----Original Message-----
> From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Reinhard Nappert
> Sent: Wednesday, May 04, 2011 5:32 PM
> To: General discussion list for the 389 Directory server project.
> Subject: Re: [389-users] Referral errors ....
>
> Rich,
>
> I was able to get one box in this situation (not sure, how though). Do you want me do change some accesslog-levels or errorlog-levels?
>
> Now would be a good time to gather more information
>
> -Reinhard
>
> -----Original Message-----
> From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Richard Megginson
> Sent: Wednesday, May 04, 2011 11:57 AM
> To: General discussion list for the 389 Directory server project.
> Subject: Re: [389-users] Referral errors ....
>
>> No replies so far. Does this mean nobody has seen this issue before?
> I have not seen this.
>
> Any errors in the errors log?
>
>> -Reinhard
>>
>>
>> From: 389-users-bounces@lists.fedoraproject.org
>> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
>> Reinhard Nappert
>> Sent: Friday, April 29, 2011 9:44 AM
>> To: 389-users@lists.fedoraproject.org
>> Subject: [389-users] Referral errors ....
>>
>>
>>
>> Hi,
>>
>> I have the following setup:
>>
>> I have a 2 multimaster replication setup, where both masters also have
>> a number of shadowing agreements to other consumers. The data gets
>> replicated to all boxes and there are no issues. When I try to perform
>> an update on the slaves, it works on all, but one. Meaning, the server
>> sends back err=10, with the referral to one of the masters and the
>> client automatically follows the referrals. Unfortunately, it does not
>> works with one box:
>>
>> When there is an attempt to write to the db, the server returns an
>> error-code 1, with the following message:
>> javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node
>> for o=base is set to return a referral, but no referral is configured
>> for it];
>>
>> This can also be seen in the access file:
>>
>>
>> [ 26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 ADD dn="o u = test
>> ,o= base "
>> [26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 RESULT err=1 tag=105
>> nentries=0 etime=0
>>
>> When I have a look at the configuration, it looks exactly like the
>> others: dn: cn="o=Base",cn=mapping tree,cn=config objectClass: top
>> objectClass: extensibleObject objectClass: nsMappingTree cn: "o=Base"
>> nsslapd-state: referral on update nsslapd-backend: userRoot
>> modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp:
>> 20100721202730Z nsslapd-referral: ldap://master-ld01:389/o=Base
>> nsslapd-referral : ldap://master-ld02:389/o=Base numSubordinates : 1
>> dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
>> nsDS5ReplicaBindDN: cn=replication,cn=config nsDS5ReplicaRoot: o=Base
>> nsDS5Flags: 0 nsDS5ReplicaType: 2 nsds5ReplicaPurgeDelay: 43200
>> objectClass: top objectClass: nsDS5Replica cn: replica modifiersName:
>> cn=Multimaster Replication Plugin,cn=plugins,cn=config
>> modifyTimestamp: 20110421052744Z nsDS5ReplicaId: 65535 nsState::
>> //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
>> nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
>> nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
>> nsDS5ReplicaReferral : ldap://master-ld02:389/o=Base I was wondering
>> if someone has seen this kind of issue. Everything looks fine to me
>> and I can not explain this behavior. Right now, I can not reproduce
>> this issue. I only see it in this one setup. Thanks, -Reinhard
>> --
>> 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 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
 
Old 05-05-2011, 12:41 PM
Reinhard Nappert
 
Default Referral errors ....

This is actually what I thought, too. It logs looked fine to me as well.

Guess what, a restart of the LDAP server did get rid of the issue!

For sure it would be nice to figure out how the system can get into this state!

-Reinhard

-----Original Message-----
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Wednesday, May 04, 2011 6:28 PM
To: General discussion list for the 389 Directory server project.
Cc: Reinhard Nappert
Subject: Re: [389-users] Referral errors ....

On 05/04/2011 03:59 PM, Reinhard Nappert wrote:
> I actually tried even a bit more 1+2+4+65536=65543.
>
> I tried to add the object uid=stibbons,ou=admins,o=operator s,o=UMC.
>
> I tried to add it at (from access file):
> [04/May/2011:17:40:32 -0400] conn=83 op=51 SRCH
> base="uid=stibbons,ou=admins,o=o perators,o=UMC" scope=0
> filter="(objectClass=*)" attrs=ALL
> [04/May/2011:17:40:32 -0400] conn=83 op=51 RESULT err=32 tag=101
> nentries=0 etim e=0
> [04/May/2011:17:40:32 -0400] conn=83 op=52 ADD
> dn="uid=stibbons,ou=admins,o=oper ators,o=UMC"
> [04/May/2011:17:40:32 -0400] conn=83 op=52 RESULT err=1 tag=105
> nentries=0 etime =0
>
> Here is what you see in errors:
>
> [04/May/2011:17:40:32 -0400] - mapping tree release backend : userRoot
> [04/May/2011:17:40:32 -0400] - do_search
> [04/May/2011:17:40:32 -0400] - SRCH
> base="uid=stibbons,ou=admins,o=operators,o=UMC" scope=0 deref=3
> sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs=ALL
> [04/May/2011:17:40:32 -0400] - => get_ldapmessage_controls
> [04/May/2011:17:40:32 -0400] -<= get_ldapmessage_controls no controls
> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for
> 2.16.840.1.113730.3.4.3)
> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
> [04/May/2011:17:40:32 -0400] - mtn_lock : lock count : 1
> [04/May/2011:17:40:32 -0400] - mapping tree selected backend :
> userRoot
> [04/May/2011:17:40:32 -0400] - mtn_unlock : lock count : 0
> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit()
> conn=0xfd42c678, handle=2
> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit()
> returning NO VALUE
> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit()
> conn=0xfd42c678, handle=1
> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit()
> returning NO VALUE
> [04/May/2011:17:40:32 -0400] - => compute_limits: sizelimit=2000,
> timelimit=3600
> [04/May/2011:17:40:32 -0400] - Calling plugin 'ACL preoperation' #1
> type 403
> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for
> 2.16.840.1.113730.3.4.12)
> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for
> 2.16.840.1.113730.3.4.18)
> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
> [04/May/2011:17:40:32 -0400] - Calling plugin 'Legacy replication
> preoperation plugin' #3 type 403
> [04/May/2011:17:40:32 -0400] - Calling plugin 'Multimaster replication
> preoperation plugin' #4 type 403
> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit()
> conn=0xfd42c678, handle=0
> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit()
> returning NO VALUE
> [04/May/2011:17:40:32 -0400] - => find_entry_internal
> (dn=uid=stibbons,ou=admins,o=operators,o=umc) lock 0
> [04/May/2011:17:40:32 -0400] - => dn2entry "uid=stibbons,ou=admins,o=operators,o=umc"
> [04/May/2011:17:40:32 -0400] - => index_read( "entrydn" = "uid=stibbons,ou=admins,o=operators,o=umc" )
> [04/May/2011:17:40:32 -0400] - indextype: "eq" indexmask: 0x2
> [04/May/2011:17:40:32 -0400] -<= index_read 0 candidates
> [04/May/2011:17:40:32 -0400] -<= dn2entry 0
> [04/May/2011:17:40:32 -0400] - => dn2ancestor "uid=stibbons,ou=admins,o=operators,o=umc"
> [04/May/2011:17:40:32 -0400] - => dn2entry "ou=admins,o=operators,o=umc"
> [04/May/2011:17:40:32 -0400] -<= dn2entry f0cdb0
> [04/May/2011:17:40:32 -0400] -<= dn2ancestor f0cdb0
> [04/May/2011:17:40:32 -0400] -<= find_entry_internal_dn not found
> (uid=stibbons,ou=admins,o=operators,o=umc)
> [04/May/2011:17:40:32 -0400] - => send_ldap_result 32u=admins,o=operators,o=umc:
> [04/May/2011:17:40:32 -0400] -<= send_ldap_result
> [04/May/2011:17:40:32 -0400] - mapping tree release backend : userRoot
> [04/May/2011:17:40:32 -0400] - do_add
> [04/May/2011:17:40:32 -0400] - do_add: dn (uid=stibbons,ou=admins,o=operators,o=UMC)
> [04/May/2011:17:40:32 -0400] - slapi_entry_add_values: using an AVL
> tree to detect duplicate values
> [04/May/2011:17:40:32 -0400] - => get_ldapmessage_controls
> [04/May/2011:17:40:32 -0400] -<= get_ldapmessage_controls no controls
> [04/May/2011:17:40:32 -0400] - mtn_lock : lock count : 1
> [04/May/2011:17:40:32 -0400] - mtn_unlock : lock count : 0
> [04/May/2011:17:40:32 -0400] - => send_ldap_result 1::Mapping tree
> node for o=umc is set to return a referral, but no referral is
> configured for it
> [04/May/2011:17:40:32 -0400] -<= send_ldap_result
> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit()
> conn=0xfd42c8a8, handle=3
> [04/May/2011:17:40:33 -0400] -<= slapi_reslimit_get_integer_limit()
> returning NO VALUE
> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit()
> conn=0xfd42c790, handle=3
> [04/May/2011:17:40:33 -0400] -<= slapi_reslimit_get_integer_limit()
> returning NO VALUE
> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit()
> conn=0xfd42c678, handle=3
>
>
> Let me know what you see.....
I don't see anything unusual. Does this problem persist after a server restart?
> Thanks,
> -Reinhard
>
> -----Original Message-----
> From: 389-users-bounces@lists.fedoraproject.org
> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
> Reinhard Nappert
> Sent: Wednesday, May 04, 2011 5:32 PM
> To: General discussion list for the 389 Directory server project.
> Subject: Re: [389-users] Referral errors ....
>
> Rich,
>
> I was able to get one box in this situation (not sure, how though). Do you want me do change some accesslog-levels or errorlog-levels?
>
> Now would be a good time to gather more information
>
> -Reinhard
>
> -----Original Message-----
> From: 389-users-bounces@lists.fedoraproject.org
> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
> Richard Megginson
> Sent: Wednesday, May 04, 2011 11:57 AM
> To: General discussion list for the 389 Directory server project.
> Subject: Re: [389-users] Referral errors ....
>
>> No replies so far. Does this mean nobody has seen this issue before?
> I have not seen this.
>
> Any errors in the errors log?
>
>> -Reinhard
>>
>>
>> From: 389-users-bounces@lists.fedoraproject.org
>> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
>> Reinhard Nappert
>> Sent: Friday, April 29, 2011 9:44 AM
>> To: 389-users@lists.fedoraproject.org
>> Subject: [389-users] Referral errors ....
>>
>>
>>
>> Hi,
>>
>> I have the following setup:
>>
>> I have a 2 multimaster replication setup, where both masters also
>> have a number of shadowing agreements to other consumers. The data
>> gets replicated to all boxes and there are no issues. When I try to
>> perform an update on the slaves, it works on all, but one. Meaning,
>> the server sends back err=10, with the referral to one of the masters
>> and the client automatically follows the referrals. Unfortunately, it
>> does not works with one box:
>>
>> When there is an attempt to write to the db, the server returns an
>> error-code 1, with the following message:
>> javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node
>> for o=base is set to return a referral, but no referral is configured
>> for it];
>>
>> This can also be seen in the access file:
>>
>>
>> [ 26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 ADD dn="o u = test
>> ,o= base "
>> [26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 RESULT err=1 tag=105
>> nentries=0 etime=0
>>
>> When I have a look at the configuration, it looks exactly like the
>> others: dn: cn="o=Base",cn=mapping tree,cn=config objectClass: top
>> objectClass: extensibleObject objectClass: nsMappingTree cn: "o=Base"
>> nsslapd-state: referral on update nsslapd-backend: userRoot
>> modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp:
>> 20100721202730Z nsslapd-referral: ldap://master-ld01:389/o=Base
>> nsslapd-referral : ldap://master-ld02:389/o=Base numSubordinates : 1
>> dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
>> nsDS5ReplicaBindDN: cn=replication,cn=config nsDS5ReplicaRoot: o=Base
>> nsDS5Flags: 0 nsDS5ReplicaType: 2 nsds5ReplicaPurgeDelay: 43200
>> objectClass: top objectClass: nsDS5Replica cn: replica modifiersName:
>> cn=Multimaster Replication Plugin,cn=plugins,cn=config
>> modifyTimestamp: 20110421052744Z nsDS5ReplicaId: 65535 nsState::
>> //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
>> nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
>> nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
>> nsDS5ReplicaReferral : ldap://master-ld02:389/o=Base I was wondering
>> if someone has seen this kind of issue. Everything looks fine to me
>> and I can not explain this behavior. Right now, I can not reproduce
>> this issue. I only see it in this one setup. Thanks, -Reinhard
>> --
>> 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 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
 
Old 05-05-2011, 02:36 PM
Rich Megginson
 
Default Referral errors ....

On 05/05/2011 06:41 AM, Reinhard Nappert wrote:
> This is actually what I thought, too. It logs looked fine to me as well.
>
> Guess what, a restart of the LDAP server did get rid of the issue!
>
> For sure it would be nice to figure out how the system can get into this state!
Yes, this is an odd problem.
> -Reinhard
>
> -----Original Message-----
> From: Rich Megginson [mailto:rmeggins@redhat.com]
> Sent: Wednesday, May 04, 2011 6:28 PM
> To: General discussion list for the 389 Directory server project.
> Cc: Reinhard Nappert
> Subject: Re: [389-users] Referral errors ....
>
> On 05/04/2011 03:59 PM, Reinhard Nappert wrote:
>> I actually tried even a bit more 1+2+4+65536=65543.
>>
>> I tried to add the object uid=stibbons,ou=admins,o=operator s,o=UMC.
>>
>> I tried to add it at (from access file):
>> [04/May/2011:17:40:32 -0400] conn=83 op=51 SRCH
>> base="uid=stibbons,ou=admins,o=o perators,o=UMC" scope=0
>> filter="(objectClass=*)" attrs=ALL
>> [04/May/2011:17:40:32 -0400] conn=83 op=51 RESULT err=32 tag=101
>> nentries=0 etim e=0
>> [04/May/2011:17:40:32 -0400] conn=83 op=52 ADD
>> dn="uid=stibbons,ou=admins,o=oper ators,o=UMC"
>> [04/May/2011:17:40:32 -0400] conn=83 op=52 RESULT err=1 tag=105
>> nentries=0 etime =0
>>
>> Here is what you see in errors:
>>
>> [04/May/2011:17:40:32 -0400] - mapping tree release backend : userRoot
>> [04/May/2011:17:40:32 -0400] - do_search
>> [04/May/2011:17:40:32 -0400] - SRCH
>> base="uid=stibbons,ou=admins,o=operators,o=UMC" scope=0 deref=3
>> sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs=ALL
>> [04/May/2011:17:40:32 -0400] - => get_ldapmessage_controls
>> [04/May/2011:17:40:32 -0400] -<= get_ldapmessage_controls no controls
>> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for
>> 2.16.840.1.113730.3.4.3)
>> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
>> [04/May/2011:17:40:32 -0400] - mtn_lock : lock count : 1
>> [04/May/2011:17:40:32 -0400] - mapping tree selected backend :
>> userRoot
>> [04/May/2011:17:40:32 -0400] - mtn_unlock : lock count : 0
>> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit()
>> conn=0xfd42c678, handle=2
>> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit()
>> returning NO VALUE
>> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit()
>> conn=0xfd42c678, handle=1
>> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit()
>> returning NO VALUE
>> [04/May/2011:17:40:32 -0400] - => compute_limits: sizelimit=2000,
>> timelimit=3600
>> [04/May/2011:17:40:32 -0400] - Calling plugin 'ACL preoperation' #1
>> type 403
>> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for
>> 2.16.840.1.113730.3.4.12)
>> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
>> [04/May/2011:17:40:32 -0400] - => slapi_control_present (looking for
>> 2.16.840.1.113730.3.4.18)
>> [04/May/2011:17:40:32 -0400] -<= slapi_control_present 0 (NO CONTROLS)
>> [04/May/2011:17:40:32 -0400] - Calling plugin 'Legacy replication
>> preoperation plugin' #3 type 403
>> [04/May/2011:17:40:32 -0400] - Calling plugin 'Multimaster replication
>> preoperation plugin' #4 type 403
>> [04/May/2011:17:40:32 -0400] - => slapi_reslimit_get_integer_limit()
>> conn=0xfd42c678, handle=0
>> [04/May/2011:17:40:32 -0400] -<= slapi_reslimit_get_integer_limit()
>> returning NO VALUE
>> [04/May/2011:17:40:32 -0400] - => find_entry_internal
>> (dn=uid=stibbons,ou=admins,o=operators,o=umc) lock 0
>> [04/May/2011:17:40:32 -0400] - => dn2entry "uid=stibbons,ou=admins,o=operators,o=umc"
>> [04/May/2011:17:40:32 -0400] - => index_read( "entrydn" = "uid=stibbons,ou=admins,o=operators,o=umc" )
>> [04/May/2011:17:40:32 -0400] - indextype: "eq" indexmask: 0x2
>> [04/May/2011:17:40:32 -0400] -<= index_read 0 candidates
>> [04/May/2011:17:40:32 -0400] -<= dn2entry 0
>> [04/May/2011:17:40:32 -0400] - => dn2ancestor "uid=stibbons,ou=admins,o=operators,o=umc"
>> [04/May/2011:17:40:32 -0400] - => dn2entry "ou=admins,o=operators,o=umc"
>> [04/May/2011:17:40:32 -0400] -<= dn2entry f0cdb0
>> [04/May/2011:17:40:32 -0400] -<= dn2ancestor f0cdb0
>> [04/May/2011:17:40:32 -0400] -<= find_entry_internal_dn not found
>> (uid=stibbons,ou=admins,o=operators,o=umc)
>> [04/May/2011:17:40:32 -0400] - => send_ldap_result 32u=admins,o=operators,o=umc:
>> [04/May/2011:17:40:32 -0400] -<= send_ldap_result
>> [04/May/2011:17:40:32 -0400] - mapping tree release backend : userRoot
>> [04/May/2011:17:40:32 -0400] - do_add
>> [04/May/2011:17:40:32 -0400] - do_add: dn (uid=stibbons,ou=admins,o=operators,o=UMC)
>> [04/May/2011:17:40:32 -0400] - slapi_entry_add_values: using an AVL
>> tree to detect duplicate values
>> [04/May/2011:17:40:32 -0400] - => get_ldapmessage_controls
>> [04/May/2011:17:40:32 -0400] -<= get_ldapmessage_controls no controls
>> [04/May/2011:17:40:32 -0400] - mtn_lock : lock count : 1
>> [04/May/2011:17:40:32 -0400] - mtn_unlock : lock count : 0
>> [04/May/2011:17:40:32 -0400] - => send_ldap_result 1::Mapping tree
>> node for o=umc is set to return a referral, but no referral is
>> configured for it
>> [04/May/2011:17:40:32 -0400] -<= send_ldap_result
>> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit()
>> conn=0xfd42c8a8, handle=3
>> [04/May/2011:17:40:33 -0400] -<= slapi_reslimit_get_integer_limit()
>> returning NO VALUE
>> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit()
>> conn=0xfd42c790, handle=3
>> [04/May/2011:17:40:33 -0400] -<= slapi_reslimit_get_integer_limit()
>> returning NO VALUE
>> [04/May/2011:17:40:33 -0400] - => slapi_reslimit_get_integer_limit()
>> conn=0xfd42c678, handle=3
>>
>>
>> Let me know what you see.....
> I don't see anything unusual. Does this problem persist after a server restart?
>> Thanks,
>> -Reinhard
>>
>> -----Original Message-----
>> From: 389-users-bounces@lists.fedoraproject.org
>> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
>> Reinhard Nappert
>> Sent: Wednesday, May 04, 2011 5:32 PM
>> To: General discussion list for the 389 Directory server project.
>> Subject: Re: [389-users] Referral errors ....
>>
>> Rich,
>>
>> I was able to get one box in this situation (not sure, how though). Do you want me do change some accesslog-levels or errorlog-levels?
>>
>> Now would be a good time to gather more information
>>
>> -Reinhard
>>
>> -----Original Message-----
>> From: 389-users-bounces@lists.fedoraproject.org
>> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
>> Richard Megginson
>> Sent: Wednesday, May 04, 2011 11:57 AM
>> To: General discussion list for the 389 Directory server project.
>> Subject: Re: [389-users] Referral errors ....
>>
>>> No replies so far. Does this mean nobody has seen this issue before?
>> I have not seen this.
>>
>> Any errors in the errors log?
>>
>>> -Reinhard
>>>
>>>
>>> From: 389-users-bounces@lists.fedoraproject.org
>>> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of
>>> Reinhard Nappert
>>> Sent: Friday, April 29, 2011 9:44 AM
>>> To: 389-users@lists.fedoraproject.org
>>> Subject: [389-users] Referral errors ....
>>>
>>>
>>>
>>> Hi,
>>>
>>> I have the following setup:
>>>
>>> I have a 2 multimaster replication setup, where both masters also
>>> have a number of shadowing agreements to other consumers. The data
>>> gets replicated to all boxes and there are no issues. When I try to
>>> perform an update on the slaves, it works on all, but one. Meaning,
>>> the server sends back err=10, with the referral to one of the masters
>>> and the client automatically follows the referrals. Unfortunately, it
>>> does not works with one box:
>>>
>>> When there is an attempt to write to the db, the server returns an
>>> error-code 1, with the following message:
>>> javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node
>>> for o=base is set to return a referral, but no referral is configured
>>> for it];
>>>
>>> This can also be seen in the access file:
>>>
>>>
>>> [ 26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 ADD dn="o u = test
>>> ,o= base "
>>> [26/Apr/2011:05:35:45 -0300] conn=3418 op=13256 RESULT err=1 tag=105
>>> nentries=0 etime=0
>>>
>>> When I have a look at the configuration, it looks exactly like the
>>> others: dn: cn="o=Base",cn=mapping tree,cn=config objectClass: top
>>> objectClass: extensibleObject objectClass: nsMappingTree cn: "o=Base"
>>> nsslapd-state: referral on update nsslapd-backend: userRoot
>>> modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp:
>>> 20100721202730Z nsslapd-referral: ldap://master-ld01:389/o=Base
>>> nsslapd-referral : ldap://master-ld02:389/o=Base numSubordinates : 1
>>> dn: cn=replica,cn="o=Base",cn=mapping tree,cn=config
>>> nsDS5ReplicaBindDN: cn=replication,cn=config nsDS5ReplicaRoot: o=Base
>>> nsDS5Flags: 0 nsDS5ReplicaType: 2 nsds5ReplicaPurgeDelay: 43200
>>> objectClass: top objectClass: nsDS5Replica cn: replica modifiersName:
>>> cn=Multimaster Replication Plugin,cn=plugins,cn=config
>>> modifyTimestamp: 20110421052744Z nsDS5ReplicaId: 65535 nsState::
>>> //8AAAAAAADLv69NAAAAAAAAAAAAAAAALSoAAAAAAAAIAAAAAAAA AA==
>>> nsDS5ReplicaName: 59480b7e-94fb11df-9df8eeea-774385c0
>>> nsDS5ReplicaReferral: ldap://master-ld01:389/o=Base
>>> nsDS5ReplicaReferral : ldap://master-ld02:389/o=Base I was wondering
>>> if someone has seen this kind of issue. Everything looks fine to me
>>> and I can not explain this behavior. Right now, I can not reproduce
>>> this issue. I only see it in this one setup. Thanks, -Reinhard
>>> --
>>> 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 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
 

Thread Tools




All times are GMT. The time now is 07:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org