Hello,
I was wondering if someone could give a quick summary comparing these two. Are there any benefits going with either one?
Thanks,
Michael Pelletier Senior Linux Systems Administrator / Programmer INTECH (Enhanced Investment Technologies, LLC) http://www.intechjanus.com/
This e-mail transmission contains information intended only for the use of the recipient(s) named above. Further, it contains information that may be privileged and confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message (including any attachments) is strictly prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail and then delete this message from your mail system. Thank you for your compliance.
Michael Pelletier wrote:
Hello,
I was wondering if someone could give a quick summary comparing these two. Are there any benefits going with either one?
There are no benefits to using slurpd. I could elaborate but I don't wish to violate the confidentiality of your email or disseminate the information to any unintended recipients.
Thanks,
Michael Pelletier Senior Linux Systems Administrator / Programmer INTECH (Enhanced Investment Technologies, LLC) http://www.intechjanus.com/
This e-mail transmission contains information intended only for the use of the recipient(s) named above. Further, it contains information that may be privileged and confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message (including any attachments) is strictly prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail and then delete this message from your mail system. Thank you for your compliance.
On Thu, Mar 22, 2007 at 01:56:47AM -0700, Howard Chu wrote:
There are no benefits to using slurpd. I could elaborate but I don't wish to violate the confidentiality of your email or disseminate the information to any unintended recipients.
Can you elaborate in a reply to me? I have no braindead-automatically-attached-policy about e-mail confidentiality :-)
I have set up something using slurpd because I understood that using replsync, the replica would need an access on the master, whereas slurpd allowed a pure push method, where the replicas have no right to connect to the master (the master can even be firewalled)
Emmanuel Dreyfus wrote:
Can you elaborate in a reply to me? I have no braindead-automatically-attached-policy about e-mail confidentiality :-)
Sure...
I have set up something using slurpd because I understood that using replsync, the replica would need an access on the master, whereas slurpd allowed a pure push method, where the replicas have no right to connect to the master (the master can even be firewalled)
Syncrepl can operate in either direction. In the pure push/firewall case, just set up a proxy backend as the syncrepl consumer. test045 and test048 in the test suite both demonstrate how to configure this. Those tests are in OpenLDAP 2.4, but you can do something similar in 2.3. You just need to use a separate slapd instance for the consumer in 2.3.
Just because the protocol was defined a particular way (consumer initiated single master replication) doesn't mean it can't be used in other ways. OpenLDAP is far more flexible than that. We've enhanced the basic syncrepl functionality a number of different ways (delta-syncrepl, proxied syncrepl, mirrormode, and multimaster) all without altering any of the syncrepl protocol definition. All it takes is a little creativity to assemble the pieces in the proper order.
On Thu, Mar 22, 2007 at 02:44:19AM -0700, Howard Chu wrote:
Just because the protocol was defined a particular way (consumer initiated single master replication) doesn't mean it can't be used in other ways. OpenLDAP is far more flexible than that. We've enhanced the basic syncrepl functionality a number of different ways (delta-syncrepl, proxied syncrepl, mirrormode, and multimaster) all without altering any of the syncrepl protocol definition. All it takes is a little creativity to assemble the pieces in the proper order.
And what are the reasons for not using slurpd? It has less functionnalities, but can it be considered reliable? Should I change my working setup for syncrepl, or can I live with slurpd?
Emmanuel Dreyfus wrote:
On Thu, Mar 22, 2007 at 02:44:19AM -0700, Howard Chu wrote:
Just because the protocol was defined a particular way (consumer initiated single master replication) doesn't mean it can't be used in other ways. OpenLDAP is far more flexible than that. We've enhanced the basic syncrepl functionality a number of different ways (delta-syncrepl, proxied syncrepl, mirrormode, and multimaster) all without altering any of the syncrepl protocol definition. All it takes is a little creativity to assemble the pieces in the proper order.
And what are the reasons for not using slurpd? It has less functionnalities, but can it be considered reliable? Should I change my working setup for syncrepl, or can I live with slurpd?
Problems with slurpd have been discussed on the lists and recorded in the ITS many times over the years. I'll just recap briefly:
No, it is not reliable. It is extremely sensitive to the ordering of records in the replog; it can easily go out of sync at which point manual intervention is required to resync the slave database with the master.
Syncrepl is self-synchronizing; you can start with a database in any state from totally empty to fully sync'd and it will automatically do the right thing to achieve and maintain synchronization.
Slurpd isn't very tolerant of unavailable servers. If a slave goes down for a long time, the replog may grow to a size that's too large for slurpd to process. Some of these problems are fixable, but there's really no point. Syncrepl covers all the bases slurpd did, plus more.
The slurpd code is going to be deleted from the source tree. Maybe not in 2.4 (though I think that's still possible) but certainly by 2.5.
Hi,
Just yesterday i set up slurpd for replication. The openldap documentation points one to slurpd at many places. Example: http://www.openldap.org/doc/admin23/config.html#Replicated%20Directory%20Ser... No word of an alternative. Could someone give some hints in that chapter and problably in the chapter "14. Replication with slurpd"? The FAQ-O-Matic says that "multimaster replication is harmful". Is this still true as you say that syncrepl works with that?
Thanks for the nice piece of software.
Flo
Howard Chu schrieb:
Emmanuel Dreyfus wrote:
On Thu, Mar 22, 2007 at 02:44:19AM -0700, Howard Chu wrote:
Just because the protocol was defined a particular way (consumer initiated single master replication) doesn't mean it can't be used in other ways. OpenLDAP is far more flexible than that. We've enhanced the basic syncrepl functionality a number of different ways (delta-syncrepl, proxied syncrepl, mirrormode, and multimaster) all without altering any of the syncrepl protocol definition. All it takes is a little creativity to assemble the pieces in the proper order.
And what are the reasons for not using slurpd? It has less functionnalities, but can it be considered reliable? Should I change my working setup for syncrepl, or can I live with slurpd?
Problems with slurpd have been discussed on the lists and recorded in the ITS many times over the years. I'll just recap briefly:
No, it is not reliable. It is extremely sensitive to the ordering of records in the replog; it can easily go out of sync at which point manual intervention is required to resync the slave database with the master.
Syncrepl is self-synchronizing; you can start with a database in any state from totally empty to fully sync'd and it will automatically do the right thing to achieve and maintain synchronization.
Slurpd isn't very tolerant of unavailable servers. If a slave goes down for a long time, the replog may grow to a size that's too large for slurpd to process. Some of these problems are fixable, but there's really no point. Syncrepl covers all the bases slurpd did, plus more.
The slurpd code is going to be deleted from the source tree. Maybe not in 2.4 (though I think that's still possible) but certainly by 2.5.
flo@redflo.de wrote:
Hi,
Just yesterday i set up slurpd for replication. The openldap documentation points one to slurpd at many places. Example: http://www.openldap.org/doc/admin23/config.html#Replicated%20Directory%20Ser... No word of an alternative. Could someone give some hints in that chapter and problably in the chapter "14. Replication with slurpd"?
"Someone" probably could. Maybe that someone should be you. File an ITS.
The FAQ-O-Matic says that "multimaster replication is harmful". Is this still true as you say that syncrepl works with that?
At a basic level, multi-master replication introduces a lot of uncertainty/potential inconsistency into the database. The X.500 service model makes some consistency guarantees that break in a multi-master environment, and such inconsistencies can certainly cause problems in many situations.
On the other hand, even single-master isn't perfectly consistent 100% of the time, due to the delay time in propagating changes from a master to all of the slaves. And it's always possible for a rapid sequence of changes to create the appearance of conflicting data. (E.g., a bunch of modifies in rapid succession, that toggle a particular attribute between a few values. The value that a reading client sees is really unpredictable, it just depends on luck, at what instant its search request is processed, relative to the modifications.)
The syncrepl protocol only offers loose consistency to begin with - it only guarantees eventual convergence. But what's important is that the convergence will actually occur. The multi-master support is the same - it's possible for conflicting views of the data to appear within small time intervals, but eventually it will all resolve.
Thanks for the nice piece of software.
Hi,
Is possible access rights info configured as ACL in config file achieve as ACI or similar attribute for each object ?
Thanks in advance,
Andris Eiduks
openldap-software@openldap.org
-
Andris.Eiduks＠tietoenator.com -
Emmanuel Dreyfus -
flo＠redflo.de -
Howard Chu -
Michael Pelletier -
Tony Earnshaw