I would not recommend using slurpd because it requires the master to be
able to push changes to the slave. syncrepl is a better approach all
around in my opinion and I think it's even easier to manage/set up. The
essential difference is this. Slurpd is a background daemon that runs on
the master and pushes changes to the slave. syncrepl is part of the
slapd daemon configured within the slapd.conf file. It is set up on the
slave server and issues configurable query paramaters to the master
server the results of which it uses to update it's tree. You can either
specify the update interval for non persistent queries, or a persistent
style query in which the search connection remains open. The master
server "remembers" the query made by the slave and when any alteration
is made to it's tree that matches the parameters of the slave's search
it sends an update to the slave. This allows for very quick updates and
eliminates the traffic overhead of the polling style mechanism. If this
isn't clear hopefully the following will help.
This approach requires setting up some ACLs so hopefully you're familiar
with that.
Essentially what you do is this. You need to create 2 new dn's in your
tree that can be bound to (ie have userPassword attributes). You can use
inetOrgPerson, organizationalRole, whatever, just so long as someone can
bind to that dn. So for example:
cn=slave_reader,dc=directory,dc=com
ACLS on the master must grant this user access to read the entire
portion of the tree that is to be replicated. (the entire tree? depends
on what you need)
cn=slave_writer,dc=directory,dc=com
ACLS on the slave must grant write access to the same portion of the
slave's tree
Here are some tips for configuring your ACLs:
MASTER:
The following makes it possible for the slave to get huge result sets
back from the master without the search timing out. Needed in most cases
for entire tree updates like the initial sync. Place it in the Master's
slapd.conf or acl include file if you use one.
limits dn.exact="cn=slave_reader,dc=directory,dc=com" size=unlimited
time=unlimited
(Long line wrapped, this is all one line space seperated)
The following is probably not as important and may not even be
necessary. It should allow the slave to update itself in any
circumstance without timing out.
limits dn.exact="cn=slave_writer,dc=directory,dc=com" size=unlimited
time=unlimited
Placing the following in the master at the beginning of your ACL
declarations will allow the slave to read everything on the master:
access to *
by dn.exact="cn=slave_reader,dc=directory,dc=com" read stop
by * none break
The by * none break makes the rest of your ACLs function as normal and
just permits the slave writer to read everything.
The following goes in the slaves ACL declarations and makes it possible
for the slave to write to itself.
access to *
by dn.exact="cn=slave_writer,dc=directory,dc=com" write stop
by * none break
Now that the ACLs are set up you may want to test by logging into the
slave/master with some ldap client with those dn's you configured and
ensure that on the master you can read everything in the tree but make
no modifications, and on the slave you can make any modification you
wish.
If everything worked out go ahead and continue setting up syncrepl.
This e-mail is long enough and already duplicates much of the
information in the documentation I sent earlier so I won't attempt an
explanation of the configuration parameters. See the docs including the
slapd.conf man page for more details. Essentially, replacing the obvious
in the following configuration should give you what you need.
syncrepl rid=1
provider=ldap://master_server.com:389
type=refreshAndPersist
retry=1,5,5,5,10,+
searchbase="dc=directory,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
updatedn="cn=slave_writer,dc=directory,dc=com"
bindmethod=simple
binddn="cn=slave_reader,dc=directory,dc=com"
credentials=slave_pass_on_master
updateref ldap://master_server.com:389
Lee Jensen
On Wed, 2005-03-16 at 14:53 +0200, Omar Al-Tabari wrote:
Lee Jensen wrote:
TCP is two-way. If the master can't talk to the slave it won't work.
I'd suggest putting a new nic in the master and give it a private address
and use that network to talk between the master and slave.
Read this to learn how to setup a master/slave pair.
http://www.openldap.org/doc/admin22/replication.html
This may not necessarilly be accurate... The inability of the master to
"talk" to the slave is perhaps just a result of the non-routable address
that the slave will be using. If the slave can establish a TCP
connection to the master then you should have enough for replication to
occur via the syncrepl method. See the following links for more
information:
http://www.openldap.org/doc/admin22/syncrepl.html
TCP is two-way. If the master can't talk to the slave it won't work.
I'd suggest putting a new nic in the master and give it a private address
and use that network to talk between the master and slave.
Read this to learn how to setup a master/slave pair.
http://www.openldap.org/doc/admin22/replication.html
This may not necessarilly be accurate... The inability of the master to
FAQs:
http://www.openldap.org/faq/data/cache/1117.html
http://www.openldap.org/faq/data/cache/1125.html
Essentially the sync replication mechanism allows the client to connect
to the server and pass a cookie notifying the server of the state of
it's DIT. The server then sends changes back to the slave using standard
search result mechanisms. So if the slave can do a search on the master
it can replicate via syncrepl...
Lee Jensen
Now I've read the above links, and i still dont get it, do i use slurpd,
or do i use Syncrepl, or are they the same!
also i dont know how to setup the thing, i understand the concept, but
haven't got a clue on the actual implementation.
can someone help me with that please.
thanks in advance.