[Date Prev][Date Next]
Re: Problem binding two naming contexts
On Wed Nov 23 2005 at 14:25:54 CET, Pierangelo Masarati wrote:
> On Wed, 2005-11-23 at 13:52 +0100, Jan-Piet Mens wrote:
> > Thank you! That worked. I notice that binds on
> > uid=xx,ou=rsc,dc=virtual always work (i.e. they don't seem to be
> > checked on the target server); is that correct and/or can it
> > be changed?
> No, it's not. Please make sure you're not missing anything, post the
> logs (at "stats") of the remote and the proxy servers. If the problem
> is confirmed, you should file an ITS.
I've upgraded to 2.3.12 and binds now work as I expected them to.
> > Furthermore, upon searching for sn=mens for example, only the
> > results from the first URI are returned. Can that be changed
> > to include all results of all uri?
> All should. Again, please post logs for both the remote server and the
> proxy (now at "stats" + "stats2").
> Sorry, I got confused. In fact, locally the databases see all the DN
> rewritten; so you should have everything rewritten; I don't think this
> can be done yet. Stay with the other approach
Understood. Once again, thank you very much for your help, Pierangelo!
> please report about
> the issues we discussed above. Try to deal with each of them
> separately, so please don't intermix the bind and the search logs.
The stats/stats2 log from the source server (the one we are discussing)
Nov 23 14:44:06 slapd: conn=1 op=1 SRCH base="dc=virtual" scope=2 deref=0 filter="(sn=mens)"
Nov 23 14:44:06 slapd: conn=1 op=1 SRCH attr=cn
Nov 23 14:44:06 slapd: conn=1 op=1 ENTRY dn="uid=jpm,ou=rsc,dc=virtual"
Nov 23 14:44:06 slapd: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Nov 23 14:44:06 slapd: conn=1 op=2 UNBIND
I can't change the logging on target server at the moment, but here is the log entry
from that (its search base is correct, and it correctly finds one entry):
Nov 23 14:44:07 slapd: conn=2261387 op=2 SRCH attr=cn
Nov 23 14:44:07 slapd: conn=2261387 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
The entry returned from dc=virtual (on the source) is the entry found on the
target. The missing entry is the one from the source BDB backend.
Just to be on the safe side: the entries ARE different (different classes, different
CN, etc.) but they share the same SN. That ought to be possible?