7:07 p.m.
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.
11:19 p.m.
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
--
Buchan Milne
ISP Systems Specialist - Monitoring/Authentication Team Leader
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
12:51 a.m.
On 3/27/07, Buchan Milne <bgmilne(a)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.
5:08 a.m.
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(a)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.
5:43 a.m.
On 3/27/07, Aaron Richton <richton(a)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
--
Evolution: Taking care of those too stupid to take care of themselves.
1:24 p.m.
Alec Thomas wrote:
On 3/27/07, Aaron Richton <richton(a)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
--
-- 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/
12:07 a.m.
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
manu(a)netbsd.org
12:50 a.m.
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.
--
-- 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/
6016
days inactive
6026
days old
openldap-software@openldap.org
7 comments
5 participants
participants (5)
-
Aaron Richton -
Alec Thomas -
Buchan Milne -
Emmanuel Dreyfus -
Howard Chu