- openldap-bugs - openldap.org

(ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hume-ol＠bofh.ca 08 Dec '11

08 Dec '11

Full_Name: Brandon Hume Version: 2.4.28 OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 URL: http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) OpenLDAP 2.4.28 compiled with BerkeleyDB 5.2.36, attempting to configure for multi-master replication. Problems occurred with the second server complaining about operations errors while attempting to replicate the cn=config tree; I've been able to reproduce the problem from the command line using ldapsearch from the same compile. The host is RHEL 6.1 running inside VMWare. Version of OpenLDAP is 2.4.28, compiled with BerkeleyDB 5.2.36 (no patches available from Oracle at the time I downloaded). Configuration options used are visible in http://den.bofh.ca/~hume/config_ol_sh.txt The problem does *not* seem to be consistent, as *sometimes* it will work but most of the time not. I've run the example query once, had it fail, run it again immediately and had it succeed, and then again fail a dozen times in a row. Wireshark traces showed the connection was established using LDAPv3; putting the server in debug "Any" mode also confirms the same. The syslogs generated are viewable at http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt I've compiled 2.4.27 with the same options and it *seemed* to behave, though I may have merely gotten lucky. Example ldapsearch invocation: $ /appl/ldap/bin/ldapsearch -x -D 'cn=config' -h kil-ds-3.its.dal.ca -b cn=config -w bindpass -s sub -E sync=rp -e manageDSAit 'objectclass=*' # extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: objectclass=* # requesting: ALL # with manageDSAit control # # search result search: 2 result: 2 Protocol error text: controls require LDAPv3 # numResponses: 1 ldap_result: Can't contact LDAP server (-1) These servers are not yet in production and I have ~two weeks to play and tweak to generate more debugging information if you'd find it useful.

1 0

Re: (ITS#7106) NSS and NSPR on Oracle Linux
by hyc＠symas.com 06 Dec '11

06 Dec '11

openldap(a)myname.nl wrote: > Full_Name: Daniël van Eeden > Version: 2.4.28 > OS: Oracle Linux 6.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:610:62d:0:5a94:6bff:fe5e:6904) > > > When doing a configure on Oracle linux 6.1 (extremely similair to RHEL 6.1) it > reports that nssutil.h > > checking nssutil.h usability... no > checking nssutil.h presence... no > checking for nssutil.h... no > configure: error: MozNSS not found - please specify the location to the NSPR and > NSS header files in CPPFLAGS and the location to the NSPR and NSS libraries in > LDFLAGS (if not in the system location) > > I've installed nspr4 and nss3 using the official oracle packages, so I shouldn't > need to set CPPFLAGS as the header files are installed in the system location. > > With these CPP flags it does work: > export CPPFLAGS="-I/usr/include/nss3 -I/usr/include/nspr4" > > I believe that OpenLDAP's configure should be able to locate these files as long > as they're installed in the official locations from the official media. There is no "official" location for NSS or NSPR header files, it varies with every system. This ITS will be closed. -- -- 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#7106) NSS and NSPR on Oracle Linux
by openldap＠myname.nl 06 Dec '11

06 Dec '11

Full_Name: Daniël van Eeden Version: 2.4.28 OS: Oracle Linux 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:610:62d:0:5a94:6bff:fe5e:6904) When doing a configure on Oracle linux 6.1 (extremely similair to RHEL 6.1) it reports that nssutil.h checking nssutil.h usability... no checking nssutil.h presence... no checking for nssutil.h... no configure: error: MozNSS not found - please specify the location to the NSPR and NSS header files in CPPFLAGS and the location to the NSPR and NSS libraries in LDFLAGS (if not in the system location) I've installed nspr4 and nss3 using the official oracle packages, so I shouldn't need to set CPPFLAGS as the header files are installed in the system location. With these CPP flags it does work: export CPPFLAGS="-I/usr/include/nss3 -I/usr/include/nspr4" I believe that OpenLDAP's configure should be able to locate these files as long as they're installed in the official locations from the official media.

1 0

(ITS#7105) Feature Request: accesslog exclude rule
by marco.pizzoli＠gmail.com 05 Dec '11

05 Dec '11

Full_Name: Marco Pizzoli Version: ALL OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) Hi, This is a feature request. I would like to take forward what started with ITS#6815. My request is to extend slapo-accesslog flexibility by introducing a directive "logbase-exclude". My request is to exclude a particular basedn to be logged by slapo-accesslog. If I have a tree with several ou's at the same level, it seems to me a lot inefficient to explicit all ou's logbases except one, only to exclude one of them. Thanks in advance Marco

1 0

(ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations
by mkrz＠free.fr 04 Dec '11

04 Dec '11

Full_Name: Martin Krzaczek Version: 2.4.28 OS: CentOS 5.7 URL: Submission from: (NULL) (83.202.204.201) Hello, I noticed an issue with "refreshOnly" syncrepl when a large number of records is added, updated and deleted. At the end of synchronization the contextCSN is equal on all servers, but the data is out of synchronization for some deleted records that remains undeleted on consumer/slave servers. Restarting the consumer or forcing a synchronization with "slapd ... -c 'rid=1,csn=0' " does not help. A similar issue was submitted few weeks ago (ITS#7052), but I'm not sure the problem is the same. My configuration : - CentOS 5.7 + OpenLDAP 2.4.28 + BDB 5.1.29 (the same issue occurs with CentOS 5.7 + OpenLDAP 2.4.26 + BDB 5.1.25) - one main provider where all modification operations are performed - one 'first level' consumer synchronizing data on the main provider and providing data for 'second level' consumers - one 'second level' consumer synchronizing data on the 'first level' consumer/provider I tried several combinations of configurations (refreshOnly/refreshAndPersist, syncprov-sessionlog) and noticed that when refreshOnly mode is used, some records may be not deleted on consumer/slave servers. The number of undeleted records varies depending on the configuration. So with a higher value of "syncprov-sessionlog" (for example 5000 instead of 500) the number of lost records is reduced. I have an application that sequentially (i.e. in a single thread) adds about 12000 records, modifies about 25000 records and deletes about 1000 records. Add/update/delete operations are mixed i.e. it is possible a have sequences such as add/add/delete/update/update/update/delete/add/... With a small amount of records to add/update/delete the synchronization properly works without any data loss. So it seams that if all modifications may be cached and transmitted to consumers then deleted records are not lost. There is no data loss for added and updated records whatever is the number of operations. Regards, Martin

1 0

Re: (ITS#7085) mutex lockup issue
by quanah＠zimbra.com 02 Dec '11

02 Dec '11

--On Friday, December 02, 2011 11:41 AM -0500 Soichi Hayashi <hayashis(a)indiana.edu> wrote: > Quanah, > > > Were you able to recreate this issue? > Hi Soichi, I have not even attempted to reproduce it. I will see if I have time in my lab to do so. However, I use BDB 5.2.28. I will note that the backtrace you provided is useless, since you apparently did not build your binaries with debugging symbols, which is always advised. I also don't know what optimization level you used, but I strongly advise against building optimized OpenLDAP builds, gcc rarely does the right thing. Finally, OpenLDAP doesn't use select() on Linux platforms, it uses poll() which appears to be what you're backtrace indicates as well. Since you don't have debugging symbols enabled, it's virtually impossible to determine where the problem is originating. --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

Re: (ITS#7085) mutex lockup issue
by hayashis＠indiana.edu 02 Dec '11

02 Dec '11

--0016364c7ac7fff89504b31ea350 Content-Type: text/plain; charset=ISO-8859-1 Quanah, Were you able to recreate this issue? Soichi On Wed, Nov 16, 2011 at 3:56 PM, Soichi Hayashi <hayashis(a)indiana.edu>wrote: > Quanah, > > We have compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4 > hours into our testing in similar manner to what I have reported earlier. I > believe this issue still occurs on the latest version. > > However, when I used gdb, I didn't notice the mutex locked threads like I > did with OpenLDAP 2.4.22. > > Following is from locked 2.4.26 slapd server. > > (gdb) info thread > 14 Thread 0x418dd940 (LWP 13814) 0x00000037aa4d48a8 in epoll_wait () > from /lib64/libc.so.6 > 13 Thread 0x420de940 (LWP 13815) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 12 Thread 0x428df940 (LWP 13816) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 11 Thread 0x430e0940 (LWP 13843) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 10 Thread 0x438e1940 (LWP 13855) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 9 Thread 0x440e2940 (LWP 13856) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 8 Thread 0x448e3940 (LWP 13857) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 7 Thread 0x450e4940 (LWP 13858) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 6 Thread 0x458e5940 (LWP 13859) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 5 Thread 0x460e6940 (LWP 13860) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 4 Thread 0x468e7940 (LWP 2007) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 3 Thread 0x470e8940 (LWP 2008) 0x00000037aa4cd722 in select () from > /lib64/libc.so.6 > 2 Thread 0x478e9940 (LWP 2009) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > * 1 Thread 0x2ac6ccfdc930 (LWP 13805) 0x00000037aac07b35 in pthread_join > () from /lib64/libpthread.so.0 > (gdb) thread 3 > [Switching to thread 3 (Thread 0x470e8940 (LWP 2008))]#0 > 0x00000037aa4cd722 in select () from /lib64/libc.so.6 > (gdb) bt > #0 0x00000037aa4cd722 in select () from /lib64/libc.so.6 > #1 0x000000000054ece5 in ?? () > #2 0x000000000054aa15 in ?? () > #3 0x0000000000557637 in ?? () > #4 0x0000000000557c11 in ?? () > #5 0x00000000004b2d93 in ?? () > #6 0x00000000004e9d7c in ?? () > #7 0x00000037aac0673d in start_thread () from /lib64/libpthread.so.0 > #8 0x00000037aa4d44bd in clone () from /lib64/libc.so.6 > > It looks like it's waiting on select() on thread 3 which never get fired > when I access it using ldapsearch command. > > I ran strace on ldapsearch (on a client machine) and following is what I > see at the end of the log.. > > $ strace ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b > mds-vo-name=WT2,o=grid > "(&(objectClass=GlueLocation)(GlueLocationName=TIMESTAMP))" > > .... > write(1, "\n", 1 > ) = 1 > write(3, "0l\2\1\2cg\4\26mds-vo-name=WT2,o=grid\n"..., 110) = 110 > poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1 > > Not sure if this strace is useful or not.. but after this, ldapsearch > never returned. > > Thanks, > Soichi > > > On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > >> --On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.eduwrote: >> >> Full_Name: Soichi Hayashi >>> Version: 2.4.22 >>> >> >> OpenLDAP 2.4.22 is quite old, and had various known issues. Please use a >> current release (2.4.26). This report will not be investigated unless you >> can reproduce it with a current release of OpenLDAP. You also fail to note >> what BDB release you are using, and whether or not it has all the relevant >> patches applied to it. If you have a broken policy of only using vendor >> provided packages, then you will need to send a bug report to RedHat, as it >> is their job to maintain their vendor packages. >> >> >> 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 >> > > --0016364c7ac7fff89504b31ea350 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quanah,<div><br></div><div>Were you able to recreate this issue?</div><div>= <br></div><div>Soichi<br><div><br><div class=3D"gmail_quote">On Wed, Nov 16= , 2011 at 3:56 PM, Soichi Hayashi <span dir=3D"ltr"><<a href=3D"mailto:h= ayashis(a)indiana.edu">hayashis(a)indiana.edu</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div>Quanah,</div><div><br></div><div>We ha= ve compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4 hours= into our testing in similar manner to what I have reported earlier. I beli= eve this issue still occurs on the latest version.</div> <div><br></div><div>However, when I used gdb, I didn't notice the mutex= locked threads like I did with OpenLDAP 2.4.22.</div><div><br></div><div>F= ollowing is from locked 2.4.26 slapd server.</div><div><br></div><div> (gdb) info thread</div> <div>=A0 14 Thread 0x418dd940 (LWP 13814) =A00x00000037aa4d48a8 in epoll_wa= it () from /lib64/libc.so.6</div><div>=A0 13 Thread 0x420de940 (LWP 13815) = =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libp= thread.so.0</div> <div>=A0 12 Thread 0x428df940 (LWP 13816) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 11 Thre= ad 0x430e0940 (LWP 13843) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC= _2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 10 Thread 0x438e1940 (LWP 13855) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 9 Threa= d 0x440e2940 (LWP 13856) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_= 2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 8 Thread 0x448e3940 (LWP 13857) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 7 Thread= 0x450e4940 (LWP 13858) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 6 Thread 0x458e5940 (LWP 13859) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 5 Thread= 0x460e6940 (LWP 13860) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 4 Thread 0x468e7940 (LWP 2007) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 3 Thread = 0x470e8940 (LWP 2008) =A00x00000037aa4cd722 in select () from /lib64/libc.s= o.6</div> <div>=A0 2 Thread 0x478e9940 (LWP 2009) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>* 1 Thread 0x= 2ac6ccfdc930 (LWP 13805) =A00x00000037aac07b35 in pthread_join () from /lib= 64/libpthread.so.0</div> <div>(gdb) thread 3</div><div>[Switching to thread 3 (Thread 0x470e8940 (LW= P 2008))]#0 =A00x00000037aa4cd722 in select () from /lib64/libc.so.6</div><= div>(gdb) bt</div><div>#0 =A00x00000037aa4cd722 in select () from /lib64/li= bc.so.6</div> <div>#1 =A00x000000000054ece5 in ?? ()</div><div>#2 =A00x000000000054aa15 i= n ?? ()</div><div>#3 =A00x0000000000557637 in ?? ()</div><div>#4 =A00x00000= 00000557c11 in ?? ()</div><div>#5 =A00x00000000004b2d93 in ?? ()</div><div>= #6 =A00x00000000004e9d7c in ?? ()</div> <div>#7 =A00x00000037aac0673d in start_thread () from /lib64/libpthread.so.= 0</div><div>#8 =A00x00000037aa4d44bd in clone () from /lib64/libc.so.6</div= ><div><br></div><div>It looks like it's waiting on select() on thread 3= which never get fired when I access it using ldapsearch command.=A0</div> <div><br></div><div>I ran strace on ldapsearch (on a client machine) and fo= llowing is what I see at the end of the log..</div><div><br></div><div>$ st= race ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b mds-vo-name=3DWT2,o=3Dg= rid "(&(objectClass=3DGlueLocation)(GlueLocationName=3DTIMESTAMP))= "</div> <div><br></div><div>....</div><div>write(1, "\n", 1</div><div>) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 1</div><div>write(3, "= 0l\2\1\2cg\4\26mds-vo-name=3DWT2,o=3Dgrid\n"..., 110) =3D 110</div><di= v>poll([{fd=3D3, events=3DPOLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1</div> <div><br></div><div>Not sure if this strace is useful or not.. but after th= is, ldapsearch never returned.</div><div><br></div><div>Thanks,</div><div>S= oichi</div><div class=3D"HOEnZb"><div class=3D"h5"><div><br></div><br><div = class=3D"gmail_quote"> On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <span dir=3D"ltr"><<= a href=3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah(a)zimbra.com</a>= ></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">--On Wednesday, November 09, 2011 2:01 PM +0= 000 <a href=3D"mailto:hayashis@indiana.edu" target=3D"_blank">hayashis@indi= ana.edu</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Soichi Hayashi<br> Version: 2.4.22<br> </blockquote> <br> OpenLDAP 2.4.22 is quite old, and had various known issues. =A0Please use a= current release (2.4.26). =A0This report will not be investigated unless y= ou can reproduce it with a current release of OpenLDAP. =A0You also fail to= note what BDB release you are using, and whether or not it has all the rel= evant patches applied to it. =A0If you have a broken policy of only using v= endor provided packages, then you will need to send a bug report to RedHat,= as it is their job to maintain their vendor packages.<br> <br> <br> Thanks!<span><font color=3D"#888888"><br> <br> --Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Sr. Member of Technical Staff<br> Zimbra, Inc<br> A Division of VMware, Inc.<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </font></span></blockquote></div><br> </div></div></blockquote></div><br></div></div> --0016364c7ac7fff89504b31ea350--

1 0

Re: (ITS#6962) Download down?
by h.b.furuseth＠usit.uio.no 30 Nov '11

30 Nov '11

h.b.furuseth(a)usit.uio.no writes: >demian.djrn(a)gmail.com writes: >> all mirrors are down, i can't download the program. > > The mirror list needs to be updated. These are down or obsolete: > > Costa Rica: No /openldap directory. Still missing in the directory listing at <http://mirrors.ucr.ac.cr/>. > Italy: Unknown host it.openldap.org. > Korea: No route to host ftp.holywar.net; TTL exceeded. > Portugal: Last update was in 2008. I notice these have been removed from the mirror list now. -- Hallvard

1 0

(ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by dieter＠dkluenter.de 30 Nov '11

30 Nov '11

Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) slapd crashes with segmentation fault on a slapo-dds refresh operation, if syncprov is enabled and configured (gdb) bt #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 #4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:915 #5 0x000000000048aedb in fe_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:237 #6 0x000000000048ab57 in do_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:177 #7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60, arg_v=0x7f01d8013530) at connection.c:1138 #8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60, argv=0x10) at connection.c:1274 #9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540) at tpool.c:685 #10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at pthread_create.c:297 #11 0x00007f01f3c1166d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { (gdb) frame 1 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 1793 slap_get_commit_csn( op, &maxcsn, &foundit ); (gdb) frame 2 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 505 rc = op->o_callback->sc_response( op, rs ); (gdb) frame 3 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 580 rc = slap_response_play( op, rs ); (gdb) -Dieter

1 0

(ITS#7101) test001 no longer supports back-ldif
by h.b.furuseth＠usit.uio.no 29 Nov '11

29 Nov '11

Full_Name: Hallvard B Furuseth Version: 2.4.28 OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard test001-slapadd now breaks with back-ldif, since it uses unordered slapadd which back-ldif does not support. Also 'rm -f $DBDIR1/*' should be 'rm -rf' for back-ldif.

1 0

Re: (ITS#7098) OpenLDAP crashes when changing OID value in schema definition in cn=config
by hyc＠symas.com 29 Nov '11

29 Nov '11

nick(a)eurobjects.com wrote: > Full_Name: Nikolaos Milas > Version: 2.4.26 (LTB RPM) > OS: CentOS 5.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.251.204.222) > > > We use the following schema (among others): Thanks for the report, this is now fixed in git master. > > DN: cn={5}postfix,cn=schema,cn=config > objectClass: olcSchemaConfig > cn: {5}postfix > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' > DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines > the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {2}( 1.3.6.1.4.1.25260.1.002 NAME 'mailacceptinguser' DESC > 'Defines if this user accepts mail' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {3}( 1.3.6.1.4.1.25260.1.003 NAME 'aliasInactive' DESC 'A > flag, for marking the alias as not in use' EQUALITY booleanMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) > olcObjectClasses: {0}( 1.3.6.1.4.1.25260.1.1.100 NAME 'virtualaccount' DESC > 'Holds mail info for a virtual account' STRUCTURAL MUST ( owner $ > mailacceptinggeneralid $ maildrop $ cn ) MAY ( description $ aliasInactive ) ) > olcObjectClasses: {1}( 1.3.6.1.4.1.25260.1.1.101 NAME 'maillist' DESC 'Virtual > account for holding mailing list info' STRUCTURAL MUST ( mailacceptinggeneralid > $ maildrop $ cn ) MAY ( owner $ description $ aliasInactive ) ) > olcObjectClasses: {2}( 1.3.6.1.4.1.25260.1.1.102 NAME 'mailAccount' DESC 'Email > account details' AUXILIARY MUST ( mailacceptinguser $ maildrop $ cn ) MAY ( > mailacceptinggeneralid $ aliasInactive ) ) > olcObjectClasses: {3}( 1.3.6.1.4.1.25260.1.1.105 NAME 'virtualbox' DESC 'Mailbox > for system use' STRUCTURAL MUST ( owner $ mail $ uid $ cn ) MAY description ) > > We run: > # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange1 > > where /root/work/schemachange1: > dn: cn={5}postfix,cn=schema,cn=config > changetype: modify > delete: olcAttributeTypes > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' > DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > - > add: olcAttributeTypes > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC > 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > This is successful: > [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange1 > ldap_initialize( ldap://localhost ) > Enter LDAP Password: > delete olcAttributeTypes: > {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines > an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > add olcAttributeTypes: > {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines > an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > modifying entry "cn={5}postfix,cn=schema,cn=config" > modify complete > > However, then we try to run: > # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange2 > > where /root/work/schemachange2: > dn: cn={5}postfix,cn=schema,cn=config > changetype: modify > delete: olcAttributeTypes > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines > the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > - > add: olcAttributeTypes > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the > address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > and this causes an OpenLDAP crash: > [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange2 > ldap_initialize( ldap://localhost ) > Enter LDAP Password: > delete olcAttributeTypes: > {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address > mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 ) > add olcAttributeTypes: > {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address > mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 ) > modifying entry "cn={5}postfix,cn=schema,cn=config" > > This hangs, and we interrupt with Ctrl-C. > > gdb reports: -- -- 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#7099) slapadd segfaults with back-mdb and slapo-dds
by hyc＠symas.com 29 Nov '11

29 Nov '11

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.38.5.243) > > > back-mdb tries to read entry databases prior to initialisation, which leeds to > segmatation fault slapo-dds was misbehaving, fixed now in master. Overlays that hook the db_open entry point are required to check for (slapMode & SLAP_TOOL_MODE) and exit as a no-op in that case. slapo-dds was not doing this. It caused slapcat to crash as well. This problem was triggered by using the dds-max_dynamocObjects setting, which makes slapo-dds fire off a search at startup to find entries to expire/delete. Of course this operation fails in slapcat anyway, since the database is opened read-only. > > output of slapadd -d-1 > [...] > 4ed4888e slapadd startup: initiated. > 4ed4888e backend_startup_one: starting "o=avci,c=de" > 4ed4888e mdb_db_open: "o=avci,c=de" > 4ed4888e mdb_db_open: database "o=avci,c=de": > dbenv_open(/home/dieter/openldap/var/ldap-dds). > 4ed4888e str2filter "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20111129072258Z))" > 4ed4888e begin get_filter > 4ed4888e AND > 4ed4888e begin get_filter_list > 4ed4888e begin get_filter > 4ed4888e EQUALITY > 4ed4888e end get_filter 0 > 4ed4888e begin get_filter > 4ed4888e LE > 4ed4888e end get_filter 0 > 4ed4888e end get_filter_list > 4ed4888e end get_filter 0 > Speicherzugriffsfehler > > the appropriate slapo-dds configuration: > [...] > overlay dds > dds-max-ttl 86400 > dds-min-ttl 0 > dds-default-ttl 3600 > dds-interval 1800 > dds-tolerance 60 > dds-max-dynamicObjects 100 > dds-state TRUE > [...] > > -Dieter > > -- -- 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#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 29 Nov '11

29 Nov '11

Pierangelo Masarati wrote: > Good point. I overlooked this in my original interpretation. I'll look into > this, time permitting. Thanks, p. Take your time. Nothing urgent. I'm just playing with it for interop testing (refresh operation and plugin classes in web2ldap). Ciao, Michael.

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by masarati＠aero.polimi.it 29 Nov '11

29 Nov '11

On 11/29/2011 02:34 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.15.82) > > > As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a > dynamicObject entry. But slapo-dds always returns the same value for entryTTL > (last refreshTTL). Another server implementation returns decreasing values for > entryTTL which would be IMO the correct behaviour. Good point. I overlooked this in my original interpretation. I'll look into this, time permitting. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 29 Nov '11

29 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.15.82) As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a dynamicObject entry. But slapo-dds always returns the same value for entryTTL (last refreshTTL). Another server implementation returns decreasing values for entryTTL which would be IMO the correct behaviour.

1 0

Re: (ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by hyc＠symas.com 29 Nov '11

29 Nov '11

paul(a)scom.ca wrote: > Full_Name: Paul Kudla > Version: 2.4.23& 2.4.28 > OS: Freebsd 8.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.171.154.78) > > > Simply put openldap will not configure > > How do i get it to find the sql.h file > > checking number of arguments of ctime_r... 2 > checking number of arguments of gethostbyname_r... 6 > checking number of arguments of gethostbyaddr_r... 8 > checking for openlog... yes > checking sql.h usability... no > checking sql.h presence... no > checking for sql.h... no > configure: error: could not locate SQL headers > > installed UnixODBC version unixODBC-2.3.1 > > > [00:28:54] root@ldap /usr/local/src/openldap-2.4.23 > # ll /usr/local/include/sql.h > -rw-r--r-- 1 root wheel 32305 Nov 28 11:58 /usr/local/include/sql.h > > [00:34:18] root@ldap /usr/local/src/openldap-2.4.23 > # > > this issue googles alot without any clear explanation. > > have no problem contributing to the cause - let me know how. Read the INSTALL document. Set the CPPFLAGS variable correctly. No bug here, closing this ITS. > > -- -- 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#7099) slapadd segfaults with back-mdb and slapo-dds
by dieter＠dkluenter.de 29 Nov '11

29 Nov '11

Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) back-mdb tries to read entry databases prior to initialisation, which leeds to segmatation fault output of slapadd -d-1 [...] 4ed4888e slapadd startup: initiated. 4ed4888e backend_startup_one: starting "o=avci,c=de" 4ed4888e mdb_db_open: "o=avci,c=de" 4ed4888e mdb_db_open: database "o=avci,c=de": dbenv_open(/home/dieter/openldap/var/ldap-dds). 4ed4888e str2filter "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20111129072258Z))" 4ed4888e begin get_filter 4ed4888e AND 4ed4888e begin get_filter_list 4ed4888e begin get_filter 4ed4888e EQUALITY 4ed4888e end get_filter 0 4ed4888e begin get_filter 4ed4888e LE 4ed4888e end get_filter 0 4ed4888e end get_filter_list 4ed4888e end get_filter 0 Speicherzugriffsfehler the appropriate slapo-dds configuration: [...] overlay dds dds-max-ttl 86400 dds-min-ttl 0 dds-default-ttl 3600 dds-interval 1800 dds-tolerance 60 dds-max-dynamicObjects 100 dds-state TRUE [...] -Dieter

1 0

(ITS#7098) OpenLDAP crashes when changing OID value in schema definition in cn=config
by nick＠eurobjects.com 29 Nov '11

29 Nov '11

Full_Name: Nikolaos Milas Version: 2.4.26 (LTB RPM) OS: CentOS 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.251.204.222) We use the following schema (among others): DN: cn={5}postfix,cn=schema,cn=config objectClass: olcSchemaConfig cn: {5}postfix olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {2}( 1.3.6.1.4.1.25260.1.002 NAME 'mailacceptinguser' DESC 'Defines if this user accepts mail' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {3}( 1.3.6.1.4.1.25260.1.003 NAME 'aliasInactive' DESC 'A flag, for marking the alias as not in use' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcObjectClasses: {0}( 1.3.6.1.4.1.25260.1.1.100 NAME 'virtualaccount' DESC 'Holds mail info for a virtual account' STRUCTURAL MUST ( owner $ mailacceptinggeneralid $ maildrop $ cn ) MAY ( description $ aliasInactive ) ) olcObjectClasses: {1}( 1.3.6.1.4.1.25260.1.1.101 NAME 'maillist' DESC 'Virtual account for holding mailing list info' STRUCTURAL MUST ( mailacceptinggeneralid $ maildrop $ cn ) MAY ( owner $ description $ aliasInactive ) ) olcObjectClasses: {2}( 1.3.6.1.4.1.25260.1.1.102 NAME 'mailAccount' DESC 'Email account details' AUXILIARY MUST ( mailacceptinguser $ maildrop $ cn ) MAY ( mailacceptinggeneralid $ aliasInactive ) ) olcObjectClasses: {3}( 1.3.6.1.4.1.25260.1.1.105 NAME 'virtualbox' DESC 'Mailbox for system use' STRUCTURAL MUST ( owner $ mail $ uid $ cn ) MAY description ) We run: # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/schemachange1 where /root/work/schemachange1: dn: cn={5}postfix,cn=schema,cn=config changetype: modify delete: olcAttributeTypes olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - add: olcAttributeTypes olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) This is successful: [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/schemachange1 ldap_initialize( ldap://localhost ) Enter LDAP Password: delete olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) add olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) modifying entry "cn={5}postfix,cn=schema,cn=config" modify complete However, then we try to run: # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/schemachange2 where /root/work/schemachange2: dn: cn={5}postfix,cn=schema,cn=config changetype: modify delete: olcAttributeTypes olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - add: olcAttributeTypes olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) and this causes an OpenLDAP crash: [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/schemachange2 ldap_initialize( ldap://localhost ) Enter LDAP Password: delete olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) add olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) modifying entry "cn={5}postfix,cn=schema,cn=config" This hangs, and we interrupt with Ctrl-C. gdb reports: ------------------------------------------- (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42e54940 (LWP 4089)] 0x000000000047ab0c in at_next (at=0x42e51418) at at.c:366 366 *at = LDAP_STAILQ_NEXT(*at,sat_next); (gdb) backtrace full #0 0x000000000047ab0c in at_next (at=0x42e51418) at at.c:366 __PRETTY_FUNCTION__ = "at_next" #1 0x000000000042c816 in config_generic (c=0x42e51610) at bconfig.c:1667 i = 0 at = 0x0 prev = 0x0 i = <value optimized out> __PRETTY_FUNCTION__ = "config_generic" #2 0x00000000004317eb in config_set_vals (Conf=0x81e1e0, c=0x42e51610) at config.c:334 rc = <value optimized out> arg_type = 0 ptr = <value optimized out> #3 0x00000000004355fd in config_parse_add (ct=0x81e1e0, c=0x42e51610, valx=<value optimized out>) at config.c:678 rc = <value optimized out> #4 0x0000000000427fe9 in config_modify_add (ct=0x81e1e0, ca=0x42e51610, ad=<value optimized out>, i=1) at bconfig.c:5420 rc = <value optimized out> #5 0x000000000042a486 in config_modify_internal (op=0x13086920, rs=0x42e53c20) at bconfig.c:5689 a = <value optimized out> colst = 0x131f7f80 dels = <value optimized out> ml = <value optimized out> e = 0x12955548 rc = <value optimized out> oc_at = <value optimized out> s = 0x12d56d48 ct = 0x81e1e0 i = 2 nocs = 2 #6 config_back_modify (op=0x13086920, rs=0x42e53c20) at bconfig.c:5802 cfb = 0x82a640 ce = <value optimized out> last = <value optimized out> ml = <value optimized out> ca = {argc = 19, argv = 0x131f5120, argv_size = 513, line = 0x132030b3 "( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )", tline = 0x13203ce0 "(", fname = 0x587799 "slapd", lineno = 0, log = "olcAttributeTypes: value #1", '\000' <repeats 4096 times>, reply = {err = 0, msg = "\000lcAttributeTypes: Duplicate attributeType: \"1.3.6.1.4.1.25260.1.0\"", '\000' <repeats 188 times>}, depth = 0, valx = 1, values = { v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_ber_t = 0, v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 0, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x0}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 25, ca_op = 0x13086920, be = 0x82c1a0, bi = 0x0, ca_entry = 0x12955548, ca_private = 0x129aeaf0, cleanup = 0, table = Cft_Schema} ---Type <return> to continue, or q <return> to quit--- rdn = {bv_len = 2, bv_val = 0x129dac10 "cn={5}postfix,cn=schema,cn=config"} rad = 0x12903de0 do_pause = 1 #7 0x0000000000452a07 in fe_op_modify (op=0x13086920, rs=0x42e53c20) at modify.c:303 repl_user = <value optimized out> bd = 0x82c1a0 textbuf = "@\270\220\022", '\000' <repeats 12 times>, "@\270\220\022\000\000\000\000\316YE\000\000\000\000\000\260\u01dd\022\000\000\000\000\260[\217\022\000\000\000\000\002\000\000\000\000\000\000\000\262\u01dd\022\000\000\000\000\001\000\000\000\000\000\000\000\261\u01dd\022\000\000\000\000\003\000\000\000\000\000\000\000\260\u01dd\022\000\000\000\000\260\000\000\000\000\000\000\000\060~\037\023", '\000' <repeats 20 times>, " u\037\023", '\000' <repeats 12 times>"\360, \271\220\022\000\000\000\000 ", '\000' <repeats 15 times>, "\023$E\000\000\000\000\000\300\312\005\023\000\000\000\000\000\001\000\000\000\000\000\000\320:\345B\000\000\000\000@<\345B\000\000\000\000 i\b\023\000\000\000\000\001\000\000\000\000\000\000\000Xi\b\023\000\000\000\000Hi\b\023\000\000\000\000\300\312\005\023\000\000\000\000\311"... #8 0x0000000000453172 in do_modify (op=0x13086920, rs=0x42e53c20) at modify.c:177 dn = {bv_len = 33, bv_val = 0x13202669 "cn={5}postfix,cn=schema,cn=config"} textbuf = "\327k\b\023", '\000' <repeats 52 times>"\273, (\207?9\000\000\000\000\000\037\023", '\000' <repeats 16 times>, "\001\000\000\000\260\200\037\023", '\000' <repeats 12 times>"\211, \331\000@9", '\000' <repeats 11 times>"\365, \377\377\377\377\377\377\377oy\037\023\000\000\000\000\b\000\000\000\000\000\000\000H:\265?9\000\000\000\251oW", '\000' <repeats 13 times>"\361, \001\000\000\000\000\000\000\333\001\000\000\000\000\000\000@\000\000\000\000\000\000\000H:\265?9\000\000\000\020<\345B", '\000' <repeats 12 times>, "!\000\000\000\000\000\000\000\023\000\000\000\000\000\000\000v\277H\000\000\000\000\000\020o\030\023\000\000\000\000\200g\270\022\000\000\000" tmp = 0x0 #9 0x000000000043b965 in connection_operation (ctx=0x42e53d70, arg_v=<value optimized out>) at connection.c:1138 rc = <value optimized out> cancel = <value optimized out> op = 0x13086920 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x12b86780 memctx = 0x1305cac0 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043bf3f in connection_read_thread (ctx=0x42e53d70, argv=<value optimized out>) at connection.c:1274 s = 31 #11 0x000000000054d68c in ldap_int_thread_pool_wrapper (xpool=0x12907380) at tpool.c:685 task = 0x12e1b240 work_list = <value optimized out> ctx = {ltu_id = 1122322752, ltu_key = {{ltk_key = 0x43a8d0, ltk_data = 0x1305c9b0, ltk_free = 0x43a9a0 <conn_counter_destroy>}, {ltk_key = 0x48c440, ltk_data = 0x1305cac0, ltk_free = 0x48c320 <slap_sl_mem_destroy>}, {ltk_key = 0x12b25e30, ltk_data = 0x1305cce0, ltk_free = 0x4e0010 <bdb_reader_free>}, {ltk_key = 0x44e220, ltk_data = 0x0, ltk_free = 0x44e000 <slap_op_q_destroy>}, {ltk_key = 0x0, ---Type <return> to continue, or q <return> to quit--- ltk_data = 0x131f5120, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = <value optimized out> keyslot = 976 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x000000394000673d in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x000000393f8d44bd in clone () from /lib64/libc.so.6 No symbol table info available. -------------------------------------------

1 0

Re: (ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by quanah＠zimbra.com 28 Nov '11

28 Nov '11

--On Tuesday, November 29, 2011 12:35 AM +0000 paul(a)scom.ca wrote: > this issue googles alot without any clear explanation. Read your config.log file that is generated to see why it doesn't like the sql.h file. --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

(ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by paul＠scom.ca 28 Nov '11

28 Nov '11

Full_Name: Paul Kudla Version: 2.4.23 & 2.4.28 OS: Freebsd 8.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.171.154.78) Simply put openldap will not configure How do i get it to find the sql.h file checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking for openlog... yes checking sql.h usability... no checking sql.h presence... no checking for sql.h... no configure: error: could not locate SQL headers installed UnixODBC version unixODBC-2.3.1 [00:28:54] root@ldap /usr/local/src/openldap-2.4.23 # ll /usr/local/include/sql.h -rw-r--r-- 1 root wheel 32305 Nov 28 11:58 /usr/local/include/sql.h [00:34:18] root@ldap /usr/local/src/openldap-2.4.23 # this issue googles alot without any clear explanation. have no problem contributing to the cause - let me know how.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by quanah＠zimbra.com 25 Nov '11

25 Nov '11

--On Friday, November 25, 2011 10:15 AM +0000 michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> hyc(a)symas.com wrote: >>>>> You don't have to teach me anything in the testing field. >>>> >>>> Clearly I *do* need to, based on the completely useless content-free >>>> emails you've posted so far. >>> >>> Maybe then you should learn to read. The cause was already mentioned in >>> a message before. I did not expect that you are not able to generate >>> test data not in tree order yourself. >> >> You're assuming I've been sitting on my ass waiting for your followups. > > Well, and you assume that I have endless spare times tracking down bugs. I > don't. Especially at the current moment. Hi Michael, No one assumed any such thing. All that was every requested from you was information that only you had. The information on how exactly to reproduce this issue that you found, because no one else was able to reproduce with the information you had provided. Now that you finally provided the requisite information, someone *else* was able to track down and fix the actual bug. It is very unfortunate that you find requests for information to be so tedious. Having to continually request basic information from you is also quite tedious. If you could just provide the requisite information up front, then entire situations like this could be entirely avoided. --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

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 25 Nov '11

25 Nov '11

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> hyc(a)symas.com wrote: >>>> You don't have to teach me anything in the testing field. >>> >>> Clearly I *do* need to, based on the completely useless content-free emails >>> you've posted so far. >> >> Maybe then you should learn to read. The cause was already mentioned in a >> message before. I did not expect that you are not able to generate test data >> not in tree order yourself. > > You're assuming I've been sitting on my ass waiting for your followups. Well, and you assume that I have endless spare times tracking down bugs. I don't. Especially at the current moment. Ciao, Michael.

1 0

Re: (ITS#7096) Make depend error on redhat 6 with OpenLDAP 2.3.43
by h.b.furuseth＠usit.uio.no 25 Nov '11

25 Nov '11

llx88217(a)126.com writes: > Version: OpenLDAP 2.3.43 > In file included from slurp.h:53, > from ri.c:45: > ../../include/ldap_pvt_thread.h:64:7: error: missing binary operator before > token "(" OpenLDAP 2.3 is not under development, please check bugs against the latest release before reporting. This one is ITS#5824, fixed in by commit debfd2d796fd47481e077dff97fb38b21b030af7 in the Git repository. -- Hallvard

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com 25 Nov '11

25 Nov '11

michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >>> You don't have to teach me anything in the testing field. >> >> Clearly I *do* need to, based on the completely useless content-free emails >> you've posted so far. > > Maybe then you should learn to read. The cause was already mentioned in a > message before. I did not expect that you are not able to generate test data > not in tree order yourself. You're assuming I've been sitting on my ass waiting for your followups. I fed a number of unordered LDIFs into slapadd and the problem never surfaced. -- -- 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#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 25 Nov '11

25 Nov '11

hyc(a)symas.com wrote: >> You don't have to teach me anything in the testing field. > > Clearly I *do* need to, based on the completely useless content-free emails > you've posted so far. Maybe then you should learn to read. The cause was already mentioned in a message before. I did not expect that you are not able to generate test data not in tree order yourself. Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by masarati＠aero.polimi.it 25 Nov '11

25 Nov '11

On 11/25/2011 09:31 AM, hyc(a)symas.com wrote: > this and the typos in back-sql On a related note, I merely found those typos by building back-sql statically, as it wouldn't allow slapd to start. I haven't tested its functionality yet. Sorry for this, too busy. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com 25 Nov '11

25 Nov '11

Michael Ströder wrote: > Howard Chu wrote: >> One crucial step in isolating the problem would be to determine if the error >> actually occurs during slapadd or slapcat. > > I revise my statement that data looks ok via LDAP. Messing up the data seems > to happen during slapadd if the LDIF is not in tree order (as already > suspected in a former posting which was not read I guess). > > Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is > in tree order while in data1.ldif subordinate entries come before their > superior entries (which is what slapcat sometimes produce). Interestingly enough, my results differed from yours. Also the results differed depending on whether I slapadd'd the bare LDIF, or an LDIF with all operational attributes included. But this is now fixed in git master. Given this and the typos in back-sql it appears we should scratch 2.4.27 and push a new release. > These entries > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Groups > > dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 > > get mixed into that: > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > hasSubordinates: TRUE > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 -- -- 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#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com 24 Nov '11

24 Nov '11

Michael Ströder wrote: > Howard Chu wrote: >> One crucial step in isolating the problem would be to determine if the error >> actually occurs during slapadd or slapcat. > > I revise my statement that data looks ok via LDAP. Messing up the data seems > to happen during slapadd if the LDIF is not in tree order (as already > suspected in a former posting which was not read I guess). > > Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is > in tree order while in data1.ldif subordinate entries come before their > superior entries (which is what slapcat sometimes produce). > > These entries > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Groups > > dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 > > get mixed into that: > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > hasSubordinates: TRUE > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 > >> Bug-hunting takes systematic, methodical testing. You can't just go changing >> revisions willy-nilly. > > You don't have to teach me anything in the testing field. Clearly I *do* need to, based on the completely useless content-free emails you've posted so far. > Again: Your arrogant attitude does not help at all. It solely frustrates > people who are trying to help even if they don't have much spare time left. The only person copping an attitude here is you. I'm simply asking you for information that would help point to the problem; you're choosing to ignore my questions until I make a point of re-asking. Thank you for the test data. -- -- 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#7096) Make depend error on redhat 6 with OpenLDAP 2.3.43
by llx88217＠126.com 24 Nov '11

24 Nov '11

Full_Name: llx Version: OpenLDAP 2.3.43 OS: redhat 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.37.47.42) configuration is successfully, and run "make depend" this error prompt: In file included from slurp.h:53, from ri.c:45: ../../include/ldap_pvt_thread.h:64:7: error: missing binary operator before token "("

1 0

(ITS#7095) Make depend error on redhat 6 with OpenLDAP 2.3.43
by llx88217＠126.com 24 Nov '11

24 Nov '11

Full_Name: llx Version: OpenLDAP 2.3.43 OS: redhat 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.37.47.42) configuration is successfully, and run "make depend" this error prompt: In file included from slurp.h:53, from ri.c:45: ../../include/ldap_pvt_thread.h:64:7: error: missing binary operator before token "("

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 24 Nov '11

24 Nov '11

This is a multi-part message in MIME format. --------------000109050706000504040005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Howard Chu wrote: > One crucial step in isolating the problem would be to determine if the error > actually occurs during slapadd or slapcat. I revise my statement that data looks ok via LDAP. Messing up the data seems to happen during slapadd if the LDIF is not in tree order (as already suspected in a former posting which was not read I guess). Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is in tree order while in data1.ldif subordinate entries come before their superior entries (which is what slapcat sometimes produce). These entries dn: ou=Groups,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Groups dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local cn: slapd-1 objectClass: applicationProcess objectClass: simpleSecurityObject userPassword: pw_slapd1 get mixed into that: dn: ou=Groups,ou=schulung,dc=stroeder,dc=local cn: slapd-1 hasSubordinates: TRUE objectClass: applicationProcess objectClass: simpleSecurityObject userPassword: pw_slapd1 > Bug-hunting takes systematic, methodical testing. You can't just go changing > revisions willy-nilly. You don't have to teach me anything in the testing field. Again: Your arrogant attitude does not help at all. It solely frustrates people who are trying to help even if they don't have much spare time left. Get real. How many people do you think are really testing such a wide range of OpenLDAP functionality like me? How many people you expect to thoroughly test back-mdb within the next six months even if released in 2.4.27? How many people do you expect to really dive into such problems? Most people will just use another backend or another LDAP server. Ciao, Michael. --------------000109050706000504040005 Content-Type: application/x-gzip; name="openldap-testbed-its7090.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="openldap-testbed-its7090.tar.gz" H4sICIz/zU4CA29wZW5sZGFwLXRlc3RiZWQtaXRzNzA5MC50YXIA7RxrU9tIkq/Wr5gzuSvI MrY0elPl2mKBJOwR4DDZy2ZzlRppRrYuep1GWiCP/349ku2YsAQwNsrdaqggeaTpnn53D+2k GU8iRjNccFF4nOGwELbqqv215Q0Vhq2q9dUyqqtm1NfJWNM0y9J12zYsaw0e2pa+hsy1Rxil KGiO0Foc+mPKo2+8x3Ox9n830pvkH4siTznjeS9iYfBg+VsTef+R/IlBpPwJMUybaATkb1ua tYbUVv4rHyzZRmXIBjNxb6Xl4JWkVd4If1xGZTLaYv5g9gLcR6lPIwXWbaPZQiX1/s39Yjei QmyjMOHFcT46AUBpoviA5WXNYDScvi9gcvZBsvcEVp6nOQCVyii4n/NCUdba0YT9M1pQ7eG2 P7P/m/0/sWxz6v8twzLB/i2L2K39P5b932roVyw7zUc0CT/QIkwTGr1KwkJJy200haAoE5An aRT6Ib+DH7kL+Cm0GXgR0SzFWSbnL7eWj2/ii75CXLnKWlPu7SjrZVexU99Py6S4OinCOIv4 kPtlHhaXx9WjbzjICUPuuJe7EF+BqgH7ScVphjUJengpCh6/T5OCJ7ejkl5/svgrqrMMmFph PclTnwtxbwZk5+8q0NpX2yQP2SZZ2TbJTEz329tdpDUPcYbmeZ6W2ZLUoYY1Y/QOi8OkAn1X JJLDM4Oql19FPJKAjoMjGoOhxTz2eL6orU13ecor4d1rn1PMD1H6azAW1Mjp/r/BKGWV8V+G xQJXJPTEeKX1n6XP6j+T2FX+b5pqG/8fY6z/pe+FSV+MFeX4ZP/ocG/n5N3J6f6zg9eDbj/N iv5MQU73idFVDo93dw53j4+eHTyHF8ZpzPsTzvVBwbP+TfrUVZR1hDBDfpoE4WgLuF6I+jfZ on60RfOR2Cpy6vMtcZn46K2iPPn41ZY+96PQ4xfc71d6Ce/cDPILuIz673kh6rfHqCu3t93v q73qZ5uotobkXAiTfyXPJE1wmVAFd5IuuNxEGTyqDV2kEk+3xpNMQsrkpXqynCYB9ccAPfk4 x8/PNVU9SY7SeP4/9VA4hDAQ0gjXxUDPo++XW/9rmq2Rmf2bNvgJQqAqaO3/fzP/h+WlX5Q5 jY5vWcaTIr989epgbxuZRFcN6jmYebaDDdOzMA14gE3NtlQ94KpvcwXSXVqkuZDRr04PWJhT Ft8hoMqV/CyEqFnQONtGBNRO04ihOqplkjf1VnaHR18/6RFTMx33zXqtq+uTfzCUOAVzCPki 26mWXn5jOyuuoRYSkaebKg1Uim3CPGxAkMYUSnfsceJ5nmk5hq82IiJd6ojTlIgevQ6tjG0e 6WLiNAgllHEHU1uj2LADB7uqE2DH1AmxWeBrtCFxOoatG02Jc+lV9ELCcbjlOk7gYdvQVGxQ 1cOOTQkOgkCngW4xkFQjwjEsoqlqI8L5To5ethF7/ssH9uIo+lX/OWI7g8FNIp4imJOrTTSu ux44TebbYHSahz3iWNgnhLuO5hsBNRqRq6m7rqU2ZXQrPhNZyAQDyj1mUw3rKtOxASkp9igh WFUNnRHuUdWhjYjK0mxbJY2IajmHgWSVB4OwyRcQvMjF2H/+j4sbTfM6njnRWx61mWuCbbqu jw3XIphybmPuqnZgOwELVK8Z0ZtQNmnNiv77OmC9Iu7LxcRNuW/brqphn/sWNixmYk+HYGsS zTRVz4Dao5lga6uW65KmnPIKTpAXcsS2Y1IbYiPmasBkaUixo9kq5EK+5ZrAIth7M+JxDNdw mrLG5ZzCy7kVH8jfIPQrGObEzXSDM0cHayQW1CXc0bEbOCYONIuCIri2x5uJu6B0rmo1Je4/ wZ8z7qkokJ1ZDg84NhymQZRmPkRpSNW4ZgVWoAdcs7VGFMXVbEd9/AJ2Bf0f5PH7P6rzX9n/ Ybbnv23/x3fX/7GyPovvuLHkMToW2jaTJbeZtP0fbf/Hw+K/t7SvANyn/9+0Zf+/qZuk7f9v 9u//s16EVed/lqrP8j/TUHWZ/9l62//zOP0/yjoaco6+iHvD3ERBmiPGCxpGAqXJpMEGKjMZ GFCayYvowcqzcShQEEawfpyWEUNHx2fI4wgcPXyACopRL+Lwpuz+GfpjHkNVgWgpAHqOjkH3 ZHcP3gvBB4ZeKeEqYeJHJeOdzvX2oz4v/NmM7FABeH0/zXmvvl9grQiThVfL7zhAyMyq7zhM gQChezyAR2gUpR6N0M7uoUBFilgoJDOA8oCWUVFxR6ZpEO97ipKFTPIRcN+9p6qfl8nETmG5 IlueKhiLgZDLFVlnlhHPaDH+Iy5M26+ms0Dtgwcw7DAFVrDLhMKekSfbtRKG6p2I7WWgqGFF gKYjwb+LmdeL6JJ2X/eiTaSd0RxicyHz+iUAV9ajdBTx33kkbTCpbA1go6rJTSnGUocEshRB RYQhbc/yNBNI5lciGKjKejUPL0UxGp6dHu/v7Z/2do9fLonwU34OGSlHw53hIQoZTwrIT6Wq 7x2czT4vhw1o//XZ/unRziFKfwf6ITW9QHtpTMME1W13Ci2L8QegdcQvMgWh7ihkSSlTscHG byp2//XD5tu3P5TXJrcgT8s4z6HiYfKeXwB/IfmV9xJkV8KadAz2b0vcfvxRlN6PG3/bmMvZ Bhn4mIuduhzb3IAdHNU7eEI2N0ZfPmmbm1WP5E4UoZj7YwGGIDiT7leGnoM9MAhRoEKeAKHz sBiDqtUZ9TXSZeK88RvFH3bwmy9UbrBwBMaPY2Z+8kFJq5ukiOJPWQR8/ASaBr9HQtAs3HwI +RI9kNNdkpY9rw2r9pTSDABttCStOk3TAu0N96EIi6L0HNHkMgXPDSpceWeofyZopf9OelIi g24XeZfoafWGjGqlV3t+tAHUb1angvcGCdyewZkHvwQyp2zco1B6eDR5j4ISLEhWEInIaRnf fvyzrE0o8kxREtwB/6soogyC8KLT6d62ga7CwhzsKc0v7xXbAEkOAmYJ4LjHWWu3WpWddzof h8MXO58LUsZj8tIL7KNfDn/65/hnd4+/eJ2fx7+eFHo+FAqYeQERptOB7AU4fZAwfoH/Pp8z QWoBc2jOLXQ6/D/AgvADj8I4LDpYW5qwr8r9Jw6sGxewlWTEExTGTYj+ihZ80X9aFLkYzB9l gLtBUv+rOreyi3ufNnTR4PziOpwFzgO6tRFOQAkeBfOgn6LBhXLVmMEBFDkHe75dxZZBZxV9 V0DpU3QELktpv3r7Z/7+rywMGjj/qf//B9O07Pb8px3taEc72tGOdrSjHe1oRzuWOf4LOFpf UgBQAAA= --------------000109050706000504040005--

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 23 Nov '11

23 Nov '11

Howard Chu wrote: > This would imply that the error is isolated to slapcat. Since you claim the > problem did not occur in an earlier revision, Well, that's not sure anymore since I could simply not have observed it before because the slapcat'ed LDIF was always in tree order. Not sure. As said. The difference in data1 (messes up) and data2 (works) is that data2 is in tree-order. Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com 23 Nov '11

23 Nov '11

michael(a)stroeder.com wrote: > I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with > *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... You still haven't answered this first question: > If you revert the code to an older commit, does it produce the same result? Since you haven't provided steps to reproduce the error, all we can do is rely on you to triage the problem. One crucial step in isolating the problem would be to determine if the error actually occurs during slapadd or slapcat. If you knew that the problem did not occur in a previous revision, then by slapadd'ing the LDIF with that known good revision, and then slapcat'ing with both the known revision and the later revision, would reveal whether the error is actually stored in the database, or whether it's a bug in how slapcat reads out the database. > Also LDAP access to the entries mixed in slapcat output is completely ok. This would imply that the error is isolated to slapcat. Since you claim the problem did not occur in an earlier revision, it might be easy to run thru the commit logs and find the cause of the problem. But without your confirmation of these guesses, we still have nothing to go on. Since we have nothing to go on, and therefore could take no steps to address this issue, it should come as no surprise to you that testing an even later revision than the one you originally reported against still shows the bug occurring. Bug-hunting takes systematic, methodical testing. You can't just go changing revisions willy-nilly. -- -- 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#7090) back-mdb produces wrong slapcat output
by quanah＠zimbra.com 23 Nov '11

23 Nov '11

--On Wednesday, November 23, 2011 11:16 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > Quanah Gibson-Mount wrote: >> --On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder >> <michael(a)stroeder.com> wrote: >> >>> No way. >> >> Then it is unlikely this will get fixed until you can provide a dummy >> data set that triggers the issue. > > As said I'll try to provide test data. But what strikes me is that your > statement sounds like I'm the only one who's interested in getting this > fixed. I never said nor implied any such thing. I simply pointed out that until you can provide test data that reproduces the problem, it is unlikely this bug will be fixed. Not for lack of willingness for it to be fixed, but because *you* are the only person seeing it, and *you* are the only person with a data set that causes the issue. Thus it is up to *you* to provide such data to the project, or describe it in such a way that someone in the project can reproduce it. Again, this is why I keep an NDA with Symas. It allows me to provide them data necessary for such reproductions. I've managed to hit all sorts of odd ball edge cases over the years that no one else could produce. What I didn't do is expect the project to be able to figure out with a bare minimum of detail what was going wrong. --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

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 23 Nov '11

23 Nov '11

Quanah Gibson-Mount wrote: > --On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > >> No way. > > Then it is unlikely this will get fixed until you can provide a dummy data set > that triggers the issue. As said I'll try to provide test data. But what strikes me is that your statement sounds like I'm the only one who's interested in getting this fixed. Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by quanah＠zimbra.com 23 Nov '11

23 Nov '11

--On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > No way. Then it is unlikely this will get fixed until you can provide a dummy data set that triggers the issue. Personally this is why I keep an NDA with Symas. --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

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 23 Nov '11

23 Nov '11

Quanah Gibson-Mount wrote: > --On Wednesday, November 23, 2011 9:48 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > >>> Can you provide these two data sets? >> >> As said in my first posting: This is private address book data. So nope. > > Can you provide it outside of the ITS system in a private manner to Howard? No way. Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by quanah＠zimbra.com 23 Nov '11

23 Nov '11

--On Wednesday, November 23, 2011 9:48 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: >> Can you provide these two data sets? > > As said in my first posting: This is private address book data. So nope. Can you provide it outside of the ITS system in a private manner to Howard? That is going to be the easiest way to get this resolved. --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

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 23 Nov '11

23 Nov '11

Quanah Gibson-Mount wrote: > --On Wednesday, November 23, 2011 8:18 PM +0000 michael(a)stroeder.com wrote: > >> I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with >> *nearly* the same data (data2) and the bug does not seem to happen again. >> Hmm... >> >> But with the old last good backup LDIF (data1) the bug happens again. > > I'm trying to comprehend what you're saying here... So is this correct? > > You have two data sets, data1 and data2. You get can reproduce the issue > using dataset data1, and you have no issues using dataset data2. Yes. And the obvious difference is the order of superior and subordinate entries which get mixed with other superior entries as described in my last posting. > Can you provide these two data sets? As said in my first posting: This is private address book data. So nope. Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by quanah＠zimbra.com 23 Nov '11

23 Nov '11

--On Wednesday, November 23, 2011 8:18 PM +0000 michael(a)stroeder.com wrote: > I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with > *nearly* the same data (data2) and the bug does not seem to happen again. > Hmm... > > But with the old last good backup LDIF (data1) the bug happens again. I'm trying to comprehend what you're saying here... So is this correct? You have two data sets, data1 and data2. You get can reproduce the issue using dataset data1, and you have no issues using dataset data2. Can you provide these two data sets? --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

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 23 Nov '11

23 Nov '11

I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... But with the old last good backup LDIF (data1) the bug happens again. I noticed that in data1 the entries which were mixed up later in slapcat output were in the order (example data) dn: cn=John Doe,o=Company dn: o=Company whereas later in data2 there was exported: dn: o=Company dn: cn=John Doe,o=Company I will try to provide a test LDIF if necessary but I'm in a hurry now. Please note that I'm talking about LDIF files which were all generated by slapcat and therefore are assumed to be valid input for restoring with slapadd. Also LDAP access to the entries mixed in slapcat output is completely ok. Ciao, Michael.

1 0

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by h.b.furuseth＠usit.uio.no 23 Nov '11

23 Nov '11

draft-behera-ldap-password-policy: - Says this should be supported via attribute SubtreeSpecification in the pwdPolicy subentry. I think OpenLDAP does not support this attribute, it accepts it but does not do anything. - Leaves room to make the requested behavior configurable in cn=config, or for that matter make it the default: The draft mostly says ppolicy applies to "user entries". Browsing it quicly, I don't see it define what that means, nor consider the existence of non-user entries. A config attribute could define that. I don't know if anyone will bother to implement this (patches welcome) but I don't see a formal problem with whether it could/should be done. -- Hallvard

1 0

Re: (ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by michael＠stroeder.com 23 Nov '11

23 Nov '11

It seems to work with git master fadb48a723756ac0111731f7650f7da1a23c12a3 So you can close this ITS. If any issue is in the RE24 I will file new ITS. Ciao, Michael.

1 0

Re: (ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by quanah＠zimbra.com 22 Nov '11

22 Nov '11

--On Monday, November 21, 2011 10:35 AM +0000 michael(a)stroeder.com wrote: > Full_Name: > Version: git master 9845c030ab1b569d9943c885cd6db876c535758d > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.128.253.198) > > > test000 works with bdb and mdb but not hdb > > $ ./run -b hdb test000 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test000-rootdse for hdb... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: line 66: kill: (5333) - No such process > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>>> Test failed > So what do you see in the generated log file? --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

(ITS#7094) slapd ciphersuite TLS_RSA_3DES_EDE_CBC_SHA1 not usable with GnuTLS
by quanah＠OpenLDAP.org 22 Nov '11

22 Nov '11

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) As reported in the debian bug tracker at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648056 If slapd is set to use the TLS_RSA_3DES_EDE_CBC_SHA1 cipher suite, it fails to start up, even though gnuTLS reports it as supported.

1 0

ITS#7059 UTF8StringNormalize issue
by hyc＠symas.com 22 Nov '11

22 Nov '11

As Ralf Haferkamp noted, the real bug was introduced with postalAddressNormalize which was released in 2.4.10, so nothing earlier than that is affected. Also, this bug had no effect on most Linux installs because glibc malloc always allocates at least 16 bytes. The bug was only detected because I was running valgrind to check for leaks; there was no known crash related to this bug. -- -- 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#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by michael＠stroeder.com 21 Nov '11

21 Nov '11

Noël Köthe wrote: >> noel debian.org wrote: >>> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute >>> to DN's which don't have a userPassword attribute and cannot get >>> one. > >> Hmm, this is somewhat debatable. I'm not sure. But I also don't see any >> harm in the current behaviour. It's surely the client configuration >> which needs to > > :( > >> be fixed. > > In my case the behaviour is pollution my data with unneeded and unwanted > data in ous which I want to prevent. I don't have control over the > clients so sadly I cannot fix the source of the problem (the requests). > The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there > is a userPassword: attribute ( when using pwdAttribute: userPassword). Is > there any chance that the behaviour is accepted as a problem? Maybe you got me wrong: I don't have a really strong opinion on that (nor am I the one who decides on this). The question is: What should the pwdFailureTime exactly mean? I understand what's your personal opinion on that and I somewhat support it. But there might be corner-cases where the current behaviour makes sense. Ciao, Michael.

1 0

(ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by michael＠stroeder.com 21 Nov '11

21 Nov '11

Full_Name: Version: git master 9845c030ab1b569d9943c885cd6db876c535758d OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.253.198) test000 works with bdb and mdb but not hdb $ ./run -b hdb test000 Cleaning up test run directory leftover from previous run. Running ./scripts/test000-rootdse for hdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: line 66: kill: (5333) - No such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed

1 0

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by noel＠debian.org 21 Nov '11

21 Nov '11

--=-OBICNroNT6O1Nc+JWJc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Michael, >noel debian.org wrote: >> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to D= N's >> which don't have a userPassword attribute and cannot get one. > Hmm, this is somewhat debatable. I'm not sure. But I also don't see any h= arm > in the current behaviour. It's surely the client configuration which need= s to :( > be fixed. In my case the behaviour is pollution my data with unneeded and unwanted data in ous which I want to prevent. I don't have control over the clients so sadly I cannot fix the source of the problem (the requests). The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there is a userPassword: attribute ( when using pwdAttribute: userPassword). Is there any chance that the behaviour is accepted as a problem? --=20 No=C3=ABl K=C3=B6the <noel debian.org> Debian GNU/Linux, www.debian.org --=-OBICNroNT6O1Nc+JWJc8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk7KFRUACgkQ9/DnDzB9Vu2a8QCfdLgeqXZE6hgK5wy2Tk+bZCAZ vMYAnA9UHtRGoukZcJ/KtvxHDZECFP6d =91QP -----END PGP SIGNATURE----- --=-OBICNroNT6O1Nc+JWJc8--

1 0

Re: (ITS#7092) Please re-open #6548 - Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com 19 Nov '11

19 Nov '11

online(a)mark.ziesemer.com wrote: > Full_Name: Mark A. Ziesemer > Version: 2.4.2 2.4.2 would have been an early alpha or beta release. Bug reports filed against such a release at this point are worthless. > OS: Ubuntu Linux 11.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.156.254.191) > Please re-open http://www.openldap.org/its/index.cgi/Incoming?id=6548 . This is > listed as a confirmed issue for Ubuntu at > https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/594840 , affecting at > least 12 users - and there is no evidence to show that this is an issue specific > to Ubuntu. > > Please also refer to and at least acknowledge the unaddressed comments left in > response to #6548, which includes a report from a Debian user as well. > To clarify, this appears to be an issue with the libldap client library provided > by OpenLDAP itself (2.4.25), and not the slapd daemon. Some comments simply aren't worth addressing. Inserting sleeps is never the correct solution. A new patch for slapd is in git master, please test. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs