Hi,
I have a similar situation to the one mentioned here:
http://www.openldap.org/lists/openldap-software/200607/msg00024.html
I was wondering if somebody could clarify why this behaviour is intentional?
Alec -- Evolution: Taking care of those too stupid to take care of themselves.
On Tuesday 27 March 2007, Alec Thomas wrote:
Hi,
I have a similar situation to the one mentioned here:
http://www.openldap.org/lists/openldap-software/200607/msg00024.html
I was wondering if somebody could clarify why this behaviour is intentional?
The real question is, what do you *need*.
If you just need a log of changes, look at the auditlog overlay (which is mentioned in the answer to the mail you reference).
Regards, Buchan
On 3/27/07, Buchan Milne bgmilne@staff.telkomsa.net wrote:
The real question is, what do you *need*.
We have a need to provide a limited "view" of our LDAP tree to a DMZ environment. We replicate to an intermediate server using a filtered syncrepl, which leaves this server with the limited "view".
To then get this data into the DMZ it would be preferable to push than pull, as this would not require a hole in the firewall back into the corporate network.
If you just need a log of changes, look at the auditlog overlay (which is mentioned in the answer to the mail you reference).
We've already considered auditlog and it will probably be the fallback if we can't get any other push based mechanism working.
You can "push" from syncrepl today. See the list archives and, I believe, the tests configs.
On Tue, 27 Mar 2007, Alec Thomas wrote:
On 3/27/07, Buchan Milne bgmilne@staff.telkomsa.net wrote:
The real question is, what do you *need*.
We have a need to provide a limited "view" of our LDAP tree to a DMZ environment. We replicate to an intermediate server using a filtered syncrepl, which leaves this server with the limited "view".
To then get this data into the DMZ it would be preferable to push than pull, as this would not require a hole in the firewall back into the corporate network.
If you just need a log of changes, look at the auditlog overlay (which is mentioned in the answer to the mail you reference).
We've already considered auditlog and it will probably be the fallback if we can't get any other push based mechanism working.
-- Evolution: Taking care of those too stupid to take care of themselves.
On 3/27/07, Aaron Richton richton@nbcs.rutgers.edu wrote:
You can "push" from syncrepl today. See the list archives and, I believe, the tests configs.
As I understand it, and other threads confirm, even though syncrepl logically supports a "push" based mechanism, from a network perspective it's a connection from the replica to the master which is not ideal from a DMZ.
From a previous thread [1], it sounds like 2.4 will support this model
using a hidden proxy database. For 2.3 it sounds like it may be possible by using the attr keyword to the replica statement. I'll play with this tomorrow.
[1] http://www.openldap.org/lists/openldap-software/200609/msg00071.html
Alec Thomas wrote:
On 3/27/07, Aaron Richton richton@nbcs.rutgers.edu wrote:
You can "push" from syncrepl today. See the list archives and, I believe, the tests configs.
As I understand it, and other threads confirm, even though syncrepl logically supports a "push" based mechanism, from a network perspective it's a connection from the replica to the master which is not ideal from a DMZ.
That's syncrepl by itself, yes. Using syncrepl in conjunction with back-ldap provides a pure push based mechanism though.
From a previous thread [1], it sounds like 2.4 will support this model
using a hidden proxy database. For 2.3 it sounds like it may be possible by using the attr keyword to the replica statement. I'll play with this tomorrow.
[1] http://www.openldap.org/lists/openldap-software/200609/msg00071.html
On Thu, Apr 05, 2007 at 01:24:09PM -0700, Howard Chu wrote:
That's syncrepl by itself, yes. Using syncrepl in conjunction with back-ldap provides a pure push based mechanism though.
Is there any document explaining how to set up this? I asked a few weeks ago, and I the answer I had was to look at the testsuite for a setup example. Anyone wrote a few lines to make it a bit more accessible to the rest of us?
Emmanuel Dreyfus wrote:
On Thu, Apr 05, 2007 at 01:24:09PM -0700, Howard Chu wrote:
That's syncrepl by itself, yes. Using syncrepl in conjunction with back-ldap provides a pure push based mechanism though.
Is there any document explaining how to set up this? I asked a few weeks ago, and I the answer I had was to look at the testsuite for a setup example. Anyone wrote a few lines to make it a bit more accessible to the rest of us?
A detailed description in plaintext will be far more lengthy than the working example already provided in the test suite and you would just need an example anyway.
In brief: Set up the syncrepl provider as normal. Set up the remote slave with an updatedn (as if you were configuring it for slurpd). Set up a separate slapd with a back-ldap proxy, on the provider's side of the firewall. Point this back-ldap proxy at the remote slave. Set up a syncrepl consumer on this proxy that talks to the provider.
Done.
In OpenLDAP 2.4 some of the proxy setup can be streamlined using the "hidden" database keyword, but the generic approach given above works with 2.3.
openldap-software@openldap.org
-
Aaron Richton -
Alec Thomas -
Buchan Milne -
Emmanuel Dreyfus -
Howard Chu