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.
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, and not worry which machine is use to make changes, modification, etc.... 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? 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? Please advise.
Any help is greatly appreciated.
-Ivan
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
Buchan Milne wrote:
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).
I'm sorry for not providing as much information as I can. We are using openldap version 2.3.43 and samba 3.0.31.
Having the PDC replicate to BDC1 and BDC2 to me seems a little risky. What happen if the PDC crashed? Will you have to configure one of the BDC to be the new PDC? We want to make it act like a Windows domain type of replication where we can use any of the DCs to make changes.
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.).
What I meant to say is to have all the server sync every time a change is made. RefreshAndPersist seems like the way to go here.
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.
Our BDCs are set in a way that they can only see and read the changes made to samba and ldap. You can not create account or make any changes on our domain using the BDCs. That is the way it was setup.
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)
Thanks for all your help.
Regards, Buchan
I'm about ready to configure slapd.conf on our domain controllers to use "syncrepl" to replicate our database but before I do, I want to ask a question regarding recovery.
If things don't go into plan and say our backend database crashed, how do I proceed about recovering the database? is "db_recover" good enough tools to get us up and running again?
Ivan Ordonez wrote:
Buchan Milne wrote:
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).
I'm sorry for not providing as much information as I can. We are using openldap version 2.3.43 and samba 3.0.31.
Having the PDC replicate to BDC1 and BDC2 to me seems a little risky. What happen if the PDC crashed? Will you have to configure one of the BDC to be the new PDC? We want to make it act like a Windows domain type of replication where we can use any of the DCs to make changes.
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.).
What I meant to say is to have all the server sync every time a change is made. RefreshAndPersist seems like the way to go here.
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.
Our BDCs are set in a way that they can only see and read the changes made to samba and ldap. You can not create account or make any changes on our domain using the BDCs. That is the way it was setup.
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)
Thanks for all your help.
Regards, Buchan
I still can't get syncrepl to work on our machines.
Looking at the log, the one error that stands out to me is the error below. I get this error when I start LDAP.
slapd[16146]: do_syncrep1: rid 001 ldap_sasl_bind_s failed (13) slapd[16146]: do_syncrepl: rid 001 quitting
I'm not sure why it is failing since I know for sure, my password is correct. Removing the "updatedn" line will get rid of the error, but that doesn't fix the issue. Any changes I made on the Master server doesn't replicate or go to the Slave server.
Here is my setup.
Master overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
Slave syncrepl rid=1 provider=ldap://pdc.ldap.com:389 type=refreshAndPersist searchbase="dc=my,dc=domain,dc=com" schemachecking=off updatedn="cn=Replicator,ou=DSA,dc=my,dc=domain,dc=com" binddn="cn=Replicator,ou=DSA,dc=my,dc=domain,dc=com" bindmethod=simple credentials=mypassword
Thanks in advance.
-Ivan
Ivan Ordonez wrote:
Buchan Milne wrote:
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).
I'm sorry for not providing as much information as I can. We are using openldap version 2.3.43 and samba 3.0.31.
Having the PDC replicate to BDC1 and BDC2 to me seems a little risky. What happen if the PDC crashed? Will you have to configure one of the BDC to be the new PDC? We want to make it act like a Windows domain type of replication where we can use any of the DCs to make changes.
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.).
What I meant to say is to have all the server sync every time a change is made. RefreshAndPersist seems like the way to go here.
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.
Our BDCs are set in a way that they can only see and read the changes made to samba and ldap. You can not create account or make any changes on our domain using the BDCs. That is the way it was setup.
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)
Thanks for all your help.
Regards, Buchan
--On Wednesday, December 03, 2008 5:50 PM -0800 Ivan Ordonez iordonez@nature.berkeley.edu wrote:
I still can't get syncrepl to work on our machines.
Looking at the log, the one error that stands out to me is the error below. I get this error when I start LDAP.
slapd[16146]: do_syncrep1: rid 001 ldap_sasl_bind_s failed (13) slapd[16146]: do_syncrepl: rid 001 quitting
I'm not sure why it is failing since I know for sure, my password is correct. Removing the "updatedn" line will get rid of the error, but that doesn't fix the issue. Any changes I made on the Master server doesn't replicate or go to the Slave server.
updatedn is not valid for a syncrepl statement.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
No wonder I am getting that error. When I removed the updatedn, the error disappear but syncrepl still doesn't work.
Can anyone please point me in the right direction of converting database from slurpd to syncrepl? I found a link in Google but the howto did not work.
Thanks, -Ivan Ivan Ordonez wrote:
I still can't get syncrepl to work on our machines.
Looking at the log, the one error that stands out to me is the error below. I get this error when I start LDAP.
slapd[16146]: do_syncrep1: rid 001 ldap_sasl_bind_s failed (13) slapd[16146]: do_syncrepl: rid 001 quitting
I'm not sure why it is failing since I know for sure, my password is correct. Removing the "updatedn" line will get rid of the error, but that doesn't fix the issue. Any changes I made on the Master server doesn't replicate or go to the Slave server.
Here is my setup.
Master overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
Slave syncrepl rid=1 provider=ldap://pdc.ldap.com:389 type=refreshAndPersist searchbase="dc=my,dc=domain,dc=com" schemachecking=off updatedn="cn=Replicator,ou=DSA,dc=my,dc=domain,dc=com" binddn="cn=Replicator,ou=DSA,dc=my,dc=domain,dc=com" bindmethod=simple credentials=mypassword
Thanks in advance.
-Ivan
Ivan Ordonez wrote:
Buchan Milne wrote:
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).
I'm sorry for not providing as much information as I can. We are using openldap version 2.3.43 and samba 3.0.31.
Having the PDC replicate to BDC1 and BDC2 to me seems a little risky. What happen if the PDC crashed? Will you have to configure one of the BDC to be the new PDC? We want to make it act like a Windows domain type of replication where we can use any of the DCs to make changes.
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.).
What I meant to say is to have all the server sync every time a change is made. RefreshAndPersist seems like the way to go here.
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.
Our BDCs are set in a way that they can only see and read the changes made to samba and ldap. You can not create account or make any changes on our domain using the BDCs. That is the way it was setup.
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)
Thanks for all your help.
Regards, Buchan
--On Wednesday, December 03, 2008 6:10 PM -0800 Ivan Ordonez iordonez@nature.berkeley.edu wrote:
No wonder I am getting that error. When I removed the updatedn, the error disappear but syncrepl still doesn't work.
Can anyone please point me in the right direction of converting database from slurpd to syncrepl? I found a link in Google but the howto did not work.
Don't use howto's. Use official documentation.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
I take it back. I am still getting the error message below even after removing the "updatedn" line.
slapd[16146]: do_syncrep1: rid 001 ldap_sasl_bind_s failed (13) slapd[16146]: do_syncrepl: rid 001 quitting
Can someone please help on this. I have been following the official documentation carefully to no avail.
Thanks, -Ivan
Quanah Gibson-Mount wrote:
--On Wednesday, December 03, 2008 6:10 PM -0800 Ivan Ordonez iordonez@nature.berkeley.edu wrote:
No wonder I am getting that error. When I removed the updatedn, the error disappear but syncrepl still doesn't work.
Can anyone please point me in the right direction of converting database from slurpd to syncrepl? I found a link in Google but the howto did not work.
Don't use howto's. Use official documentation.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
We are using OpenLDAP version 2.3.43 on Gentoo. Samba version is 3.0.33.
Thanks again.
-Ivan
Ivan Ordonez wrote:
I take it back. I am still getting the error message below even after removing the "updatedn" line.
slapd[16146]: do_syncrep1: rid 001 ldap_sasl_bind_s failed (13) slapd[16146]: do_syncrepl: rid 001 quitting
Can someone please help on this. I have been following the official documentation carefully to no avail.
Thanks, -Ivan
Quanah Gibson-Mount wrote:
--On Wednesday, December 03, 2008 6:10 PM -0800 Ivan Ordonez iordonez@nature.berkeley.edu wrote:
No wonder I am getting that error. When I removed the updatedn, the error disappear but syncrepl still doesn't work.
Can anyone please point me in the right direction of converting database from slurpd to syncrepl? I found a link in Google but the howto did not work.
Don't use howto's. Use official documentation.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On Thursday, December 04, 2008 10:02 AM -0800 Ivan Ordonez iordonez@nature.berkeley.edu wrote:
Ivan Ordonez wrote:
I take it back. I am still getting the error message below even after removing the "updatedn" line.
slapd[16146]: do_syncrep1: rid 001 ldap_sasl_bind_s failed (13) slapd[16146]: do_syncrepl: rid 001 quitting
Can someone please help on this. I have been following the official documentation carefully to no avail.
Your error indicates that binding from the replica to the master failed. Have you tried doing a bind from the replica itself to the master as the replica's credentials? Something like:
ldapsearch -LLL -x -H ldap://pdc.ldap.com:389 -D "cn=Replicator,ou=DSA,dc=my,dc=domain,dc=com" -s base -b "dc=my,dc=domain,dc=com" -w mypassword
from the replica itself.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
I tried your suggestion and the result I got was below:
dn: dc=my,dc=domain,dc=com objectClass: dcObject objectClass: organization o: my dc: my
Is this the result we want?
-Ivan
Quanah Gibson-Mount wrote:
--On Thursday, December 04, 2008 10:02 AM -0800 Ivan Ordonez iordonez@nature.berkeley.edu wrote:
Ivan Ordonez wrote:
I take it back. I am still getting the error message below even after removing the "updatedn" line.
slapd[16146]: do_syncrep1: rid 001 ldap_sasl_bind_s failed (13) slapd[16146]: do_syncrepl: rid 001 quitting
Can someone please help on this. I have been following the official documentation carefully to no avail.
Your error indicates that binding from the replica to the master failed. Have you tried doing a bind from the replica itself to the master as the replica's credentials? Something like:
ldapsearch -LLL -x -H ldap://pdc.ldap.com:389 -D "cn=Replicator,ou=DSA,dc=my,dc=domain,dc=com" -s base -b "dc=my,dc=domain,dc=com" -w mypassword
from the replica itself.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On Thursday, December 04, 2008 12:17 PM -0800 Ivan Ordonez iordonez@nature.berkeley.edu wrote:
I tried your suggestion and the result I got was below:
dn: dc=my,dc=domain,dc=com objectClass: dcObject objectClass: organization o: my dc: my
Is this the result we want?
Please don't top post. :)
And yes, that means it connected correctly.
Would it be possible for you to include your full master & replica conf files, with anything private (like secure passwords) blocked out.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org