--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 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 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 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

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

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