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. Thanks, Oren. > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: [EMAIL PROTECTED] > --------------------------------------- > >
