openldap-devel February 2012

openldap-devel@openldap.org

11 participants
11 discussions

ITS#7052, syncrepl, deletes, and MMR
by Howard Chu 09 Mar '12

09 Mar '12

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/

3 5

RE24 testing call#1 (2.4.30)
by Quanah Gibson-Mount 27 Feb '12

27 Feb '12

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/h…> 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

5 5

Re: RE24 testing call#1 (2.4.30)
by Toby Blake 27 Feb '12

27 Feb '12

> 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/h…> > > 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.

1 0

Re: RE24 testing call#1 (2.4.30)
by Nikolaos Milas 25 Feb '12

25 Feb '12

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

1 0

perl backend and Modification.sm_values
by Cristian Constantin 17 Feb '12

17 Feb '12

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

1 0

when 2.4.30?
by Michael Ströder 15 Feb '12

15 Feb '12

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.

2 1

CVS branching -> Git branching model
by Hallvard Breien Furuseth 10 Feb '12

10 Feb '12

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

5 9

2.4.29?
by Michael Ströder 08 Feb '12

08 Feb '12

HI! RE24 seems to be tagged ready to release. When will 2.4.29 be officially released? Ciao, Michael.

2 1

Re: RE24 testing call #4
by Quanah Gibson-Mount 03 Feb '12

03 Feb '12

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

1 1

Re: RE24 testing call #4
by Quanah Gibson-Mount 01 Feb '12

01 Feb '12

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel February 2012