openldap-devel

openldap-devel@openldap.org

2 participants
1419 discussions

slapd: attr.c:481: attr_merge: Assertion
by Michael Ströder 16 Mar '12

16 Mar '12

HI! What does it mean when slapd aborts with this assertion? ------------------------------------ snip ------------------------------------ slapd: attr.c:481: attr_merge: Assertion `( nvals == ((void *)0) && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0) && ( ( (*a)->a_vals == ((void *)0) && (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )' failed. Aborted ------------------------------------ snip ------------------------------------ In the source code there is a FIXME remark. Does that remark mean the assertion is still not as strict as required or that the assertion might be too strict? Ciao, Michael.

4 6

slapcat of selected attributes
by Hallvard Breien Furuseth 14 Mar '12

14 Mar '12

I'd like slapcat to accept an attribute list to output: slapcat -H "ldap:///dc=uio,dc=no?telephoneNumber,cn" slapcat URLs won't mean the same as in the LDAP spec, though: An empty attribute list = all attrs, both user user and operational ones: "*,+". Elsewhere in LDAP it means just user attrs: "*". Do anyone have a problem with that, or see a more sensible way to express it? It's not problem currently, when slapcat does not support an attribute list anyway. Come to think of it, ldapsearch ought to support full URLs too - but until it does, at least there's no risk of confusion with ldapsearch attribute lists. -- Hallvard

1 0

ITS candidates for 2.4.31
by Quanah Gibson-Mount 11 Mar '12

11 Mar '12

Looking at open ITSes, I would note the following are probably worthwhile to fix for 2.4.31: 6825, 6942, 7042, 7088, 7100, 7102, 7109, 7149, 7168, 7197, 7202 I know Hallvard is also looking at 6883. --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

3 2

Ancient ITSes
by Quanah Gibson-Mount 10 Mar '12

10 Mar '12

We have a lot of ITSes going back well over 5 years in the ITS system that are "open". Would it be possible for someone with some idea on them to go through and close them out as WONT FIX or otherwise prioritize them? I think a lot of them no longer really apply. --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 1

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

10 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 28 Feb '12

28 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel