Thanks I've read the replication section many times at the site and logically it doesn't make sense when you look at the configuration. My Master has this configuration:

# Add indexes to the frontend db. dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryCSN eq - add: olcDbIndex olcDbIndex: entryUUID eq

#Load the syncprov and accesslog modules. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov - add: olcModuleLoad olcModuleLoad: accesslog

# Accesslog database definitions dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=example,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart

# Accesslog db syncprov. dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE

# syncrepl Provider for primary db dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE

# accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE # scan the accesslog DB every day, and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00

There's nothing in the configuration to inform the slapd daemon to "push" the info to a consumer in the dmz.

Here's my slave ldap configuration:

#Load the syncprov module. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov

# syncrepl specific indices dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID eq - add: olcSyncRepl olcSyncRepl: rid=0 provider=ldap://ldaptest1.example.com bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=passwd searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshOnly retry="60 +" syncdata=accesslog - add: olcUpdateRef olcUpdateRef: ldap://ldaptest1.example.com

Here the consumer has a provider address and looks like this will initially connect to the provider server which won't work in the dmz.

But I will try it. :)

Regards.

On Thu, Nov 18, 2010 at 9:48 AM, Aaron Richton richton@nbcs.rutgers.eduwrote:

On Thu, 18 Nov 2010, Anton Chu wrote:

I have a provider server in the intranet and I want to add a consumer

...

server in a DMZ for replication. The problem is that a connection can only be initiated from the intranet to the DMZ. I've read both refreshandpersist and refesh-only replications both require an initial connection from the consumer server which will be in the DMZ. Should I put the provider server in the DMZ instead?

While only you can decide on your optimal network configuration, I note that configuration of push based (i.e. provider initiated connection) replication is detailed in the OpenLDAP 2.4 Administrator's Guide. So OpenLDAP software will handle whatever you decide is your optimal network configuration.