Hi!
This is an old can of worms, Bobby.
Basically, Quanah & the OpenLDAP developers are not interested in supporting old versions, because it takes away from the time they have to work on the current version. We as users should support this, because the software will stop growing if the devs spend too much time on older versions.
I understand completely. I write software myself and only admin my network enough to support my software development. I have a small number of users but a large number of machines hence why I use ldaps.
I dont want to support years old releases of my own software. However, I dont radically change my config file formats either :)
I've followed this policy for the decade or so that I've been using OpenLDAP and been very successful. I am running a large infrastructure of Red Hat OL builds right now - dozens of replicas, with no problems whatsoever.
Thanks!! I'm going to tackle the conversion after I get this new system in place.
Bobby
--On Monday, May 21, 2012 4:11 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
This is an old can of worms, Bobby.
Basically, Quanah & the OpenLDAP developers are not interested in supporting old versions, because it takes away from the time they have to work on the current version. We as users should support this, because the software will stop growing if the devs spend too much time on older versions.
It has nothing to do with not wanting to support old versions. It has to do with ensuring people do not encounter bugs already known to be fixed.
I've followed this policy for the decade or so that I've been using OpenLDAP and been very successful. I am running a large infrastructure of Red Hat OL builds right now - dozens of replicas, with no problems whatsoever.
Then you have either been extremely lucky, or you aren't doing routine comparisons of the validity of your replicated data (assuming you are using syncrepl and not delta-syncrepl).
The other bit you clearly miss is the fact of RH using NSS instead of OpenSSL, which is a whole other can of worms.
--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
On 21/5/2012 11:39 μμ, Quanah Gibson-Mount wrote:
Then you have either been extremely lucky, or you aren't doing routine comparisons of the validity of your replicated data
By the way, is there a tool or a suggested way to do routine comparisons of the validity of replicated data (using syncrepl)?
Thanks, Nick
--On Tuesday, May 22, 2012 1:32 PM +0300 Nick Milas nick@eurobjects.com wrote:
On 21/5/2012 11:39 μμ, Quanah Gibson-Mount wrote:
Then you have either been extremely lucky, or you aren't doing routine comparisons of the validity of your replicated data
By the way, is there a tool or a suggested way to do routine comparisons of the validity of replicated data (using syncrepl)?
man slapcat
--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
On 22/5/2012 7:48 μμ, Quanah Gibson-Mount wrote:
man slapcat
Thank you Quanah,
You mean slapcat both ends and diff the two ldif files? I am afraid I don't understand.
If so, are the two output files expected to have exported entries in the same sequence?
Can you please be more detailed?
Thanks, Nick
--On May 22, 2012 8:19:22 PM +0300 Nick Milas nick@eurobjects.com wrote:
On 22/5/2012 7:48 μμ, Quanah Gibson-Mount wrote:
man slapcat
Thank you Quanah,
You mean slapcat both ends and diff the two ldif files? I am afraid I don't understand.
If so, are the two output files expected to have exported entries in the same sequence?
Can you please be more detailed?
I would generally expect a replica to export the database in the same order as the master. But in general, yes, you compare the LDIF generated by the master and the replica. If the replica is out of order in relation to the master, you can use the ldifsort perl utility that's found fairly easily to sort both ldif's into entry order prior to doing the diff.
--Quanah
On 23/5/2012 6:11 πμ, Quanah Gibson-Mount wrote:
I would generally expect a replica to export the database in the same order as the master. But in general, yes, you compare the LDIF generated by the master and the replica. If the replica is out of order in relation to the master, you can use the ldifsort perl utility that's found fairly easily to sort both ldif's into entry order prior to doing the diff.
Thanks,
This method however would be really feasible only when the whole DIT is replicated. If a non-root DN is used for replication, then only the parts of the DIT that are accessible by that DN will be replicated.
Additionally, slapcat outputs operational attributes too, which I think can not be identical on both ends.
In this case I think slapcat does not offer a solution. Therefore, could we use:
ldapsearch -H <provider> -D <dn used on the consumer setup> <filter, if used on the consumer setup> -L *
and
ldapsearch -H <consumer> -D <root dn> -L *
instead (without operational attrs)?
Is this approach correct?
Regards, Nick
--On May 23, 2012 12:52:19 PM +0300 Nick Milas nick@eurobjects.com wrote:
On 23/5/2012 6:11 πμ, Quanah Gibson-Mount wrote:
I would generally expect a replica to export the database in the same order as the master. But in general, yes, you compare the LDIF generated by the master and the replica. If the replica is out of order in relation to the master, you can use the ldifsort perl utility that's found fairly easily to sort both ldif's into entry order prior to doing the diff.
Thanks,
This method however would be really feasible only when the whole DIT is replicated. If a non-root DN is used for replication, then only the parts of the DIT that are accessible by that DN will be replicated.
Additionally, slapcat outputs operational attributes too, which I think can not be identical on both ends.
With the exception of perhaps ppolicy overlay, the operational attributes better damn well be identical. ;)
Also, the recommendation is always to use a non-rootDN for replication. I fail to see what that has to do with anything. You can certainly fully replicate the DIT w/o a root DN for replication.
In this case I think slapcat does not offer a solution. Therefore, could we use:
ldapsearch -H <provider> -D <dn used on the consumer setup> <filter, if used on the consumer setup> -L *and
ldapsearch -H <consumer> -D <root dn> -L *instead (without operational attrs)?
Is this approach correct?
No. Again, man slapcat. It accepts filters too.
--Quanah
Nick Milas wrote:
On 23/5/2012 6:11 πμ, Quanah Gibson-Mount wrote:
I would generally expect a replica to export the database in the same order as the master. But in general, yes, you compare the LDIF generated by the master and the replica. If the replica is out of order in relation to the master, you can use the ldifsort perl utility that's found fairly easily to sort both ldif's into entry order prior to doing the diff.
Thanks,
This method however would be really feasible only when the whole DIT is replicated. If a non-root DN is used for replication, then only the parts of the DIT that are accessible by that DN will be replicated.
RTFM. slapcat(8) can be told to dump only a portion of the database, if desired.
Additionally, slapcat outputs operational attributes too, which I think can not be identical on both ends.
Possibly. There are server-specific operational attributes, which might differ from one to the next. These are pretty rare though. Most operational attributes are global to the directory system, and will be identical.
On 23/5/2012 5:35 μμ, Howard Chu wrote:
RTFM. slapcat(8) can be told to dump only a portion of the database, if desired.
I know we can specify filters. However there is a huge difference between specifying a filter and replicating based on ACLs (see below more on this).
Possibly. There are server-specific operational attributes, which might differ from one to the next. These are pretty rare though. Most operational attributes are global to the directory system, and will be identical.
OK, this is important to know. Thanks.
On 23/5/2012 5:15 μμ, Quanah Gibson-Mount wrote:
Also, the recommendation is always to use a non-rootDN for replication. I fail to see what that has to do with anything. You can certainly fully replicate the DIT w/o a root DN for replication.
Of course we can replicate the whole DIT without a root DN. The problem is the opposite: when we *don't want* to replicate the whole DIT and we *intentionally* configure our consumers not with a filter, but with a bind DN which has limited access to only particular parts of the DIT. This is our case.
In such a case we *could try* to create a filter to simulate our ACLs, in order to use it in a slapcat, but it's not the same, and it's not guaranteed that such a filter will be possible to be constructed. Right?
So, what are our options here?
Thanks, Nick
Nick Milas wrote:
If a non-root DN is used for replication, then only the parts of the DIT that are accessible by that DN will be replicated.
Additionally, slapcat outputs operational attributes too, which I think can not be identical on both ends.
Because it is possible to initialize a replica with a slapcat output, we need all attributes which are in this output. All other operational attributes are not needed.
I have not done this in practice but I believe one may try it this way.
Assume you have an entry cn=111. So we slapcat this entry and do a temporarely search. attributes which are in slapcat and NOT in search must be added to the final search. Then compare the output of both operations.
slapcat -n1 -H 'ldap:///???(cn=111)' 2>/dev/null |cut -d: -f1 dn cn objectClass UIFtype UIFsource structuralObjectClass entryUUID creatorsName createTimestamp entryCSN modifiersName modifyTimestamp
ldapsearch -xAMMLLL 'cn=111' '*' 2>/dev/null |cut -d: -f1 dn cn objectClass UIFtype UIFsource
In this case, a db which is not a replica, we must add this attributes: structuralObjectClass entryUUID creatorsName createTimestamp entryCSN modifiersName modifyTimestamp
so the final search is: ldapsearch -xMMLLL 'cn=111' '*' structuralObjectClass entryUUID creatorsName createTimestamp entryCSN modifiersName modifyTimestamp 2>/dev/null
The used switches MM and LLL are important.
So now we have a way to partial slapcat a DIT and do a search which produces the same result if the user who is doing the search, has the rights to see all attributes.
Use the mentioned perl tools to sort and diff the output.
On 23/5/2012 10:38 μμ, harry.jede@arcor.de wrote:
so the final search is: ldapsearch -xMMLLL 'cn=111' '*' structuralObjectClass entryUUID creatorsName createTimestamp entryCSN modifiersName modifyTimestamp 2>/dev/null
The used switches MM and LLL are important.
So now we have a way to partial slapcat a DIT and do a search which produces the same result if the user who is doing the search, has the rights to see all attributes.
Thank you Harry for your insightful info!
I'll test your suggestion soon.
Regards, Nick
openldap-technical@openldap.org
-
Bobby Krupczak -
harry.jede＠arcor.de -
Howard Chu -
Nick Milas -
Quanah Gibson-Mount