- openldap-bugs - openldap.org

Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by hyc＠symas.com 10 Oct '13

10 Oct '13

stefw(a)redhat.com wrote: > Full_Name: Stef Walter > Version: 2.4.35 > OS: Fedora 19 > URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch > Submission from: (NULL) (46.5.2.70) > > > Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is broken for > IPv6 for current versions of openldap. Tested with version 2.4.35 > > It's not clear if this ever worked properly. No, clearly not, the code was written and deprecated before IPv6 existed. Nobody should be using this code today. Even if it were to be used, the patch would break slapd; your getnameinfo patch changes the format of the peername string. The format of this string is not arbitrary, it's used in ACLs and the format is documented in slapd.access(5). In the future, write patches that fix one single issue. Don't make gratuitous changes, particularly if you haven't researched what you're changing. > Connections immediately fail with: > > ldap_search_ext: Can't contact LDAP server (-1) > > The reason for this is that the LDAP_CONNECTIONLESS buffers include a prefix > containing an address in a "struct sockaddr". However, struct sockaddr, is not a > concrete type. In particular struct sockaddr_in6 is longer than struct > sockaddr. > > Noted here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… > > So this leads to failures when using IPv6 as the code assumes that the address > length is equal to sizeof (struct sockaddr). Seen here: > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… > > Example command: > > $ ldapsearch -d -1 -LL -H 'cldap://[2620:52:0:2223::1:1]' -b '' -s base > '(&(DnsDomain=ad.baseos.qe)(NtVer=\06\00\00\00))' NetLogon > > Output will contain this: > > ldap_write: want=96 error=Invalid argument > > Which is the EINVAL resulting from bad value passed to sendto(). > > -- -- 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 0

Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by hyc＠symas.com 10 Oct '13

10 Oct '13

quanah(a)zimbra.com wrote: > --On Thursday, September 12, 2013 4:04 PM +0000 stefw(a)redhat.com wrote: > >>> 2.4.35 is not the current version of OpenLDAP, 2.4.36 is. There were >>> fixes to CLDAP made in 2.4.36. Please test against 2.4.36 and report >>> back, thanks. >> >> This patch is against master. >> >> However master cldap support is broken in additional ways, and I'll be >> filing further bugs/patches. > > Hi Stef, > > Thanks! In the future then, if it is an issue with the current 2.4 release > series still, you can just put RE24 as the version. ;) Then I won't spend > time trying to see if it's a known issue already fixed via the changes log. The CLDAP code is a remnant from pre-LDAPv3, there was no such thing as IPv6 when it was written, so no, this has never worked with IPv6. Who still uses CLDAP today? This code has no valid reason to exist any more. -- -- 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 0

(ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 10 Oct '13

10 Oct '13

With current master and re24 which have the fix for this ITS I now see seg faults in test023-refint test057-memberof-refint.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

michael(a)stroeder.com wrote: > On Wed, 09 Oct 2013 08:13:24 -0700 Howard Chu <hyc(a)symas.com> wrote >> slapd already strips DSA-specific attributes before sending a syncrepl entry. >> memberOf is not marked in the schema as DSA-specific. This is working as >> designed. > > IIRC attribute 'memberOf' was replicated in former releases. So it was not > DSA-specific back then. > > Then the behaviour was changed in a more recent OpenLDAP release. Nowadays each > replica has to be configured with slapo-memberof performing *local* operations. > Therefore I'd argue that 'memberOf' should be marked DSA-specific now since the > *local* configuration is significant for its content. > Note that there is no formal specification for attribute 'memberOf' at all. > > I have deployments where most users are member of more than 10 groups, > sometimes more than 20. So not sending 'memberOf' could save quite a lot of > network traffic. > > What are your objections against marking 'memberOf' as DSA-specific? > > (I vaguely remember this being discussed before without result though.) Additionally consider partial replication where only a subset of group entries is present on a certain consumer. One would not want to have 'memberOf' point to group entries not really existing on that consumer. => 'memberOf' is definitely DSA-specific. Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

On Wed, 09 Oct 2013 08:13:24 -0700 Howard Chu <hyc(a)symas.com> wrote > slapd already strips DSA-specific attributes before sending a syncrepl entry. > memberOf is not marked in the schema as DSA-specific. This is working as > designed. IIRC attribute 'memberOf' was replicated in former releases. So it was not DSA-specific back then. Then the behaviour was changed in a more recent OpenLDAP release. Nowadays each replica has to be configured with slapo-memberof performing *local* operations. Therefore I'd argue that 'memberOf' should be marked DSA-specific now since the *local* configuration is significant for its content. Note that there is no formal specification for attribute 'memberOf' at all. I have deployments where most users are member of more than 10 groups, sometimes more than 20. So not sending 'memberOf' could save quite a lot of network traffic. What are your objections against marking 'memberOf' as DSA-specific? (I vaguely remember this being discussed before without result though.) Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Michael Ströder wrote: > On Wed, 9 Oct 2013 14:05:52 GMT hyc(a)symas.com wrote >> Howard Chu wrote: >>> Michael Ströder wrote: >>>> But now I see this during initial refresh phase of second server: >>>> >>>> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 >>>> already exists" >>>> >>>> Is that expected? >>> >>> Not seeing that with your testcase. >>> >> Ah, I see it now. Yes, it's normal; memberOf on the provider already added >> the relevant values. The consumer receives a group entry and performs the >> same set of memberof updates, which are redundant at that point. It's >> harmless. > > Hmm, wouldn't it be reasonable to strip those attributes marked as > non-replication attrs when generating syncrepl search results at the provider? > (Even if consumer asks for attrs=*,+) slapd already strips DSA-specific attributes before sending a syncrepl entry. memberOf is not marked in the schema as DSA-specific. This is working as designed. -- -- 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 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

On Wed, 9 Oct 2013 14:05:52 GMT hyc(a)symas.com wrote > Howard Chu wrote: > > Michael Ströder wrote: > >> But now I see this during initial refresh phase of second server: > >> > >> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 > >> already exists" > >> > >> Is that expected? > > > > Not seeing that with your testcase. > > > Ah, I see it now. Yes, it's normal; memberOf on the provider already added > the relevant values. The consumer receives a group entry and performs the > same set of memberof updates, which are redundant at that point. It's > harmless. Hmm, wouldn't it be reasonable to strip those attributes marked as non-replication attrs when generating syncrepl search results at the provider? (Even if consumer asks for attrs=*,+) Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Howard Chu wrote: > Michael Ströder wrote: >> On Wed, 09 Oct 2013 05:01:40 -0700 Howard Chu <hyc(a)symas.com> wrote >> >>> michael(a)stroeder.com wrote: >>>> I've updated the test data with LDIF files and a README describing the LDAP >>>> operations to perform: >>>> >>>> http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 >>>> >>>> I consider this to be a serious issue which could be the cause for other >>>> replication issues including dead-locks we're experiencing. (Maybe there >>>> are similar issues in slapo-refint since dead-locks in our deployment >>>> arised when moving entries into different subtree.) >>> >>> Thanks, fixed now in master. Looks like refint may have run into the same >>> issue, also patched in master. >> >> contextCSN values are correct now. >> >> But now I see this during initial refresh phase of second server: >> >> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 >> already exists" >> >> Is that expected? > > Not seeing that with your testcase. > Ah, I see it now. Yes, it's normal; memberOf on the provider already added the relevant values. The consumer receives a group entry and performs the same set of memberof updates, which are redundant at that point. It's harmless. -- -- 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 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Michael Ströder wrote: > On Wed, 09 Oct 2013 05:01:40 -0700 Howard Chu <hyc(a)symas.com> wrote > >> michael(a)stroeder.com wrote: >>> I've updated the test data with LDIF files and a README describing the LDAP >>> operations to perform: >>> >>> http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 >>> >>> I consider this to be a serious issue which could be the cause for other >>> replication issues including dead-locks we're experiencing. (Maybe there >>> are similar issues in slapo-refint since dead-locks in our deployment >>> arised when moving entries into different subtree.) >> >> Thanks, fixed now in master. Looks like refint may have run into the same >> issue, also patched in master. > > contextCSN values are correct now. > > But now I see this during initial refresh phase of second server: > > send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 > already exists" > > Is that expected? Not seeing that with your testcase. -- -- 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 0

(ITS#7717) Sudden memory increase leading to Master LDAP crash
by marco.pizzoli＠gmail.com 09 Oct '13

09 Oct '13

--089e0115ff765de02a04e84f36b1 Content-Type: text/plain; charset=ISO-8859-1 I think I faced this same problem last week during a massive load of users (300K +) using a single ldapadd execution. My db "exploded" (MDB_MAP_FULL) after about 120K users populated. The main issue was related to the size of the db than to the actual memory allocated. It grew up to over 12GB before reaching the limit of my file system. But with memory-mapped files topics are close, I suppose. Curious enough, populating the same db from a full syncrepl led the db to grew to only (more or less) 500MB. As additional information, this server was part of a 5-node multi-master. And after the ldapadd the db -size was very different on each of the servers being part of the cluster. I cannot share any conf, I'm sorry. Marco --089e0115ff765de02a04e84f36b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>I think I faced this same problem last week= during a massive load of users (300K +) using a single ldapadd execution.<= br>My db "exploded" (MDB_MAP_FULL) after about 120K users populat= ed.<br> The main issue was related to the size of the db than to the actual memory = allocated. It grew up to over 12GB before reaching the limit of my file sys= tem. But with memory-mapped files topics are close, I suppose.<br><br> </div> Curious enough, populating the same db from a full syncrepl led the db to g= rew to only (more or less) 500MB.<br><br>As additional information, this se= rver was part of a 5-node multi-master. And after the ldapadd the db -size = was very different on each of the servers being part of the cluster.<br> <br></div>I cannot share any conf, I'm sorry.<br></div>Marco<br></div> --089e0115ff765de02a04e84f36b1--

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

On Wed, 09 Oct 2013 05:01:40 -0700 Howard Chu <hyc(a)symas.com> wrote > michael(a)stroeder.com wrote: > > I've updated the test data with LDIF files and a README describing the LDAP > > operations to perform: > > > > http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 > > > > I consider this to be a serious issue which could be the cause for other > > replication issues including dead-locks we're experiencing. (Maybe there > > are similar issues in slapo-refint since dead-locks in our deployment > > arised when moving entries into different subtree.) > > Thanks, fixed now in master. Looks like refint may have run into the same > issue, also patched in master. contextCSN values are correct now. But now I see this during initial refresh phase of second server: send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 already exists" Is that expected? Ciao, Michael. 52555576 syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 52555576 syncrepl_entry: rid=002 inserted UUID b5736b9e-c52f-1032-99c4-31a68f008587 52555576 mdb_idl_fetch_key: [3bec70f1] 52555576 send_ldap_result: err=0 matched="" text="" 52555576 syncrepl_entry: rid=002 be_search (0) 52555576 syncrepl_entry: rid=002 cn=replicas,ou=groups,dc=example,dc=com 52555576 ==> mdb_add: cn=replicas,ou=groups,dc=example,dc=com 52555576 mdb_idl_insert_keys: b [f4f2ead9] 52555576 mdb_idl_insert_keys: b [8f2b53e8] 52555576 mdb_idl_insert_keys: b [cb13035d] 52555576 mdb_idl_insert_keys: b [c14a3e76] 52555576 mdb_idl_insert_keys: b [3bec70f1] 52555576 mdb_idl_insert_keys: b 52555576 send_ldap_result: err=0 matched="" text="" 52555576 mdb_modify: cn=slapd-1,ou=sys,dc=example,dc=com 52555576 mdb_modify_internal: add memberOf 52555576 dnMatch 0 "cn=replicas,ou=groups,dc=example,dc=com" "cn=replicas,ou=groups,dc=example,dc=com" 52555576 mdb_modify_internal: 20 modify/add: memberOf: value #0 already exists 52555576 send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 already exists" 52555576 conn=-1 op=0: memberof_value_modify DN="cn=slapd-1,ou=sys,dc=example,dc=com" add memberOf="cn=replicas,ou=groups,dc=example,dc=com" failed err=20 52555576 mdb_modify: cn=slapd-2,ou=sys,dc=example,dc=com 52555576 mdb_modify_internal: add memberOf 52555576 dnMatch 0 "cn=replicas,ou=groups,dc=example,dc=com" "cn=replicas,ou=groups,dc=example,dc=com" 52555576 mdb_modify_internal: 20 modify/add: memberOf: value #0 already exists 52555576 send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 already exists" 52555576 conn=-1 op=0: memberof_value_modify DN="cn=slapd-2,ou=sys,dc=example,dc=com" add memberOf="cn=replicas,ou=groups,dc=example,dc=com" failed err=20 52555576 syncrepl_entry: rid=002 be_add cn=replicas,ou=groups,dc=example,dc=com (0) 52555576 do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE 52555576 do_syncrep2: rid=002 cookie=rid=002,sid=001,csn=20131009130900.890770Z#000000#001#000000 52555576 slap_queue_csn: queing 0x7fd79c10c200 20131009130900.890770Z#000000#001#000000 52555576 base_candidates: base: "dc=example,dc=com" (0x00000001) 52555576 send_ldap_result: err=0 matched="" text="" 52555576 mdb_modify: dc=example,dc=com 52555576 mdb_modify_internal: replace contextCSN 52555576 send_ldap_result: err=0 matched="" text="" 52555576 slap_graduate_commit_csn: removing 0x7fd79c10c170 20131009130900.890770Z#000000#001#000000

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

michael(a)stroeder.com wrote: > I've updated the test data with LDIF files and a README describing the LDAP > operations to perform: > > http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 > > I consider this to be a serious issue which could be the cause for other > replication issues including dead-locks we're experiencing. (Maybe there are > similar issues in slapo-refint since dead-locks in our deployment arised when > moving entries into different subtree.) Thanks, fixed now in master. Looks like refint may have run into the same issue, also patched in master. -- -- 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 0

Re: (ITS#7722) Assertion failure on MDB_NEXT of existing cursor following delete
by hyc＠symas.com 09 Oct '13

09 Oct '13

dw(a)botanicus.net wrote: > Full_Name: David Wilson > Version: bf0e97aa0e9 @ git://gitorious.org/mdb/mdb.git > OS: Linux > URL: https://gist.github.com/dw/ba100e59b42ed5fccb67/raw/f25b08334e6956d9558bb05… > Submission from: (NULL) (178.238.153.20) > > > The attached cursor-del-break.c exhibits an assertion failure after successfully > deleting 1246 256-byte records from a set of 2048. This hammers the case where > one cursor is used to iterate, while a temporary cursor is used to delete the > record currently pointed to by the first cursor. > > cursor-del-break: src/py-lmdb/lib/mdb.c:5025: mdb_cursor_next: Assertion > `((((mp)->mp_flags) & (0x02)) == (0x02))' failed. > > > Thanks for the report, fixed now in mdb.master. -- -- 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 0

(ITS#7722) Assertion failure on MDB_NEXT of existing cursor following delete
by dw＠botanicus.net 09 Oct '13

09 Oct '13

Full_Name: David Wilson Version: bf0e97aa0e9 @ git://gitorious.org/mdb/mdb.git OS: Linux URL: https://gist.github.com/dw/ba100e59b42ed5fccb67/raw/f25b08334e6956d9558bb05… Submission from: (NULL) (178.238.153.20) The attached cursor-del-break.c exhibits an assertion failure after successfully deleting 1246 256-byte records from a set of 2048. This hammers the case where one cursor is used to iterate, while a temporary cursor is used to delete the record currently pointed to by the first cursor. cursor-del-break: src/py-lmdb/lib/mdb.c:5025: mdb_cursor_next: Assertion `((((mp)->mp_flags) & (0x02)) == (0x02))' failed.

1 0

(ITS#7721) slapo-lastbind patch to allow authTimestamp updates to be forwarded via updateref
by ck＠cksoft.de 08 Oct '13

08 Oct '13

Full_Name: Christian Kratzer Version: HEAD OS: CentOS 6.4 URL: http://www.cksoft.de/paste/34e81be96925e5ea28daea7da2b84b09049f7f3d/0001-Al… Submission from: (NULL) (2003:41:c010:8001:8de8:2245:8dd7:5c5e) I, Christian Kratzer, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. I have adapted code from slapo-ppolicy to slapo-lastbind from contrib to allow forwarding of updates to authTimestamp via updateref and chaining. The patch introduces a new lastbind_forward_updates (olcLastBindForwardUpdates ) boolean parameter to slapo-lastbind that has the same semantics as ppolicy_forward_updates (olcPPolicyForwardUpdates) in slapo-ppolicy. I have a 2 master, 2 slave syncrepl test setup which chaining from the slaves to the masters ( to one of them to be precise ). - Bind on master1 results in authTimestamp getting replicated to master2 and both slaves. - Bind on slave1 with olcLastBindForwardUpdates=TRUE results in authTimestamp getting forwarded to the master with updateRef and chaining and replicated from there. Please review especially the one from ppolicy I did not merge marked with TODO. Greetings Christian

1 0

Re: (ITS#7720) 2.4.36 build failure on HP-UX
by hyc＠symas.com 08 Oct '13

08 Oct '13

bugs-openldap(a)vendor.thewrittenword.com wrote: > Full_Name: Albert Chin > Version: 2.4.36 > OS: HP-UX 11.23/PA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.67.212.94) Thanks for the report. Interesting, this should also have been flagged as illegal in gcc but wasn't. Fixed now in master. > While trying to build 2.4.36 on HP-UX 11.23/PA with the HP C compiler: > cc -z +O2 +Olit=all +Ofltacc +Oentrysched +Odataprefetch +Onolimit > -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb > -I/opt/TWWfsw/tcpwrap/include -I/opt/TWWfsw/libsasl21/include > -I/opt/TWWfsw/libopenssl10/include -I/opt/TWWfsw/libdb47/include -c tools.c -o > tools.o > cc: "tools.c", line 1384: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "tools.c", line 1410: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > gmake[3]: *** [tools.lo] Error 1 > gmake[3]: Leaving directory `/opt/build/openldap-2.4.36/servers/slapd/back-mdb' > > ... > > cc -z +O2 +Olit=all +Ofltacc +Oentrysched +Odataprefetch +Onolimit > -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb > -I/opt/TWWfsw/tcpwrap/include -I/opt/TWWfsw/libsasl21/include > -I/opt/TWWfsw/libopenssl10/include -I/opt/TWWfsw/libdb47/include -c dn2id.c -o > dn2id.o > cc: "dn2id.c", line 168: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 181: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 249: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 262: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 402: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 798: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > gmake[3]: *** [dn2id.lo] Error 1 > gmake[3]: Leaving directory `/opt/build/openldap-2.4.36/servers/slapd/back-mdb' > > -- -- 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 0

(ITS#7720) 2.4.36 build failure on HP-UX
by bugs-openldap＠vendor.thewrittenword.com 08 Oct '13

08 Oct '13

Full_Name: Albert Chin Version: 2.4.36 OS: HP-UX 11.23/PA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.67.212.94) While trying to build 2.4.36 on HP-UX 11.23/PA with the HP C compiler: cc -z +O2 +Olit=all +Ofltacc +Oentrysched +Odataprefetch +Onolimit -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -I/opt/TWWfsw/tcpwrap/include -I/opt/TWWfsw/libsasl21/include -I/opt/TWWfsw/libopenssl10/include -I/opt/TWWfsw/libdb47/include -c tools.c -o tools.o cc: "tools.c", line 1384: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "tools.c", line 1410: error 1539: Cannot do arithmetic with pointers to objects of unknown size. gmake[3]: *** [tools.lo] Error 1 gmake[3]: Leaving directory `/opt/build/openldap-2.4.36/servers/slapd/back-mdb' ... cc -z +O2 +Olit=all +Ofltacc +Oentrysched +Odataprefetch +Onolimit -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -I/opt/TWWfsw/tcpwrap/include -I/opt/TWWfsw/libsasl21/include -I/opt/TWWfsw/libopenssl10/include -I/opt/TWWfsw/libdb47/include -c dn2id.c -o dn2id.o cc: "dn2id.c", line 168: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 181: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 249: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 262: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 402: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 798: error 1539: Cannot do arithmetic with pointers to objects of unknown size. gmake[3]: *** [dn2id.lo] Error 1 gmake[3]: Leaving directory `/opt/build/openldap-2.4.36/servers/slapd/back-mdb'

1 0

Re: (ITS#7719) configure delayed response time
by quanah＠zimbra.com 08 Oct '13

08 Oct '13

--On Tuesday, October 08, 2013 3:59 AM +0000 rashtrapathy(a)gmail.com wrote: > Full_Name: Rashtrapathy > Version: 2.4.36 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.163.217.105) > > > Dear All, > > I want my openldap server to send a delayed searchResEntry & > searchResDone for any searchRequest. > > Where i need to change the configuration file for this delayed response? The ITS system is for reporting bugs, not asking usage questions. I would however suggest you look at contrib modules like the noop module to see about how to insert a delay into the slapd stack. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7718) mdb_cursor_del() segfault on last entry
by hyc＠symas.com 08 Oct '13

08 Oct '13

matthew.monaco(a)colorado.edu wrote: > Full_Name: Matthew Monaco > Version: mdb-0.9.8, mdb-d327a36 > OS: linux-3.11.4 > URL: http://pastie.org/8385142 > Submission from: (NULL) (128.138.64.206) > > > I'm getting a segfault with MDB when using mdb_cursor_del() on the last entry in > the database. Example on pastie.org [1]. Thanks for the report and testcase, fixed now in mdb.master/ > > [1] http://pastie.org/8385142 > > -- -- 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 0

(ITS#7719) configure delayed response time
by rashtrapathy＠gmail.com 08 Oct '13

08 Oct '13

Full_Name: Rashtrapathy Version: 2.4.36 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.163.217.105) Dear All, I want my openldap server to send a delayed searchResEntry & searchResDone for any searchRequest. Where i need to change the configuration file for this delayed response? Please help me ASAP. Thanks, Rash.

1 0

(ITS#7718) mdb_cursor_del() segfault on last entry
by matthew.monaco＠colorado.edu 08 Oct '13

08 Oct '13

Full_Name: Matthew Monaco Version: mdb-0.9.8, mdb-d327a36 OS: linux-3.11.4 URL: http://pastie.org/8385142 Submission from: (NULL) (128.138.64.206) I'm getting a segfault with MDB when using mdb_cursor_del() on the last entry in the database. Example on pastie.org [1]. [1] http://pastie.org/8385142

1 0

Re: (ITS#7717) Sudden memory increase leading to Master LDAP crash
by quanah＠zimbra.com 08 Oct '13

08 Oct '13

--On Thursday, October 03, 2013 1:14 PM +0000 marcon.bruno(a)free.fr wrote: > The problem is very easy to replay : one master and one slave are > sufficient. Then run 9 windows with a script adding an entry and > modifying an entry. Please provide full configuration details. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by ck＠cksoft.de 08 Oct '13

08 Oct '13

Hi Michael, On Sun, 6 Oct 2013, michael(a)stroeder.com wrote: > I've updated the test data with LDIF files and a README describing the LDAP > operations to perform: > > http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 > > I consider this to be a serious issue which could be the cause for other > replication issues including dead-locks we're experiencing. (Maybe there are > similar issues in slapo-refint since dead-locks in our deployment arised when > moving entries into different subtree.) I can confirm that I can see the same bug with your testcase. It seems that restarting the second slapd instance fixes the contextCSN issue just because it scans all it's entries and does the right thing. Even a slapcat of both directories shows the issue. Things that I find disturbing: After applying the group membership the member dn: gets it's memberOf attribute updated accordingly. But the entryCSN stays unchanged. Entry before applying group membership: # michael, users, example.com dn: uid=michael,ou=users,dc=example,dc=com uid: michael objectClass: account objectClass: simpleSecurityObject userPassword:: dGVzdHNlY3JldA== description: test entryCSN: 20131006193757.912740Z#000000#002#000000 Entry after applying group membership is obviously updated but still has the same entryCSN: # michael, users, example.com dn: uid=michael,ou=users,dc=example,dc=com uid: michael objectClass: account objectClass: simpleSecurityObject userPassword:: dGVzdHNlY3JldA== memberOf: cn=admins,ou=groups,dc=example,dc=com memberOf: cn=testgroup1,ou=groups,dc=example,dc=com description: test entryCSN: 20131006193757.912740Z#000000#002#000000 I can also confirm the subsequent contextCSN mismatch. I too consider this a serious issue. If I read Howards reply correctly and from what I see in the source code of the memberOf overlay the strategy here seems to be not to replicate the side effect of adding the memberOf: entry. OpenLDAP relies on the side effect happening on the replicas through the same codepath when the member: attribute in the group gets updated through replication. This sounds very similar to the difference between: 1. statement replication in sql databases ala mysql 2. log based replication ala postgresql OpenLDAP is doing 1. here while 2. would perhaps have been the better option. I understand turning this around is propably too late at this point in time. Looks like we will just have to work out the bugs the hard way. I am using slapo-lastbind and slapo-ppolicy extensively in my current project and will keep my eyes open for similar issues resulting from not replicating the side effects that these overlays produce. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 07 Oct '13

07 Oct '13

Christian Kratzer wrote: > This sounds very similar to the difference between: > > 1. statement replication in sql databases ala mysql > > 2. log based replication ala postgresql > > OpenLDAP is doing 1. here while 2. would perhaps have been the better option. >From my understanding 2. is OpenLDAP's delta-syncrepl. Ciao, Michael.

1 0

Re: (ITS#7716) slapd crashes after search immediately followed by (abandon+) unbind
by quanah＠zimbra.com 07 Oct '13

07 Oct '13

--On Wednesday, October 02, 2013 12:32 PM +0000 michael.vishchers(a)7p-group.com wrote: > Full_Name: Michael Vishchers > Version: 2.4.23 This release is years old, and has numerous known issues. It sounds like you are using RedHat's package. If you absolutely have to use that package, then you need to report this issue with RedHat. Otherwise, I suggest upgrading to the latest release. If you don't feel comfortable building OpenLDAP yourself, you can easily use the packages from the LTB project: <http://ltb-project.org/wiki/download#openldap> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- 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-bugs