Hi,
under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment.
I attached two logs excepts in sync.log. In the first except there is only a DEL Jan 31 09:16:01 ldapserver slapd[10641]: conn=79138 op=2 DEL dn="employeeNumber=19676,ou=humans,ou=foo" For this there is a Jan 31 09:16:01 ldapserver slapd[10641]: syncprov_sendresp: cookie=rid=401,csn=20120131081601.377028Z#000000#000#000000 line for every connected consumer.
In the second step there is a MOD and a DEL Jan 31 10:31:01 ldapserver slapd[10641]: conn=79938 op=2 MOD dn="ou=FA-WF,ou=gruppen,ou=humans,ou=foo" Jan 31 10:31:01 ldapserver slapd[10641]: conn=79938 op=3 DEL dn="employeeNumber=24387,ou=humans,ou=foo" As far as I can see, there is only sync activity for the MOD action, and not for the DEL action. The DEL is not synced.
Marc
Marc Patermann wrote:
Hi,
under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment.
Already known, ITS#7052.
Hi,
Howard Chu schrieb (31.01.2012 12:08 Uhr):
Marc Patermann wrote:
under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment.
Already known, ITS#7052.
Thanks. So this is fixed in 2.6.27 (and later). The master already is 2.4.28, the consumers are older. So I have to update the consumers, right?
Marc
Marc Patermann wrote:
Hi,
Howard Chu schrieb (31.01.2012 12:08 Uhr):
Marc Patermann wrote:
under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment.
Already known, ITS#7052.
Thanks. So this is fixed in 2.6.27 (and later). The master already is 2.4.28, the consumers are older. So I have to update the consumers, right?
Yes, the fix was consumer side. Also, the fix was incomplete, an additional fix will be in 2.4.29.
Howard,
Howard Chu schrieb (31.01.2012 14:22 Uhr):
Marc Patermann wrote:
Howard Chu schrieb (31.01.2012 12:08 Uhr):
Marc Patermann wrote:
under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment.
Already known, ITS#7052.
Thanks. So this is fixed in 2.6.27 (and later). The master already is 2.4.28, the consumers are older. So I have to update the consumers, right?
Yes, the fix was consumer side. Also, the fix was incomplete, an additional fix will be in 2.4.29.
Is there any information about this?
Marc
Howard,
Howard Chu schrieb (31.01.2012 14:22 Uhr):
Marc Patermann wrote:
Howard Chu schrieb (31.01.2012 12:08 Uhr):
Marc Patermann wrote:
under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment.
Already known, ITS#7052.
Thanks. So this is fixed in 2.6.27 (and later). The master already is 2.4.28, the consumers are older. So I have to update the consumers, right?
Yes, the fix was consumer side. Also, the fix was incomplete, an additional fix will be in 2.4.29.
Even with 2.4.28 on a consumer I see the same behavior. :( I found your 3 day old commit in master, but this does not seem to be related, is it?
Marc
--On Tuesday, January 31, 2012 9:58 PM +0200 Nick Milas nick@eurobjects.com wrote:
On 31/1/2012 6:35 μμ, Marc Patermann wrote:
an additional fix will be in 2.4.29
Is there an anticipated (even approximate) release date for 2.4.29?
We never announce release dates. However, if you were subscribed to the openldap-devel list, you would see that I have been making repeated calls for testing on the RE24 branch in preparation for a 2.4.29 release. Unfortunately, very few people have responded that they've tested it. If you'd like to test it, that would certainly help make its release be more towards the near future than the far future.
--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 31/1/2012 10:16 μμ, Quanah Gibson-Mount wrote:
If you'd like to test it, that would certainly help make its release be more towards the near future than the far future.
Thanks Quanah,
I would surely like to test it. However, I haven't got a clue on building the software and our systems are setup to use ltb-project RPMs for CentOS.
If such RPMs could be provided (or detailed guidance on how to build them from source), I would be happy to test and report any issues.
Best Regards, Nick
Nick Milas schrieb (01.02.2012 11:03 Uhr):
On 31/1/2012 10:16 μμ, Quanah Gibson-Mount wrote:
If you'd like to test it, that would certainly help make its release be more towards the near future than the far future.
I would surely like to test it. However, I haven't got a clue on building the software and our systems are setup to use ltb-project RPMs for CentOS.
If such RPMs could be provided (or detailed guidance on how to build them from source), I would be happy to test and report any issues.
Now that you know the sources, get the source rpm from ltb and install it. Change the spec file accordingly and build your own pre 2.4.29 rpm with this. now you can update your test system with the rpm.
Marc
On 1/2/2012 3:52 μμ, Marc Patermann wrote:
Now that you know the sources, get the source rpm from ltb and install it. Change the spec file accordingly and build your own pre 2.4.29 rpm with this. now you can update your test system with the rpm.
As a follow-up, I would like to inform you that I have successfully built RPMs using LTB-Project src.rpm and openldap-OPENLDAP_REL_ENG_2_4-ad04676 and, after successful tests, I am now running it in production for full-scale testing.
No problems up to now.
Regards, Nick
On 1/31/12 9:16 PM, Quanah Gibson-Mount wrote:
--On Tuesday, January 31, 2012 9:58 PM +0200 Nick Milas nick@eurobjects.com wrote:
On 31/1/2012 6:35 μμ, Marc Patermann wrote:
an additional fix will be in 2.4.29
Is there an anticipated (even approximate) release date for 2.4.29?
We never announce release dates. However, if you were subscribed to the openldap-devel list, you would see that I have been making repeated calls for testing on the RE24 branch in preparation for a 2.4.29 release. Unfortunately, very few people have responded that they've tested it. If you'd like to test it, that would certainly help make its release be more towards the near future than the far future.
Any direction on how to test the build and to check out the branch in order to run the tests ?
We have a couple of OS on which we can un them, but if I can spare the time to discover the correct configuration...
Thanks !
On 1/2/2012 12:19 μμ, Emmanuel Lecharny wrote:
Any direction on how to test the build and to check out the branch in order to run the tests ?
Can someone provide a current source code (2.4 Branch) build as a .tgz?
Or, can someone provide directions on how we can do it from OpenLDAP git repository? (This would be a more complex scenario.)
Thanks, Nick
Nick Milas wrote:
On 1/2/2012 12:19 μμ, Emmanuel Lecharny wrote:
Any direction on how to test the build and to check out the branch in order to run the tests ?
Can someone provide a current source code (2.4 Branch) build as a .tgz?
Or, can someone provide directions on how we can do it from OpenLDAP git repository? (This would be a more complex scenario.)
I'm not an git expert. But here's what I did following some git cookbooks:
$ mkdir /tmp/openldap-git $ cd /tmp/openldap-git $ git clone git://git.openldap.org/openldap.git $ cd openldap
You now have a clone of the whole repository including all branches with the default branch set to 'master'. You have to switch the active branch to RE24.
Clean up everything left over from a previous build *before* switching a branch:
$ make distclean
List all available branches:
$ git branch -a michael@nb2:/tmp/openldap-git-re24/openldap> git branch -a * master [..snipped..] remotes/origin/OPENLDAP_REL_ENG_2_4 [..snipped..]
# Switch branch giving it a local name 're24':
$ git checkout -b re24 remotes/origin/OPENLDAP_REL_ENG_2_4 Branch re24 set up to track remote branch OPENLDAP_REL_ENG_2_4 from origin. Switched to a new branch 're24'
Check which branch is active:
$ git branch master * re24
Especially you now see the file CHANGES which contains the release history within the 2.4.x release series.
Ciao, Michael.
Hi all, last time I answered Quanah's testing call I simply downloaded the tgz from gitweb and then compiled as usual.
This is the link I can find on gitweb: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/he...
Hope this helps Marco
2012/2/1 Michael Ströder michael@stroeder.com
Nick Milas wrote:
On 1/2/2012 12:19 μμ, Emmanuel Lecharny wrote:
Any direction on how to test the build and to check out the branch in
order to run the tests ?
Can someone provide a current source code (2.4 Branch) build as a .tgz?
Or, can someone provide directions on how we can do it from OpenLDAP git repository? (This would be a more complex scenario.)
I'm not an git expert. But here's what I did following some git cookbooks:
$ mkdir /tmp/openldap-git $ cd /tmp/openldap-git $ git clone git://git.openldap.org/**openldap.githttp://git.openldap.org/openldap.git $ cd openldap
You now have a clone of the whole repository including all branches with the default branch set to 'master'. You have to switch the active branch to RE24.
Clean up everything left over from a previous build *before* switching a branch:
$ make distclean
List all available branches:
$ git branch -a michael@nb2:/tmp/openldap-git-**re24/openldap> git branch -a
- master
[..snipped..] remotes/origin/OPENLDAP_REL_**ENG_2_4 [..snipped..]
# Switch branch giving it a local name 're24':
$ git checkout -b re24 remotes/origin/OPENLDAP_REL_**ENG_2_4 Branch re24 set up to track remote branch OPENLDAP_REL_ENG_2_4 from origin. Switched to a new branch 're24'
Check which branch is active:
$ git branch master
- re24
Especially you now see the file CHANGES which contains the release history within the 2.4.x release series.
Ciao, Michael.
On 1/2/2012 2:45 μμ, Marco Pizzoli wrote:
last time I answered Quanah's testing call I simply downloaded the tgz from gitweb and then compiled as usual.
This is the link I can find on gitweb: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/he...
Thanks,
It works!
Nick
--On Wednesday, February 01, 2012 1:40 PM +0100 Michael Ströder michael@stroeder.com wrote:
Nick Milas wrote:
On 1/2/2012 12:19 μμ, Emmanuel Lecharny wrote:
Any direction on how to test the build and to check out the branch in order to run the tests ?
Can someone provide a current source code (2.4 Branch) build as a .tgz?
Or, can someone provide directions on how we can do it from OpenLDAP git repository? (This would be a more complex scenario.)
I'm not an git expert. But here's what I did following some git cookbooks:
$ mkdir /tmp/openldap-git $ cd /tmp/openldap-git $ git clone git://git.openldap.org/openldap.git $ cd openldap
You now have a clone of the whole repository including all branches with the default branch set to 'master'. You have to switch the active branch to RE24.
I find this a little simpler:
git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4
openldap-2.4.26.tar
--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
Quanah Gibson-Mount wrote:
--On Wednesday, February 01, 2012 1:40 PM +0100 Michael Ströder michael@stroeder.com wrote:
Nick Milas wrote:
On 1/2/2012 12:19 μμ, Emmanuel Lecharny wrote:
Any direction on how to test the build and to check out the branch in order to run the tests ?
Can someone provide a current source code (2.4 Branch) build as a .tgz?
Or, can someone provide directions on how we can do it from OpenLDAP git repository? (This would be a more complex scenario.)
I'm not an git expert. But here's what I did following some git cookbooks:
$ mkdir /tmp/openldap-git $ cd /tmp/openldap-git $ git clone git://git.openldap.org/openldap.git $ cd openldap
You now have a clone of the whole repository including all branches with the default branch set to 'master'. You have to switch the active branch to RE24.
I find this a little simpler:
git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4
Yes, that's simpler.
Maybe the page http://www.openldap.org/software/repo.html should contain a description like this or the table in section "Useful Branches and Tags" on that page should contain links like the one posted by Marco? This could lead to more people actually testing pre-releases in the RE24 branch.
Ciao, Michael.
2012/2/1 Michael Ströder michael@stroeder.com
Quanah Gibson-Mount wrote:
--On Wednesday, February 01, 2012 1:40 PM +0100 Michael Ströder michael@stroeder.com wrote:
Nick Milas wrote:
On 1/2/2012 12:19 μμ, Emmanuel Lecharny wrote:
Any direction on how to test the build and to check out the branch in
order to run the tests ?
Can someone provide a current source code (2.4 Branch) build as a .tgz?
Or, can someone provide directions on how we can do it from OpenLDAP git repository? (This would be a more complex scenario.)
I'm not an git expert. But here's what I did following some git cookbooks:
$ mkdir /tmp/openldap-git $ cd /tmp/openldap-git $ git clone git://git.openldap.org/**openldap.githttp://git.openldap.org/openldap.git $ cd openldap
You now have a clone of the whole repository including all branches with the default branch set to 'master'. You have to switch the active branch to RE24.
I find this a little simpler:
git archive --format=tar --remote=git-master.openldap.**org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4
Yes, that's simpler.
Maybe the page http://www.openldap.org/**software/repo.htmlhttp://www.openldap.org/software/repo.htmlshould contain a description like this or the table in section "Useful Branches and Tags" on that page should contain links like the one posted by Marco? This could lead to more people actually testing pre-releases in the RE24 branch.
+1 Actually this has been my biggest obstacle to give a contribute to the project. As an example, consider also that in my corp cvs/git protocols are not available through the internet. Web is the only way...
Marco
On 2/1/12 7:16 PM, Quanah Gibson-Mount wrote:
--On Wednesday, February 01, 2012 1:40 PM +0100 Michael Ströder michael@stroeder.com wrote:
Nick Milas wrote:
On 1/2/2012 12:19 μμ, Emmanuel Lecharny wrote:
Any direction on how to test the build and to check out the branch in order to run the tests ?
Can someone provide a current source code (2.4 Branch) build as a .tgz?
Or, can someone provide directions on how we can do it from OpenLDAP git repository? (This would be a more complex scenario.)
I'm not an git expert. But here's what I did following some git cookbooks:
$ mkdir /tmp/openldap-git $ cd /tmp/openldap-git $ git clone git://git.openldap.org/openldap.git $ cd openldap
You now have a clone of the whole repository including all branches with the default branch set to 'master'. You have to switch the active branch to RE24.
I find this a little simpler:
git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4
openldap-2.4.26.tar
emmanuel-lecharnys-MacBook-Pro:openldap-git elecharny$ git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 openldap-2.4.26.tar Permission denied (publickey). fatal: The remote end hung up unexpectedly ...
Am I missing something ?
--On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny elecharny@gmail.com wrote:
emmanuel-lecharnys-MacBook-Pro:openldap-git elecharny$ git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 openldap-2.4.26.tar Permission denied (publickey). fatal: The remote end hung up unexpectedly ...
Am I missing something ?
You're not on the project team, so you don't have access to git-master. You'd need to use git.openldap.org, and I'm not sure how you do anonymous access with it. My reply about that was for Stroeder. If you can get it to work in this method, however, I'd love to see that documented on the website as well.
--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 Thu, 02 Feb 2012 11:19:30 -0800, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny elecharny@gmail.com wrote:
emmanuel-lecharnys-MacBook-Pro:openldap-git elecharny$ git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 openldap-2.4.26.tar
This does not build the release. OpenLDAP does use git archive to pick the files for a release, but then untars them, runs build/mkrelease, and tars the result up again.
mkrelease seems to use sha1 and md5 programs from FreeBSD, the Linux utilities I found have different output format.
As for git archive --remote=git://git.openldap.org/openldap.git, man git-daemon says this requires 'git config daemon.uploadarch true'. But since the result differs from a release, it may do more harm than help to enable it. Unless it is set up to create an README.INCOMPLETE-RELEASE file or something.
--On Thursday, February 02, 2012 9:41 PM +0100 Hallvard B Furuseth h.b.furuseth@usit.uio.no wrote:
On Thu, 02 Feb 2012 11:19:30 -0800, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny elecharny@gmail.com wrote:
emmanuel-lecharnys-MacBook-Pro:openldap-git elecharny$ git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 openldap-2.4.26.tar
This does not build the release. OpenLDAP does use git archive to pick the files for a release, but then untars them, runs build/mkrelease, and tars the result up again.
No one is talking about "building" the release tarball. What we are talking about is my TESTING calls for RE24 that I make on -devel, and how to best make that possible for people who are willing to volunteer their time and systems to do that. What they need for that is a tarball of the SOURCE as it occurs in RE24.
--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 2/2/12 8:19 PM, Quanah Gibson-Mount wrote:
--On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny elecharny@gmail.com wrote:
emmanuel-lecharnys-MacBook-Pro:openldap-git elecharny$ git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 openldap-2.4.26.tar Permission denied (publickey). fatal: The remote end hung up unexpectedly ...
Am I missing something ?
You're not on the project team, so you don't have access to git-master. You'd need to use git.openldap.org, and I'm not sure how you do anonymous access with it. My reply about that was for Stroeder. If you can get it to work in this method, however, I'd love to see that documented on the website as well.
Does not work either :
emmanuel-lecharnys-MacBook-Pro:openLdap elecharny$ git archive --format=tar --remote=git.openldap.org:~git/git/openldap.git The authenticity of host 'git.openldap.org (204.152.186.56)' can't be established. DSA key fingerprint is e2:4b:5a:5b:71:0c:71:4c:18:6a:18:99:e1:e7:b5:f2. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'git.openldap.org,204.152.186.56' (DSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly
--On Saturday, February 04, 2012 1:19 AM +0100 Emmanuel Lécharny elecharny@apache.org wrote:
On 2/2/12 8:19 PM, Quanah Gibson-Mount wrote:
--On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny elecharny@gmail.com wrote:
emmanuel-lecharnys-MacBook-Pro:openldap-git elecharny$ git archive --format=tar --remote=git-master.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 openldap-2.4.26.tar Permission denied (publickey). fatal: The remote end hung up unexpectedly ...
Am I missing something ?
You're not on the project team, so you don't have access to git-master. You'd need to use git.openldap.org, and I'm not sure how you do anonymous access with it. My reply about that was for Stroeder. If you can get it to work in this method, however, I'd love to see that documented on the website as well.
Does not work either :
emmanuel-lecharnys-MacBook-Pro:openLdap elecharny$ git archive --format=tar --remote=git.openldap.org:~git/git/openldap.git The authenticity of host 'git.openldap.org (204.152.186.56)' can't be established. DSA key fingerprint is e2:4b:5a:5b:71:0c:71:4c:18:6a:18:99:e1:e7:b5:f2. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'git.openldap.org,204.152.186.56' (DSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly
Hallvard already noted that a change needs to be done on the remote daemon side to allow this to occur. So it's not possible until Kurt tweaks the git configuration for anonymous git.
--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 31/1/2012 10:16 μμ, Quanah Gibson-Mount wrote:
if you were subscribed to the openldap-devel list, you would see that I have been making repeated calls for testing on the RE24 branch in preparation for a 2.4.29 release.
I wanted to add that, in order to get more visibility to these calls, you could also post them to this list, because I am sure that some people (judging from myself) who could/would test are not developers but sysadmins and would not be subscribed to the developer list.
Additionally, testing would surely be much more widespread if some RC builds were available at least for the most common distros (RPM, deb). If some of the project developers build RC package versions for their own testing, why not post their builds and make them available to people in this list?
OK, we can try and build, yet I believe that response to test calls would be much greater if some RC package builds were available.
I guess that could be made possible if some distro/project package maintainers could agree to provide packages (with standard options) for RC versions e.g. in specialized repos.
That would allow testers to focus on testing the final product and not spend considerable time in building (probably sometimes with inadequate results).
Finally, if there are some suggested testing scenarios that are proposed for testing (e.g. running particular scripts), that would help testers too. Otherwise, we would be testing haphazardly.
Just 2c - I'm only trying to help.
Nick
Nick Milas wrote:
On 31/1/2012 10:16 μμ, Quanah Gibson-Mount wrote:
if you were subscribed to the openldap-devel list, you would see that I have been making repeated calls for testing on the RE24 branch in preparation for a 2.4.29 release.
I wanted to add that, in order to get more visibility to these calls, you could also post them to this list, because I am sure that some people (judging from myself) who could/would test are not developers but sysadmins and would not be subscribed to the developer list.
Sounds fair.
Additionally, testing would surely be much more widespread if some RC builds were available at least for the most common distros (RPM, deb). If some of the project developers build RC package versions for their own testing, why not post their builds and make them available to people in this list?
Two answers: 1) The OpenLDAP Project does source releases. Period, end of story.
2) sometimes it is the build procedure that needs to be widely tested; e.g. if we update versions of autoconf/libtool/etc. (as we plan to do in the near future).
OK, we can try and build, yet I believe that response to test calls would be much greater if some RC package builds were available.
Calls for testing are only useful if competent people perform the tests. We don't want the general public downloading candidates. We want people who are experts on their build systems, who can do some degree of problem isolation/ triage on their own, and who know how to file useful bug reports.
I guess that could be made possible if some distro/project package maintainers could agree to provide packages (with standard options) for RC versions e.g. in specialized repos.
Something like Ubuntu ppa's, sure. That's for those other project maintainers to get into.
That would allow testers to focus on testing the final product and not spend considerable time in building (probably sometimes with inadequate results).
That misses the point.
Finally, if there are some suggested testing scenarios that are proposed for testing (e.g. running particular scripts), that would help testers too. Otherwise, we would be testing haphazardly.
Just 2c - I'm only trying to help.
That's appreciated, believe me.
Howard,
Howard Chu schrieb (31.01.2012 14:22 Uhr):
Marc Patermann wrote:
Howard Chu schrieb (31.01.2012 12:08 Uhr):
Marc Patermann wrote:
under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment.
Already known, ITS#7052.
Thanks. So this is fixed in 2.6.27 (and later). The master already is 2.4.28, the consumers are older. So I have to update the consumers, right?
Yes, the fix was consumer side. Also, the fix was incomplete, an additional fix will be in 2.4.29.
Around begin of February I built an RPM based on pre 2.4.29 code from git. With this installed on a consumer I sill get the same behavior, that DEL do not get replicated, if one of the server was restarted and the entry existed before the restart. This is very bad. It seems the objects between consumer and provider loose "contact". When the object changed (ADD or MOD) even DEL get replicated.
I don't know what to do, because this destroys the consistency in our ldap system. :( In about more than 5 years in having openldap in production I have never had such bad issues.
There are reverted commits in git (ITS#7162). Should a build again with current git status?
Marc
On Tuesday, 21 February 2012 11:25:22 Marc Patermann wrote:
Howard,
Howard Chu schrieb (31.01.2012 14:22 Uhr):
Marc Patermann wrote:
Howard Chu schrieb (31.01.2012 12:08 Uhr):
Marc Patermann wrote:
under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment.
Already known, ITS#7052.
Thanks. So this is fixed in 2.6.27 (and later). The master already is 2.4.28, the consumers are older. So I have to update the consumers, right?
Yes, the fix was consumer side. Also, the fix was incomplete, an additional fix will be in 2.4.29.
Around begin of February I built an RPM based on pre 2.4.29 code from git. With this installed on a consumer I sill get the same behavior, that DEL do not get replicated, if one of the server was restarted and the entry existed before the restart. This is very bad. It seems the objects between consumer and provider loose "contact". When the object changed (ADD or MOD) even DEL get replicated.
I don't know what to do, because this destroys the consistency in our ldap system. :( In about more than 5 years in having openldap in production I have never had such bad issues.
There are reverted commits in git (ITS#7162). Should a build again with current git status?
As far as I have read in changelogs and ITS, anything from OPENLDAP_REL_ENG_2_4 (including 2.4.29) before:
commit 10c81e2a46c9b603ba1dfcf53422573d5068ba04 Author: Howard Chu hyc@openldap.org Date: Sun Feb 12 21:07:25 2012 -0800
ITS#7162 Revert "ITS#7052 ignore Adds with too old entryCSN"
This reverts commit ba4366eae098c0e4950a78b1da8d79ffe8b34fee. The patch caused a regression (ITS#7162).
will probably still be broken.
Regards, Buchan
Buchan,
Buchan Milne schrieb (21.02.2012 11:38 Uhr):
As far as I have read in changelogs and ITS, anything from OPENLDAP_REL_ENG_2_4 (including 2.4.29) before:
commit 10c81e2a46c9b603ba1dfcf53422573d5068ba04 Author: Howard Chu hyc@openldap.org Date: Sun Feb 12 21:07:25 2012 -0800
ITS#7162 Revert "ITS#7052 ignore Adds with too old entryCSN" This reverts commit ba4366eae098c0e4950a78b1da8d79ffe8b34fee. The patch caused a regression (ITS#7162).will probably still be broken.
Thank you. But what does this mean to me exactly? What is the best to try now?
Marc
On Tuesday, 21 February 2012 12:41:40 Marc Patermann wrote:
Buchan,
Buchan Milne schrieb (21.02.2012 11:38 Uhr):
As far as I have read in changelogs and ITS, anything from OPENLDAP_REL_ENG_2_4 (including 2.4.29) before:
commit 10c81e2a46c9b603ba1dfcf53422573d5068ba04 Author: Howard Chu hyc@openldap.org Date: Sun Feb 12 21:07:25 2012 -0800
ITS#7162 Revert "ITS#7052 ignore Adds with too old entryCSN" This reverts commit ba4366eae098c0e4950a78b1da8d79ffe8b34fee. The patch caused a regression (ITS#7162).will probably still be broken.
Thank you. But what does this mean to me exactly? What is the best to try now?
Current OPENLDAP_REL_ENG_2_4 from git, or 2.4.29 with the 2 or 3 commits in OPENLDAP_REL_ENG_2_4, or a package that has them (I have RPMs internally, but my public repo is down for a bit).
Regards, Buchan
Buchan,
Buchan Milne schrieb (21.02.2012 12:48 Uhr):
On Tuesday, 21 February 2012 12:41:40 Marc Patermann wrote:
Buchan Milne schrieb (21.02.2012 11:38 Uhr):
As far as I have read in changelogs and ITS, anything from OPENLDAP_REL_ENG_2_4 (including 2.4.29) before:
commit 10c81e2a46c9b603ba1dfcf53422573d5068ba04 Author: Howard Chu hyc@openldap.org Date: Sun Feb 12 21:07:25 2012 -0800
ITS#7162 Revert "ITS#7052 ignore Adds with too old entryCSN" This reverts commit ba4366eae098c0e4950a78b1da8d79ffe8b34fee. The patch caused a regression (ITS#7162).will probably still be broken.
Thank you. But what does this mean to me exactly? What is the best to try now?
Current OPENLDAP_REL_ENG_2_4 from git, or 2.4.29 with the 2 or 3 commits in OPENLDAP_REL_ENG_2_4, or a package that has them (I have RPMs internally, but my public repo is down for a bit).
Thanks again. With building plain 2.4.29 I got the same test-054 error like Michael postet in #7162. I'm building with OPENLDAP_REL_ENG_2_4 (for the next 2 h) now.
Marc
Marc Patermann schrieb (21.02.2012 14:44 Uhr):
Buchan Milne schrieb (21.02.2012 12:48 Uhr):
On Tuesday, 21 February 2012 12:41:40 Marc Patermann wrote:
Buchan Milne schrieb (21.02.2012 11:38 Uhr):
As far as I have read in changelogs and ITS, anything from OPENLDAP_REL_ENG_2_4 (including 2.4.29) before:
commit 10c81e2a46c9b603ba1dfcf53422573d5068ba04 Author: Howard Chu hyc@openldap.org Date: Sun Feb 12 21:07:25 2012 -0800
ITS#7162 Revert "ITS#7052 ignore Adds with too old entryCSN" This reverts commit ba4366eae098c0e4950a78b1da8d79ffe8b34fee. The patch caused a regression (ITS#7162).will probably still be broken.
Thank you. But what does this mean to me exactly? What is the best to try now?
Current OPENLDAP_REL_ENG_2_4 from git, or 2.4.29 with the 2 or 3 commits in OPENLDAP_REL_ENG_2_4, or a package that has them (I have RPMs internally, but my public repo is down for a bit).
Thanks again. With building plain 2.4.29 I got the same test-054 error like Michael postet in #7162. I'm building with OPENLDAP_REL_ENG_2_4 (for the next 2 h) now.
As it turns out, I'm still having the issue with pre 2.4.30 code from the Feb 21st. After the refill of the consumer with older data, there was an initial present check and the servers are in sync. Todays changes are replicated without the DEL. :(
I do not see any changes since then which should have effects in the official 2.4.30 release, are there any?
this is the provider:
database hdb suffix "ou=humans,ou=foo" subordinate rootdn "cn=gen.man,ou=mgr,ou=foo" directory /var/lib/ldap/human-data checkpoint 4096 5 index default eq index objectClass index uid index mail sub,eq index sn sub,eq index cn sub,eq index givenName sub,eq index maildrop,ou sub,eq index entryCSN,entryUUID eq cachesize 5000 idlcachesize 15000 dbconfig set_cachesize 0 262144000 0 dbconfig set_lg_dir /var/log/bdb/human dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE overlay syncprov syncprov-checkpoint 100 10 database hdb suffix "ou=system,ou=foo" subordinate rootdn "cn=gen.man,ou=mgr,ou=foo" directory /var/lib/ldap/sys-data checkpoint 4096 5 cachesize 5000 idlcachesize 15000 index objectClass eq index cn eq,sub index version eq index relativeDomainName eq,sub index default eq index dhcpHWAddress index dhcpClassData index dhcpOption index entryCSN index entryUUID index zoneName dbconfig set_cachesize 1 0 0 dbconfig set_lg_dir /var/log/bdb/sys dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE overlay syncprov syncprov-checkpoint 100 10 database bdb suffix "ou=linux,ou=foo" subordinate rootdn "cn=linux,ou=mgr,ou=foo" directory /var/lib/ldap/linux-data checkpoint 4096 5 cachesize 5000 idlcachesize 15000 dbconfig set_cachesize 0 268435456 0 dbconfig set_lg_dir /var/log/bdb/linux dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE index entryCSN eq index entryUUID eq index objectclass,uid,mail eq index sn,cn,givenName sub,eq index uidNumber,gidNumber eq include /etc/openldap/linux.acl overlay syncprov syncprov-checkpoint 100 10 database hdb suffix "ou=foo" rootdn "cn=gen.man,ou=mgr,ou=foo" directory /var/lib/ldap/main-data checkpoint 4096 5 cachesize 5000 idlcachesize 15000 dbconfig set_cachesize 0 8157440 0 dbconfig set_lg_dir /var/log/bdb/main dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE index objectClass eq index cn eq,sub index version eq index entryCSN,entryUUID eq overlay glue overlay accesslog logdb "cn=log" logops writes logpurge 10:00 01:00 overlay dynlist dynlist-attrset groupOfURLs memberURL overlay refint refint_attributes member memberOf refint_nothing "cn=dummy,ou=foo" overlay syncprov syncprov-checkpoint 100 10 database hdb suffix "cn=log" directory /var/lib/ldap/log-data rootdn "cn=gen.man,ou=mgr,ou=foo" checkpoint 10240 5 dbconfig set_cachesize 0 367001600 0 dbconfig set_lg_dir /var/log/bdb/log dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE index objectClass eq index cn eq,sub index reqStart eq overlay syncprov syncprov-nopresent TRUE syncprov-checkpoint 100 10 database monitor access to dn.subtree="cn=monitor" by * read
this is the consumer
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/authldap.schema include /etc/openldap/schema/ofdaddon.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/dhcp.schema include /etc/openldap/schema/ofdconf.schema include /etc/openldap/schema/nagios.schema include /etc/openldap/mail.acl pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/openldap/modules moduleload back_meta.la moduleload accesslog.la defaultsearchbase "ou=humans,ou=foo" timelimit -1 sizelimit -1 loglevel config stats stats2 sync TLSCACertificateFile /etc/openldap/ssl/ca2006.pem TLSCertificateFile /etc/openldap/ssl/cert2006.pem TLSCertificateKeyFile /etc/openldap/ssl/key2006.pem threads 400 authz-policy to authz-regexp uid=human,cn=[^,]*,cn=auth dn:"cn=human,ou=mgr,ou=foo" authz-regexp uid=cyrus,cn=[^,]*,cn=auth "ldap:///ou=humans,ou=foo??sub?(uid=cyrus)" authz-regexp uid=([^,@]*),cn=[^,]*,cn=auth "ldap:///ou=humans,ou=foo??sub?(maildrop=$1@*)" authz-regexp uid=([^,]*),cn=[^,]*,cn=auth "ldap:///ou=humans,ou=foo??sub?(maildrop=$1*)" authz-regexp "cn=human,ou=mgr,ou=foo" dn.subtree="ou=humans,ou=foo" database meta suffix "ou=bar,ou=foo" subordinate uri "ldap://meta.server/ou=bar,ou=foo" conn-ttl 30 idle-timeout 1m30s database meta suffix "ou=AllgV,ou=foo" subordinate uri "ldap://meta.server/ou=AllgV,ou=foo" conn-ttl 30 idle-timeout 1m30s database bdb suffix "ou=humans,ou=foo" subordinate directory /var/lib/ldap/human-data rootdn "cn=gen.man,ou=mgr,ou=foo" index objectclass,reqStart eq index uid,mail sub,eq index sn,cn,givenName sub,eq index maildrop,ou sub,eq index entryUUID,entryCSN eq index member eq checkpoint 4096 5 cachesize 5000 idlcachesize 5000 dbconfig set_cachesize 0 68157440 0 dbconfig set_lg_dir /var/log/bdb/human dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE syncrepl rid=401 provider=ldap://master.server type=refreshAndPersist retry="60 10 300 10 3600 10" searchbase="ou=humans,ou=foo" bindmethod=simple binddn="cn=human,ou=mgr,ou=foo" credentials=*** updateref ldap://master.server overlay syncprov syncprov-checkpoint 100 10 database bdb suffix "ou=linux,ou=foo" subordinate rootdn "cn=gen.man,ou=mgr,ou=foo" directory /var/lib/ldap/linux-data checkpoint 4096 5 cachesize 5000 idlcachesize 5000 idletimeout 20 dbconfig set_cachesize 0 268435456 0 dbconfig set_lg_dir /var/log/bdb/linux dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE index entryCSN eq index entryUUID eq index objectclass,uid,mail eq index sn,cn,givenName sub,eq index uidNumber eq index gidNumber eq index memberUid eq include /etc/openldap/linux.acl syncrepl rid=402 provider=ldap://master.server type=refreshAndPersist retry="60 10 300 10 3600 +" searchbase="ou=linux,ou=foo" bindmethod=simple binddn="cn=linux,ou=mgr,ou=foo" credentials=*** updateref ldap://master.server overlay syncprov syncprov-checkpoint 100 10 database bdb suffix "ou=system,ou=foo" directory /var/lib/ldap/sys-data rootdn "cn=gen.man,ou=mgr,ou=foo" index objectclass eq index cn sub,eq index version eq index relativeDomainName eq,sub index dhcpHWAddress,dhcpClassData,dhcpOption eq index entryCSN,entryUUID,zoneName eq checkpoint 4096 5 cachesize 5000 idlcachesize 5000 dbconfig set_cachesize 0 268435456 0 dbconfig set_lg_dir /var/log/bdb/sys dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE syncrepl rid=403 provider=ldap://master.server type=refreshAndPersist retry="60 10 300 10 3600 +" searchbase="ou=system,ou=foo" bindmethod=simple binddn="cn=sys,ou=mgr,ou=foo" credentials=*** updateref ldap://master.server subordinate overlay syncprov syncprov-checkpoint 100 10 database bdb suffix "ou=foo" rootdn "cn=gen.man,ou=mgr,ou=foo" directory /var/lib/ldap/main-data index objectclass,uid,mail eq index sn,cn,givenName sub,eq index maildrop,ou sub,eq index entryUUID,entryCSN eq checkpoint 4096 5 cachesize 5000 idlcachesize 5000 dbconfig set_cachesize 0 8157440 0 dbconfig set_lg_dir /var/log/bdb/main dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE overlay glue overlay accesslog logdb "cn=log" logops writes logpurge 180+00:00 1+00:00 database monitor access to dn.subtree="cn=monitor" by * read database config rootdn "cn=gen.man,ou=mgr,ou=foo" database bdb suffix "cn=log" directory /var/lib/ldap/log-data rootdn "cn=gen.man,ou=mgr,ou=foo" index objectclass,reqStart eq checkpoint 4096 5 cachesize 5000 idlcachesize 5000 dbconfig set_cachesize 0 8157440 0 dbconfig set_lg_dir /var/log/bdb/log dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE
Marc
On 21/2/2012 1:48 μμ, Buchan Milne wrote:
Current OPENLDAP_REL_ENG_2_4 from git or 2.4.29 with the 2 or 3 commits in OPENLDAP_REL_ENG_2_4
Since these updates are important to syncrepl behavior, could it be worth considering a v2.4.30 at this point?
Unless, of course, there are other imminent *important* changes which justify a 2.4.30 after these are completed, i.e. a bit (but not much!) later.
Just thinking loudly. :-)
Regards, Nick
--On Tuesday, February 21, 2012 3:55 PM +0200 Nick Milas nick@eurobjects.com wrote:
On 21/2/2012 1:48 μμ, Buchan Milne wrote:
Current OPENLDAP_REL_ENG_2_4 from git or 2.4.29 with the 2 or 3 commits in OPENLDAP_REL_ENG_2_4
Since these updates are important to syncrepl behavior, could it be worth considering a v2.4.30 at this point?
Unless, of course, there are other imminent *important* changes which justify a 2.4.30 after these are completed, i.e. a bit (but not much!) later.
There will be a 2.4.30 release when it is time for one. There are several issues currently being resolved. I will call for testing as soon as those issues are worked out.
--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
Marc Patermann wrote:
There are reverted commits in git (ITS#7162). Should a build again with current git status?
Yes, build with current git.
Michael Ströder wrote:
Howard Chu wrote:
Marc Patermann wrote:
There are reverted commits in git (ITS#7162). Should a build again with current git status?
Yes, build with current git.
Should we take this as a call to have a test round?
Eh. I would look at the RE24 CHANGES file and see if any of it is likely to affect you. If so, then feel free to try it. If not, then no rush. I'm still chasing down ITS#7170 in the meantime; expect 2.4.30 to go when 7170 is resolved.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Marc Patermann wrote:
There are reverted commits in git (ITS#7162). Should a build again with current git status?
Yes, build with current git.
Should we take this as a call to have a test round?
Eh. I would look at the RE24 CHANGES file and see if any of it is likely to affect you. If so, then feel free to try it.
Personally I'm testing master and RE24 whenever something appears in git. But at least ITS#7162 IMO affects anyone with a syncrepl setup in production.
If not, then no rush. I'm still chasing down ITS#7170 in the meantime; expect 2.4.30 to go when 7170 is resolved.
Given that back-mdb is rather experimental working on ITS#7170 shouldn't hold up 2.4.30 too long. I guess that not many people currently use back-mdb in production. (But I'm running my local address book setup with back-mdb.)
Ciao, Michael.
On 2/22/12 5:15 AM, Howard Chu wrote:
Eh. I would look at the RE24 CHANGES file and see if any of it is likely to affect you. If so, then feel free to try it. If not, then no rush. I'm still chasing down ITS#7170 in the meantime; expect 2.4.30 to go when 7170 is resolved.
As a non-developer, one thing I have not figured out how to do is to pull the RE24 branch from the git, I seem to only be allowed to pull the HEAD branch. Is there some option I haven't figured out on git that I need to set?
Hi
On Wed, Feb 22, 2012 at 3:43 PM, Francis Swasey Frank.Swasey@uvm.eduwrote:
On 2/22/12 5:15 AM, Howard Chu wrote:
Eh. I would look at the RE24 CHANGES file and see if any of it is likely
to affect you. If
so, then feel free to try it. If not, then no rush. I'm still chasing
down ITS#7170 in the
meantime; expect 2.4.30 to go when 7170 is resolved.
As a non-developer, one thing I have not figured out how to do is to pull the RE24 branch from the git, I seem to only be allowed to pull the HEAD branch. Is there some option I haven't figured out on git that I need to set?
I can help you by posting this link to download directly the tar.gz of the updated RE24 branch. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/he...
HTH
Marco
Hi,
from a provider with pre 2.4.30 (from Feb. 21st) and four consumers with exact the same config (checked by md5sum), two with 2.4.26, one with pre 2.4.29 and one with the same pre 2.4.30 version, I get this:
MOD an object (provider log)
# grep 20120301093101.562252Z /var/log/ldap Mar 1 10:31:01 rzhs720 slapd[17243]: slap_queue_csn: queing 0x7f9091fbce80 20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: slap_graduate_commit_csn: removing 0x7f90e0956a30 20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: slap_queue_csn: queing 0x7f9189972bd8 20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: slap_graduate_commit_csn: removing 0x7f90e1088e60 20120301093101.562252Z#000000#000#000000
This is on every consumer. There are 5 syncprov_sendresp entries (there is one more consumer).
In the same second there is a DEL
# grep 20120301093101.571993 /var/log/ldap Mar 1 10:31:01 rzhs720 slapd[17243]: slap_queue_csn: queing 0x7f90c07f5300 20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: slap_queue_csn: queing 0x7f90e8120f20 20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: slap_graduate_commit_csn: removing 0x7f90e0456370 20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs720 slapd[17243]: slap_graduate_commit_csn: removing 0x7f90e1088e60 20120301093101.571993Z#000000#000#000000
There are only two syncprov_sendresp entries.
All providers show log entries for the MOD
# grep 20120301093101.562252Z /var/log/ldap Mar 1 10:31:01 rzhs725 slapd[27945]: do_syncrep2: rid=401 cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs725 slapd[27945]: slap_queue_csn: queing 0x7f6ea9846820 20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs725 slapd[27945]: slap_graduate_commit_csn: removing 0x7f6ea985a7b0 20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs725 slapd[27945]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs725 slapd[27945]: slap_queue_csn: queing 0x7f6ea9846820 20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs725 slapd[27945]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs725 slapd[27945]: slap_graduate_commit_csn: removing 0x7f6ea9852280 20120301093101.562252Z#000000#000#000000 Mar 1 10:31:01 rzhs725 slapd[27945]: syncprov_sendresp: cookie=rid=401,csn=20120301093101.562252Z#000000#000#000000
But only tow of the four have the DEL replicated and this log entries:
# grep 20120301093101.571993 /var/log/ldap Mar 1 10:31:01 rzhs723 slapd[5460]: do_syncrep2: rid=401 cookie=rid=401,csn=20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs723 slapd[5460]: slap_queue_csn: queing 0x7f83b791bd20 20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs723 slapd[5460]: slap_graduate_commit_csn: removing 0x7f83b4720590 20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs723 slapd[5460]: slap_queue_csn: queing 0x7f83b791bd20 20120301093101.571993Z#000000#000#000000 Mar 1 10:31:01 rzhs723 slapd[5460]: slap_graduate_commit_csn: removing 0x7f83b4137010 20120301093101.571993Z#000000#000#000000
This is one of the 2.4.26 and the 2.4.29 server. Because even two server with the exact same config and the same release version are effected, I think this is a provider issue here.
Marc
On 1/3/2012 6:32 μμ, Marc Patermann wrote:
from a provider with pre 2.4.30 (from Feb. 21st) and four consumers with exact the same config (checked by md5sum), two with 2.4.26, one with pre 2.4.29 and one with the same pre 2.4.30 version, I get this:
...
Because even two server with the exact same config and the same release version are effected, I think this is a provider issue here.
Was just thinking: If you manage to install to all your machines (provider and all consumers) v2.4.31, do you still have this problem?
Regards, Nick
Nick,
Nick Milas schrieb (28.04.2012 21:06 Uhr):
On 1/3/2012 6:32 μμ, Marc Patermann wrote:
from a provider with pre 2.4.30 (from Feb. 21st) and four consumers with exact the same config (checked by md5sum), two with 2.4.26, one with pre 2.4.29 and one with the same pre 2.4.30 version, I get this:
...
Because even two server with the exact same config and the same release version are effected, I think this is a provider issue here.
Was just thinking: If you manage to install to all your machines (provider and all consumers) v2.4.31, do you still have this problem?
Thanks for the heads up!
All this brought a lot of trouble and instability to our system. So my colleagues hated me a bit about this. The system is somewhat stable with older version now. I'm going to think about the update.
Marc
openldap-technical@openldap.org
-
Buchan Milne -
Emmanuel Lecharny -
Emmanuel Lécharny -
Francis Swasey -
Hallvard B Furuseth -
Howard Chu -
Marc Patermann -
Marco Pizzoli -
Michael Ströder -
Nick Milas -
Quanah Gibson-Mount