2:51 a.m.
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
3:08 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:57 a.m.
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
5:22 a.m.
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 Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:40 a.m.
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
8:35 a.m.
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
12:16 p.m.
--On Tuesday, January 31, 2012 9:58 PM +0200 Nick Milas
<nick(a)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
2:03 a.m.
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
5:52 a.m.
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
12:28 p.m.
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
2:19 a.m.
On 1/31/12 9:16 PM, Quanah Gibson-Mount wrote:
--On Tuesday, January 31, 2012 9:58 PM +0200 Nick Milas
<nick(a)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 !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
4:12 a.m.
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
4:40 a.m.
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.
4:45 a.m.
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...
Hope this helps
Marco
2012/2/1 Michael Ströder <michael(a)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.git<http://git.openldap.org/openldap...
$ 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.
--
_________________________________________
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison
5:20 a.m.
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...
Thanks,
It works!
Nick
10:16 a.m.
--On Wednesday, February 01, 2012 1:40 PM +0100 Michael Ströder
<michael(a)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
10:35 a.m.
Quanah Gibson-Mount wrote:
--On Wednesday, February 01, 2012 1:40 PM +0100 Michael Ströder
<michael(a)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.
11 a.m.
2012/2/1 Michael Ströder <michael(a)stroeder.com>
Quanah Gibson-Mount wrote:
> --On Wednesday, February 01, 2012 1:40 PM +0100 Michael Ströder
> <michael(a)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<http://git.openldap.org/openldap...
>> $ 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<http://www.openldap.org/s...
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
--
_________________________________________
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison
1:46 a.m.
On 2/1/12 7:16 PM, Quanah Gibson-Mount wrote:
--On Wednesday, February 01, 2012 1:40 PM +0100 Michael Ströder
<michael(a)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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
11:19 a.m.
--On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny
<elecharny(a)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
12:41 p.m.
On Thu, 02 Feb 2012 11:19:30 -0800, Quanah Gibson-Mount
<quanah(a)zimbra.com> wrote:
--On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny
<elecharny(a)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.
--
Hallvard
12:47 p.m.
--On Thursday, February 02, 2012 9:41 PM +0100 Hallvard B Furuseth
<h.b.furuseth(a)usit.uio.no> wrote:
On Thu, 02 Feb 2012 11:19:30 -0800, Quanah Gibson-Mount
<quanah(a)zimbra.com> wrote:
> --On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny
> <elecharny(a)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
4:19 p.m.
On 2/2/12 8:19 PM, Quanah Gibson-Mount wrote:
--On Thursday, February 02, 2012 10:46 AM +0100 Emmanuel Lecharny
<elecharny(a)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
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
4:57 p.m.
--On Saturday, February 04, 2012 1:19 AM +0100 Emmanuel Lécharny
<elecharny(a)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(a)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
12:31 p.m.
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
12:59 p.m.
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 Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:25 a.m.
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
2:38 a.m.
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(a)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
2:41 a.m.
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(a)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
3:48 a.m.
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(a)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
5:44 a.m.
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(a)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
1:04 a.m.
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(a)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
5:55 a.m.
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
9:44 a.m.
--On Tuesday, February 21, 2012 3:55 PM +0200 Nick Milas
<nick(a)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
11:21 a.m.
Marc Patermann wrote:
There are reverted commits in git (ITS#7162). Should a build again
with
current git status?
Yes, build with current git.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:15 a.m.
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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:07 a.m.
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.
6:43 a.m.
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?
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
6:55 a.m.
Hi
On Wed, Feb 22, 2012 at 3:43 PM, Francis Swasey <Frank.Swasey(a)uvm.edu>wrote:
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...
HTH
Marco
8:32 a.m.
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
12:06 p.m.
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
2:17 a.m.
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
4160
days inactive
4252
days old
openldap-technical@openldap.org
44 comments
11 participants
participants (11)
-
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