2.0: Configuring LDAP: Difference between revisions

From SambaWiki
No edit summary
No edit summary
Line 10: Line 10:
bindmethod=simple credentials=SyncUser
bindmethod=simple credentials=SyncUser
To bind to the database the slave replicas will need to use “upateuser’s” password defined above as '''“credentials=UpdateUser“'''. Initially you will need to manually populate the slave database as defined in section 3.4 Database Replication.
To bind to the database the slave replicas will need to use “syncusers’s” password defined above as '''“credentials=SyncUser“'''. Initially you will need to manually populate the slave database as defined in section 3.4 Database Replication.
The main restriction with using this original design is the ldap database needs to be restarted on both the master and the slave when adding additional replicas.
The main restriction with using this original design is the ldap database needs to be restarted on both the master and the slave when adding additional replicas.
Line 23: Line 23:


A slave LDAP database that provides load balance authentication, and can be used as a failover if the master becomes unavailable.
A slave LDAP database that provides load balance authentication, and can be used as a failover if the master becomes unavailable.



Line 30: Line 31:


'''Consumers(s)'''
'''Consumers(s)'''



A provider LDAP database that has the most updated version of the database.
A provider LDAP database that has the most updated version of the database.


A consumer requests an update at a set interval, and provides load balancing.
A consumer requests an update at a set interval, and provides load balancing.



The ulternative is to use syncrepl which is included in the ldap daemon. This means we no longer need to run slurpd daemon which is to replicate the database.
The ulternative is to use syncrepl which is included in the ldap daemon. This means we no longer need to run slurpd daemon which is to replicate the database.



There are 2 main types of syncrepl operation: '''“refeshOnly”''' operation where the consumer requests an update from the provider at set time interval defined as '''“interval=00:00:10:00”''' which would pull the provider every 10 minutes. The more desirable way is to use delta-syncrepl; this provides a mode known as '''“refrshAndPersist”''' which provides a consistent connection. Instead of using a time interval to poll the provider we have the parameter '''“retry="30 10 300 +"''' which means it will retry 10 times every 30 seconds, then every 300 seconds '''“+”''' indicates indefinite number of retries.
There are 2 main types of syncrepl operation: '''“refeshOnly”''' operation where the consumer requests an update from the provider at set time interval defined as '''“interval=00:00:10:00”''' which would pull the provider every 10 minutes. The more desirable way is to use delta-syncrepl; this provides a mode known as '''“refrshAndPersist”''' which provides a consistent connection. Instead of using a time interval to poll the provider we have the parameter '''“retry="30 10 300 +"''' which means it will retry 10 times every 30 seconds, then every 300 seconds '''“+”''' indicates indefinite number of retries.
Line 43: Line 43:


If you are using Syncrepl with version 2.2 Openldap delta-syncrepl is known to be very buggy, so you are better sticking with standard syncrepl refreshOnly mode.
If you are using Syncrepl with version 2.2 Openldap delta-syncrepl is known to be very buggy, so you are better sticking with standard syncrepl refreshOnly mode.



Additionally the ldap daemon does not need to be restarted on the provider; the consumer will request it by polling the provider at a set interval.
Additionally the ldap daemon does not need to be restarted on the provider; the consumer will request it by polling the provider at a set interval.

Revision as of 10:46, 25 January 2007

2.0: Configuring LDAP

It is necessary to use LDAP as our backend to Samba which provides replication to the Backup Domain Controllers.

There are two methods for providing replication, using openldap’s “slurpd” to provide Master / Slave operation, the database is pushed to slaves which is defined in slapd.conf on the master LDAP server; here is an example of the original way defined in 2.1: slapd.conf Master.

replica     host=192.168.0.3:389
            suffix="dc=differentialdesign,dc=org"
            binddn="cn=syncuser,dc=differentialdesign,dc=org"
            bindmethod=simple credentials=SyncUser

To bind to the database the slave replicas will need to use “syncusers’s” password defined above as “credentials=SyncUser“. Initially you will need to manually populate the slave database as defined in section 3.4 Database Replication.

The main restriction with using this original design is the ldap database needs to be restarted on both the master and the slave when adding additional replicas.

LDAP Replication Configuration

Master

Slave(s)

A master LDAP database that is replicated real time to the backup domain controller.

A slave LDAP database that provides load balance authentication, and can be used as a failover if the master becomes unavailable.


LDAP Replication Configuration

Provider

Consumers(s)


A provider LDAP database that has the most updated version of the database.

A consumer requests an update at a set interval, and provides load balancing.

The ulternative is to use syncrepl which is included in the ldap daemon. This means we no longer need to run slurpd daemon which is to replicate the database.

There are 2 main types of syncrepl operation: “refeshOnly” operation where the consumer requests an update from the provider at set time interval defined as “interval=00:00:10:00” which would pull the provider every 10 minutes. The more desirable way is to use delta-syncrepl; this provides a mode known as “refrshAndPersist” which provides a consistent connection. Instead of using a time interval to poll the provider we have the parameter “retry="30 10 300 +" which means it will retry 10 times every 30 seconds, then every 300 seconds “+” indicates indefinite number of retries.


If you are using Syncrepl with version 2.2 Openldap delta-syncrepl is known to be very buggy, so you are better sticking with standard syncrepl refreshOnly mode.

Additionally the ldap daemon does not need to be restarted on the provider; the consumer will request it by polling the provider at a set interval.