ITS#7052, syncrepl, deletes, and MMR
by Howard Chu
I'm still seeing cases where deleted entries are getting resurrected when a
number of concurrent Add/Delete sequences are occurring, with multiple MMR
servers (4 minimum to show the error).
The problem begins because multiple writes are outstanding, and they are
replicated in persist mode without a CSN in their syncrepl cookie. This is a
normal occurrence when the current op does not correspond to the last
committed CSN.
Because there is no CSN, the consumer doesn't update its cookie state while
performing a particular op.
As a result, if a client does Add/Delete/Add/Delete of the same DN, it's
possible for the Adds to propagate several times (more than the client
actually executed).
Adds and Modifies can usually be rejected if they're too old, because they
carry an entryCSN attribute which can be compared against the existing entry,
even if the consumer cookie state has not been updated. But Deletes don't
carry any attributes, and Deleted entries can't be checked.
So, given a MMR setup like so:
1 -- 2
| |
3 -- 4
A sequence of Add/Del/Add/Del performed at server 1 will be replicated to both
2 and 3 immediately. They will then cascade it to server 4. If many other
writes were occurring at the same time, causing these writes to be propagated
without a cookie CSN, then server 4 will propagate them back to 3 and 2
respectively, and 3 and 2 will re-add the deleted entries because they have
nothing to check that says the Adds are old. This cycle only gets broken if
server 1 eventually sends an op with accompanying cookie update, so that all
the downstream servers can see that the ops are old.
...
OK, upon further digging, this appears to be caused by ITS#6024. rein's patch
prevents the consumer and provider from informing each other of their SIDs
when no CSN is present; this prevents syncprov's propagation loop detection
from working. Sigh. Reverting ITS#6024 patch...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 6 months
RE24 testing call#1 (2.4.30)
by Quanah Gibson-Mount
If you know how to build OpenLDAP manually, and would like to participate
in testing the next set of code for the 2.4.30 release, please do so.
Generally, get the code for RE24:
<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs...>
Configure & build.
Execute the test suite (via make test) after it is built.
Thanks,
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 years, 7 months
Re: RE24 testing call#1 (2.4.30)
by Toby Blake
> If you know how to build OpenLDAP manually, and would like to participate
> in testing the next set of code for the 2.4.30 release, please do so.
>
> Generally, get the code for RE24:
>
> <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs...>
>
> Configure & build.
>
> Execute the test suite (via make test) after it is built.
All tests pass on Scientific Linux 6.1 x86_64; bdb 4.8.30
Cheers
Toby Blake
School of Informatics
University of Edinburgh
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
11 years, 7 months
Re: RE24 testing call#1 (2.4.30)
by Nikolaos Milas
On Feb 24, 2012, at 19:20 , Quanah Gibson-Mount wrote:
>> If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.30 release, please do so.
>>
I've upgraded on a provider and a consumer (I used
openldap-OPENLDAP_REL_ENG_2_4-eb3ea42.tar.gz with LTB src.rpm's on
Centos 5.7 64bit).
The only problem I mentioned was that after having stopped/upgraded the
provider and restarted, changes on the directory were not replicated to
the consumers (neither to the upgraded one, nor to another one running
2.4.22).
I had to restart the consumers for things to start running smoothly
again. In the past, in such cases consumers continued to replicate
without problems. (But I can remember some cases in the past when this
happened again.) I don't know if there are KNOWN circumstances under
which the consumers stop picking up provider changes after a restart (of
the provider). If so, I would like to know more on the issue, if someone
can provide details.
At the time when modifications were not being synced, on the provider logs:
Feb 25 19:31:30 ldap slapd[2249]: [INFO] Using /etc/default/slapd for
configuration
Feb 25 19:31:30 ldap slapd[2251]: [INFO] Launching OpenLDAP
configuration test...
Feb 25 19:31:31 ldap slapd[2282]: [OK] OpenLDAP configuration test
successful
Feb 25 19:31:31 ldap slapd[2292]: [INFO] No db_recover done
Feb 25 19:31:31 ldap slapd[2293]: [INFO] Launching OpenLDAP...
Feb 25 19:31:31 ldap slapd[2294]: [OK] File descriptor limit set to 1024
Feb 25 19:31:31 ldap slapd[2295]: @(#) $OpenLDAP: slapd 2.4.X (Feb 25
2012 18:38:31) $
swbuilder@vdev.noa.gr:/home/swbuilder/rpmbuild/BUILD/openldap-2.4.30b3/servers/slapd
Feb 25 19:31:32 ldap slapd[2296]: slapd starting
Feb 25 19:31:33 ldap slapd[2300]: [OK] OpenLDAP started
Feb 25 19:47:30 ldap slapd[2296]: slap_queue_csn: queing 0x422d1400
20120225174730.829877Z#000000#000#000000
Feb 25 19:47:30 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f41050 20120225174730.829877Z#000000#000#000000
Feb 25 19:49:05 ldap slapd[2296]: slap_queue_csn: queing 0x422d1400
20120225174905.178671Z#000000#000#000000
Feb 25 19:49:05 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f52ea0 20120225174905.178671Z#000000#000#000000
Feb 25 19:49:18 ldap slapd[2296]: slap_queue_csn: queing 0x42ad2400
20120225174918.725184Z#000000#000#000000
Feb 25 19:49:18 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f516c0 20120225174918.725184Z#000000#000#000000
Feb 25 19:49:27 ldap slapd[2296]: slap_queue_csn: queing 0x422d1400
20120225174927.883674Z#000000#000#000000
Feb 25 19:49:27 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f4ed80 20120225174927.883674Z#000000#000#000000
Feb 25 19:51:36 ldap slapd[2296]: slap_queue_csn: queing 0x42ad2400
20120225175136.055019Z#000000#000#000000
Feb 25 19:51:36 ldap slapd[2296]: entry failed schema check: naming
attribute 'dc' is not present in entry
Feb 25 19:51:36 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19ed68e0 20120225175136.055019Z#000000#000#000000
Feb 25 19:51:57 ldap slapd[2296]: slap_queue_csn: queing 0x42ad2400
20120225175157.332360Z#000000#000#000000
Feb 25 19:51:57 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f52a60 20120225175157.332360Z#000000#000#000000
Feb 25 19:52:06 ldap slapd[2296]: slap_queue_csn: queing 0x432d3400
20120225175206.888091Z#000000#000#000000
Feb 25 19:52:06 ldap slapd[2296]: entry failed schema check: naming
attribute 'dc' is not present in entry
Feb 25 19:52:06 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f5b4f0 20120225175206.888091Z#000000#000#000000
Feb 25 19:52:41 ldap slapd[2296]: slap_queue_csn: queing 0x432d3400
20120225175241.756488Z#000000#000#000000
Feb 25 19:52:41 ldap slapd[2296]: entry failed schema check: naming
attribute 'dc' is not present in entry
Feb 25 19:52:41 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f516c0 20120225175241.756488Z#000000#000#000000
Feb 25 19:53:34 ldap slapd[2296]: slap_queue_csn: queing 0x422d2430
20120225175334.154298Z#000000#000#000000
Feb 25 19:53:34 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f5b4f0 20120225175334.154298Z#000000#000#000000
Feb 25 19:53:39 ldap slapd[2296]: slap_queue_csn: queing 0x422d2430
20120225175339.947561Z#000000#000#000000
Feb 25 19:53:39 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f516c0 20120225175339.947561Z#000000#000#000000
Feb 25 19:53:48 ldap slapd[2296]: slap_queue_csn: queing 0x42ad2400
20120225175348.026487Z#000000#000#000000
Feb 25 19:53:48 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19db6b30 20120225175348.026487Z#000000#000#000000
Feb 25 19:53:56 ldap slapd[2296]: slap_queue_csn: queing 0x422d2430
20120225175356.478960Z#000000#000#000000
Feb 25 19:53:56 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f774e0 20120225175356.478960Z#000000#000#000000
Feb 25 19:54:03 ldap slapd[2296]: slap_queue_csn: queing 0x422d2430
20120225175403.408232Z#000000#000#000000
Feb 25 19:54:03 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19db6b30 20120225175403.408232Z#000000#000#000000
Feb 25 19:54:10 ldap slapd[2296]: slap_queue_csn: queing 0x42ad2400
20120225175410.321133Z#000000#000#000000
Feb 25 19:54:10 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f516c0 20120225175410.321133Z#000000#000#000000
Feb 25 19:54:21 ldap slapd[2296]: slap_queue_csn: queing 0x42ad3430
20120225175421.152806Z#000000#000#000000
Feb 25 19:54:21 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f5b4f0 20120225175421.152806Z#000000#000#000000
Feb 25 19:54:25 ldap slapd[2296]: slap_queue_csn: queing 0x42ad3430
20120225175425.678290Z#000000#000#000000
Feb 25 19:54:25 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f516c0 20120225175425.678290Z#000000#000#000000
Feb 25 19:54:34 ldap slapd[2296]: slap_queue_csn: queing 0x432d4430
20120225175434.170357Z#000000#000#000000
Feb 25 19:54:34 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f19700 20120225175434.170357Z#000000#000#000000
Feb 25 19:54:41 ldap slapd[2296]: slap_queue_csn: queing 0x42ad3430
20120225175441.740593Z#000000#000#000000
Feb 25 19:54:41 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f19340 20120225175441.740593Z#000000#000#000000
Feb 25 19:54:48 ldap slapd[2296]: slap_queue_csn: queing 0x432d3400
20120225175448.827690Z#000000#000#000000
Feb 25 19:54:48 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f192a0 20120225175448.827690Z#000000#000#000000
Feb 25 19:55:55 ldap slapd[2296]: slap_queue_csn: queing 0x432d3400
20120225175555.025407Z#000000#000#000000
Feb 25 19:55:55 ldap slapd[2296]: slap_queue_csn: queing 0x422d1400
20120225175555.028843Z#000000#000#000000
Feb 25 19:55:55 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19f1cb80 20120225175555.025407Z#000000#000#000000
Feb 25 19:55:55 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x19ed6a90 20120225175555.028843Z#000000#000#000000
At the same time, consumers were not logging anything (but were running
normally).
After restart of the consumers, on the provider:
Feb 25 20:02:55 ldap slapd[2296]: srs csn
20120217132800.021716Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225174730.829877Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225174905.178671Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225174918.725184Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225174927.883674Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175157.332360Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175334.154298Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175339.947561Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175348.026487Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175356.478960Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175403.408232Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175410.321133Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175421.152806Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175425.678290Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175434.170357Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175441.740593Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175448.827690Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175555.025407Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: log csn
20120225175555.028843Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: Entry
dc=1.1.0.2.8.4.6.0.1.0.0.2.ip6.arpa,ou=dns1,dc=noa,dc=gr CSN
20120217132800.021716Z#000000#000#000000 older or equal to ctx
20120217132800.021716Z#000000#000#000000
Feb 25 20:02:55 ldap slapd[2296]: syncprov_search_response:
cookie=rid=333,csn=20120225175555.028843Z#000000#000#000000
Feb 25 20:04:15 ldap slapd[2296]: slap_queue_csn: queing 0x42ad2400
20120225180415.859416Z#000000#000#000000
Feb 25 20:04:15 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x1a07bf70 20120225180415.859416Z#000000#000#000000
Feb 25 20:04:15 ldap slapd[2296]: syncprov_sendresp:
cookie=rid=333,csn=20120225180415.859416Z#000000#000#000000
Feb 25 20:04:15 ldap slapd[2296]: slap_queue_csn: queing 0x432d3400
20120225180415.876718Z#000000#000#000000
Feb 25 20:04:15 ldap slapd[2296]: syncprov_sendresp:
cookie=rid=333,csn=20120225180415.876718Z#000000#000#000000
Feb 25 20:04:15 ldap slapd[2296]: slap_graduate_commit_csn: removing
0x1a089990 20120225180415.876718Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: srs csn
20120217132800.021716Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225174730.829877Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225174905.178671Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225174918.725184Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225174927.883674Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175157.332360Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175334.154298Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175339.947561Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175348.026487Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175356.478960Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175403.408232Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175410.321133Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175421.152806Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175425.678290Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175434.170357Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175441.740593Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175448.827690Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175555.025407Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225175555.028843Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225180415.859416Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: log csn
20120225180415.876718Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: Entry
dc=1.1.0.2.8.4.6.0.1.0.0.2.ip6.arpa,ou=dns1,dc=noa,dc=gr CSN
20120217132800.021716Z#000000#000#000000 older or equal to ctx
20120217132800.021716Z#000000#000#000000
Feb 25 20:18:03 ldap slapd[2296]: syncprov_search_response:
cookie=rid=222,csn=20120225180415.876718Z#000000#000#000000
Regards,
Nick
--
NOC NOAnet
Systems Design and Administration
Research Support Department
National Observatory of Athens
http://www.noa.gr
11 years, 7 months
perl backend and Modification.sm_values
by Cristian Constantin
hi!
the perl backend sends parts of the ldap request message as parameters
to certain functions of a specified perl module.
for example, in case of an ModifyRequest, in the file:
servers/slapd/back-perl/modify.c
function:
int
perl_back_modify(
Operation *op,
SlapReply *rs )
I see this starting with line 60:
for ( i = 0;
mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL;
i++ )
{
XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); <--- SAFE ???
}
perlguts (http://perldoc.perl.org/perlguts.html#Working-with-SVs) says about
newSVpv():
"Notice that you can choose to specify the length of the string to be assigned
by using sv_setpvn , newSVpvn , or newSVpv , or you may allow Perl to calculate
the length by using sv_setpv or by specifying 0 as the second argument to
newSVpv . Be warned, though, that Perl will determine the string's length by
using strlen , which depends on the string terminating with a NUL
character."
is it safe to assume that bc_val points to something that terminates
with '\0' ??
thanks!
bye now!
cristian
11 years, 7 months
when 2.4.30?
by Michael Ströder
HI!
CHANGES in branch RE24 now contains:
OpenLDAP 2.4.30 Engineering
Fixed slapd syncrepl delete handling (ITS#7052,ITS#7162)
Fixed slapo-syncprov loop detection (ITS#6024)
Will there be a quick-fix release 2.4.30 soon?
Ciao, Michael.
11 years, 7 months
CVS branching -> Git branching model
by Hallvard Breien Furuseth
I think we should leave the current CVS-style branching model and make
better use of Git.
'master' is currently two things: The development branch, and getting
in the way it's an abandonware repository: slapmodify, vc, etc.
Maybe that's harsh, but if it is not abandonware, why are the authors
not finishing it so it can be released? Some of it is years old.
The justification for keeping a bunch of features under development in
master instead of feature branches was to get more eyes and testers for
them. Well, OK, if the features were underway to be finished and
released. But that's not working out.
So I suggest we reclassify such code as abandonware and throw it out of
master. Maybe except code behind #ifdef LDAP_DEVEL which is safe to
include in releases. If this prompts someone to finish some code so it
can be released, great. Otherwise the reclassification is correct.
The code is still in the repo. Someone can recreate it as a feature
branch if they care. If some is for RE25, let's make a RE25 branch.
If we are going to keep avoiding feature branches and put unfinished
stuff in the devel branch, well OK, limited to code which _will_ get
released soon and code behind #ifdef LDAP_DEVEL which can be in releases
anyway. Otherwise after a while send the author a nastygram, revert the
code, maybe re-revert it into a feature branch so it's not forgotten.
We can still have a branch with all such unfinished code: See the 'pu'
branch in the gitworkflows(7) manpage. It merges the feature branches.
RE25 above could be another such branch of merged features.
Another issue is that we sometimes want a quick release - normally for a
regression in last release - but OPENLDAP_REL_ENG_2_4 is not in shape to
be released. So we wait, or end up with a quicka release wich is a
bugfix release with some other hopefully-OK code.
So, something like the following:
- 'maint' branch: Planned releases, like today's OPENLDAP_REL_ENG_2_4.
- Temporary 'hotfix' or 'itsNNNN' branches, branched off last release:
Quick unplanned releases, when 'maint' is not in shape to be released
quickly. After release, merge the branch into 'maint' and delete it.
- Some sort of 'devel' branch, branched off 'maint' and current
'master', merging 'maint' after releases.
Like to today's 'master' but without unfinished features other than
code behind #ifdef LDAP_DEVEL. That way it can be merged into maint
now and then (like before a release), which has to be easier than
cherry-picking all the time.
- Feature branches for long-lived unfinished features. Merged into 'pu'
below, and hopefully eventually into the other branches.
- 'pu', branching off 'devel' and merging the feature branches, so it
looks like today's 'master'. Needs to be thrown away and recreated
now and then to avoid clutter.
'maint' or 'devel' above would be named 'master'. I don't care which.
Completed feature branches can merge into the branch they branched off.
A feature branched off devel cannot merge into maint, since it'd drag
devel features with it. So it'd be really nice to keep merging devel
into maint now and then, instead of cherry-picking.
One final issue, I'd like to get rid of the clutter of old branches and
tags from CVS which are no longer of any use. Either delete them, or
rename to refs/archive/<heads,tags>/<name>. 'git clone' without
'--mirror' will not clone these.
--
Hallvard
11 years, 7 months
2.4.29?
by Michael Ströder
HI!
RE24 seems to be tagged ready to release. When will 2.4.29 be officially released?
Ciao, Michael.
11 years, 7 months
Re: RE24 testing call #4
by Quanah Gibson-Mount
--On Thursday, February 02, 2012 6:27 AM -0500 Jan Vcelak
<jvcelak(a)redhat.com> wrote:
>> > And from some reason, we encounter segfaults in certain tools
>> > (like SSSD) and even in slapd with syncrepl when terminating
>> > (appeared somewhere between 2.4.26 and 2.4.28):
>>
>> Do you still see this with RE24? I can't tell based on what you've
>> said
>> above. I.e. is this ITS#7132? Also, did you upgrade sasl to 2.1.25
>> at the
>> same time? It's got a whole boatload of bugs.
>
> Yes, I see it with RE24 (0056912) and cyrus-sasl-2.1.23-28.fc17.x86_64.
Please file an ITS with a stack trace of the crash.
--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 years, 7 months
Re: RE24 testing call #4
by Quanah Gibson-Mount
--On Wednesday, February 01, 2012 7:55 AM -0500 Jan Vcelak
<jvcelak(a)redhat.com> wrote:
> Hello.
>
> If you use Fedora, I've established repository with the test builds
> for versions 16 and 17 (Rawhide):
> http://repos.fedorapeople.org/repos/jvcelak/openldap/
>
> openldap-2.4.29-0.1.tc4 matches currently latest commit 0056912
>
> Some comments:
>
> Basic client/server operations seems to work. There are still
> some problems with MozNSS we discovered recently and haven't
> figured out yet. The biggest problem is, that syncrepl with PEM
> certificates is broken (works with MozNSS certdb). But this
> problem seems to be present in previous versions as well.
>
> And from some reason, we encounter segfaults in certain tools
> (like SSSD) and even in slapd with syncrepl when terminating
> (appeared somewhere between 2.4.26 and 2.4.28):
Do you still see this with RE24? I can't tell based on what you've said
above. I.e. is this ITS#7132? Also, did you upgrade sasl to 2.1.25 at the
same time? It's got a whole boatload of bugs.
--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 years, 7 months
