[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Openldap replication over XMPP

Emmanuel Lecharny wrote:

   On 7/22/10 8:23 AM, kalyan wrote:

On Wed, Jul 21, 2010 at 02:50:27PM -0700, Howard Chu wrote:

kalyan wrote:

Hi,

I would like to share some simple idea and find out similar interest.
This is about the ldap replication using the existing xmpp network.

Why?


To be frank, i did not think this because there is some serious problem
in the existing replication mechanism. But the below might be considered
for your question.

<snip/>

Definitely this can't be a default replication method for openldap, but
I am thinking what if I make another directory server to sync to openldap.

The best way is probably for this different server to implement RFC
4533. This is what we did at Apache Directory Server allowing us to sync
with an OpenLDAP server. It works, it's not *that* complicated. Here is
an exemple on how to leverage a Java API implementing this RFC :

http://fanf42.blogspot.com/2010/07/java-ldap-sdk-for-syncrepl-replication.html
I would never be one to tell someone not to do whatever they want to do for fun. (My first C programming project was Hack 1.0.2 - there's nothing more fun than hacking on a game...) But if you're going to do something with LDAP you might as well make it useful too. Two small projects that could be completed in a short amount of time: implement a DirSync module for OpenLDAP to replicate from M$AD, and implement a passwordSync module for OpenLDAP with AD.
Inventing new protocols can be fun, but IMO it's only worthwhile if the new protocols are more efficient than existing ones. New protocols need to be more than "twice as good" as existing ones in order to have any chance of adoption. Otherwise it's not worth the effort of transitioning the installed base. 


To be frank, i did not think this because there is some serious problem
in the existing replication mechanism. But the below might be considered
for your question.

* The unchanged attribute is never sent to other server. Always the
  changed attribute is sent instantly.


Delta-syncrepl already does this.


* The above delta sync does not maintain a changelog, because the
  changes will be sent immediatly as it happens on a server and
  unreachable server receives an offline message. Hence no need of
  a changelog.
Your offline message store becomes a changelog anyway. It's incorrect to say there is no changelog in your scheme. 


* N-Way multi-master + multi-salve combination is acheived. You could
  change the role of a server to master or to slave without the need to
  change the configuration file and restarting the server.


All of this is already supported using cn=config with no restarts required.


* If its secure environment and if xmpp ports are opened this can be
  used as proxy as well. But I dont know such environment exist.
It's quite hard to envision an environment where LDAP is needed but is being blocked by a firewall, while the much riskier XMPP protocol is not being blocked. 

* I learn openldap and xmpp.
XMPP, and anything else based on XML, is just a gross misuse of SGML. Any network that actually deployed the solution you suggest would quickly be overwhelmed by the traffic, which would be far more heavyweight in carrying LDAP traffic than just plain LDAP. 


* Its FUN.


Not everything that's FUN is GOOD.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/