Oren Laadan wrote: > > Pierangelo Masarati wrote: >> [EMAIL PROTECTED] wrote: >>> Oren Laadan wrote: >>>>> It shows enough; back-meta is hanging waiting for responses from some >>>>> other >>>>> LDAP server. This is a pretty bad configuration; you should not use >>>>> back-meta >>>>> (or back-ldap) to redirect queries back into the same slapd. You should >>>>> use >>>>> back-relay instead. >>>> I'm not quite sure why having the server query itself is such a bad idea. >>>> Can you please explain ? >>> Any request then occupies a minimum of two slapd threads - one for back-meta >>> itself, and one for the extra inbound query. If you misconfigure the meta >>> URIs >>> then you get into an infinite loop, which consumes all of the available >>> slapd >>> threads. >> Let me add that, moreover, any request is re-encoded as an LDAP request, >> sent to itself, re-decoded and re-processed by slapd. Back-relay >> directly relies the original, decoded request to another database, >> within the same thread. So it saves at least 3 resource-consuming steps- >> > > Ok, I see the rational. So I guess my question is whether back-relay gives > the same functionality like ldap-meta (that is, merging the two databases, > the remote one and the local one) except better with respect to a local > database ? and if so, then how would I set it up for this ? > > I looked at "subordinate" directive but I'm not sure it helps, since as > far as I could tell it can join two disjoint subtrees into seemingly one > big database. However, what I need is to add local (new) entries (not > only modify attributes) to an existing database.
This discussion has wandered off of potential bugs and into regular software usage. You should pick this up again on the -software mailing list. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
