[389-users] Db-link setup question

Rich Megginson rmeggins at redhat.com
Wed Jul 29 21:38:02 UTC 2009


Reinhard Nappert wrote:
> Rick, 
>
> the first issue is solved my adding an additional aci for that proxy admin,  allowing proxy:
> aci: (targetattr=*)(target = "ldap:///ou=region B,ou=people,o=suffix")(version 3.0;acl
>  "Allows use of admin for chaining"; allow (proxy) (userdn="ldap:///uid=proxy admin,cn=config");)
>
> However, when I restart Server A, it is broken with err=32.
>   
What entry is giving err=32?
> -Reinhard
>
> -----Original Message-----
> From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Reinhard Nappert
> Sent: Monday, July 20, 2009 3:17 PM
> To: General discussion list for the 389 Directory server project.
> Subject: RE: [389-users] Db-link setup question
>
> I do not feel very confident using chained links:
>
> When I  change my configuration to 
>
> dn: cn=serverBlink,cn=chaining database,cn=plugins,cn=config
> objectclass: top
> objectclass: extensibleObject
> objectclass: nsBackendInstance
> nsslapd-suffix: ou=region B,ou=people,o=suffix
> nsfarmserverurl: ldap://serverB:389/
> nsmultiplexorbinddn: cn=proxy admin,cn=config
> nsmultiplexorcredentials: secret
> cn: serverBlink
>   
> dn: cn="ou=region B,ou=people,o=suffix",cn=mapping tree,cn=config
> objectclass: top
> objectclass: extensibleObject
> objectclass: nsMappingTree
> nsslapd-state: backend
> nsslapd-backend: serverBlink
> nsslapd-parent-suffix: "ou=people,o=suffix "
> cn: "ou=region B,ou=people,o=suffix" 
>
> Server A proxies the correct search to Server B. However, the response is empty if I search for an existing entry of Server B. I also see the search in Server B's access file, but the response is empty. If I contact Server B with the proxy admin credentials, it returns the existing object. This tells me that the ACI's are working.
> Do you have an explanation for that?
>
> Even more disturbing: After I restart Server A, the entire chaining is broken. I get again err=32, but this time server A even does not perform the search twoards Server B.
>
> -Reinhard
>
> -----Original Message-----
> From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich Megginson
> Sent: Monday, July 20, 2009 2:33 PM
> To: General discussion list for the 389 Directory server project.
> Subject: Re: [389-users] Db-link setup question
>
> Reinhard Nappert wrote:
>   
>> Sorry, the chaining server. 
>> I checked the chained to server (Server B)'s access file and it gets it from there. This is good, that Server A actually talks to Server B. The issue is the following:
>>
>> I do a search with the
>> Base: l=location B,ou=people,o=suffix
>>
>> It performs the search on Server B with the exactly same search-base, 
>> although I configured it as
>> nsslapd-suffix: ou=region B,ou=people,o=suffix
>>
>> So, shouldn't Server A alter the search and use ou=region 
>> B,ou=people,o=suffix as base?
>>
>> On the otherhand, I could change the configuration accordingly.
>>   
>>     
> There is no search altering or search mapping with chaining.
>   
>> -Reinhard
>>
>> -----Original Message-----
>> From: fedora-directory-users-bounces at redhat.com
>> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich 
>> Megginson
>> Sent: Monday, July 20, 2009 1:57 PM
>> To: General discussion list for the 389 Directory server project.
>> Subject: Re: [389-users] Db-link setup question
>>
>> Reinhard Nappert wrote:
>>   
>>     
>>> Nothing in error and only err=32 in access.
>>>   
>>>     
>>>       
>> err=32 in which access?  The chaining server or the chained to server?
>>   
>>     
>>> -Reinhard
>>>
>>> -----Original Message-----
>>> From: fedora-directory-users-bounces at redhat.com
>>> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich 
>>> Megginson
>>> Sent: Monday, July 20, 2009 1:15 PM
>>> To: General discussion list for the 389 Directory server project.
>>> Subject: Re: [389-users] Db-link setup question
>>>
>>> Reinhard Nappert wrote:
>>>   
>>>     
>>>       
>>>> Thanks Rick,
>>>>
>>>> Yes this is what I did. I find the error message not very user-friendly. Anyway, when I use a different bind dn, it says that my sub suffix l=location B,ou=people,o=suffix does not exist. Do I need to add that object as well? Thought, the directory takes care of this one.
>>>>   
>>>>     
>>>>       
>>>>         
>>> Yes, the object does not have to exist in the chaining database, only in the real database that is chained to.  Any info in the access and error logs on the chaining server or the chained to server?
>>>   
>>>     
>>>       
>>>> -Reinhard
>>>>
>>>> -----Original Message-----
>>>> From: fedora-directory-users-bounces at redhat.com
>>>> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich 
>>>> Megginson
>>>> Sent: Monday, July 20, 2009 12:37 PM
>>>> To: General discussion list for the 389 Directory server project.
>>>> Subject: Re: [389-users] Db-link setup question
>>>>
>>>> Reinhard Nappert wrote:
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> Hi,
>>>>>  
>>>>> I have two LDAP Servers setup (Server A and Server B). Both of them 
>>>>> have the identical suffix (o=suffix). Again, both of them have a 
>>>>> people organizational unit (ou=people,o=suffix). Server B has a big 
>>>>> subtree (ou=region B,ou=people,o=suffix).
>>>>>  
>>>>> My intension is to create a db link on Server A, which links to the 
>>>>> ou=region B,ou=people,o=suffix subtree on Server B.
>>>>>  
>>>>> I did create the database link and a new suffix l=location 
>>>>> B,ou=people,o=suffix on Server A with the following entries:
>>>>>  
>>>>> dn: cn=serverBlink,cn=chaining database,cn=plugins,cn=config
>>>>> objectclass: top
>>>>> objectclass: extensibleObject
>>>>> objectclass: nsBackendInstance
>>>>> nsslapd-suffix: ou=region B,ou=people,o=suffix
>>>>> nsfarmserverurl: ldap://serverB:389/
>>>>> nsmultiplexorbinddn: cn=proxy admin,cn=config
>>>>> nsmultiplexorcredentials: secret
>>>>> cn: serverBlink
>>>>>  
>>>>> dn: cn="l=location B,ou=people,o=suffix",cn=mapping tree,cn=config
>>>>> objectclass: top
>>>>> objectclass: extensibleObject
>>>>> objectclass: nsMappingTree
>>>>> nsslapd-state: backend
>>>>> nsslapd-backend: serverBlink
>>>>> nsslapd-parent-suffix: "ou=people,o=suffix "
>>>>> cn: "l=location B,ou=people,o=suffix"
>>>>>  
>>>>> I am only interested in reading the server B information, when 
>>>>> accessing from server A. The "proxy admin" user was created as well.
>>>>>  
>>>>> When I do a search with the base l=location B,ou=people,o=suffix, 
>>>>> accessing server A, I always get the following error "Proxy dn 
>>>>> should not be rootdn".
>>>>>  
>>>>> What did I miss for the setup?
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> You cannot chain the directory manager user (aka rootdn).  I'm assuming you're doing a search like ldapsearch -D "cn=directory manager" ...
>>>> This will not work - you must use a user other than directory manager.
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>  
>>>>> Thanks,
>>>>> -Reinhard
>>>>>  
>>>>> -------------------------------------------------------------------
>>>>> -
>>>>> --
>>>>> --
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>   
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> --
>>>> 389 users mailing list
>>>> 389-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>   
>>>>     
>>>>       
>>>>         
>>> --
>>> 389 users mailing list
>>> 389-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>   
>>>     
>>>       
>> --
>> 389 users mailing list
>> 389-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>>     
>
>
> --
> 389 users mailing list
> 389-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
> --
> 389 users mailing list
> 389-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20090729/15fe93e4/attachment.bin>


More information about the 389-users mailing list