On 27/01/2012 18:43, Michael Ströder wrote:

Jephte CLAIN wrote:

...

I use OpenLDAP 2.4.23 on debian squeeze

I'm currently testing full replication with the small configuration seed on the consumer side, but the replication is not complete.

For various reasons I would not use the OpenLDAP 2.4.23 packages shipped with Debian.

Note this article in OpenLDAP's FAQ:

Why is using the OpenLDAP server from a Linux distribution not recommended? http://www.openldap.org/faq/data/cache/1456.html

See also here for all the fixes to syncrepl implementation in OpenLDAP after 2.4.23:

http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=CHANGES;h=d...

Hello,

thank you for the suggestion. I was doing that with the 2.3.x line to always have the current version on our servers, but it was time consuming. Somehow, I felt the need to make my job easier. guess I'll start over the good practices :-)

in the 2.4.24 changelog, there is: Fixed slapd syncrepl refresh to use complete cookie (ITS#6807) which seems interesting

I'll try the newer version next monday to see if it fixes the issue. time to go home :-)

best regards,

Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

Peter Marschall wrote:

On Friday, 27. January 2012, Michael Ströder wrote:

...

For various reasons I would not use the OpenLDAP 2.4.23 packages shipped with Debian.

Note this article in OpenLDAP's FAQ:

Why is using the OpenLDAP server from a Linux distribution not recommended? http://www.openldap.org/faq/data/cache/1456.html

Thisd article is an interesting read, especially as - by pure chance - 2.4.23 is the lastest release officially declared stable of OpenLDAP. (http://www.openldap.org/software/download/)

On one hand declaring some versions as stable and on the other hand recommending people not to use those stable versions when they are provided by distributions as well as not giving any kind of support for releases declared stable (with the exception of the standard "ugrade to the latest release"), I consider OpenLDAP project's behaviour as contradictory.

Yes.

Why not simply giving up the "Stable" column on http://www.openldap.org/software/download/ when these is no difference between a stable release and any other release w.r.t. long term support, ...

http://www.openldap.org/lists/openldap-devel/201111/msg00046.html

Ciao, Michael.

On 27/01/2012 17:33, Jephte CLAIN wrote:

hello,

I'm new on this list. I use OpenLDAP 2.4.23 on debian squeeze

Hello,

Following the advice from Michael Ströder, I tried with OpenLDAP 2.4.28

By the way, I ported the openldap-2.4.28 package from wheezy to squeeze, and made source and binary packages. they are available on http://wapps.univ-reunion.fr/openldap-files/ There are minimal instructions to build them yourself, but it's in french (sorry). Also, it's totally unsupported, but you already did know that, didn't you :-)

It seems that the problem is still there with openldap-2.4.28. The log says:

4f28bfdf syncrepl_entry: rid=000 be_add cn=config (68) 4f28bfdf dn_callback : new entry is older than ours cn=config ours 20120201043021.553920Z#000000#000#000000, new 20120131114804.777497Z#000000#000#000000 4f28bfdf syncrepl_entry: rid=000 entry unchanged, ignored (cn=config)

4f28bfdf syncrepl_entry: rid=000 be_add olcDatabase={-1}frontend,cn=config (68) 4f28bfdf dn_callback : new entry is older than ours olcDatabase={-1}frontend,cn=config ours 20120201043021.554303Z#000000#000#000000, new 20120131114801.967340Z#000000#000#000000 4f28bfdf syncrepl_entry: rid=000 entry unchanged, ignored (olcDatabase={-1}frontend,cn=config)

4f28bfdf syncrepl_entry: rid=000 be_add olcDatabase={0}config,cn=config (68) 4f28bfdf dn_callback : new entry is older than ours olcDatabase={0}config,cn=config ours 20120201043021.554194Z#000000#000#000000, new 20120131114801.503432Z#000000#000#000000 4f28bfdf syncrepl_entry: rid=000 entry unchanged, ignored (olcDatabase={0}config,cn=config)

This is not working as documented, isn't it? For now, I will seed the consumer with an export of the two objects cn=config and olcDatabase={0}config,cn=config from the master. even though they are not updated, it will not be problem because the consumer will already be up to date :-)

However, my initial question remains:

My goal is to replicate schemas, indexes, limits, acls and Authz definitions. I thought that a whole replica would the easiest. How do you guys do this at your sites? Is it possible/advisable to only replicate a subset of cn=config?

I've got one more question: I'm not sure about the meaning of rid in 'slapd -c'. it's the replication id from the consumer side pov, ok?

so, suppose the master has

------------- 8< ------------- dn: olcDatabase={0}config,cn=config ... olcSyncrepl: {0}rid=0 provider="ldap://master.tld/" searchbase=cn=config bindmethod=simple binddn=cn=config credentials=password type=refreshAndPersist retry="60 10 300 +" schemachecking=off ------------- 8< -------------

and the consumer seed is:

------------- 8< ------------- dn: olcDatabase={0}config,cn=config ... olcSyncrepl: {0}rid=999 provider="ldap://master.tld/" searchbase=cn=config bindmethod=simple binddn=cn=config credentials=password type=refreshAndPersist retry="60 10 300 +" schemachecking=off ------------- 8< -------------

Should I start slapd with -c "rid=999" or -c "rid=0" ? From what I understand, I would ulse -c "rid=999", it would replicate cn=config and replace (if it was working) the "rid=999..." attribute value with the "rid=0..." one. Did I understand correctly?

Thank in advance for your clarifications have a good day. regards, jephté

I'm currently testing full replication with the small configuration seed on the consumer side, but the replication is not complete.

Let me explain in details:

so, the consumer starts with no data at all (I wipe /etc/ldap/slapd.d/* files, and /var/lib/ldap/*)

Based on the test049, I do 'slapadd -F /etc/ldap/slapd.d -b cn=config -l initial.ldif' with initial.ldif as:

------------- 8< ------------- dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcSyncrepl: {0}rid=0 provider="ldap://master.tld/" searchbase=cn=config bindmethod=simple binddn=cn=config credentials=password type=refreshAndPersist retry="60 10 300 +" schemachecking=off ------------- 8< -------------

on the provider side, cn=config is the rootdn of cn=config

so the database cn=config is replicated, except for the above objects. Indeed, the logs says:

dn_callback : new entry is older than ours cn=config ours 20120127114737.207735Z#000000#000#000000, new 20120127112957.179717Z#000000#000#000000 dn_callback : new entry is older than ours olcDatabase={0}config,cn=config ours 20120127114737.207985Z#000000#000#000000, new 20120127112953.813862Z#000000#000#000000

and this makes sense. I searched the archives, and found a message from Howard Chu made on 19 Apr 2011:

------------- 8< ------------- ... Use slapd -c. Read the slapd(8) manpage. ------------- 8< -------------

The manpage says:

------------- 8< ------------- -c cookie (...) Use only the rid part to force a full reload. ------------- 8< -------------

So I tried '/usr/sbin/slapd -c "rid=0" -d 16384 ...' but I got the message above about the entry not overwritten because of the timestamp. I wonder what I am doing wrong...

I'd prefer not to have to use a more recent version, because debian already does a good job following the patches and keeping the whole thing stable :-) But If this is a known issue, what are my options?

I mean, my goal is to replicate schemas, indexes, limits, acls and Authz definitions. I thought that a whole replica would the easiest.

On 01/02/2012 10:38, Jephte CLAIN wrote:

On 01/02/2012 08:47, Jephte CLAIN wrote:

...

On 27/01/2012 17:33, Jephte CLAIN wrote: This is not working as documented, isn't it? For now, I will seed the consumer with an export of the two objects cn=config and olcDatabase={0}config,cn=config from the master. even though they are not updated, it will not be problem because the consumer will already be up to date :-)

Hello,

I kinda have a chicken and egg problem here: with slapadd, I cannot define an acl with a DN that is not existing

I mean, I define acls on the frontend to enable syncrepl replication. I have to seed olcDatabase={-1}frontend to have the initial acls, because like the two other, it is not replicated, because the frontend on the consumer is newer than the one on the provider.

So, I have on the provider:

dn: olcDatabase={-1}frontend,cn=config ... olcAccess: {1}to * by dn.exact="cn=syncrepl,dc=univ-reunion,dc=fr" manage by * break

When I try to slapadd it on the empty consumer, I get:

4f28d8ef /etc/ldap/slapd.d: line 1: bad DN "cn=syncrepl,dc=univ-reunion,dc=fr" in by DN clause

It does not work because cn=syncrepl,dc=univ-reunion,dc=fr does not exist yet. And I cannot add it later, because as a replica, it cannot be modified

... what can I do? Perhaps I just can't setup the consumer properly? Am I the only one to hit this "bug"?

The workaround is simple: each time I setup a consumer, refresh the entries on the master to force the replication with the current content, but this is awkward

Ok, talking to myself on the list since this morning :-)

I ended up doing like this:

- seed the consumer with a super-mininal initial ldif like the following: ------------- 8< ------------- dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcSyncrepl: {0}rid=0 provider="ldap://provider.tld/" searchbase=cn=config bindmethod=simple binddn=cn=config credentials=password type=refreshAndPersist retry="60 10 300 +" schemachecking=off ------------- 8< ------------- - start the consumer - then "touch" the objects on the provider, to force their replication:

ldapmodify -H ldap://provider.tld -x -D cn=config -w password <<EOF dn: cn=config changetype: modify

dn: olcDatabase={-1}frontend,cn=config changetype: modify

dn: olcDatabase={0}config,cn=config changetype: modify EOF

so far, it's working as intended

Looking forward for the answers to my previous questions though. And: is it a bug, or a feature? is this the only (intended) to do it?

best regards,

Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06