Hello list.
I'm planning to deploy ppolicy on our directory, but I'm facing a problem with replication, as I only control the master server, and not the slaves configuration for the moment.
Despite being only active on the master server, a local experiment told me than the slaves need the following items: - the ppolicy schema, for replicating policies objects - the ppolicy overlay, for replicating operational attributes of user objects
The first requisite is quite easy to achieve, as it is just a file I need other admins to add in their configuration. The second is a bit more difficult, as it is an additional binary, and given the lack of consistency between servers, I'm not sure it is available for each installation...
So, is there some way of either configuring ppolicy or the replication, to avoid the need for the ppolicy overlay on the slaves, while I don't have full control over all the servers ?
--On Monday, July 16, 2012 2:44 PM +0200 Guillaume Rousse guillomovitch@gmail.com wrote:
Hello list.
I'm planning to deploy ppolicy on our directory, but I'm facing a problem with replication, as I only control the master server, and not the slaves configuration for the moment.
Despite being only active on the master server, a local experiment told me than the slaves need the following items:
- the ppolicy schema, for replicating policies objects
- the ppolicy overlay, for replicating operational attributes of user
objects
The first requisite is quite easy to achieve, as it is just a file I need other admins to add in their configuration. The second is a bit more difficult, as it is an additional binary, and given the lack of consistency between servers, I'm not sure it is available for each installation...
So, is there some way of either configuring ppolicy or the replication, to avoid the need for the ppolicy overlay on the slaves, while I don't have full control over all the servers ?
ppolicy verions need to match too, so you can't just rely on distro builds. I would strongly advise you to make your *own* build of OpenLDAP at a fixed version, which they then need to deploy.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Le 16/07/2012 18:51, Quanah Gibson-Mount a écrit :
So, is there some way of either configuring ppolicy or the replication, to avoid the need for the ppolicy overlay on the slaves, while I don't have full control over all the servers ?
ppolicy verions need to match too, so you can't just rely on distro builds. I would strongly advise you to make your *own* build of OpenLDAP at a fixed version, which they then need to deploy.
Given than those different slave servers actually use different OS (various linux distributions), that's quite irrealistic :)
What kind of bad surprise should I expect from different versions here ? Just "Bad things may happen", or more precise issues ?
--On Monday, July 16, 2012 7:32 PM +0200 Guillaume Rousse guillomovitch@gmail.com wrote:
Le 16/07/2012 18:51, Quanah Gibson-Mount a écrit :
So, is there some way of either configuring ppolicy or the replication, to avoid the need for the ppolicy overlay on the slaves, while I don't have full control over all the servers ?
ppolicy verions need to match too, so you can't just rely on distro builds. I would strongly advise you to make your *own* build of OpenLDAP at a fixed version, which they then need to deploy.
Given than those different slave servers actually use different OS (various linux distributions), that's quite irrealistic :)
What kind of bad surprise should I expect from different versions here ? Just "Bad things may happen", or more precise issues ?
I don't see it as unrealistic at all. It is perfectly possible to create OpenLDAP binary distributions that run on multiple linux OSes. You shouldn't be mix & matching OpenLDAP versions anyway between your master and the slaves. As for ppolicy, there are incompatibilities between different versions, you would probably want to read the CHANGES file to see what changes have been done.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Guillaume Rousse -
Quanah Gibson-Mount