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 <[email protected]>wrote:
> 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.
