On Friday 29 August 2008 17:59:39 Ivan Ordonez wrote:
Hi all,
We have a small size domain with about 500 users and computers. We are
using Samba with Openldap integration to authenticate user login and
file sharing. Our setup is consist of 3 servers running Gentoo Linux -
1PDC and 2BDCs. As for replication, we are still using "slurpd". Any
changes or modification is done through the PDC which replicates the
changes to BDC1, then from BDC1, it then goes down to BDC2 - it's like a
chain.
Why? Why not have PDC replicate to BDC1 and BDC2?
You didn't provide your OpenLDAP version (which is quite important in
discussing the options).
We want to start using "syncrepl" soon as a way to
replicate our
database but I'm not sure were to start. We want to setup all of our
machine to sync with each other everyday,
Only once a day?? Syncrepl in RefreshAndPersist will be immediate (as or more
immediate than slurpd, with fewer problems regarding resyncing etc.).
and not worry which machine is
use to make changes, modification, etc....
Changes done via what? Samba has referral chasing, so you don't need multi-
master to have a BDC be able to write to OpenLDAP.
I'm not sure which syncrepl
function to use to achieve what we want to do. Is "N-Way Multi Master
replication" the correct choice to do this?
It's not a requirement, and it may be excessive complexity if you just want
replication to work.
We are using "BDB" database
on each servers, and would like to achieve this with minimal downtime if
possible. What is the best way to do this?
Configure syncrepl on the provider and the two consumers, assuming you have a
recent enough OpenLDAP version, and restart ...
Configuration of syncrepl does require at least:
1)syncprov overlay configured on provider
2)limits and access statements on provider to ensure DNs used by consumers can
get all entries/attributes
3)entryUUID and entryCSN attributes indexed on all servers
4)syncrepl statements in consumer configuration
(so, your restart may be a stop;slapindex;start for the indexes, but your
database is small)
Regards,
Buchan