Hi,
This post is because of: http://www.openldap.org/lists/openldap-technical/200906/msg00221.html http://www.openldap.org/lists/openldap-technical/200908/msg00028.html
So, if you're using ppolicy-slapo in a load-balanced environment, you pool servers never will be sync completely; at least, the ppolicy state atributes will be not replicated. I know isn't really a slapo-ppolicy limitation rather than RFC especification consequence.
Well... I want my load-balancing environment and I want also the ppolicy overlay. So ¿how to make an effective workaround?
At first, I've thinked in next scenario:
* 1 provider and 2 consumers * every 5 minutes the consumers rsync the contents of master ddbb (/var/lib/ldap/* in my case, Debian Lenny boxes)
¿It will be enough?
I wonder if consumers slapd can accept these data change "on the fly" or maybe restarting the service is mandatory.
--On August 6, 2009 11:36:48 AM +0200 Jordi Espasa Clofent jespasac@minibofh.org wrote:
Hi,
This post is because of: http://www.openldap.org/lists/openldap-technical/200906/msg00221.html http://www.openldap.org/lists/openldap-technical/200908/msg00028.html
So, if you're using ppolicy-slapo in a load-balanced environment, you pool servers never will be sync completely; at least, the ppolicy state atributes will be not replicated. I know isn't really a slapo-ppolicy limitation rather than RFC especification consequence.
Well... I want my load-balancing environment and I want also the ppolicy overlay. So ¿how to make an effective workaround?
I would check out ppolicy and the man page from REL_ENG_2_4 CVS, where an option to push all updates to the master instead of updating the slave has been added.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Jordi Espasa Clofent wrote:
Hi,
This post is because of: http://www.openldap.org/lists/openldap-technical/200906/msg00221.html http://www.openldap.org/lists/openldap-technical/200908/msg00028.html
So, if you're using ppolicy-slapo in a load-balanced environment, you pool servers never will be sync completely; at least, the ppolicy state atributes will be not replicated. I know isn't really a slapo-ppolicy limitation rather than RFC especification consequence.
This is already fixed in 2.4.17 ppolicy. Read the slapo-ppolicy manpage, look at the Forward_Updates directive.
openldap-technical@openldap.org
-
Howard Chu -
Jordi Espasa Clofent -
Quanah Gibson-Mount