- openldap-bugs - openldap.org

(ITS#5384) access control: "attrs" field handled incorrectly in URI form of sets
by ando＠sys-net.it 17 Feb '08

17 Feb '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando There seems to be an error in (optional) attribute handling in URIs used in sets. Background: in OpenLDAP 2.3 sets were enhanced by allowing to dereference URIs by performing the corresponding internal search; the syntax was: [<uri>]/<attr> returning the value of <attr> after searching for <uri>; if optional attrs were specified in the URI, their values could be added to the result set; so [ldap:///o=suffix?cn,sn?sub]/uid would have collected the "cn", the "sn" and the "uid" of entries matching the URI. Well, this is broken: it seems to only work as expected when no optional attrs are given. A fix for HEAD is about to come. p.

1 0

Re: (ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com 17 Feb '08

17 Feb '08

Howard Chu wrote: > > In RE24 the config schema are only exposed for DEVEL builds. Why that? Especially why was it changed compared to RE23? Ciao, Michael.

1 0

Re: (ITS#5383) olc* not present in subschema subentry
by hyc＠symas.com 17 Feb '08

17 Feb '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: OpenSUSE Linux 10.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.120.38) > > > IMO a show-stopper for 2.4.8! > > The schema elements for back-config (olc*) are not present/readable in the > subschema subentry. They are present with the very same config in RE23. Note > that the schema elements have to be retrieved by schema-aware clients for doing > the right thing... In RE24 the config schema are only exposed for DEVEL builds. This is not a regression from 2.4.7 or any other 2.4 releases, so this is certainly not a show-stopper. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com 17 Feb '08

17 Feb '08

Full_Name: Michael Ströder Version: RE24 OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.120.38) IMO a show-stopper for 2.4.8! The schema elements for back-config (olc*) are not present/readable in the subschema subentry. They are present with the very same config in RE23. Note that the schema elements have to be retrieved by schema-aware clients for doing the right thing...

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by hyc＠symas.com 16 Feb '08

16 Feb '08

Howard Chu wrote: > A fix has been committed in the GnuTLS code base. For reference, the discussion on gnutls-devel was here http://lists.gnu.org/archive/html/gnutls-devel/2008-02/msg00005.html -- -- Howard Chu Chief Architect, 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#5361) cert verification failures with GnuTLS and DNS subjectAltName
by hyc＠symas.com 16 Feb '08

16 Feb '08

A fix has been committed in the GnuTLS code base. -------- Original Message -------- Subject: Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName Date: Fri, 15 Feb 2008 23:11:32 +0200 From: Nikos Mavrogiannopoulos <nmav(a)gnutls.org> To: Howard Chu <hyc(a)symas.com> CC: Joe Orton <joe(a)manyfish.co.uk>, gnutls-devel(a)gnu.org References: <200802100917.m1A9HkSb015171(a)boole.openldap.org> <200802152216.25025.nmav(a)gnutls.org> <47B5F843.8080503(a)symas.com> On Friday 15 February 2008, Howard Chu wrote: > > Anyway, does the attached > > patch solve your problem? > > Not really. It still returns a size one byte larger than expected for the > strings. Even in languages where NUL-terminated strings are the norm, the > terminating byte is not included in the length. > > The point is, we expect this API to return exactly the data that was in the > certificate. If the caller wants to treat the data as a string, they can > NUL-terminate it themselves. The manpage only says that the data will be > returned, it does not say that it will be altered in any way. Actually you are right. The return value shouldn't be increased (this also happens in the other similar functions). I've corrected the patch and commited at: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=4cc3c6b6ed0… regards, Nikos -- -- Howard Chu Chief Architect, 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#5336)
by quanah＠zimbra.com 16 Feb '08

16 Feb '08

A similar bug has been reported in the debian bug tracking system, with some debugging information and reproducibility steps. <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465915> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5381) ldap_result error
by hyc＠symas.com 15 Feb '08

15 Feb '08

fabio.ubaldi(a)coritel.it wrote: > Full_Name: Fabio Ubaldi > Version: 2.3.27 > OS: Linux kernel 2.6.18 > URL: > Submission from: (NULL) (194.237.142.11) > It seems that the error happens only if the two process runs > simultaneously (I use a dual core PC). Thinking of a race condition > error , I used the libldap_r library to build process, but the error > still remains. Processes are completely separate (unless you happen to be using explicitly shared memory). It's pretty much impossible for any code in libldap to be directly responsible for the behavior you're reporting. If you're using a new socket for each request and not closing them when done, it's likely that you're running out of free ports in your system. > The openldap version is 2.3.27 both for slapd servers and the libraries. > > Have anyone encountered a similar error ? > > Thanks in advance for the reply There is no indication of a bug in OpenLDAP Software here. This ITS will be closed. Since it's most likely an issue in how you coded your application, you can followup to the OpenLDAP-software mailing list if you want to discuss this further. -- -- Howard Chu Chief Architect, 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#5369) GSSAPI support for client library
by kurt＠OpenLDAP.org 15 Feb '08

15 Feb '08

I note that the patch appears to be incomplete. No gssapi.c included. -- Kurt On Feb 14, 2008, at 8:26 PM, kurt(a)openldap.org wrote: > You've only included one of the two required statements. You need > also need to include either a copyright + license statement, or a > public domain release statement. -- Kurt > > On Feb 14, 2008, at 9:12 AM, mimir(a)samba.org wrote: > >> >> --OgqxwSJOaUobr8KG >> Content-Type: text/plain; charset=iso-8859-2 >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> Kurt, >> >> On Mon, Feb 11, 2008 at 09:06:19AM -0800, Kurt Zeilenga wrote: >>>> Full_Name: Rafal Szczesniak >>>> Version: HEAD >>>> OS: GNU/Linux >>>> URL: http://www.samba.org/~mimir/gssapi-head.diff >>> >>> The submitted patch file does not contain (at the top of the file, >>> not = >> =20 >>> as part of the diffs) the required notices. Please review=20 >>> http://www.openldap.org/devel/contributing.html and insert >>> appropriate=20 >>> notices. Also, please don't include in the diffs derived files >>> (e.g.,=20 >>> configure). >> >> I've updated the patch file with necessary changes. Please take a >> look >> if it's fine now. >> >> >> cheers, >> --=20 >> Rafal Szczesniak >> Samba Team member http://www.samba.org >> Likewise Software http://www.likewisesoftware.com >> >> >> --OgqxwSJOaUobr8KG >> Content-Type: application/pgp-signature; name="signature.asc" >> Content-Description: Digital signature >> Content-Disposition: inline >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQFHtJLCHvdfyv3qiKkRArL0AJ9ZazJE3LUduZb3A8rz21KheW/EYQCfQt8z >> F7AnIDF5EkJ7ssDwHStryEo= >> =tIVf >> -----END PGP SIGNATURE----- >> >> --OgqxwSJOaUobr8KG-- >> >> > >

1 0

(ITS#5382) JLDAP
by jim＠willeke.com 15 Feb '08

15 Feb '08

Full_Name: Jim Willeke Version: N/A OS: Several URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.76.26.2) This code: String o1="cn=admin, ou=marketing, o=corporation"; String o2="ou=marketing, o=corporation"; DN dn1 = new DN(o1.toString()); DN dn2 = new DN(o2.toString()); if(dn1.isDescendantOf(dn2)) { System.out.println(dn1 + " isDescendantOf "+ dn2); } if(dn2.isDescendantOf(dn1)) { System.out.println(dn2 + " isDescendantOf "+ dn1); } o1="ou=marketing, o=corporation"; o2="cn=admin, ou=marketing, o=corporation"; dn1 = new DN(o1.toString()); dn2 = new DN(o2.toString()); if(dn1.isDescendantOf(dn2)) { System.out.println(dn1 + " isDescendantOf "+ dn2); } if(dn2.isDescendantOf(dn1)) { System.out.println(dn2 + " isDescendantOf "+ dn1); } Yields these results: ou=marketing,o=corporation isDescendantOf cn=admin,ou=marketing,o=corporation ou=marketing,o=corporation isDescendantOf cn=admin,ou=marketing,o=corporation Sure looks wrong to me.

1 0

Re: (ITS#5380) master slapd hangs when writing
by quanah＠zimbra.com 15 Feb '08

15 Feb '08

--On Friday, February 15, 2008 10:34 AM +0000 ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.3.36 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > My directory is formed with 4 servers syncronized through syncrepl > (RefreshAndPersist). > THe directory contains about 10 million entries in the BDB back-end. > My slapd servers are configured with the default 16 threads. > I have a JAVA injector for write operations. The injector establishes 28 > connections to the master and writes about 1400 entries per minute. > > After several hours of activity the master hangs. It accepts TCP > connections but does not handle LDAP operations. LDAP requests remain > hanged until interruption by the client. The replicas are OK. strace is useless. Please get a backtrace of all the threads using gdb. Make sure you compiled with debugging symbols, and that slapd is not stripped. I'd also advise getting a backtrace on a current release, as there have been a number of race conditions and cleanup fixes made since 2.3.36. You may want to wait on 2.3.41 which will be released in the next few days. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5381) ldap_result error
by fabio.ubaldi＠coritel.it 15 Feb '08

15 Feb '08

Full_Name: Fabio Ubaldi Version: 2.3.27 OS: Linux kernel 2.6.18 URL: Submission from: (NULL) (194.237.142.11) Hi all, I have two processes running on the same PC that receive data from an LDAP server. Each process opens a connection with a different "slapd" server (i.e each server runs on a different PC) and launches "search" requests at a fixed rate (about 100 searches/s). Each process creates a thread that polls the server responses using the API "ldap_result" the used macro are LDAP_RES_ANY and LDAP_MSG_ONE. When the two processes send the requestes one of the two "ldap_result" return with error (-1) and the error is "Can't contact the LDAP server". I tried to launch one processes and it works fine (the maximum measured rate is 800 searches/s). Also I launch the two processes alternating the search requestes and it works fine. It seems that the error happens only if the two process runs simultaneously (I use a dual core PC). Thinking of a race condition error , I used the libldap_r library to build process, but the error still remains. The openldap version is 2.3.27 both for slapd servers and the libraries. Have anyone encountered a similar error ? Thanks in advance for the reply

1 0

(ITS#5380) master slapd hangs when writing
by ali.pouya＠free.fr 15 Feb '08

15 Feb '08

Full_Name: Ali Pouya Version: 2.3.36 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) My directory is formed with 4 servers syncronized through syncrepl (RefreshAndPersist). THe directory contains about 10 million entries in the BDB back-end. My slapd servers are configured with the default 16 threads. I have a JAVA injector for write operations. The injector establishes 28 connections to the master and writes about 1400 entries per minute. After several hours of activity the master hangs. It accepts TCP connections but does not handle LDAP operations. LDAP requests remain hanged until interruption by the client. The replicas are OK. Is this problem already known ? I checked the CHANGES file for the 2.3.40 release and did not find any trace of a known problem. I used strace to see what slapd does at hang (freeze) situation. It shows an infinite epoll loop in one of the threads. I reproduce the result at the end of this ITS. Thanks for your help Best regards Ali ==================== The strace result : Process 16970 attached with 18 threads - interrupt to quit [pid 16601] futex(0xa341abf8, FUTEX_WAIT, 16625, NULL <unfinished ...> [pid 16625] time( <unfinished ...> [pid 16626] futex(0xb7f4d3d0, FUTEX_WAIT, 9, NULL <unfinished ...> [pid 16627] futex(0xb7f4c110, FUTEX_WAIT, 21, NULL <unfinished ...> [pid 20161] futex(0xb7f53708, FUTEX_WAIT, 3, NULL <unfinished ...> [pid 20162] futex(0xb7f4c9a8, FUTEX_WAIT, 19, NULL <unfinished ...> [pid 31353] futex(0xb7f4b5bc, FUTEX_WAIT, 11, NULL <unfinished ...> [pid 31354] futex(0xb7f4980c, FUTEX_WAIT, 1, NULL <unfinished ...> [pid 31355] futex(0xb7f4d178, FUTEX_WAIT, 11, NULL <unfinished ...> [pid 2229] futex(0xb7f4fd9c, FUTEX_WAIT, 1, NULL <unfinished ...> [pid 2241] futex(0xb7f48cb8, FUTEX_WAIT, 5, NULL <unfinished ...> [pid 2242] futex(0xb7f50440, FUTEX_WAIT, 3, NULL <unfinished ...> [pid 2243] futex(0xb7f49d20, FUTEX_WAIT, 17, NULL <unfinished ...> [pid 16228] futex(0xb7f523e4, FUTEX_WAIT, 17, NULL <unfinished ...> [pid 16899] futex(0xb7f500bc, FUTEX_WAIT, 19, NULL <unfinished ...> [pid 16916] futex(0xb7f4aa04, FUTEX_WAIT, 29, NULL <unfinished ...> [pid 16969] futex(0xb7f52060, FUTEX_WAIT, 23, NULL <unfinished ...> [pid 16970] futex(0xb7f4c87c, FUTEX_WAIT, 27, NULL <unfinished ...> [pid 16625] <... time resumed> NULL) = 1203063506 [pid 16625] epoll_wait(6, {{EPOLLERR|EPOLLHUP, {u32=153710248, u64=153710248}}, {EPOLLERR|EPOLLHUP, {u32=153710244, u64=15371 0244}}, {EPOLLERR|EPOLLHUP, {u32=153710232, u64=153710232}}, {EPOLLERR|EPOLLHUP, {u32=153710220, u64=153710220}}, {EPOLLERR|E POLLHUP, {u32=153710204, u64=153710204}}, {EPOLLERR|EPOLLHUP, {u32=153710196, u64=153710196}}, {EPOLLERR|EPOLLHUP, {u32=15371 0224, u64=153710224}}, {EPOLLERR|EPOLLHUP, {u32=153710192, u64=153710192}}, {EPOLLERR|EPOLLHUP, {u32=153710180, u64=153710180 }}, {EPOLLERR|EPOLLHUP, {u32=153710176, u64=153710176}}, {EPOLLERR|EPOLLHUP, {u32=153710164, u64=153710164}}, {EPOLLERR|EPOLL HUP, {u32=153710160, u64=153710160}}, {EPOLLERR|EPOLLHUP, {u32=153710144, u64=153710144}}, {EPOLLERR|EPOLLHUP, {u32=153710140 , u64=153710140}}, {EPOLLERR|EPOLLHUP, {u32=153710128, u64=153710128}}, {EPOLLERR|EPOLLHUP, {u32=153710116, u64=153710116}}, {EPOLLERR|EPOLLHUP, {u32=153710108, u64=153710108}}, {EPOLLERR|EPOLLHUP, {u32=153710104, u64=153710104}}, {EPOLLERR|EPOLLHUP, {u32=153710100, u64=153710100}}, {EPOLLERR|EPOLLHUP, {u32=153710096, u64=153710096}}, {EPOLLERR|EPOLLHUP, {u32=153710092, u6 4=153710092}}, {EPOLLERR|EPOLLHUP, {u32=153710088, u64=153710088}}, {EPOLLERR|EPOLLHUP, {u32=153710080, u64=153710080}}, {EPO LLERR|EPOLLHUP, {u32=153710068, u64=153710068}}, {EPOLLERR|EPOLLHUP, {u32=153710056, u64=153710056}}, {EPOLLERR|EPOLLHUP, {u3 2=153710052, u64=153710052}}, {EPOLLERR|EPOLLHUP, {u32=153710048, u64=153710048}}, {EPOLLERR|EPOLLHUP, {u32=153710044, u64=15 3710044}}, {EPOLLERR|EPOLLHUP, {u32= ..........

1 0

ITS#5375
by ecizaguirre＠gmv.com 15 Feb '08

15 Feb '08

Hi Pierangelo, the patch corrects the issue in the current CVS of REL_ENG_2_4 and now is working correctly. I will test the system with more workload. The make phase fails with the following error after applying the patch to 2.4.7 release: cd back-meta; make all rm -f version.c ../../../build/mkversion -v "2.4.7" back_meta > version.c /bin/sh ../../..//libtool --tag=disable-shared --mode=compile gcc -m64 -D_AVL_H -g -I../../../include -I../../../include -I.. -I./.. -I/opt/db-4.5.20/include -I/opt/openssl-0.9.8d/include -c init.c gcc -m64 -D_AVL_H -g -I../../../include -I../../../include -I.. -I./.. -I/opt/db-4.5.20/include -I/opt/openssl-0.9.8d/include -c init.c -o init.o /bin/sh ../../..//libtool --tag=disable-shared --mode=compile gcc -m64 -D_AVL_H -g -I../../../include -I../../../include -I.. -I./.. -I/opt/db-4.5.20/include -I/opt/openssl-0.9.8d/include -c config.c gcc -m64 -D_AVL_H -g -I../../../include -I../../../include -I.. -I./.. -I/opt/db-4.5.20/include -I/opt/openssl-0.9.8d/include -c config.c -o config.o /bin/sh ../../..//libtool --tag=disable-shared --mode=compile gcc -m64 -D_AVL_H -g -I../../../include -I../../../include -I.. -I./.. -I/opt/db-4.5.20/include -I/opt/openssl-0.9.8d/include -c search.c gcc -m64 -D_AVL_H -g -I../../../include -I../../../include -I.. -I./.. -I/opt/db-4.5.20/include -I/opt/openssl-0.9.8d/include -c search.c -o search.o search.c: In function `meta_back_search_start': search.c:627: error: structure has no member named `mi_ldap_extra' search.c:644: error: structure has no member named `mi_ldap_extra' *** Error code 1 make: Fatal error: Command failed for target `search.lo' Current working directory /opt/software/fuentes/openldap-2.4.7/servers/slapd/back-meta *** Error code 1 The following command caused the error: if test -n "back-ldif back-monitor back-bdb back-hdb back-ldap back-meta back-relay"; then \ echo "building static backends..."; \ for i in XX back-ldif back-monitor back-bdb back-hdb back-ldap back-meta back-relay; do \ if test $i != XX; then \ echo " "; echo " cd $i; make all"; \ ( cd $i; make all ); \ if test $? != 0; then exit 1; fi; \ fi; \ done; \ echo " "; \ fi make: Fatal error: Command failed for target `.backend' Current working directory /opt/software/fuentes/openldap-2.4.7/servers/slapd *** Error code 1 The following command caused the error: for i in slapd ; do \ echo " Entering subdirectory $i"; \ ( cd $i; make all ); \ if test $? != 0 ; then exit 1; fi ; \ echo " "; \ done make: Fatal error: Command failed for target `all-common' Current working directory /opt/software/fuentes/openldap-2.4.7/servers *** Error code 1 The following command caused the error: for i in include libraries clients servers tests doc ; do \ echo " Entering subdirectory $i"; \ ( cd $i; make all ); \ if test $? != 0 ; then exit 1; fi ; \ echo " "; \ done make: Fatal error: Command failed for target `all-common' Thanks for the fix. Cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

Re: (ITS#5369) GSSAPI support for client library
by kurt＠OpenLDAP.org 15 Feb '08

15 Feb '08

You've only included one of the two required statements. You need also need to include either a copyright + license statement, or a public domain release statement. -- Kurt On Feb 14, 2008, at 9:12 AM, mimir(a)samba.org wrote: > > --OgqxwSJOaUobr8KG > Content-Type: text/plain; charset=iso-8859-2 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Kurt, > > On Mon, Feb 11, 2008 at 09:06:19AM -0800, Kurt Zeilenga wrote: >>> Full_Name: Rafal Szczesniak >>> Version: HEAD >>> OS: GNU/Linux >>> URL: http://www.samba.org/~mimir/gssapi-head.diff >> >> The submitted patch file does not contain (at the top of the file, >> not = > =20 >> as part of the diffs) the required notices. Please review=20 >> http://www.openldap.org/devel/contributing.html and insert >> appropriate=20 >> notices. Also, please don't include in the diffs derived files >> (e.g.,=20 >> configure). > > I've updated the patch file with necessary changes. Please take a look > if it's fine now. > > > cheers, > --=20 > Rafal Szczesniak > Samba Team member http://www.samba.org > Likewise Software http://www.likewisesoftware.com > > > --OgqxwSJOaUobr8KG > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: Digital signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHtJLCHvdfyv3qiKkRArL0AJ9ZazJE3LUduZb3A8rz21KheW/EYQCfQt8z > F7AnIDF5EkJ7ssDwHStryEo= > =tIVf > -----END PGP SIGNATURE----- > > --OgqxwSJOaUobr8KG-- > >

1 0

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by quanah＠zimbra.com 15 Feb '08

15 Feb '08

--On February 14, 2008 12:21:00 PM +0000 hyc(a)symas.com wrote: > Pierangelo Masarati wrote: >> hyc(a)OpenLDAP.org wrote: >> >>> Another possibility would be to filter out any entries whose entryCSNs >>> are newer than the contextCSN in the LDIF before trying to slapadd it. >> >> Should slapadd take care of it (perhaps if instructed to do so)? > > Of course it might be better to change the delta-sync consumer to check > the target's entryCSN after a modification fails, to see if it matches > the current modification attempt. If so, then the failure can be safely > ignored. -- Note: It should be if it matches or is greater. For example, if it was the very last entry in the DB, thus the last to be added to the resulting LDIF, it is entirely possible that multiple modifications could be done from the time the dump started and the dump ended, meaning the CSN would be greater than the one encountered in the accesslog DB. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5369) GSSAPI support for client library
by mimir＠samba.org 14 Feb '08

14 Feb '08

--OgqxwSJOaUobr8KG Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kurt, On Mon, Feb 11, 2008 at 09:06:19AM -0800, Kurt Zeilenga wrote: >> Full_Name: Rafal Szczesniak >> Version: HEAD >> OS: GNU/Linux >> URL: http://www.samba.org/~mimir/gssapi-head.diff > > The submitted patch file does not contain (at the top of the file, not = =20 > as part of the diffs) the required notices. Please review=20 > http://www.openldap.org/devel/contributing.html and insert appropriate=20 > notices. Also, please don't include in the diffs derived files (e.g.,=20 > configure). I've updated the patch file with necessary changes. Please take a look if it's fine now. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewisesoftware.com --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHtJLCHvdfyv3qiKkRArL0AJ9ZazJE3LUduZb3A8rz21KheW/EYQCfQt8z F7AnIDF5EkJ7ssDwHStryEo= =tIVf -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG--

1 0

Re: (ITS#5377) Why can I delete attributeType and objectClass together
by quanah＠zimbra.com 14 Feb '08

14 Feb '08

The ITS system is for reporting bugs, not for asking questions about how to use the software. Software usage questions should be sent to openldap-software(a)openldap.org. --Quanah --On February 13, 2008 2:32:10 PM +0000 bsdrab(a)gmail.com wrote: > Full_Name: Niki Petrov > Version: 2.4.6 > OS: FreeBSD 7.0 RC1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.125.204.194) > > > Why can I delete attributeType and objectClass together, and how can I do > this? > ------------------------------------------------------------------------- > ---------------- ># ldapmodify -x -W -D "cn=rtoo,o=hoji,l=gu,c=fr" -f > /usr/home/testu/scripts/user_delete > ... > ..(file user_delete) > dn: uid=user,o=hoji,l=gu,c=fr > > changetype: modify > > delete: virtualdomain > > virtualdomain: hoji.gu.fr > > delete: objectClass > > objectClass: CourierDomainAlias > ..... > (error in command-line) > ldapmodify: wrong attributeType at line 5, entry > "uid=user,o=hoji,l=gu,c=fr" > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5375
by ando＠sys-net.it 14 Feb '08

14 Feb '08

I have a fix: servers/slapd/back-meta/search.c 1.204 -> 1.205 servers/slapd/overlays/rwm.c 1.98 -> 1.99 should apply smoothly to both 2.4.7 and current re24. Please test and report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

ITS#5375
by ecizaguirre＠gmv.com 14 Feb '08

14 Feb '08

Nice to know that, if you need any more information regarding this problem let me know. As soon as there is any patch or new version available I will test it and send you the results. Thanks and cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

Re: ITS#5375
by ando＠sys-net.it 14 Feb '08

14 Feb '08

.. in any case I think I located the original issue in modify_add_values() when permissive is set. I'll see if I can figure out a simple fix. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5375
by ando＠sys-net.it 14 Feb '08

14 Feb '08

ecizaguirre(a)gmv.com wrote: > Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 > Program received signal SIGABRT, Aborted. > [Switching to LWP 4] > 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > (gdb) bt > #0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > #1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 > #2 0xfe240040 in abort () from /usr/lib/libc.so.1 > #3 0xfe24027c in _assert () from /usr/lib/libc.so.1 > #4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 > #5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", > textlen=256) at mods.c:155 > #6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 > #7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 > #8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 > #9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 #10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 > #11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 I have another concern: you don't need slapo-rwm(5) with slapd-meta(5), since it has internal rewrite capabilities. See slapd-meta(5). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by hyc＠symas.com 14 Feb '08

14 Feb '08

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> Another possibility would be to filter out any entries whose entryCSNs are >> newer than the contextCSN in the LDIF before trying to slapadd it. > > Should slapadd take care of it (perhaps if instructed to do so)? Of course it might be better to change the delta-sync consumer to check the target's entryCSN after a modification fails, to see if it matches the current modification attempt. If so, then the failure can be safely ignored. -- -- Howard Chu Chief Architect, 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#5378) hot slapcat for slapadd issues with delta-sync
by hyc＠symas.com 14 Feb '08

14 Feb '08

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> Another possibility would be to filter out any entries whose entryCSNs are >> newer than the contextCSN in the LDIF before trying to slapadd it. > > Should slapadd take care of it (perhaps if instructed to do so)? I guess that would be ok. It seems that doc/devel/toolargs isn't up to date now, dunno what option flag would make sense here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#5375
by ecizaguirre＠gmv.com 14 Feb '08

14 Feb '08

This is a multi-part message in MIME format. ------_=_NextPart_001_01C86EFB.88B8168F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =20 Hi Pierangelo, I have configured slapd as a metadirectory against two Activ= e Directory servers. Our goal is to use it as the primary ldap network name= service for all of our Unix/Linux systems. The slapd config file is attach= ed with this mail. This problem only happens when a search is issued for a specific user entry= and all attributes of that entry are requested. I would send you all attri= butes of that entry if you need to check them. The analisys of the core file with gdb and following your instructions, giv= es us the followng results: (gdb) frame 4 #4 0x0005e104 in attr_merge (e=3D0xfd3feaf0, desc=3D0x33a9b0, vals=3D0x3db= 1b0, nvals=3D0x3d96b0) at attr.c:477 477 assert( ( nvals =3D=3D NULL && (*a)->a_nvals =3D=3D= (*a)->a_vals ) (gdb) p nvals $1 =3D (BerVarray) 0x3d96b0 (gdb) p (*a)->a_nvals $2 =3D (BerVarray) 0x3daef8 (gdb) p (*a)->a_vals $3 =3D (BerVarray) 0x3daef8 (gdb) p vals[0] $4 =3D {bv_len =3D 5, bv_val =3D 0x3d9020 "10001"} (gdb) p nvals[0] $5 =3D {bv_len =3D 5, bv_val =3D 0x3d9020 "10001"} (gdb) p (*a)->a_vals[0] $6 =3D {bv_len =3D 2, bv_val =3D 0x3d8f70 "10"} (gdb) p (*a)->a_nvals[0] $7 =3D {bv_len =3D 2, bv_val =3D 0x3d8f70 "10"} (gdb) p (*a)->a_desc[0] $8 =3D {ad_next =3D 0x0, ad_type =3D 0x33bbc8, ad_cname =3D {bv_len =3D 9, = bv_val =3D 0x33b550 "gidNumber"}, ad_tags =3D {bv_len =3D 0, bv_val =3D 0x0}, ad_flags =3D 0} (gdb) p (*a)->a_numvals $9 =3D 1 (gdb) p (*a)->a_flags $10 =3D 0 If you need more information don't hesitate in contact me. Thanks and cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator =20=09=20 GRUPO TECNOL=D3GICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com =09 ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la=20 Informacion siendo para uso exclusivo del destinatario, quedando=20 prohibida su divulgacion copia o distribucion a terceros sin la=20 autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.= =20 Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential=20 information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ ------_=_NextPart_001_01C86EFB.88B8168F Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Description: slapd.conf Content-Disposition: attachment; filename="slapd.conf" Iw0KIyBTZWUgc2xhcGQuY29uZig1KSBmb3IgZGV0YWlscyBvbiBjb25maWd1 cmF0aW9uIG9wdGlvbnMuDQojIFRoaXMgZmlsZSBzaG91bGQgTk9UIGJlIHdv cmxkIHJlYWRhYmxlLg0KIw0KIyMjIEZpY2hlcm8gZGUgc2NoZW1hIGJhc2lj byBkZSBPcGVuTERBUC4NCmluY2x1ZGUgICAgICAgICAvb3B0L29wZW5sZGFw LTIuMy4zOC9ldGMvb3BlbmxkYXAvc2NoZW1hL2NvcmUuc2NoZW1hDQojIyMg RGVmaW5pY2lvbmVzIGluY2x1aWRhcyBjb24gT3BlbkxEQVAuIEVzIGltcG9y dGFudGUgdXNhciBlbCBvcmRlbiBkYWRvIHlhDQojIyMgcXVlIGhheSBhdHJp YnV0b3MgZGVmaW5pZG9zIGVuIHVuIHNjaGVtYSBxdWUgc2UgdXNhbiBlbiBs b3Mgc2lndWllbnRlcy4NCmluY2x1ZGUgICAgICAgICAvb3B0L29wZW5sZGFw LTIuMy4zOC9ldGMvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWENCmlu Y2x1ZGUgICAgICAgICAvb3B0L29wZW5sZGFwLTIuMy4zOC9ldGMvb3Blbmxk YXAvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hDQojIyMgRGVmaW5pY2lv biBkZSBhdHJpYnV0b3MgZGUgQWN0aXZlIERpcmVjdG9yeS4NCmluY2x1ZGUg ICAgICAgICAvb3B0L29wZW5sZGFwLTIuMy4zOC9ldGMvb3BlbmxkYXAvc2No ZW1hL0FELnNjaGVtYQ0KIyMjIERlZmluaWNpb24gaW5jbHVpZGEgY29uIE9w ZW5MREFQIHBhcmEgdXNhciBMREFQIGNvbW8gc2VydmljaW8gTklTLg0KaW5j bHVkZSAgICAgICAgIC9vcHQvb3BlbmxkYXAtMi4zLjM4L2V0Yy9vcGVubGRh cC9zY2hlbWEvbmlzLnNjaGVtYQ0KIyMjIERlZmluaWNpb24gZGUgYXRyaWJ1 dG9zIHkgb2JqZXRvcyBkZSBHcnVwbyBHTVYuDQppbmNsdWRlICAgICAgICAg L29wdC9vcGVubGRhcC0yLjMuMzgvZXRjL29wZW5sZGFwL3NjaGVtYS9sb2Nh bC5zY2hlbWENCiMjIyBEZWZpbmljaW9uIGRlIGF0cmlidXRvcyB5IG9iamV0 b3MgZGUgc2FtYmEuDQppbmNsdWRlICAgICAgICAgL29wdC9vcGVubGRhcC0y LjMuMzgvZXRjL29wZW5sZGFwL3NjaGVtYS9zYW1iYS5zY2hlbWENCg0KIyBE ZWZpbmUgZ2xvYmFsIEFDTHMgdG8gZGlzYWJsZSBkZWZhdWx0IHJlYWQgYWNj ZXNzLg0KDQpwaWRmaWxlCQkvb3B0L29wZW5sZGFwLTIuMy4zOC92YXIvcnVu L3NsYXBkLnBpZA0KYXJnc2ZpbGUJL29wdC9vcGVubGRhcC0yLjMuMzgvdmFy L3J1bi9zbGFwZC5hcmdzDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQojDQojIERlZmluaWNpb24gZGUgdW5hIGJhc2UgZGUgZGF0b3MgTWV0YWRp cmVjdG9yaW8gcGFyYSBjb25zdWx0YXMgYSBBRC4NCiMNCiMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjDQpiYWNrZW5kCQltZXRhDQpkYXRhYmFzZQltZXRh DQoNCiMjIFN1ZmlqbyBkZWwgYXJib2wgbW9zdHJhZG8gcG9yIGVsIG1ldGFk aXJlY3RvcmlvIHkgdXN1YXJpbw0KIyMgYWRtaW5pc3RyYWRvciBkZWwgbWlz bW8oc3VwZXJ1c3VhcmlvIGRlIGxkYXApLg0Kc3VmZml4CQkiZGM9Z212LGRj PWVzIg0Kcm9vdGRuCQkiY249ZGlyYWRtaW4sZGM9Z212LGRjPWVzIg0KIyMg UGFzc3dvcmQgZGVsIHN1cGVydXN1YXJpbywgcGFzYXIgYSB0ZXh0byBjaWZy YWRvIGNvbiBzbGFwcGFzc3dkLiANCnJvb3RwdwkJKioqKioqDQoNCiMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMj IyBPcGNpb25lcyBjb211bmVzIGEgdG9kbyBlbCBtZXRhZGlyZWN0b3Jpby4N CiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQojIyMjIERpcmVjdGl2YXMgY29tdW5lcyBkZSBjb25maWd1cmFjaW9uLg0K IyMgVFRMIHBhcmEgdGlyYXIgdW5hIGNvbmV4aW9uLCBhdW5xdWUgbm8gZXN0 ZSBpbmFjdGl2YS4NCmNvbm4tdHRsIDYwDQojIyBWZXJzaW9uIGRlbCBwcm90 b2NvbG8gTERBUCBhIHV0aWxpemFyLg0KcHJvdG9jb2wtdmVyc2lvbiAzDQoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMjIyBEZWZpbmljaW9uIGRlbCBM REFQIHJlbW90byBwYXJhIGxhcyBjb25zdWx0YXMgZGUgaW5mb3JtYWNpb24g ZGUNCiMjIyB1c3VhcmlvIHkgZ3J1cG9zIFVOSVggZGVzZGUgbWFxdWluYXMg cXVlIHNvbiBjbGllbnRlcyBMREFQLg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjDQojIyBEZWZpbmljaW9uIGRlIGxvcyBzZXJ2aWRvcmVzIHRhcmdldCBy ZW1vdG9zIGEgY29uc3VsdGFyLg0KIyMgU2UgY29uc3VsdGFyYSBlbCBwcmlt ZXIgc2Vydmlkb3IgcmVtb3RvIHF1ZSByZXNwb25kYS4NCiMjIERlZmlubyB1 bmEgbGlzdGEgZGUgZGNzIHF1ZSBwdWVkZW4gcmVzcG9uZGVyIHBhcmEgZWwg Y29udGV4dG8gZGUgDQojIyBub21icmUgZGM9Z212LGRjPWVzLiBQcmltZXIg dGFyZ2V0IGNvbiBzdXMgcGFyYW1ldHJvcyBkZSBjb25maWd1cmFjaW9uLg0K dXJpICJsZGFwOi8vZ212ZGMxLmdtdi5lcy9EQz1nbXYsREM9ZXMJbGRhcDov L2dtdmRjMi5nbXYuZXMvIg0KIyMgSGFiaWxpdGFtb3MgZWwgc2lzdGVtYSBk ZSByZWVzY3JpdHVyYSBwYXJhIGxhcyBjb25zdWx0YXMuDQpyZXdyaXRlRW5n aW5lIG9uDQpvdmVybGF5IHJ3bQ0KIyMgQWNjaW9uIGFudGUgdW4gcmVmZXJy YWwuDQpjaGFzZS1yZWZlcnJhbHMgbm8NCiMjIFRUTCBwYXJhIHRpcmFyIHVu YSBjb25leGlvbiBpbmFjdGl2YSAoMSBob3JhKS4NCmlkbGUtdGltZW91dCAw MTAwDQojIyBQc2V1ZG9yb290IEROLg0KI3BzZXVkb3Jvb3RkbiAiQ049QWRt aW5pc3RyYWRvcixDTj1Vc2VycyxEQz1nbXYsREM9ZXMiDQojcHNldWRvcm9v dHB3IGVjZWwraTINCiNpZGFzc2VydC1hdXRoekZyb20gIkNOPUFkbWluaXN0 cmFkb3IsQ049VXNlcnMsREM9Z212LERDPWVzIg0KI2lkYXNzZXJ0LWJpbmQg ZWNlbCtpMg0KcHNldWRvcm9vdGRuICJDTj1wcm94eW1ldGFkaXIsT1U9U0lT VEVNQVMsT1U9VXN1YXJpb3MsREM9Z212LERDPWVzIg0KcHNldWRvcm9vdHB3 ICoqKioqKg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIw0KIyBEZWZpbmljaW9uIGRlIGxhcyByZWdsYXMgZGUgcmVl c2NyaXR1cmEgYSB1dGlsaXphciBwYXJhIGxvcyBEQ3MuDQojIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIyBSZWds YXMgZGUgcmVlc2NyaXR1cmEgcGFyYSBidXNjYXIgaW5mb3JtYWNpb24gZW4g bG9zIERDcy4NCiMjIFByaW1lcm8gc2UgY2FtYmlhIGVsIHN1ZmlqbyBkZWwg YXJib2wgcGFyYSBidXNjYXIgZ3J1cG9zLg0KcndtLXN1ZmZpeG1hc3NhZ2Ug Im91PWdyb3VwLGRjPWdtdixkYz1lcyIgIk9VPVByb3llY3RvcyxPVT1HcnVw b3MsREM9Z212LERDPWVzIg0KIyMgQWhvcmEgc2UgbW9kaWZpY2EgcGFyYSBi dXNjYXIgbGFzIGN1ZW50YXMgZGUgdXN1YXJpby4NCnJ3bS1zdWZmaXhtYXNz YWdlICJvdT1wZW9wbGUsZGM9Z212LGRjPWVzIiAiT1U9VXN1YXJpb3MsREM9 Z212LERDPWVzIg0KIyMgUmVnbGEgZGUgcmVlc2NyaXR1cmEgcGFyYSBlbCBE TiBkZSBsb3MgZ3J1cG9zLg0KIyMgVGVvcmljYW1lbnRlIHNvbG8gZGViZXJp YSBhcGxpY2Fyc2UgYSBsb3MgcmVzdWx0YWRvcyBkZXZ1ZWx0b3MNCiMjIGEg bG9zIGNsaWVudGVzIGRlbCBzZXJ2aWRvci4NCnJ3bS1yZXdyaXRlQ29udGV4 dCBzZWFyY2hFbnRyeURODQpyd20tcmV3cml0ZVJ1bGUgIiguKyk/X3Byaixv dT1Hcm91cCxkYz1nbXYsZGM9ZXMiICIkMSxvdT1Hcm91cCxkYz1nbXYsZGM9 ZXMiDQojIyBBaG9yYSB2aWVuZW4gbGFzIHJlZ2xhcyBkZSByZWVzY3JpdHVy YSBkZSBsb3MgYXRyaWJ1dG9zIHkgbGFzDQojIyBjbGFzZXMgZGUgb2JqZXRv IGRlIGN1ZW50YXMgZGUgdXN1YXJpbyB5IGdydXBvIFVOSVguDQpyd20tbWFw IG9iamVjdENsYXNzIHBvc2l4QWNjb3VudCB1c2VyDQpyd20tbWFwIG9iamVj dENsYXNzIHNoYWRvd0FjY291bnQgcGVyc29uDQpyd20tbWFwIG9iamVjdENs YXNzIHBvc2l4R3JvdXAgZ3JvdXANCiMjDQojIyBEZWZpbmljaW9uIGRlIGF0 cmlidXRvcyBhIG1hcGVhciBjb24gTVMgU0ZVIDMuMC4NCiMjDQpyd20tbWFw IGF0dHJpYnV0ZSBnZWNvcyBtc1NGVTMwR2Vjb3MNCnJ3bS1tYXAgYXR0cmli dXRlIGhvbWVEaXJlY3RvcnkgbXNTRlUzMEhvbWVEaXJlY3RvcnkNCnJ3bS1t YXAgYXR0cmlidXRlIHVpZE51bWJlciBtc1NGVTMwVWlkTnVtYmVyDQpyd20t bWFwIGF0dHJpYnV0ZSBsb2dpblNoZWxsIG1zU0ZVMzBMb2dpblNoZWxsDQpy d20tbWFwIGF0dHJpYnV0ZSBnaWROdW1iZXIgbXNTRlUzMEdpZE51bWJlcg0K cndtLW1hcCBhdHRyaWJ1dGUgbWVtYmVyVWlkIG1zU0ZVMzBNZW1iZXJVaWQN CnJ3bS1tYXAgYXR0cmlidXRlIFNoYWRvd0ZsYWcgbXNTRlUzMFNoYWRvd0Zs YWcNCnJ3bS1tYXAgYXR0cmlidXRlIFNoYWRvd0V4cGlyZSBtc1NGVTMwU2hh ZG93RXhwaXJlDQpyd20tbWFwIGF0dHJpYnV0ZSBTaGFkb3dJbmFjdGl2ZSBt c1NGVTMwU2hhZG93SW5hY3RpdmUNCnJ3bS1tYXAgYXR0cmlidXRlIFNoYWRv d01heCBtc1NGVTMwU2hhZG93TWF4DQpyd20tbWFwIGF0dHJpYnV0ZSBTaGFk b3dXYXJuaW5nIG1zU0ZVMzBTaGFkb3dXYXJuaW5nDQpyd20tbWFwIGF0dHJp YnV0ZSBTaGFkb3dMYXN0Q2hhbmdlIG1zU0ZVMzBTaGFkb3dMYXN0Q2hhbmdl DQpyd20tbWFwIGF0dHJpYnV0ZSBTaGFkb3dNaW4gbXNTRlUzMFNoYWRvd01p bg0KIyMjIENvbW8gaGF5IGRvcyBhdHJpYnV0b3MgaWd1YWxlcyBwYXJhIGxv cyB1c3VhcmlvcyB5IHBhcmENCiMjIyBsb3MgZ3J1cG9zIGhhcmVtb3MgZXN0 YSBkaXN0aW5jaW9uIGVudHJlIHVub3MgeSBvdHJvcw0KIyMjIHBhcmEgcmVh bGl6YXIgZWwgbWFwZW8gZW50cmUgbG9zIGRvcy4NCiMjIExvcyBncnVwb3Mg c2UgaWRlbnRpZmljYW4gcG9yIGNuLg0KcndtLW1hcCBhdHRyaWJ1dGUgY24g bXNTRlUzME5hbWUNCiMjIExvcyB1c3VhcmlvcyBzZSBpZGVudGlmaWNhbiBw b3IgdWlkLg0KcndtLW1hcCBhdHRyaWJ1dGUgdWlkIHNBTUFjY291bnROYW1l DQojIyBFbCByZXN0byBkZSBhdHJpYnV0b3Mgbm8gbG9zIHF1aWVybyBwYXJh IG5hZGEgYXNpIHF1ZSBtZSBsb3MNCiMjIGNhcmdvIGNvbiBsb3Mgc2lndWll bnRlcyBtYXBlb3MuDQpyd20tbWFwIGF0dHJpYnV0ZSBEU0NPUkVQUk9QQUdB VElPTkRBVEENCnJ3bS1tYXAgYXR0cmlidXRlIFNIT1dJTkFERFJFU1NCT09L DQpyd20tbWFwIGF0dHJpYnV0ZSBNU0VYQ0hIT01FU0VSVkVSTkFNRQ0Kcndt LW1hcCBhdHRyaWJ1dGUgTVNFWENIQUxPQkpFQ1RWRVJTSU9ODQpyd20tbWFw IGF0dHJpYnV0ZSBNU0VYQ0hNQUlMQk9YU0VDVVJJVFlERVNDUklQVE9SDQpy d20tbWFwIGF0dHJpYnV0ZSBNU0VYQ0hVU0VSQUNDT1VOVENPTlRST0wNCnJ3 bS1tYXAgYXR0cmlidXRlIE1TRVhDSE1BSUxCT1hHVUlEDQpyd20tbWFwIGF0 dHJpYnV0ZSBQUk9YWUFERFJFU1NFUw0KcndtLW1hcCBhdHRyaWJ1dGUgTUVN QkVST0YNCnJ3bS1tYXAgYXR0cmlidXRlIEhPTUVNVEENCnJ3bS1tYXAgYXR0 cmlidXRlIEhPTUVNREINCnJ3bS1tYXAgYXR0cmlidXRlIFVTRVJBQ0NPVU5U Q09OVFJPTA0KcndtLW1hcCBhdHRyaWJ1dGUgbWFuYWdlcg0KcndtLW1hcCBh dHRyaWJ1dGUgTEVHQUNZRVhDSEFOR0VETg0KcndtLW1hcCBhdHRyaWJ1dGUg QkFEUFdEQ09VTlQNCnJ3bS1tYXAgYXR0cmlidXRlIEJBRFBBU1NXT1JEVElN RQ0KcndtLW1hcCBhdHRyaWJ1dGUgTEFTVExPR09GRg0KcndtLW1hcCBhdHRy aWJ1dGUgTEFTVExPR09ODQpyd20tbWFwIGF0dHJpYnV0ZSBVU0VSV09SS1NU QVRJT05TDQpyd20tbWFwIGF0dHJpYnV0ZSBQV0RMQVNUU0VUDQpyd20tbWFw IGF0dHJpYnV0ZSBPQkpFQ1RTSUQNCnJ3bS1tYXAgYXR0cmlidXRlIEFETUlO Q09VTlQNCnJ3bS1tYXAgYXR0cmlidXRlIEFDQ09VTlRFWFBJUkVTDQpyd20t bWFwIGF0dHJpYnV0ZSBMT0dPTkNPVU5UDQpyd20tbWFwIGF0dHJpYnV0ZSBE SVJFQ1RSRVBPUlRTDQpyd20tbWFwIGF0dHJpYnV0ZSBVU05DUkVBVEVEDQpy d20tbWFwIGF0dHJpYnV0ZSBVU05DSEFOR0VEDQpyd20tbWFwIGF0dHJpYnV0 ZSBDT0RFUEFHRQ0KcndtLW1hcCBhdHRyaWJ1dGUgT0JKRUNUR1VJRA0Kcndt LW1hcCBhdHRyaWJ1dGUgTURCVVNFREVGQVVMVFMNCnJ3bS1tYXAgYXR0cmli dXRlIHRpdGxlDQpyd20tbWFwIGF0dHJpYnV0ZSBwaHlzaWNhbERlbGl2ZXJ5 T2ZmaWNlTmFtZQ0KcndtLW1hcCBhdHRyaWJ1dGUgb2JqZWN0Q2F0ZWdvcnkN CnJ3bS1tYXAgYXR0cmlidXRlIExBU1RMT0dPTlRJTUVTVEFNUA0KcndtLW1h cCBhdHRyaWJ1dGUgTVNFWENIUE9MSUNJRVNJTkNMVURFRA0KcndtLW1hcCBh dHRyaWJ1dGUgTVNSVENTSVAtUFJJTUFSWUhPTUVTRVJWRVINCnJ3bS1tYXAg YXR0cmlidXRlIE1TUlRDU0lQLVBSSU1BUllVU0VSQUREUkVTUw0KcndtLW1h cCBhdHRyaWJ1dGUgTVNSVENTSVAtRkVERVJBVElPTkVOQUJMRUQNCnJ3bS1t YXAgYXR0cmlidXRlIE1TUlRDU0lQLU9QVElPTkZMQUdTDQpyd20tbWFwIGF0 dHJpYnV0ZSBzdHJlZXQNCnJ3bS1tYXAgYXR0cmlidXRlIGpwZWdQaG90bw0K cndtLW1hcCBhdHRyaWJ1dGUgVVNFUlBBUkFNRVRFUlMNCg0KIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjDQojIyMgRGVmaW5pY2lvbiBkZWwgTERBUCBsb2Nh bCBwYXJhIGxhcyBjb25zdWx0YXMgZGUgaW5mb3JtYWNpb24gZGUNCiMjIyBt YXBhcyBkZSBhdXRvbW91bnQsIHBlcmZpbGVzIGRlIGluaWNpYWxpemFjaW9u IGRlIGNsaWVudGVzIFNvbGFyaXMNCiMjIyB5IGxvcyBuZXRncm91cHMuDQoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMjIEFob3JhIGRlZmlubyBlbCBs ZGFwIHF1ZSBjb250aWVuZSBsb3MgbWFwYXMgZGUgYXV0b2ZzDQojIyBhc2kg Y29tbyBsb3MgcGVyZmlsZXMgcGFyYSBsb3MgY2xpZW50ZXMgTERBUCBTb2xh cmlzLg0KIyMgRGUgbW9tZW50byBoYWdvIGxhIHBydWViYSBlbiBsb2NhbC4N CnVyaSAibGRhcDovLzE3Mi4yMi40LjM0OjM5MC9kYz1nbXYsZGM9ZXMiDQoj IyBIYWJpbGl0YW1vcyBlbCBzaXN0ZW1hIGRlIHJlZXNjcml0dXJhIHBhcmEg bGFzIGNvbnN1bHRhcy4NCnJld3JpdGVFbmdpbmUgb24NCiNvdmVybGF5IHJ3 bQ0KIyMgQWNjaW9uIGFudGUgdW4gcmVmZXJyYWwuDQpjaGFzZS1yZWZlcnJh bHMgbm8NCiMjIFRUTCBwYXJhIHRpcmFyIHVuYSBjb25leGlvbiBpbmFjdGl2 YSAoMSBob3JhKS4NCmlkbGUtdGltZW91dCAwMTAwDQojIyBQc2V1ZG9yb290 IEROLg0KcHNldWRvcm9vdGRuICJDTj1wcm94eW1ldGFkaXIsT1U9U0lTVEVN QVMsT1U9VXN1YXJpb3MsREM9Z212LERDPWVzIg0KcHNldWRvcm9vdHB3ICoq KioqKg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMNCiMgRGVmaW5pY2lvbiBkZSBsYXMgcmVnbGFz IGRlIHJlZXNjcml0dXJhIGEgdXRpbGl6YXIgcGFyYSBlbCBMREFQIGxvY2Fs Lg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMNCiMjIEFob3JhIGxhcyByZWdsYXMgZGUgcmVlc2Ny aXR1cmEgZGVsIHNlcnZpZG9yIExEQVAgcXVlIGNvbnRpZW5lDQojIyBsb3Mg bWFwYXMgZGUgYXV0b21vdW50IGFzaSBjb21vIGxvcyBwZXJmaWxlcyBkZSBT b2xhcmlzIHkgbG9zDQojIyBuZXRncm91cHMgZGUgVW5peC4NCnJ3bS1zdWZm aXhtYXNzYWdlICJvdT1Qcm9maWxlLGRjPWdtdixkYz1lcyIgIm91PVByb2Zp bGUsb3U9VW5peCxkYz1nbXYsZGM9ZXMiDQpyd20tc3VmZml4bWFzc2FnZSAi b3U9QXV0b21vdW50LGRjPWdtdixkYz1lcyIgIm91PUF1dG9tb3VudCxvdT1V bml4LGRjPWdtdixkYz1lcyINCnJ3bS1zdWZmaXhtYXNzYWdlICJvdT1uZXRn cm91cCxkYz1nbXYsZGM9ZXMiICJvdT1OZXRncm91cCxvdT1Vbml4LGRjPWdt dixkYz1lcyINCnJ3bS1zdWZmaXhtYXNzYWdlICJhdXRvbW91bnRtYXBuYW1l PWF1dG9faG9tZSxkYz1nbXYsZGM9ZXMiICJhdXRvbW91bnRtYXBuYW1lPWF1 dG9faG9tZSxvdT1Vbml4LGRjPWdtdixkYz1lcyINCnJ3bS1zdWZmaXhtYXNz YWdlICJhdXRvbW91bnRtYXBuYW1lPWF1dG9fbWFzdGVyLGRjPWdtdixkYz1l cyIgImF1dG9tb3VudG1hcG5hbWU9YXV0b19tYXN0ZXIsb3U9VW5peCxkYz1n bXYsZGM9ZXMiDQpyd20tc3VmZml4bWFzc2FnZSAiYXV0b21vdW50bWFwbmFt ZT1hdXRvX2RpcmVjdCxkYz1nbXYsZGM9ZXMiICJhdXRvbW91bnRtYXBuYW1l PWF1dG9fZGlyZWN0LG91PVVuaXgsZGM9Z212LGRjPWVzIg0KcndtLW1hcCBv YmplY3RDbGFzcyBuaXNPYmplY3QgbmlzT2JqZWN0DQpyd20tbWFwIG9iamVj dENsYXNzIG5pc05ldGdyb3VwIG5pc05ldGdyb3VwDQpyd20tbWFwIG9iamVj dENsYXNzIGF1dG9tb3VudE1hcCBhdXRvbW91bnRNYXANCnJ3bS1tYXAgb2Jq ZWN0Q2xhc3MgYXV0b21vdW50IGF1dG9tb3VudA0KcndtLW1hcCBhdHRyaWJ1 dGUgbWVtYmVyTmlzTmV0Z3JvdXAgbWVtYmVyTmlzTmV0Z3JvdXANCnJ3bS1t YXAgYXR0cmlidXRlIGF1dG9tb3VudE1hcE5hbWUgYXV0b21vdW50TWFwTmFt ZQ0KcndtLW1hcCBhdHRyaWJ1dGUgYXV0b21vdW50S2V5IGF1dG9tb3VudEtl eQ0KcndtLW1hcCBhdHRyaWJ1dGUgbmlzTmV0Z3JvdXBUcmlwbGUgbmlzTmV0 Z3JvdXBUcmlwbGUNCg0K ------_=_NextPart_001_01C86EFB.88B8168F--

1 0

(ITS#5379) Undefined reference when --without-tls
by hyc＠OpenLDAP.org 14 Feb '08

14 Feb '08

Full_Name: Howard Chu Version: RE24/HEAD OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slapd/config.c references ldap_pvt_tls_get_option outside of #ifdef HAVE_TLS

1 0

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by ando＠sys-net.it 14 Feb '08

14 Feb '08

hyc(a)OpenLDAP.org wrote: > Another possibility would be to filter out any entries whose entryCSNs are > newer than the contextCSN in the LDIF before trying to slapadd it. Should slapadd take care of it (perhaps if instructed to do so)? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5375
by ando＠sys-net.it 14 Feb '08

14 Feb '08

ecizaguirre(a)gmv.com wrote: > Hi Quanah, I have followed your instructions. As you can check the slapd binary is not stripped: > > -bash-3.00# file slapd > > slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped > > The backtrace of the slapd process is the following: > > <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> > > Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 ^^^ this is very interesting, as it's supposed to never happen. In order to try to figure out what is actually happening, I need your configuration and the exact operation that triggered this issue. In the meanwhile, you could probably post the contents of the variables used in that assert. For this purpose, from within gdb, you should: (gdb) frame 4 (gdb) p nvals (gdb) p (*a)->a_vals (gdb) p (*a)->a_nvals unless any of the above is NULL, you should also print its contents up to the first value of the array, namely (gdb) p vals[0] (gdb) p nvals[0] (gdb) p (*a)->a_vals[0] (gdb) p (*a)->a_nvals[0] If any of the above contains info that you consider sensible, do not post it; only tell whether the value is present or NULL (note: by NULL I mean the corresponding struct berval has a NULL bv_val member) Also, please do (gdb) p (*a)->a_desc[0] (gdb) p (*a)->a_numvals (gdb) p (*a)->a_flags > Program received signal SIGABRT, Aborted. > [Switching to LWP 4] > 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > (gdb) bt > #0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > #1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 > #2 0xfe240040 in abort () from /usr/lib/libc.so.1 > #3 0xfe24027c in _assert () from /usr/lib/libc.so.1 > #4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 > #5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", > textlen=256) at mods.c:155 > #6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 > #7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 > #8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 > #9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 #10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 > #11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 > #12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 > #13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at search.c:1128 > #14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 > #15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, which=op_search) at backover.c:704 > #16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at backover.c:726 > #17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at search.c:368 > #18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 > #19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) at connection.c:1083 #20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at connection.c:1210 > #21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at tpool.c:625 > #22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 > #23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by hyc＠OpenLDAP.org 14 Feb '08

14 Feb '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.40 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > If someone is using delta-syncrepl for replication, and does a hot slapcat of a > server, and a change occurs during the slapcat, the resulting LDIF file cannot > be used on a replica. This is because the replica will try to resume from the > CSN in the LDIF file, which is from before the change occurred. Since the > change is in the LDIF file, when the replica contacts the master, it tries to > re-replicate the change (which obviously fails). At that point, the replica is > stuck and unable to progress. The only guaranteed way to get a viable slapcat > when using delta-syncrepl is to put the server being dumped into RO mode or to > stop it. Another possibility would be to filter out any entries whose entryCSNs are newer than the contextCSN in the LDIF before trying to slapadd it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5378) hot slapcat for slapadd issues with delta-sync
by quanah＠OpenLDAP.org 13 Feb '08

13 Feb '08

Full_Name: Quanah Gibson-Mount Version: 2.3.40 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) If someone is using delta-syncrepl for replication, and does a hot slapcat of a server, and a change occurs during the slapcat, the resulting LDIF file cannot be used on a replica. This is because the replica will try to resume from the CSN in the LDIF file, which is from before the change occurred. Since the change is in the LDIF file, when the replica contacts the master, it tries to re-replicate the change (which obviously fails). At that point, the replica is stuck and unable to progress. The only guaranteed way to get a viable slapcat when using delta-syncrepl is to put the server being dumped into RO mode or to stop it. --Quanah

1 0

RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

Eduardo, Can you confirm this was with a fresh CVS checkout of RE24, and not with 2.4.7? Thanks, Quanah --On February 13, 2008 6:08:45 PM +0000 quanah(a)zimbra.com wrote: > Forwarding... > > ------------ Forwarded Message ------------ > Date: February 13, 2008 5:49:29 PM +0100 > From: Eduardo Izaguirre Pazos <ecizaguirre(a)gmv.com> > To: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: RE: (ITS#5375) Slapd core dumps > > Hi Quanah, I have followed your instructions. As you can check the slapd > binary is not stripped: > > -bash-3.00# file slapd > slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically > linked, not stripped > > The backtrace of the slapd process is the following: > > <<< dnPretty: <cn=Eduardo Izaguirre > Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> > Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || > ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) >|| ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 > > Program received signal SIGABRT, Aborted. > [Switching to LWP 4] > 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > (gdb) bt ># 0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 ># 1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 ># 2 0xfe240040 in abort () from /usr/lib/libc.so.1 ># 3 0xfe24027c in _assert () from /usr/lib/libc.so.1 ># 4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, > vals=0x3da650, nvals=0x3d8b08) at attr.c:477 ># 5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, > permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", > textlen=256) at mods.c:155 ># 6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, > a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 ># 7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at > rwm.c:1323 ># 8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at > rwm.c:1518 ># 9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at > backover.c:241 ># 10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at > result.c:307 ># 11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at > result.c:771 ># 12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, > mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 ># 13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at > search.c:1128 ># 14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, > which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 ># 15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, > which=op_search) at backover.c:704 ># 16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at > backover.c:726 ># 17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at > search.c:368 ># 18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 ># 19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) > at connection.c:1083 ># 20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at > connection.c:1210 ># 21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at > tpool.c:625 ># 22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 ># 23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 > Backtrace stopped: previous frame identical to this frame (corrupt > stack?) > > I hope this help. > > Thanks. > > Eduardo > > -----Mensaje original----- > De: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Enviado el: martes, 12 de febrero de 2008 18:44 > Para: Eduardo Izaguirre Pazos; openldap-its(a)openldap.org > Asunto: Re: (ITS#5375) Slapd core dumps > > > > --On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote: > >> Full_Name: Eduardo Izaguirre Pazos >> Version: 2.4.7 >> OS: Solaris 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.0.110.2) >> >> >> Hi all, we are using Openldap as a metadirectory against a couple of >> AD servers. The slapd server core dumps when a request of all >> attributes of one entry is issued. This is the output of the slapd >> server using the debug level -1: > > Hi Eduardo, > > Please test with the current CVS of REL_ENG_2_4. Please build without > optimization, and with debugging symbols. Make sure you don't strip > slapd on install. If you can repeat this with current CVS, please > provide a gdb backtrace of the non-optimized, non-stripped slapd. > > Thanks, > Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > ______________________ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, > puede contener informacion clasificada por su emisor como confidencial > en el marco de su Sistema de Gestion de Seguridad de la > Informacion siendo para uso exclusivo del destinatario, quedando > prohibida su divulgacion copia o distribucion a terceros sin la > autorizacion expresa del remitente. Si Vd. ha recibido este mensaje > erroneamente, se ruega lo notifique al remitente y proceda a su borrado. > Gracias por su colaboracion. > ______________________ > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are addressed. > Any unauthorised copy, disclosure or distribution of this message > is strictly forbidden. If you have received this transmission in error, > please notify the sender immediately and delete it. > ______________________ > > ---------- End Forwarded Message ---------- > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

------------ Forwarded Message ------------ Date: February 13, 2008 5:54:44 PM +0100 From: Eduardo Izaguirre Pazos <ecizaguirre(a)gmv.com> To: Quanah Gibson-Mount <quanah(a)zimbra.com> Subject: RE: (ITS#5375) Slapd core dumps Hi again Quanah, I have analyzed the core file dumped by the slapd process with gdb and I have obtanied the following backtrace: (gdb) bt # 0 0xff3bf430 in rtld_db_dlactivity () from /lib/ld.so.1 # 1 0xff3bf5f0 in rd_event () from /lib/ld.so.1 # 2 0xff3c06e4 in lm_delete () from /lib/ld.so.1 # 3 0xff3c8dbc in remove_so () from /lib/ld.so.1 # 4 0xff3caa24 in remove_hdl () from /lib/ld.so.1 # 5 0xff3c4d5c in dlclose_intn () from /lib/ld.so.1 # 6 0xff3c4e70 in dlclose () from /lib/ld.so.1 # 7 0xfdf62b44 in pkcs11_slottable_delete () from /usr/lib/libpkcs11.so.1 # 8 0xfdf5d66c in pkcs11_fini () from /usr/lib/libpkcs11.so.1 # 9 0xfe240dc8 in _postfork_child_handler () from /usr/lib/libc.so.1 # 10 0xfe2b2970 in fork1 () from /usr/lib/libc.so.1 # 11 0x001f0d48 in lutil_detach (debug=0, do_close=0) at detach.c:76 # 12 0x00027c68 in main (argc=3, argv=0xffbffb04) at main.c:864 I think this would be more useful than the previous one I've sent before. Cheers. Eduardo -----Mensaje original----- De: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Enviado el: martes, 12 de febrero de 2008 18:44 Para: Eduardo Izaguirre Pazos; openldap-its(a)openldap.org Asunto: Re: (ITS#5375) Slapd core dumps --On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote: > Full_Name: Eduardo Izaguirre Pazos > Version: 2.4.7 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.0.110.2) > > > Hi all, we are using Openldap as a metadirectory against a couple of > AD servers. The slapd server core dumps when a request of all > attributes of one entry is issued. This is the output of the slapd > server using the debug level -1: Hi Eduardo, Please test with the current CVS of REL_ENG_2_4. Please build without optimization, and with debugging symbols. Make sure you don't strip slapd on install. If you can repeat this with current CVS, please provide a gdb backtrace of the non-optimized, non-stripped slapd. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

Forwarding... ------------ Forwarded Message ------------ Date: February 13, 2008 5:49:29 PM +0100 From: Eduardo Izaguirre Pazos <ecizaguirre(a)gmv.com> To: Quanah Gibson-Mount <quanah(a)zimbra.com> Subject: RE: (ITS#5375) Slapd core dumps Hi Quanah, I have followed your instructions. As you can check the slapd binary is not stripped: -bash-3.00# file slapd slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped The backtrace of the slapd process is the following: <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 Program received signal SIGABRT, Aborted. [Switching to LWP 4] 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 (gdb) bt # 0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 # 1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 # 2 0xfe240040 in abort () from /usr/lib/libc.so.1 # 3 0xfe24027c in _assert () from /usr/lib/libc.so.1 # 4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 # 5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", textlen=256) at mods.c:155 # 6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 # 7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 # 8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 # 9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 # 10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 # 11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 # 12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 # 13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at search.c:1128 # 14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 # 15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, which=op_search) at backover.c:704 # 16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at backover.c:726 # 17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at search.c:368 # 18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 # 19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) at connection.c:1083 # 20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at connection.c:1210 # 21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at tpool.c:625 # 22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 # 23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) I hope this help. Thanks. Eduardo -----Mensaje original----- De: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Enviado el: martes, 12 de febrero de 2008 18:44 Para: Eduardo Izaguirre Pazos; openldap-its(a)openldap.org Asunto: Re: (ITS#5375) Slapd core dumps --On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote: > Full_Name: Eduardo Izaguirre Pazos > Version: 2.4.7 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.0.110.2) > > > Hi all, we are using Openldap as a metadirectory against a couple of > AD servers. The slapd server core dumps when a request of all > attributes of one entry is issued. This is the output of the slapd > server using the debug level -1: Hi Eduardo, Please test with the current CVS of REL_ENG_2_4. Please build without optimization, and with debugging symbols. Make sure you don't strip slapd on install. If you can repeat this with current CVS, please provide a gdb backtrace of the non-optimized, non-stripped slapd. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

--On February 13, 2008 11:40:17 AM +0000 hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> With a build of 2.3 with the (adjusted) patches from HEAD, it looks like >> this issue is resolved. I fully sync'd a replica from the master, and >> after it was done, I did a slapcat of them. >> >> A direct diff shows a lot of entries out of order (because the replica >> gets them in multiple refresh phases), however, if I sort the two ldif >> files, and do a diff, I get: >> >> [zimbra@smtp-2 tmp]$ sort slave.ldif>slave.ldif.s >> [zimbra@smtp-2 tmp]$ sort master.ldif>master.ldif.s >> [zimbra@smtp-2 tmp]$ diff -u master.ldif.s slave.ldif.s >> [zimbra@smtp-2 tmp]$ >> >> No diff. So I believe this is fixed. Sound correct? > > Sounds good to me. I guess this should go into both RE23 and RE24. As discussed with Howard, I'm going to drop the permissive modify bit. I verified things work correctly without it, and having it could potentially lead to issues. I also tracked down an ldif sorting script Matt Backes sent to me a while ago, and verified the LDIF matched after sorting with it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#5375
by ecizaguirre＠gmv.com 13 Feb '08

13 Feb '08

Hi Quanah, I have followed your instructions. As you can check the slapd binary is not stripped: -bash-3.00# file slapd slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped The backtrace of the slapd process is the following: <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 Program received signal SIGABRT, Aborted. [Switching to LWP 4] 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 (gdb) bt #0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 #1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 #2 0xfe240040 in abort () from /usr/lib/libc.so.1 #3 0xfe24027c in _assert () from /usr/lib/libc.so.1 #4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 #5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", textlen=256) at mods.c:155 #6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 #7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 #8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 #9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 #10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 #11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 #12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 #13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at search.c:1128 #14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 #15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, which=op_search) at backover.c:704 #16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at backover.c:726 #17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at search.c:368 #18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 #19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) at connection.c:1083 #20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at connection.c:1210 #21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at tpool.c:625 #22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 #23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) And I have obtained the following stack trace analyzing the core file dumped by the slapd process: (gdb) bt #0 0xff3bf430 in rtld_db_dlactivity () from /lib/ld.so.1 #1 0xff3bf5f0 in rd_event () from /lib/ld.so.1 #2 0xff3c06e4 in lm_delete () from /lib/ld.so.1 #3 0xff3c8dbc in remove_so () from /lib/ld.so.1 #4 0xff3caa24 in remove_hdl () from /lib/ld.so.1 #5 0xff3c4d5c in dlclose_intn () from /lib/ld.so.1 #6 0xff3c4e70 in dlclose () from /lib/ld.so.1 #7 0xfdf62b44 in pkcs11_slottable_delete () from /usr/lib/libpkcs11.so.1 #8 0xfdf5d66c in pkcs11_fini () from /usr/lib/libpkcs11.so.1 #9 0xfe240dc8 in _postfork_child_handler () from /usr/lib/libc.so.1 #10 0xfe2b2970 in fork1 () from /usr/lib/libc.so.1 #11 0x001f0d48 in lutil_detach (debug=0, do_close=0) at detach.c:76 #12 0x00027c68 in main (argc=3, argv=0xffbffb04) at main.c:864 I hope this helps. Thanks. Eduardo ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

(ITS#5377) Why can I delete attributeType and objectClass together
by bsdrab＠gmail.com 13 Feb '08

13 Feb '08

Full_Name: Niki Petrov Version: 2.4.6 OS: FreeBSD 7.0 RC1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.125.204.194) Why can I delete attributeType and objectClass together, and how can I do this? ----------------------------------------------------------------------------------------- # ldapmodify -x -W -D "cn=rtoo,o=hoji,l=gu,c=fr" -f /usr/home/testu/scripts/user_delete ... ..(file user_delete) dn: uid=user,o=hoji,l=gu,c=fr changetype: modify delete: virtualdomain virtualdomain: hoji.gu.fr delete: objectClass objectClass: CourierDomainAlias ..... (error in command-line) ldapmodify: wrong attributeType at line 5, entry "uid=user,o=hoji,l=gu,c=fr"

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by hyc＠symas.com 13 Feb '08

13 Feb '08

quanah(a)zimbra.com wrote: > With a build of 2.3 with the (adjusted) patches from HEAD, it looks like > this issue is resolved. I fully sync'd a replica from the master, and > after it was done, I did a slapcat of them. > > A direct diff shows a lot of entries out of order (because the replica gets > them in multiple refresh phases), however, if I sort the two ldif files, > and do a diff, I get: > > [zimbra@smtp-2 tmp]$ sort slave.ldif>slave.ldif.s > [zimbra@smtp-2 tmp]$ sort master.ldif>master.ldif.s > [zimbra@smtp-2 tmp]$ diff -u master.ldif.s slave.ldif.s > [zimbra@smtp-2 tmp]$ > > No diff. So I believe this is fixed. Sound correct? Sounds good to me. I guess this should go into both RE23 and RE24. -- -- Howard Chu Chief Architect, 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#5370) race condition in slap_op_time()
by h.b.furuseth＠usit.uio.no 13 Feb '08

13 Feb '08

hyc(a)symas.com writes: > Except that this will take a lot more restructuring in accesslog. Going with > the quick fix for now. Looks like I didn't notice the first use of o_tincr in accesslog:-( I guess accesslog can set an "I need o_tincr" flag somewhere, which slapd will then obey. -- Hallvard

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

--On February 13, 2008 3:14:37 AM +0000 quanah(a)zimbra.com wrote: > > > --On February 13, 2008 3:03:46 AM +0000 quanah(a)zimbra.com wrote: > >> >> And, with the patch for ITS#5282, all replication stops (probably a good >> thing). > > More specifically, the replica stops accepting any new changes, since it > can't proceed on the MODs to a non-existent entry. The master of course > continues to accept and record changes, and any non-problematic replicas > continue to receive changes. With a build of 2.3 with the (adjusted) patches from HEAD, it looks like this issue is resolved. I fully sync'd a replica from the master, and after it was done, I did a slapcat of them. A direct diff shows a lot of entries out of order (because the replica gets them in multiple refresh phases), however, if I sort the two ldif files, and do a diff, I get: [zimbra@smtp-2 tmp]$ sort slave.ldif >slave.ldif.s [zimbra@smtp-2 tmp]$ sort master.ldif >master.ldif.s [zimbra@smtp-2 tmp]$ diff -u master.ldif.s slave.ldif.s [zimbra@smtp-2 tmp]$ No diff. So I believe this is fixed. Sound correct? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

--On February 13, 2008 3:03:46 AM +0000 quanah(a)zimbra.com wrote: > > And, with the patch for ITS#5282, all replication stops (probably a good > thing). More specifically, the replica stops accepting any new changes, since it can't proceed on the MODs to a non-existent entry. The master of course continues to accept and record changes, and any non-problematic replicas continue to receive changes. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

--On February 13, 2008 2:57:39 AM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > If you start a replica with an empty DB, using delta-sync replication, > and the master is receiving a high rate of changes, the Refresh phase > will skip entries that have been modified. When it moves to the > "persist" phase, delta-syncrepl will send modification diffs to those > entries rather than the full entries, so entries end up missing, having > never been sent in a full form. And, with the patch for ITS#5282, all replication stops (probably a good thing). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

Full_Name: Quanah Gibson-Mount Version: 2.3.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) If you start a replica with an empty DB, using delta-sync replication, and the master is receiving a high rate of changes, the Refresh phase will skip entries that have been modified. When it moves to the "persist" phase, delta-syncrepl will send modification diffs to those entries rather than the full entries, so entries end up missing, having never been sent in a full form.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by hyc＠symas.com 12 Feb '08

12 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >>> Both RFCs disagree. >> They are wrong. Or at least, under-specified. In X.501 section 17.3 >> "Directory Distribution Model" it's quite clear that all of the >> components of a distributed directory must belong to a single DIT. > > Which is not true in the LDAP world, and I don't know about today's > X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe > the X.500 world has also switched to 'dc' structure, I don't know. > > Anyway, LDAP is not X.500. RFC4510 Section 2 "Relationship to X.500" This technical specification defines LDAP in terms of [X.500] as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500 (1993) series of International Telecommunication Union - Telecommunication Standardization (ITU-T) Recommendations when providing the service. > Remember, LDAP referrals need not even be > LDAP URLs. My guess is that's one reason for the difference from X.500: > When you can even return a HTTP URL, why should you _not_ be allowed > to return a far smaller change from the original URL? As I've said many times before, LDAP referrals are a poorly designed piece of junk. The fact that the spec leaves it open to return other types of URLs but nobody in the world knows what that should actually mean to an LDAP client is just further proof of the abysmal lack of thought that went into the design. > Also LDAP started out a lot sloppier than X.500. That's self-evident. ;) > Getting some response > which hopefully resembled what you wanted was better than none:-) Getting a wrong answer is worse than getting no answer, because the client will just assume that everything is OK and keep going, rather than reporting an error to the user. >> And again, the service model requires the directory to store the >> client's data without any alteration. If the client wants to create >> the entry "cn=me,o=we" either that exact entry must be created, or the >> operation must fail. > > Well, the operation does fail in the original server. Then the client > may try another operation at another server... I don't know if that's a > valid interpretation of the service model or not. In any case, it's a > detail compared to the mess No, in this case the client is not being told to retry the *same* operation in another server, it's being told to try a *very different* operation in another server. Once again, the client made a specific request to create an entry with a specific DN. If the server can't honor the request as specified then it should fail and the operation should halt. Anyway, the very existence of LDAP referrals is a violation of the service model. X.501(1993) section 18.2: It is a requirement of the Directory that, for particular modes of user interaction, the distribution of the directory be rendered transparent, thereby giving the effect that the whole of the DIB appears to be within each and every DSA. LDAPv1 had no referrals. When they were introduced in LDAPv2 it's clear that nobody knew what they were doing, or nobody wanted to tackle the glaring absence of an analogue to X.500 DSP. They should never have been introduced. We're stuck with them for now, but we can at least try to make them make sense. -- -- Howard Chu Chief Architect, 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#5370) race condition in slap_op_time()
by hyc＠symas.com 12 Feb '08

12 Feb '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> However as far as I can tell, only the accesslog overlay uses >> op->o_tincr, the value which needs the mutex. And accesslog >> calls slap_op_time() itself when it needs that value. >> So maybe we should remove the op->o_tincr field. Other calls >> to slap_op_time() can be replaced with slap_get_time(). > > Sounds like a good idea. It was somewhat redundant with the CSN counter > (except that this was for all operations, and CSN was only for write > operations) and it never became generally useful. (Shifted to microsecond > timestamps in 2.4, because tincr isn't useful across multiple servers.) I > guess it makes more sense to make it specific to accesslog. > Except that this will take a lot more restructuring in accesslog. Going with the quick fix for now. -- -- Howard Chu Chief Architect, 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#5374) accesslog+hdb crash with test043-delta-syncrepl
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 12, 2008 6:12:08 PM +0000 quanah(a)zimbra.com wrote: > (and it passed 10 times for me successfully). At Hallvard's request, I patched accesslog thusly: diff -u accesslog.c.orig accesslog.c --- accesslog.c.orig 2008-02-12 10:18:16.000000000 -0800 +++ accesslog.c 2008-02-12 10:21:46.000000000 -0800 @@ -914,6 +914,7 @@ ldap_pvt_thread_mutex_lock( &li->li_log_mutex ); old = li->li_old; li->li_old = NULL; + assert(li->li_unlock == (int) ldap_pvt_thread_self()); li->li_unlock = 0; ldap_pvt_thread_mutex_unlock( &li->li_op_mutex ); } @@ -1262,7 +1263,8 @@ * overlays like refint to keep working. */ ldap_pvt_thread_mutex_lock( &li->li_op_mutex ); - li->li_unlock = 1; + /* li->li_unlock = 1; */ + li->li_unlock = (int) ldap_pvt_thread_self(); if ( li->li_oldf && ( op->o_tag == LDAP_REQ_DELETE || op->o_tag == LDAP_REQ_MODIFY )) { int rc; Multiple runs of the test continued to be successful. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

(and it passed 10 times for me successfully). --On February 12, 2008 5:59:22 PM +0000 quanah(a)zimbra.com wrote: > > > --On February 12, 2008 12:11:50 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> Full_Name: Hallvard B Furuseth >> Version: RE23 >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> /configure \ >> --disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \ >> --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \ >> --enable-backends --disable-sql --enable-overlays \ >> CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' > > I built as: > > LD_LIBRARY_PATH="/usr/local/lib" CC=gcc CXX=g++ CFLAGS='-g -O0' > CXXFLAGS='-g -O0' CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' sh > configure --datadir='${prefix}/lib' --libexecdir='${prefix}/lib' > --sharedstatedir='${prefix}/lib' --prefix=/usr/local > --disable-ipv6 --with-cyrus-sasl --with-tls > --enable-dynamic --enable-slapd --enable-modules > --enable-spasswd --enable-rewrite > --enable-rlookups --enable-wrappers > --enable-backends=mod --disable-shell > --disable-sql --enable-overlays=mod --enable-slapi=yes > > > Thread package selected is: > > -pthread > > s,@LTHREAD_LIBS@, -pthread,;t t > > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 12, 2008 12:11:50 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > /configure \ > --disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \ > --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \ > --enable-backends --disable-sql --enable-overlays \ > CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' I built as: LD_LIBRARY_PATH="/usr/local/lib" CC=gcc CXX=g++ CFLAGS='-g -O0' CXXFLAGS='-g -O0' CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' sh configure --datadir='${prefix}/lib' --libexecdir='${prefix}/lib' --sharedstatedir='${prefix}/lib' --prefix=/usr/local --disable-ipv6 --with-cyrus-sasl --with-tls --enable-dynamic --enable-slapd --enable-modules --enable-spasswd --enable-rewrite --enable-rlookups --enable-wrappers --enable-backends=mod --disable-shell --disable-sql --enable-overlays=mod --enable-slapi=yes Thread package selected is: -pthread s,@LTHREAD_LIBS@, -pthread,;t t --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5375) Slapd core dumps
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote: > Full_Name: Eduardo Izaguirre Pazos > Version: 2.4.7 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.0.110.2) > > > Hi all, we are using Openldap as a metadirectory against a couple of AD > servers. The slapd server core dumps when a request of all attributes of > one entry is issued. This is the output of the slapd server using the > debug level -1: Hi Eduardo, Please test with the current CVS of REL_ENG_2_4. Please build without optimization, and with debugging symbols. Make sure you don't strip slapd on install. If you can repeat this with current CVS, please provide a gdb backtrace of the non-optimized, non-stripped slapd. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5373) ppolicy issues when deleting the password attribute, even if no password checking is enforced
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

This sounds like a duplicate of ITS#5285 to me. Which will be fixed in 2.4.8, but is not being fixed in 2.3. --Quanah --On February 12, 2008 9:57:46 AM +0000 Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.3.40 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.55.250.67) > > > Here are my ppolicy settings: > password policy > overlay ppolicy > ppolicy_use_lockout > ppolicy_default cn=default,ou=policies,dc=futurs,dc=inria,dc=fr > > Here is my default entry: > dn: cn=default,ou=policies,dc=futurs,dc=inria,dc=fr > cn: default > objectClass: pwdPolicy > objectClass: organizationalRole > pwdAttribute: userPassword > pwdMaxAge: 0 > pwdInHistory: 0 > pwdCheckQuality: 0 > > According to documentation, no user password quality checking should take > places, however, trying to delete userPassword attribute for an user > triggers at least a server error with this LDIF fragment: > dn: userdn > changetype: modify > delete: userPassword > > ldapmodify: Internal (implementation specific) error (80) > additional info: Internal Error > > Error message in logs: "cannot locate modification supplying new password" > > Or worst, a server crash with this one: > dn: userdn > changetype: modify > replace: userPassword > > No error message from ldapmodify, and no error message in the logs in > this case. > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5375) Slapd core dumps
by ecip＠gmv.es 12 Feb '08

12 Feb '08

Full_Name: Eduardo Izaguirre Pazos Version: 2.4.7 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.0.110.2) Hi all, we are using Openldap as a metadirectory against a couple of AD servers. The slapd server core dumps when a request of all attributes of one entry is issued. This is the output of the slapd server using the debug level -1: /opt/openldap-2.4.7/libexec/slapd -d -1 -f /opt/openldap-2.4.7/etc/openldap/slapd.conf -h "ldap://172.22.2.43/" and the output is: <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 The server wa compiled with the following configure: ./configure --prefix=/opt/openldap-2.4.7 --enable-cleartext --enable-crypt --enable-lmpasswd --enable-rewrite --enable-bdb --enable-ldap --enable-meta --with-tls --enable-proxycache --enable-rwm Cheers and thanks in advance. Eduardo

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs