Michael Ströder wrote:

Then use back-ldap as a LDAP reverse proxy or slapo-chain for chasing the referrals automatically.

You keep using that phrase "reverse proxy" - it's just a proxy.

Just call it a proxy. Reverse or forward, it's really doing the same thing, even if it's server to server proxying. Does it really matter if the server sits between the browser and an internet gateway on a specific subnet or on the other side of the internet gateway? To the browser, not much changes (if anything)

But - I digress from the real problem question here. I've just seen too many people get confused by the 'reverse' terminology and trying to understand it as reverse (e.g. the server proxies back to the browser ?? ).

On Mar 17, 2008, at 1:26 PM, Michael Ströder wrote:

Howard Chu wrote:

...

Michael Ströder wrote:

...

Then use back-ldap as a LDAP reverse proxy or slapo-chain for chasing the referrals automatically.

You keep using that phrase "reverse proxy" - it's just a proxy.

Well, I don't want to nitpick here but this wording is commonly used when dealing with web servers:

1. A forwarding proxy is one your client might have to use to reach

out to external servers (by some definition of "external") and

2. a reverse proxy is the connection end point for the client which

passes requests on to a hidden server.

For 1. the client has to know about the proxy and for 2. the client does not have to know (or even must not know).

See also: http://en.wikipedia.org/wiki/Reverse_proxy

Looking at this it seems appropriate to me to use the term "reverse proxy" when talking about back-ldap.

Ciao, Michael.

P.S.: This reminds me of a feature request I wanted to submit to ITS for letting libldap use a forwarding proxy via HTTP connect. Or at least pass a file descriptor to ldap_initialize()...

______________________________________________ Chris G. Sellers | NITLE - Technology Team 734.661.2318 | chris.sellers@nitle.org AIM: imthewherd | GoogleTalk: cgseller@gmail.com

Something isnt clear to me, on A I got the following slapd.conf:

database hdb suffix "dc=example,dc=com"

database ldap suffix "dc=B,ou=Subs,dc=example,dc=com" uri "ldap://B/" idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=[password in clear text] authzID="dn:cn=Manager,dc=example,dc=com"

And on B I got the following setup:

database hdb suffix "dc=example,dc=com"

When I start slapd on A I get:

/etc/openldap/slapd.conf: line 87: <suffix> namingContext "dc=B,ou=Subs,dc=example,dc=com" already served by a preceding hdb database serving namingContext "dc=example,dc=com".

Isnt it possible to set a database as a branch of another ?

"Or Goshen" oberonc@gmail.com writes:

Hello

I have the following situation and would like to know your opinion on the matter:

I have 2 slapd servers A and B, both require simple authentication and are

not

open for anonymous access. What I would like to do is setup a node on A that would reference the root

of

B and would allow me to perform read/write to it.

I tried so far:

1. Setup a "referral" objectClass on A in the following manner:

dn: dc=B,ou=Subservers,dc=example,dc=com dc: B objectClass: referral objectClass: extensibleObject ref: ldap://B/dc=example,dc=com

That didnt work since B requires authentication. So I tried this:

dn: dc=B,ou=Subservers,dc=example,dc=com dc: B objectClass: referral objectClass: extensibleObject ref:

ldap://??B??!bindname=cn=Manager%2cdc=example%2cdc=com/dc=example,dc=com

Didnt work either (authentication extension not supported ?).

2. slapd apparently supports an "ldap" backend/database. Problem is that

there

is no real documentation here or here on how to set them up. Anybody ever setup such a database/backend ? does it support authentication ? any

examples

I can take a look at ?

I dont want to replication B on A, I just want to act as a proxy.

There is plenty of information on back-ldap available, http://www.openldap.org/faq/data/cache/532.html

For more details see man slapd-ldap(5), man slapd-meta(5) and try to glue databases, following configfuration is just a simple hint

database bdb suffix dc=A,ou=subservers,dc=example,dc=com ... subordinate

database ldap suffix ou=subservers,dc=example,dc=com uri ldap://host.example.com ...

-Dieter

-- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

"Or Goshen" oberonc@gmail.com writes:

Something isnt clear to me, on A I got the following slapd.conf:

database hdb suffix "dc=example,dc=com"

database ldap suffix "dc=B,ou=Subs,dc=example,dc=com" uri "ldap://B/" idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=[password in clear text] authzID="dn:cn=Manager,dc=example,dc=com"

And on B I got the following setup:

database hdb suffix "dc=example,dc=com"

When I start slapd on A I get:

/etc/openldap/slapd.conf: line 87: <suffix> namingContext "dc=B,ou=Subs,dc= example,dc=com" already served by a preceding hdb database serving namingContext "dc=example,dc=com".

[...] As I mentioned in a previous mail, you have to glue the databases, this is done by using the magic word subordinate.

database ldap suffix dc=B,ou=Subs,dc=example,dc=com ... subordinate

database hdb suffix dc=example,dc=com

-Dieter