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:
>>> I would like to share some simple idea and find out similar interest.
>>> This is about the ldap replication using the existing xmpp network.
> 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.
> 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 :
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
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
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
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/