- openldap-bugs - openldap.org

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 21 Jul '09

21 Jul '09

steve(a)falchion.com wrote: > 2.4.17 fails in an identical manner. > > For those interested, 2.4.17 failed to compile because the installed > 2.4.16 libs were being picked up instead of the freshly compiled ones > during the link phase. Looks like a problem in your OpenSSL build, not in OpenLDAP. > > Steve > > On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: >> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work >> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? >> >> Steve >> >> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: >>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton >>> <steve(a)falchion.com> wrote: >>> >>>> Haven't tried it. is it stable now (or soon to be?) >>> >>> I'd assume that depends on what bugs people report against it. Knowing >>> whether or not this affects 2.4.17 would certainly be useful in that >>> determination. ;) >>> >>> --Quanah -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

2.4.17 fails in an identical manner. For those interested, 2.4.17 failed to compile because the installed 2.4.16 libs were being picked up instead of the freshly compiled ones during the link phase. Steve On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: > Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work > on it, but in the meantime, any ideas why 2.4.16 is crashing thus? > > Steve > > On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > > --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > > <steve(a)falchion.com> wrote: > > > > > Haven't tried it. is it stable now (or soon to be?) > > > > I'd assume that depends on what bugs people report against it. Knowing > > whether or not this affects 2.4.17 would certainly be useful in that > > determination. ;) > > > > --Quanah > > > > -- > > > > Quanah Gibson-Mount > > Principal Software Engineer > > Zimbra, Inc > > -------------------- > > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 20 Jul '09

20 Jul '09

Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work on it, but in the meantime, any ideas why 2.4.16 is crashing thus? Steve On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > <steve(a)falchion.com> wrote: > > > Haven't tried it. is it stable now (or soon to be?) > > I'd assume that depends on what bugs people report against it. Knowing > whether or not this affects 2.4.17 would certainly be useful in that > determination. ;) > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by quanah＠zimbra.com 20 Jul '09

20 Jul '09

--On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton <steve(a)falchion.com> wrote: > Haven't tried it. is it stable now (or soon to be?) I'd assume that depends on what bugs people report against it. Knowing whether or not this affects 2.4.17 would certainly be useful in that determination. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 20 Jul '09

20 Jul '09

Haven't tried it. is it stable now (or soon to be?) Steve On Mon, 2009-07-20 at 15:28 -0700, Quanah Gibson-Mount wrote: > --On Monday, July 20, 2009 5:44 PM +0000 steve(a)falchion.com wrote: > > > Full_Name: Steve Paras-Charlton > > Version: 2.4.16 > > OS: AIX > > URL: ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1 > > Submission from: (NULL) (66.18.215.114) > > > > > > slapd works fine unless I enable TLS and give it certificates > > (self-signed). Segfault occurs after reading config and opening > > certificate files. > > Does this happen with 2.4.17? > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by quanah＠zimbra.com 20 Jul '09

20 Jul '09

--On Monday, July 20, 2009 5:44 PM +0000 steve(a)falchion.com wrote: > Full_Name: Steve Paras-Charlton > Version: 2.4.16 > OS: AIX > URL: ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1 > Submission from: (NULL) (66.18.215.114) > > > slapd works fine unless I enable TLS and give it certificates > (self-signed). Segfault occurs after reading config and opening > certificate files. Does this happen with 2.4.17? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 20 Jul '09

20 Jul '09

Full_Name: Steve Paras-Charlton Version: 2.4.16 OS: AIX URL: ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1 Submission from: (NULL) (66.18.215.114) slapd works fine unless I enable TLS and give it certificates (self-signed). Segfault occurs after reading config and opening certificate files. built with: gcc 4.2.0, openssl 9.8.840 configure --enable-crypt --enable-modules --enable-overlays --with-tls=openssl --prefix=/usr/local backtrace, program trace and slapd.conf attached ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1

1 0

(ITS#6220) Problem with writetimeout
by moenoel＠informatik.uni-bremen.de 20 Jul '09

20 Jul '09

Full_Name: Christian Manal Version: 2.4.17 OS: SunOS 5.10 Generic_139556-08 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) Clients that take a long time to process search results are geting a writetimeout, even though the keyword is unset or 0 in slapd.conf. Setting the value to a big enough number solves the problem, but that behavior doesn't conform to the docs. Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of entries from the directory, but failed sporadically on slow systems since updating to OpenLDAP 2.4.17. Backend is hdb using BDB 4.4 from opencsw repository. Server setup is one master and four slaves on Solaris 10. Sample of 'stats' log: Jul 20 11:42:43 ldapserver slapd[9053]: [ID 848112 local4.debug] conn=12479 fd=79 ACCEPT from IP=192.168.1.1:50210 (IP=0.0.0.0:389) Jul 20 11:42:43 ldapserver slapd[9053]: [ID 270379 local4.debug] conn=12479 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 560212 local4.debug] conn=12479 op=0 STARTTLS Jul 20 11:42:43 ldapserver slapd[9053]: [ID 875301 local4.debug] conn=12479 op=0 RESULT oid= err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]: [ID 105384 local4.debug] conn=12479 fd=79 TLS established tls_ssf=256 ssf=256 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 215403 local4.debug] conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com" method=128 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 600343 local4.debug] conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com" mech=SIMPLE ssf=0 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 588225 local4.debug] conn=12479 op=1 RESULT tag=97 err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]: [ID 469902 local4.debug] conn=12479 op=2 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=2 filter="(objectClass=posixAccount)" Jul 20 11:42:43 ldapserver slapd[9053]: [ID 744844 local4.debug] conn=12479 op=2 SRCH attr=uid userpassword uidnumber gidnumber gecos homedirectory loginshell Jul 20 11:43:00 ldapserver slapd[9053]: [ID 485650 local4.debug] conn=12479 fd=79 closed (writetimeout) The (slightly modified) config files of the master and the slaves can be obtained here: http://www.informatik.uni-bremen.de/~moenoel/ldap/master.conf http://www.informatik.uni-bremen.de/~moenoel/ldap/slaves.conf

1 0

Re: (ITS#6218) MirrorMode documentation error?
by quanah＠zimbra.com 17 Jul '09

17 Jul '09

--On Friday, July 17, 2009 11:05 PM +0000 richard(a)theloop.eu wrote: > Full_Name: Richard Watson > Version: 2.4.16 > OS: Mac OS X > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (41.177.22.129) > > > In section 18.3.4 MirrorMode: > > MirrorMode node 1: ># Global section > serverID 1 ># database section ># syncrepl directive > syncrepl rid=001 > > > I believe this should end with "rid=002" Why? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6218) MirrorMode documentation error?
by richard＠theloop.eu 17 Jul '09

17 Jul '09

Full_Name: Richard Watson Version: 2.4.16 OS: Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (41.177.22.129) In section 18.3.4 MirrorMode: MirrorMode node 1: # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 I believe this should end with "rid=002"

1 0

(ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 16 Jul '09

16 Jul '09

Full_Name: Jim van Keulen Version: 2.4.16 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.37.192.24) Using openldap-2.4.16 proxcache to search a SUN Directory Server for user data, a query identified by the proxycache server to be CACHEABLE and ANSWERABLE does not return data. For some users (uid's) the data is returned, while not for others. Config: database ldap suffix "dc=few,dc=vu,dc=nl" rootdn cn=Manager,dc=few,dc=vu,dc=nl rootpw secret tls start uri ldap://klondike.few.vu.nl acl-bind bindmethod=simple binddn="cn=sambaLdapManager,ou=Special Users,dc=few,dc=vu,dc=nl" credentials="xxx" sizelimit unlimited overlay pcache proxycache bdb 100000 10 1000 100 proxyAttrset 0 gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass uid uidNumber homeDirectory sambaPwdLastSet sambaPwdCanChange sambaPwdMustChange sambaLogonTime sambaLogoffTime sambaKickoffTime sn sambaHomeDrive sambaHomePath sambaLogonScript sambaProfilePath sambaUserWorkstations sambaSID sambaPrimaryGroupSID sambaDomainName sambaAcctFlagssambaMungedDial sambaBadPasswordCount sambaBadPasswordTime sambaPasswordHistory modifyTimestamp sambaLogonHours modifyTimestamp sambaMaxPwdAge sambaPwdHistoryLength memberUid proxyTemplate (&(objectClass=)(uid=)) 0 1800 cachesize 10000 directory /var/opt/openldap/openldap-data/proxy access to * by * write index objectclass eq index cn pres,sub,eq index sn pres,sub,eq End Config I query with ldapsearch -x -h flits '(&(objectClass=sambaSamAccount)(uid=????))' uid This returns data when e.g. uid=jim, but not when e.g. uid=hbokman. I have no clue why it works for some users, but not for others. When I query the first time I get the requested data from the proxied server fine. It is cached, but not always retrieved. ldapsearch -x -h flits '(&(objectClass=sambaSamAccount)(uid=jim))' uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=jim)) # requesting: uid # # jim, People, few.vu.nl dn: uid=jim,ou=People,dc=few,dc=vu,dc=nl uid: jim # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 **** output from slapd -d4096 for query ****** query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=jim)) Lock QC index = 31f738 QUERY ANSWERABLE ************************************** ldapsearch -x -h flits '(&(objectClass=sambaSamAccount)(uid=hbokman))' uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=hbokman)) # requesting: uid # # search result search: 2 result: 0 Success # numResponses: 1 ****** output form slapd -d4096 for query ****** query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=hbokman)) Lock QC index = 31f738 QUERY ANSWERABLE ***************************************

1 0

Re: (ITS#6216) Slapd crashes when adding a backend without olcsuffix but with a olcsubordinate
by sebastien.bahloul＠gmail.com 16 Jul '09

16 Jul '09

--Boundary-00=_qWzXKhFjpfl1KM/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Successfully tested with and without a valid olcSubordinate attribute. Thanks :) Le jeudi 16 juillet 2009 15:39:31, Pierangelo Masarati a =E9crit : > sebastien.bahloul(a)gmail.com wrote: > > Full_Name: Sebastien Bahloul > > Version: 2.X (HEAD from July, 15 2009) > > OS: Ubuntu 9.04 64 bits > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.65.230.146) > > > > > > It seems that slapd crashes when I try to add a simple hdb backend (also > > confirmed with a bdb) without an olcSuffix attribute but with an > > olcSubordinate attribute value : > > Fixed in HEAD, please test. > > Also, please note that olcSubordinate: FALSE is not valid; the > olcSubordinate can only be "TRUE" or "advertise". If you don't want a > database to be subordinate, simply omit the olcSubordinate attribute > from the configuration. > > p. --Boundary-00=_qWzXKhFjpfl1KM/ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-= html40/strict.dtd"><html><head><meta name=3D"qrichtext" content=3D"1" /><st= yle type=3D"text/css">p, li { white-space: pre-wrap; }</style></head><body = style=3D" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-s= tyle:normal;">Successfully tested with and without a valid olcSubordinate a= ttribute.<br> <p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma= rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u= ser-state:0;"><br></p>Thanks :)<br> <p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma= rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u= ser-state:0;"><br></p>Le jeudi 16 juillet 2009 15:39:31, Pierangelo Masarat= i a =E9crit :<br> > sebastien.bahloul(a)gmail.com wrote:<br> > > Full_Name: Sebastien Bahloul<br> > > Version: 2.X (HEAD from July, 15 2009)<br> > > OS: Ubuntu 9.04 64 bits<br> > > URL: ftp://ftp.openldap.org/incoming/<br> > > Submission from: (NULL) (80.65.230.146)<br> > ><br> > ><br> > > It seems that slapd crashes when I try to add a simple hdb backen= d (also<br> > > confirmed with a bdb) without an olcSuffix attribute but with an<= br> > > olcSubordinate attribute value :<br> ><br> > Fixed in HEAD, please test.<br> ><br> > Also, please note that olcSubordinate: FALSE is not valid; the<br> > olcSubordinate can only be "TRUE" or "advertise". If you don't want a= <br> > database to be subordinate, simply omit the olcSubordinate attribute<b= r> > from the configuration.<br> ><br> > p.<br> <p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma= rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u= ser-state:0;"><br></p></body></html> --Boundary-00=_qWzXKhFjpfl1KM/--

1 0

Re: (ITS#6216) Slapd crashes when adding a backend without olcsuffix but with a olcsubordinate
by masarati＠aero.polimi.it 16 Jul '09

16 Jul '09

sebastien.bahloul(a)gmail.com wrote: > Full_Name: Sebastien Bahloul > Version: 2.X (HEAD from July, 15 2009) > OS: Ubuntu 9.04 64 bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.65.230.146) > > > It seems that slapd crashes when I try to add a simple hdb backend (also > confirmed with a bdb) without an olcSuffix attribute but with an olcSubordinate > attribute value : Fixed in HEAD, please test. Also, please note that olcSubordinate: FALSE is not valid; the olcSubordinate can only be "TRUE" or "advertise". If you don't want a database to be subordinate, simply omit the olcSubordinate attribute from the configuration. p.

1 0

(ITS#6216) Slapd crashes when adding a backend without olcsuffix but with a olcsubordinate
by sebastien.bahloul＠gmail.com 16 Jul '09

16 Jul '09

Full_Name: Sebastien Bahloul Version: 2.X (HEAD from July, 15 2009) OS: Ubuntu 9.04 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.65.230.146) It seems that slapd crashes when I try to add a simple hdb backend (also confirmed with a bdb) without an olcSuffix attribute but with an olcSubordinate attribute value : dn: olcDatabase=hdb,cn=config objectclass: olcDatabaseConfig objectclass: olcConfig objectclass: olcHdbConfig objectclass: top olcdatabase: hdb olcdbdirectory: /tmp olcsubordinate: FALSE GDB Backtrace : conn=0 op=1 ADD dn="olcDatabase=hdb,cn=config" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd13c010950 (LWP 7210)] 0x0000000000482fd1 in glue_sub_attach (online=1) at backglue.c:1167 1167 Debug( LDAP_DEBUG_ANY, "glue: no superior found for sub %s!\n", (gdb) bt #0 0x0000000000482fd1 in glue_sub_attach (online=1) at backglue.c:1167 #1 0x0000000000408364 in config_subordinate (c=0x7fd13c00e5f0) at bconfig.c:2354 #2 0x0000000000415c33 in config_set_vals (Conf=0x7dbe20, c=0xffffffff) at config.c:325 #3 0x000000000041989d in config_parse_add (ct=0x7dbe20, c=0x7fd13c00e5f0, valx=<value optimized out>) at config.c:665 #4 0x000000000040fdea in config_add_internal (cfb=0x7e5680, e=0x19492f8, ca=0x7fd13c00e5f0, rs=<value optimized out>, renum=0x7fd13c00e5ec, op=<value optimized out>) at bconfig.c:4573 #5 0x00000000004109d3 in config_back_add (op=0x1a47b30, rs=0x7fd13c00fc70) at bconfig.c:4800 #6 0x000000000042695e in fe_op_add (op=0x1a47b30, rs=0x7fd13c00fc70) at add.c:334 #7 0x000000000042728f in do_add (op=0x1a47b30, rs=0x7fd13c00fc70) at add.c:194 #8 0x000000000041f7b7 in connection_operation (ctx=0x7fd13c00fdd0, arg_v=<value optimized out>) at connection.c:1115 #9 0x0000000000420455 in connection_read_thread (ctx=0x7fd13c00fdd0, argv=<value optimized out>) at connection.c:1251 #10 0x0000000000528010 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #11 0x00007fd1526943ba in start_thread () from /lib/libpthread.so.0 #12 0x00007fd151c10fcd in clone () from /lib/libc.so.6 #13 0x0000000000000000 in ?? ()

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 14 Jul '09

14 Jul '09

Rich Megginson wrote: > Howard Chu wrote: >> Ok. The configure patches are in too, so moznss may be selected. But I >> think we'll wait on making this generally available until we know what >> the story will be for PEM and multi-init. > Ok Fyi, the code patches are in 2.4.17, but I held back the configure patches (which are only in HEAD). So you should be able to manually define HAVE_MOZNSS for testing purposes with this release. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6215) liblber problems
by h.b.furuseth＠usit.uio.no 14 Jul '09

14 Jul '09

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Given these declarations: #include <lber.h> #define LBER_EXBUFSIZ 4060 /* from liblber/io.c */ static char data[8000]; struct berval bv; BerElement *ber; Buffer overrun i ber_flatten(,,0): ber = der_alloc(); ber_printf(ber, "o", data, LBER_EXBUFSIZ - 4); ber_flatten2(ber, &bv, 0); ber_flatten2(,,0) \0-terminates the Ber buffer, but does not grow it first at need. Simplest fix is to allocate an extra byte in ber_realloc(), and reduce LBER_EXBUFSIZ by 1 to compensate. I don't know how kosher it is to write into the ber buffer in the first place though. Coredump - write through NULL pointer: ber_flatten2(der_alloc(), &bv, 0); A fresh Ber has no buffers yet, the buffer pointers are NULL. \0-terminating a NULL pointer doesn't work too well. Don't know if it should be called a bug though, since ber_flatten2() doesn't work right on an incomplete Ber element either (due to seqorset stuff). The NULL pointers in a fresh ber also mean ber_write, ber_len() & co do pointer arithmetic on NULL pointers, which is not valid. Oh well, it seems to work on most machines. Buffer overrun in ber_write(): ber = der_alloc(); ber_printf(ber, "{"); ber_write(ber, data, 6000, 0); ber_write() needs buffer space and calls ber_realloc(ber, 6000). However "{" has moved ber->ber_sos->sos_ptr (the write destination) 6 bytes beyond ber->ber_end, so 6006 bytes are actually needed. ber_realloc() does not know that, and allocates 6000 bytes. It cannot happen with ber_write() called from liblber: Next liblber write after "{" will be just a few bytes with the next element's tag. ber_realloc() always allocates 4060 bytes or more - moving sos_ptr beyond ber_end again. This can only happen if a caller outside liblber generates a complete "tag, length, contents" element >= 4060 bytes and ber_write()s it in one operation. There are ber_write()s in libldap and slapd/connection.c, but haven't checked if any are at risk. Don't know where to fix it: - in ber_realloc(), most techinically correct. - in ber_write() - simpler since it already knows about sos_ptr. - in ber_start_seqorset() - always alloc a buffer, never point beyond allocated data. Cleanest but most space-costly.

1 0

(ITS#6214) slapacl causes bdb_db_close error
by dkastens＠uni-osnabrueck.de 14 Jul '09

14 Jul '09

Full_Name: Dirk Kastens Version: 2.4.17 OS: Red Hat Enterprise Linux Server release 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.173.16.92) I'm using BerkeleyDB.4.6.21 This issue existed in openldap 2.4.16, so I updated to 2.4.17, but the error still exists. When I call "slapacl", for example slapacl -b uid=xmuster,ou=people,dc=myorg -D uid=xmuster,ou=people,dc=myorg the output ends with the lines: bdb(dc=myorg): Error: closing the transaction region with active transactions bdb_db_close: database "dc=myorg": close failed: Invalid argument (22) and the database is corrupted. slapd wasn't running during execution. After running slapacl slapd starts with the message: bdb_db_open: database "dc=myorg": unclean shutdown detected; attempting recovery. This seems to be an old but re-occuring bug.

1 0

(ITS#6213) test056-monitor fails when using non-default SLAPD_BASEPORT
by rhafer＠suse.de 14 Jul '09

14 Jul '09

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.248.36) # SLAPD_BASEPORT=10000 ./run test056-monitor Cleaning up test run directory leftover from previous run. [..] Comparing filter output... comparison failed - connection monitor output is not correct The problem is that data/monitor1.out contains a hardcoded portnumber. I guess we should use @PORT1@ and have conf.sh substitute the setting. Fix is on its way to cvs.

1 0

openldap-server-2.4.16_1 segmentation fault
by Alexander Panyushkin 14 Jul '09

14 Jul '09

Hello. when i to restart the apache, slapd is segmentation fault. on the version of openldap 2.3 is an error that I need help that to decide this problem. OS - FreeBSD 7.2-RELEASE-p2 amd64 apachectl -VV Server version: Apache/2.0.63 Server built: Jul 9 2009 17:34:07 Server's Module Magic Number: 20020903:13 Server loaded: APR 0.9.17, APR-UTIL 0.9.15 Compiled using: APR 0.9.17, APR-UTIL 0.9.15 Architecture: 64-bit Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_FLOCK_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/usr/local" -D SUEXEC_BIN="/usr/local/bin/suexec" -D DEFAULT_PIDLOG="/var/run/httpd.pid" -D DEFAULT_SCOREBOARD="/var/run/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/accept.lock" -D DEFAULT_ERRORLOG="/var/log/httpd-error.log" -D AP_TYPES_CONFIG_FILE="etc/apache2/mime.types" -D SERVER_CONFIG_FILE="etc/apache2/httpd.conf" nss_ldap.conf host 127.0.0.1 base dc=informalians,dc=org ldap_version 3 port 389 scope sub timelimit 10 bind_timelimit 10 bind_policy soft nss_connect_policy oneshot idle_timelimit 300 nss_paged_results yes pagesize 1000 nss_base_passwd dc=informalians,dc=org?sub nss_base_group dc=informalians,dc=org?sub nss_base_passwd dc=informalians,dc=org?sub nss_base_shadow dc=informalians,dc=org?sub ssl off nsswitch.conf passwd: files ldap shadow: files ldap group: files ldap hosts: files dns networks: files services: files shells: files protocols: files rpc: files passwd_compat: nis group_compat: nis services_compat: nis /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf -d 1 ######################################### ... slapd starting slap_listener_activate(6): >>> slap_listener(ldap:///) connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=0 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 10 do_bind: v3 anonymous bind slap_listener_activate(6): >>> slap_listener(ldap:///) slap_listener_activate(6): >>> slap_listener(ldap:///) connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next connection_get(11): got connid=1 connection_read(11): checking for input on id=1 ber_get_next ber_get_next: tag 0x30 len 167 contents: ber_get_next conn=0 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=informalians,dc=org> <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=1 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: ==> limits_get: conn=0 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") => hdb_dn2id("dc=informalians,dc=org") >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=1 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 11 connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next <= hdb_dn2id: got id=0x1 do_bind: v3 anonymous bind entry_decode: "" <= entry_decode() search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=7, last=7 bdb_search_candidates: id=1 first=7 last=7 entry_decode: "" <= entry_decode() => send_search_entry: conn 0 dn="cn=GOsa Administrators,ou=groups,dc=informalians,dc=org" ber_flush2: 139 bytes to sd 10 slap_listener_activate(6): >>> slap_listener(ldap:///) <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 51 bytes to sd 10 connection_get(11): got connid=1 connection_read(11): checking for input on id=1 ber_get_next ber_get_next: tag 0x30 len 167 contents: connection_get(14): got connid=3 ber_get_next connection_read(14): checking for input on id=3 ber_get_next conn=1 op=1 do_search ber_scanf fmt ({miiiib) ber: ber_get_next: tag 0x30 len 12 contents: ber_get_next: tag 0x30 len 12 contents: ber_get_next ber_get_next conn=3 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> conn=2 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=2 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 >>> dnPrettyNormal: <dc=informalians,dc=org> <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: do_bind: v3 anonymous bind ber_scanf fmt ({M}}) ber: slap_listener_activate(6): <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=3 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 14 >>> slap_listener(ldap:///) do_bind: v3 anonymous bind => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=1 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=7, last=7 bdb_search_candidates: id=1 first=7 last=7 => send_search_entry: conn 1 dn="cn=GOsa Administrators,ou=groups,dc=informalians,dc=org" ber_flush2: 139 bytes to sd 11 <= send_search_entry: conn 1 exit. send_ldap_result: conn=1 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 51 bytes to sd 11 connection_get(15): got connid=4 connection_read(15): checking for input on id=4 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=4 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=4 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 15 do_bind: v3 anonymous bind connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next ber_get_next: tag 0x30 len 167 contents: ber_get_next conn=2 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=informalians,dc=org> <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=2 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=7, last=7 bdb_search_candidates: id=1 first=7 last=7 => send_search_entry: conn 2 dn="cn=GOsa Administrators,ou=groups,dc=informalians,dc=org" ber_flush2: 139 bytes to sd 12 <= send_search_entry: conn 2 exit. send_ldap_result: conn=2 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 51 bytes to sd 12 connection_get(14): got connid=3 connection_read(14): checking for input on id=3 ber_get_next ber_get_next: tag 0x30 len 167 contents: ber_get_next conn=3 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=informalians,dc=org> connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=3 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read connection_get(15): got connid=4 connection_read(15): checking for input on id=4 ber_get_next ber_get_next: tag 0x30 len 167 contents: ber_get_next conn=4 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=informalians,dc=org> <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=4 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read zsh: segmentation fault /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf -d 1 -- Best regards Alexander Panyushkin

1 0

(ITS#6212) Assert raised by slapd using back-meta
by jorge.perez＠adaptia.net 14 Jul '09

14 Jul '09

Full_Name: Jorge Perez Burgos Version: 2.4.17pre OS: SLES 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.20) An assert raises using back-meta using REL2_4 in cvs. Sometimes, less often, all threads lock at "ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );" in different parts of back-meta maybe it's related. (gdb) bt #0 0x00002ac209105d45 in raise () from /lib64/libc.so.6 #1 0x00002ac209107140 in abort () from /lib64/libc.so.6 #2 0x00002ac2090ff286 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000005b6836 in ldap_sasl_bind (ld=0x0, dn=0x94b2b0 "cn=manager,dc=operator,dc=com", mechanism=0x0, cred=0x4f5fa3a0, sctrls=0x0, cctrls=0x0, msgidp=0x4f5fa398) at sasl.c:74 #4 0x00000000005695be in meta_back_proxy_authz_bind (mc=0x18e8a60, candidate=2, op=0x2aaae262f380, rs=0x4f5fbd30, sendok=LDAP_BACK_DONTSEND) at bind.c:1526 #5 0x0000000000567379 in meta_back_single_dobind (op=0x2aaae262f380, rs=0x4f5fbd30, mcp=0x4f5fa4d8, candidate=2, sendok=LDAP_BACK_DONTSEND, nretries=10, dolock=1) at bind.c:600 #6 0x000000000056774e in meta_back_dobind (op=0x2aaae262f380, rs=0x4f5fbd30, mc=0x18e8a60, sendok=LDAP_BACK_SENDERR) at bind.c:718 #7 0x0000000000509e5d in meta_back_modify (op=0x2aaae262f380, rs=0x4f5fbd30) at modify.c:54 #8 0x000000000048b2ba in fe_op_modify (op=0x2aaae262f380, rs=0x4f5fbd30) at modify.c:301 #9 0x00000000004f51e6 in overlay_op_walk (op=0x2aaae262f380, rs=0x4f5fbd30, which=op_modify, oi=0x84a430, on=0x0) at backover.c:669 #10 0x00000000004f53e9 in over_op_func (op=0x2aaae262f380, rs=0x4f5fbd30, which=op_modify) at backover.c:721 #11 0x00000000004f54c7 in over_op_modify (op=0x2aaae262f380, rs=0x4f5fbd30) at backover.c:755 #12 0x000000000048abc8 in do_modify (op=0x2aaae262f380, rs=0x4f5fbd30) at modify.c:175 #13 0x000000000046bb42 in connection_operation (ctx=0x4f5fbe70, arg_v=0x2aaae262f380) at connection.c:1115 #14 0x000000000046c0c7 in connection_read_thread (ctx=0x4f5fbe70, argv=0x191) at connection.c:1251 #15 0x00000000005acefa in ldap_int_thread_pool_wrapper (xpool=0x81ec60) at tpool.c:698 #16 0x00002ac208594143 in start_thread () from /lib64/libpthread.so.0 #17 0x00002ac209196b8d in clone () from /lib64/libc.so.6 #18 0x0000000000000000 in ?? () (gdb)

1 0

Re: (ITS#6211) Build error: LDAP_VLV_ERROR
by hyc＠symas.com 13 Jul '09

13 Jul '09

Oops, forgot a commit. Fixed. michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD synced now > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.59.27) > > > Entering subdirectory libldap > make[2]: Entering directory > `/usr/src/michael/openldap/HEAD/openldap/libraries/libldap' > /bin/sh ../../libtool --mode=compile cc -g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER > -DDEVEL -I../../include -I../../include -I/dummy/include > -I/dummy/include -I/dummy/include -I/dummy/include -DSLAP_LIGHTWEIGHT_DISPATCHER > -DDEVEL -DLDAP_LIBRARY -c error.c > cc -g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -I../../include -I../../include > -I/dummy/include -I/dummy/include -I/dummy/include -I/dummy/include > -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -DLDAP_LIBRARY -c error.c -fPIC -DPIC -o > .libs/error.o > error.c: In function ldap_err2string: > error.c:90: error: LDAP_VLV_ERROR undeclared (first use in this function) > error.c:90: error: (Each undeclared identifier is reported only once > error.c:90: error: for each function it appears in.) > make[2]: *** [error.lo] Error 1 > make[2]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/libraries/libldap' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/libraries' > make: *** [all-common] Error 1 > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6211) Build error: LDAP_VLV_ERROR� undeclared
by michael＠stroeder.com 13 Jul '09

13 Jul '09

Full_Name: Michael Ströder Version: HEAD synced now OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.59.27) Entering subdirectory libldap make[2]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/libraries/libldap' /bin/sh ../../libtool --mode=compile cc -g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -I../../include -I../../include -I/dummy/include -I/dummy/include -I/dummy/include -I/dummy/include -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -DLDAP_LIBRARY -c error.c cc -g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -I../../include -I../../include -I/dummy/include -I/dummy/include -I/dummy/include -I/dummy/include -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -DLDAP_LIBRARY -c error.c -fPIC -DPIC -o .libs/error.o error.c: In function ldap_err2string: error.c:90: error: LDAP_VLV_ERROR undeclared (first use in this function) error.c:90: error: (Each undeclared identifier is reported only once error.c:90: error: for each function it appears in.) make[2]: *** [error.lo] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6209) openldap-snacc 2.3.6 + gcc4.4.0
by hyc＠symas.com 13 Jul '09

13 Jul '09

Closing this ITS as a duplicate of #4699 ivan.kovalenko(a)gmail.com wrote: > Full_Name: Ivan Kovalenko > Version: openldap-snacc 2.3.6 > OS: RHAS4u3 i686 > URL: > Submission from: (NULL) (217.74.34.30) > > > When compiling openldap-snacc 2.3.6 using gcc 4.4.0 an varios errors comes out > > http://ivanko.pastebin.com/f5741d572 > > So, one by one > a) bits/fpos.h not found - changed it into ios in inc/asn-chartraits.h > b) rfc1155-smi.c - i've entirely removed c-examples and c++-examples from > makefile - no chance i'd resolve those errors > c) there were some errors after correcting a) like > http://ivanko.pastebin.com/f45802da6 - also cant handle it correctly. > > System info > [ivanko@vm-ivanko openldap-2.4.16]$ uname -a; gcc -v; env|egrep '(FLAGS|LD)' > Linux vm-ivanko.rosenergo.com 2.6.9-78.EL #1 Wed Jul 9 15:27:01 EDT 2008 i686 > i686 i386 GNU/Linux > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: ./configure --prefix=/home/ivanko/local/usr/ > --with-mpfr=/home/ivanko/local/usr --with-gmp=/home/ivanko/local/usr/ > --enable-languages=c,c++,java,objc > Thread model: posix > gcc version 4.4.0 (GCC) > LDFLAGS=-I/home/ivanko/local/usr/lib > CPPFLAGS=-I/home/ivanko/local/usr/include/ > OLDPWD=/u2/ivanko/0/t/openldap-snacc-2.3.6 > LD_LIBRARY_PATH=/home/ivanko/local/usr/lib > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6210) comp_match module
by ivan.kovalenko＠gmail.com 13 Jul '09

13 Jul '09

Full_Name: Ivan Kovalenko Version: 2.4.16 OS: RHAS4u3 i686 URL: Submission from: (NULL) (217.74.34.30) When running tests om comp_match module test031 (openldap-2.4.16 with enable-modules=yes with gcc3.4.5) Can see this after installing comp_match module into tests dir. slapadd init: initiated tool. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) lt_dlopenext failed: (./testdata/comp_libs/compmatch.la) ./testdata/comp_libs/compmatch.so.0: undefined symbol: BEncAsnOcts

1 0

(ITS#6209) openldap-snacc 2.3.6 + gcc4.4.0
by ivan.kovalenko＠gmail.com 12 Jul '09

12 Jul '09

Full_Name: Ivan Kovalenko Version: openldap-snacc 2.3.6 OS: RHAS4u3 i686 URL: Submission from: (NULL) (217.74.34.30) When compiling openldap-snacc 2.3.6 using gcc 4.4.0 an varios errors comes out http://ivanko.pastebin.com/f5741d572 So, one by one a) bits/fpos.h not found - changed it into ios in inc/asn-chartraits.h b) rfc1155-smi.c - i've entirely removed c-examples and c++-examples from makefile - no chance i'd resolve those errors c) there were some errors after correcting a) like http://ivanko.pastebin.com/f45802da6 - also cant handle it correctly. System info [ivanko@vm-ivanko openldap-2.4.16]$ uname -a; gcc -v; env|egrep '(FLAGS|LD)' Linux vm-ivanko.rosenergo.com 2.6.9-78.EL #1 Wed Jul 9 15:27:01 EDT 2008 i686 i686 i386 GNU/Linux Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/home/ivanko/local/usr/ --with-mpfr=/home/ivanko/local/usr --with-gmp=/home/ivanko/local/usr/ --enable-languages=c,c++,java,objc Thread model: posix gcc version 4.4.0 (GCC) LDFLAGS=-I/home/ivanko/local/usr/lib CPPFLAGS=-I/home/ivanko/local/usr/include/ OLDPWD=/u2/ivanko/0/t/openldap-snacc-2.3.6 LD_LIBRARY_PATH=/home/ivanko/local/usr/lib

1 0

Re: (ITS#6208) Timelimit exceeded error when using unlimited timelimits
by quanah＠zimbra.com 10 Jul '09

10 Jul '09

--On Friday, July 10, 2009 7:46 PM +0000 quanah(a)zimbra.com wrote: > So it looks like OpenLDAP has a hard coded 1 hour time limit. Which, of > course, is not correct. Of course, this search shouldn't take an hour, > either. Never mind, there appears to be an issue in the SASL binding so that my account isn't getting correctly mapped. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6208) Timelimit exceeded error when using unlimited timelimits
by quanah＠zimbra.com 10 Jul '09

10 Jul '09

--On Friday, July 10, 2009 6:49 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I executed the following search: > ldap-uat1:/etc/ldap# ldapsearch -LLL -Q -h ldap-uat1 -b > "dc=stanford,dc=edu" >> /dev/null > > Which ended with this error: > Time limit exceeded (3) A second run hit the same error: ldap-uat1:/root# time ldapsearch -LLL -Q -h ldap-uat1 -b "dc=stanford,dc=edu" >/dev/null Time limit exceeded (3) real 60m1.827s user 0m0.008s sys 0m0.004s So it looks like OpenLDAP has a hard coded 1 hour time limit. Which, of course, is not correct. Of course, this search shouldn't take an hour, either. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6208) Timelimit exceeded error when using unlimited timelimits
by quanah＠zimbra.com 10 Jul '09

10 Jul '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I executed the following search: ldap-uat1:/etc/ldap# ldapsearch -LLL -Q -h ldap-uat1 -b "dc=stanford,dc=edu" >/dev/null Which ended with this error: Time limit exceeded (3) Which should never happen, because my bind ID is part of the ldapadmin group, which is allowed to make searches completely free of time or sizelimit restrictions: # Let ldapadmin have limitless searches limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 09 Jul '09

09 Jul '09

On Thu, Jul 9, 2009 at 9:55 PM, Quanah Gibson-Mount<quanah(a)zimbra.com> wrot= e:. > > I think you mean compiling --with-debug, as opposed to debug symbols (-g = to > gcc). =C2=A0All asserts get added to the code path if you build with > --with-debug, but that is not the same as having debug symbols (which is > generally good practice to have available). Exactly, depends on the testing phase, the slapd are compiled with-debug and -g or it's not compiled with-debug and it's stripped. Regards

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 09 Jul '09

09 Jul '09

--On Thursday, July 09, 2009 9:23 AM +0000 jorge.perez(a)adaptia.net wrote: > The last testing was wrong due to an old slapd.conf without > writetimeout keyword, my apologies. We have been testing for 2 days to > reproduce this problem and we have not seen the problem again, even > though with debug symbols the assert ""assert( SLAP_SOCK_IS_ACTIVE( s > ))"" still fails. I think you mean compiling --with-debug, as opposed to debug symbols (-g to gcc). All asserts get added to the code path if you build with --with-debug, but that is not the same as having debug symbols (which is generally good practice to have available). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#6201) Double free in syncprov
by quanah＠zimbra.com 09 Jul '09

09 Jul '09

--On Thursday, July 09, 2009 10:18 AM +0000 Alister.Winfield(a)sns.bskyb.com wrote: > I think I have it (bad configuration)... > > Okay so it might be a configuration 'error' but I guess its worth trying > to= avoid the crash. Hi Alister, Can you provide an example of your misconfigured slapd for ease of debugging? Obviously, this is non-critical but I agree it would be nice to make sure this sort of configuration error is caught more gracefully. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6207) Build farm
by ghenry＠OpenLDAP.org 09 Jul '09

09 Jul '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Build farm should be complete by now.

1 0

(ITS#6206) Admin guide appendices or tools in contrib should be better than Ubuntu docs
by ghenry＠OpenLDAP.org 09 Jul '09

09 Jul '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Must beat or match: https://help.ubuntu.com/9.04/serverguide/C/openldap-server.html

1 0

(ITS#6205) Discuss slapadd -S in Admin guide appendix
by ghenry＠OpenLDAP.org 09 Jul '09

09 Jul '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry As per http://www.openldap.org/lists/openldap-bugs/200809/msg00140.html

1 0

(ITS#6204) General upgrade procedure missing from Admin guide
by ghenry＠OpenLDAP.org 09 Jul '09

09 Jul '09

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Documenting this procedure should be in the Admin Guide like http://www.openldap.org/faq/index.cgi?file=842 Gavin.

1 0

Re: (ITS#6202) adding command line option to disable line breaking in ldif output
by dieter＠bloms.de 09 Jul '09

09 Jul '09

Hi, On Thu, Jul 09, Michael Str=F6der wrote: > > I want to do an enhancement request for ldapsearch, because it insert a= line > > break after 78 characters. > > Many people like me use the ldapsearch command in shell script and have= to > > workaround this issue. > > Maybe it make sense to add a command line option to deactivate this lin= e breaks. >=20 > I'd rather recommend to use a decent scripting language with LDAP and/or > LDIF modules than using ldapsearch in shell scripts. This gives better > control over data and error handling. there are several ldapsearch binaries from other distributor, which includes an option -T for this concern. http://www.koders.com/c/fidD1B671B4DA7CB116CA077E4694EEBAE167D3F85E.aspx http://docs.sun.com/source/816-6400-10/lsearch.html =2E.. so why doesn't ldapsearch from openldap inlcude this option. It doesn't break any rfc and historcal implementation and as far as I can see (with google), there are many admins who have to workaround this with a little perl script. I think it must be a little diff, with a few lines I can write it, but is someone willing to inlcude it in the upstream versions ? --=20 Gru=DF Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the =46rom field.

1 0

Re: (ITS#6202) adding command line option to disable line breaking in ldif output
by michael＠stroeder.com 09 Jul '09

09 Jul '09

openldap.org(a)bloms.de wrote: > Full_Name: Dieter Bloms > Version: all > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.27.50.90) > > > I want to do an enhancement request for ldapsearch, because it insert a line > break after 78 characters. > Many people like me use the ldapsearch command in shell script and have to > workaround this issue. > Maybe it make sense to add a command line option to deactivate this line breaks. I'd rather recommend to use a decent scripting language with LDAP and/or LDIF modules than using ldapsearch in shell scripts. This gives better control over data and error handling. Ciao, Michael.

1 0

(ITS#6203)
by Andrew.Morgan＠Sun.COM 09 Jul '09

09 Jul '09

wait_until_ready is documented here: http://dev.mysql.com/doc/ndbapi/en/class-ndb-cluster-connection-methods.html #class-ndb-cluster-connection-wait-until-ready -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 09 July 2009 14:51 To: Andrew.Morgan(a)Sun.COM Subject: Re: (ITS#6203) Problem & solution for back-ndb issue connecting to Cluster data nodes *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6203. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6203) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#6203) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=6203 Please remember to retain your issue tracking number (ITS#6203) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#6203) Problem & solution for back-ndb issue connecting to Cluster data nodes
by andrew.morgan＠sun.com 09 Jul '09

09 Jul '09

Full_Name: Andrew Morgan Version: 2.4.16 OS: Ubuntu URL: Submission from: (NULL) (90.193.196.76) I am running MySQL Cluster with data nodes all running on the same host. I configured, built and installed OpenLDAP with back-ndb but when I run "slapd -d 5", it failed with "ndb_db_open: ni_cluster[0]->wait failed (1)". Looking at the code in "back-ndb/init.cpp" this implies that it was able to connect to the Cluster management node but only the first of the data nodes. The cause of this is line 133: "ni->ni_cluster[i]->wait_until_ready( 30, 0 );" - the 30,0 means wait up to 30 seconds for first data node but then no time at all for the others; the fact that the method returned 1 means that the first node was found to be live. The second parameter should be set to a non-zero value to give the other data nodes chance to show as being live. I changed the 0 to 30, recompiled/installed and slapd came up correctly.

1 0

Re: (ITS#6139) slapd: password-hash rejects multiple values
by h.b.furuseth＠usit.uio.no 09 Jul '09

09 Jul '09

It has been fixed in CVS (and in next OpenLDAP release): http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/bconfig.c.diff?r1=1.… -- Hallvard

1 0

(ITS#6202) adding command line option to disable line breaking in ldif output
by openldap.org＠bloms.de 09 Jul '09

09 Jul '09

Full_Name: Dieter Bloms Version: all OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.27.50.90) I want to do an enhancement request for ldapsearch, because it insert a line break after 78 characters. Many people like me use the ldapsearch command in shell script and have to workaround this issue. Maybe it make sense to add a command line option to deactivate this line breaks.

1 0

RE: (ITS#6201) Double free in syncprov
by Alister.Winfield＠sns.bskyb.com 09 Jul '09

09 Jul '09

I think I have it (bad configuration)... I have the 'accesslogs' at every level which makes sense because I'm replic= ating individual branches separately. I forgot to remove the "overlay glue" line from the configurati= on (previously this configuration had the whole database replicated with just one provider). Now that puts th= e same accesslog entry into two db's which might be where the source of the double free begins. NB: Testing this setup without that extraneous line of config has, so far, = not crashed. After adding it again it crashed almost instantly after I started removing = entries from LDAP. Okay so it might be a configuration 'error' but I guess its worth trying to= avoid the crash. The last crash looks like. syncprov_search_response: cookie=3Drid=3D099,csn=3D20090709104334.923157Z#0= 00000#000#000000 *** glibc detected *** /data/ldap-re24/libexec/slapd: double free or corrup= tion (out): 0x0000000041c406f0 *** =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D /lib/libc.so.6[0x7f5256652948] /lib/libc.so.6(cfree+0x76)[0x7f5256654a56] /data/ldap-re24/libexec/ldap/syncprov-2.4-releng.so.2[0x7f5254260821] /data/ldap-re24/libexec/slapd[0x441c50] /data/ldap-re24/libexec/slapd[0x44478b] /data/ldap-re24/libexec/slapd(slap_send_ldap_result+0x185)[0x4453f5] /data/ldap-re24/libexec/ldap/syncprov-2.4-releng.so.2[0x7f5254263733] /data/ldap-re24/libexec/slapd(overlay_op_walk+0x4a)[0x496bda] /data/ldap-re24/libexec/slapd[0x4976d3] /data/ldap-re24/libexec/slapd[0x49555b] /data/ldap-re24/libexec/slapd(overlay_op_walk+0x4a)[0x496bda] /data/ldap-re24/libexec/slapd[0x4976d3] /data/ldap-re24/libexec/slapd(fe_op_search+0x2c1)[0x434bb1] /data/ldap-re24/libexec/slapd(do_search+0x6fc)[0x4353ac] /data/ldap-re24/libexec/slapd[0x43292f] /data/ldap-re24/lib/libldap_r-2.4-releng.so.2[0x7f5258d0f7e0] /lib/libpthread.so.0[0x7f525831cfc7] /lib/libc.so.6(clone+0x6d)[0x7f52566ae5ad] =3D=3D=3D=3D=3D=3D=3D Memory map: =3D=3D=3D=3D=3D=3D=3D=3D 00400000-00527000 r-xp 00000000 08:06 4841518 /d= ata/ldap-re24/libexec/slapd 00726000-0072e000 rw-p 00126000 08:06 4841518 /d= ata/ldap-re24/libexec/slapd 0072e000-00772000 rw-p 0072e000 00:00 0 01511000-09566000 rw-p 01511000 00:00 0 [h= eap] 4032a000-4032b000 ---p 4032a000 00:00 0 4032b000-40b2b000 rw-p 4032b000 00:00 0 40c41000-40c42000 ---p 40c41000 00:00 0 40c42000-41442000 rw-p 40c42000 00:00 0 41442000-41443000 ---p 41442000 00:00 0 41443000-41c43000 rw-p 41443000 00:00 0 41c43000-41c44000 ---p 41c43000 00:00 0 41c44000-42444000 rw-p 41c44000 00:00 0 42444000-42445000 ---p 42444000 00:00 0 42445000-42c45000 rw-p 42445000 00:00 0 42c45000-42c46000 ---p 42c45000 00:00 0 42c46000-43446000 rw-p 42c46000 00:00 0 43446000-43447000 ---p 43446000 00:00 0 43447000-43c47000 rw-p 43447000 00:00 0 43c47000-43c48000 ---p 43c47000 00:00 0 43c48000-44448000 rw-p 43c48000 00:00 0 44448000-44449000 ---p 44448000 00:00 0 44449000-44c49000 rw-p 44449000 00:00 0 44c49000-44c4a000 ---p 44c49000 00:00 0 44c4a000-4544a000 rw-p 44c4a000 00:00 0 4544a000-4544b000 ---p 4544a000 00:00 0 4544b000-45c4b000 rw-p 4544b000 00:00 0 45c4b000-45c4c000 ---p 45c4b000 00:00 0 45c4c000-4644c000 rw-p 45c4c000 00:00 0 4644c000-4644d000 ---p 4644c000 00:00 0 4644d000-46c4d000 rw-p 4644d000 00:00 0 46c4d000-46c4e000 ---p 46c4d000 00:00 0 46c4e000-4744e00Aborted x4440:~/junk# Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trade marks of British Sky Broadcas= ting Group plc and are used under licence. British Sky Broadcasting Limited= (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554= 332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscr= ibers Services Limited (Registration No. 2340150) are direct or indirect su= bsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735)= . All of the companies mentioned in this paragraph are incorporated in Engl= and and Wales and share the same registered office at Grant Way, Isleworth,= Middlesex TW7 5QD.

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 09 Jul '09

09 Jul '09

Hi, On Tue, Jul 7, 2009 at 6:40 PM, Quanah Gibson-Mount<quanah(a)zimbra.com> wrote: > > Hi Jorge, > > We're going to need more information from you than you are providing. Please > make sure you: > > (a) build openldap without optimization (-O0) > (b) are gdbing the process, not a core file > (c) Send a full backtrace of everything: thr apply all bt full > > Also, please confirm what BDB version you are using, including if it has all > patches applied and compile options for BDB, and which backend you are > using. The last testing was wrong due to an old slapd.conf without writetimeout keyword, my apologies. We have been testing for 2 days to reproduce this problem and we have not seen the problem again, even though with debug symbols the assert ""assert( SLAP_SOCK_IS_ACTIVE( s ))"" still fails. Reading symbols from /usr/lib64/sasl2/libanonymous.so...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so Core was generated by `/local/slapd_L5B8_17-7 -f /home/cudb/dataAccess/ldapAccess/ldapFe/config/slapd.'. Program terminated with signal 6, Aborted. #0 0x00002b18e9dd5d45 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00002b18e9dd5d45 in raise () from /lib64/libc.so.6 #1 0x00002b18e9dd7140 in abort () from /lib64/libc.so.6 #2 0x00002b18e9dcf286 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000004641b0 in slapd_clr_write (s=410, wake=0) at daemon.c:939 #4 0x000000000046db7d in connection_write (s=410) at connection.c:1855 #5 0x00000000004688e0 in slapd_daemon_task (ptr=0x0) at daemon.c:2567 #6 0x00002b18e9264143 in start_thread () from /lib64/libpthread.so.0 #7 0x00002b18e9e66b8d in clone () from /lib64/libc.so.6 #8 0x0000000000000000 in ?? () Best regards.

1 0

Re: (ITS#6139) slapd: password-hash rejects multiple values
by fumiyas＠osstech.jp 08 Jul '09

08 Jul '09

Hi, At Mon, 25 May 2009 13:22:47 GMT, michael(a)stroeder.com wrote: > fumiyas(a)osstech.co.jp wrote: > > My /etc/openldap/slapd.conf has the following line: > > password-hash {CRYPT} {SSHA} > > What exactly do you want to achieve by this? I use 'password-hash {CLEARTEXT} {CRYPT}' in my slapd.conf on OpenLDAP 2.3.43 to maintain the clear text password and the crypt(3)-ed password. The {CLEARTEXT} password can be used for: 1. Generating MD5 has for Digest/CRAM-MD5 authentication. 2. Notifying a user of the user's current password. (This is a rare case, I think.) 3. Migrating users and their passwords to another system in the future. 4. ... and so on. The {CRYPT} password can be used for old NIS clients. -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: http://www.SFO.jp/blog/

1 0

Re: (ITS#6201) Double free in syncprov
by hyc＠symas.com 08 Jul '09

08 Jul '09

hyc(a)symas.com wrote: > Alister.Winfield(a)sns.bskyb.com wrote: >> Failed in the same way.... > > Can you please provide the full text of the error message that glibc printed? Also, can you reproduce this with a slapd compiled without optimization? The stack trace is missing some information here. >> >> >> (gdb) bt >> #0 0x00007f2b031b1ed5 in *__GI_raise (sig=3D<value optimized out>) at ../n= >> ptl/sysdeps/unix/sysv/linux/raise.c:64 >> #1 0x00007f2b031b33f3 in *__GI_abort () at abort.c:88 >> #2 0x00007f2b031ee3a8 in __libc_message (do_abort=3D2, fmt=3D0x7f2b0329d5f= >> 0 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linu= >> x/libc_fatal.c:170 >> #3 0x00007f2b031f3948 in malloc_printerr (action=3D2, str=3D0x7f2b0329d6d8= >> "double free or corruption (out)", ptr=3D<value optimized out>) at malloc.= >> c:5891 >> #4 0x00007f2b031f5a56 in *__GI___libc_free (mem=3D0x7f2b03293fa0) at mallo= >> c.c:3626 >> #5 0x00007f2b00e01821 in syncprov_search_cleanup (op=3D0x7f279a205010, rs= >> =3D0x40efbd30) at ../../../../openldap-re24/servers/slapd/overlays/syncprov= >> .c:2024 >> #6 0x0000000000441c50 in ?? () >> #7 0x000000000044478b in ?? () >> #8 0x00000000004453f5 in slap_send_ldap_result () >> #9 0x00007f2b00e04733 in syncprov_op_search (op=3D0x7f279a205010, rs=3D0x4= >> 0efbd30) at ../../../../openldap-re24/servers/slapd/overlays/syncprov.c:243= >> 7 >> #10 0x0000000000496bda in overlay_op_walk () >> #11 0x00000000004976d3 in ?? () >> #12 0x000000000049555b in ?? () >> #13 0x0000000000496bda in overlay_op_walk () >> #14 0x00000000004976d3 in ?? () >> #15 0x0000000000434bb1 in fe_op_search () >> #16 0x00000000004353ac in do_search () >> #17 0x000000000043292f in ?? () >> #18 0x00007f2b058b07e0 in ldap_int_thread_pool_wrapper (xpool=3D<value opti= >> mized out>) at ../../../openldap-re24/libraries/libldap_r/tpool.c:685 >> #19 0x00007f2b04ebdfc7 in start_thread (arg=3D<value optimized out>) at pth= >> read_create.c:297 >> #20 0x00007f2b0324f5ad in clone () from /usr/lib/debug/libc.so.6 >> #21 0x0000000000000000 in ?? () >> (gdb) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6201) Double free in syncprov
by hyc＠symas.com 08 Jul '09

08 Jul '09

Alister.Winfield(a)sns.bskyb.com wrote: > Failed in the same way.... Can you please provide the full text of the error message that glibc printed? > > > (gdb) bt > #0 0x00007f2b031b1ed5 in *__GI_raise (sig=3D<value optimized out>) at ../n= > ptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x00007f2b031b33f3 in *__GI_abort () at abort.c:88 > #2 0x00007f2b031ee3a8 in __libc_message (do_abort=3D2, fmt=3D0x7f2b0329d5f= > 0 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linu= > x/libc_fatal.c:170 > #3 0x00007f2b031f3948 in malloc_printerr (action=3D2, str=3D0x7f2b0329d6d8= > "double free or corruption (out)", ptr=3D<value optimized out>) at malloc.= > c:5891 > #4 0x00007f2b031f5a56 in *__GI___libc_free (mem=3D0x7f2b03293fa0) at mallo= > c.c:3626 > #5 0x00007f2b00e01821 in syncprov_search_cleanup (op=3D0x7f279a205010, rs= > =3D0x40efbd30) at ../../../../openldap-re24/servers/slapd/overlays/syncprov= > .c:2024 > #6 0x0000000000441c50 in ?? () > #7 0x000000000044478b in ?? () > #8 0x00000000004453f5 in slap_send_ldap_result () > #9 0x00007f2b00e04733 in syncprov_op_search (op=3D0x7f279a205010, rs=3D0x4= > 0efbd30) at ../../../../openldap-re24/servers/slapd/overlays/syncprov.c:243= > 7 > #10 0x0000000000496bda in overlay_op_walk () > #11 0x00000000004976d3 in ?? () > #12 0x000000000049555b in ?? () > #13 0x0000000000496bda in overlay_op_walk () > #14 0x00000000004976d3 in ?? () > #15 0x0000000000434bb1 in fe_op_search () > #16 0x00000000004353ac in do_search () > #17 0x000000000043292f in ?? () > #18 0x00007f2b058b07e0 in ldap_int_thread_pool_wrapper (xpool=3D<value opti= > mized out>) at ../../../openldap-re24/libraries/libldap_r/tpool.c:685 > #19 0x00007f2b04ebdfc7 in start_thread (arg=3D<value optimized out>) at pth= > read_create.c:297 > #20 0x00007f2b0324f5ad in clone () from /usr/lib/debug/libc.so.6 > #21 0x0000000000000000 in ?? () > (gdb) > > > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: 08 July 2009 19:15 > To: Alister Winfield; openldap-its(a)openldap.org > Subject: Re: (ITS#6201) Double free in syncprov > > --On Wednesday, July 08, 2009 4:59 PM +0000 alister.winfield(a)sns.bskyb.com > wrote: > >> Full_Name: Alister Winfield >> Version: 2.4.16 >> OS: Debian Lenny >> URL: >> Submission from: (NULL) (90.207.245.9) >> >> >> I'm testing 2.4.16 and have stumbled across a problem. > > Please re-test and follow up with current RE24 CVS, as numerous fixes have = > been made since the 2.4.16 release. Thanks! > > --Quanah -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: (ITS#6201) Double free in syncprov
by Alister.Winfield＠sns.bskyb.com 08 Jul '09

08 Jul '09

Failed in the same way.... (gdb) bt #0 0x00007f2b031b1ed5 in *__GI_raise (sig=3D<value optimized out>) at ../n= ptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f2b031b33f3 in *__GI_abort () at abort.c:88 #2 0x00007f2b031ee3a8 in __libc_message (do_abort=3D2, fmt=3D0x7f2b0329d5f= 0 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linu= x/libc_fatal.c:170 #3 0x00007f2b031f3948 in malloc_printerr (action=3D2, str=3D0x7f2b0329d6d8= "double free or corruption (out)", ptr=3D<value optimized out>) at malloc.= c:5891 #4 0x00007f2b031f5a56 in *__GI___libc_free (mem=3D0x7f2b03293fa0) at mallo= c.c:3626 #5 0x00007f2b00e01821 in syncprov_search_cleanup (op=3D0x7f279a205010, rs= =3D0x40efbd30) at ../../../../openldap-re24/servers/slapd/overlays/syncprov= .c:2024 #6 0x0000000000441c50 in ?? () #7 0x000000000044478b in ?? () #8 0x00000000004453f5 in slap_send_ldap_result () #9 0x00007f2b00e04733 in syncprov_op_search (op=3D0x7f279a205010, rs=3D0x4= 0efbd30) at ../../../../openldap-re24/servers/slapd/overlays/syncprov.c:243= 7 #10 0x0000000000496bda in overlay_op_walk () #11 0x00000000004976d3 in ?? () #12 0x000000000049555b in ?? () #13 0x0000000000496bda in overlay_op_walk () #14 0x00000000004976d3 in ?? () #15 0x0000000000434bb1 in fe_op_search () #16 0x00000000004353ac in do_search () #17 0x000000000043292f in ?? () #18 0x00007f2b058b07e0 in ldap_int_thread_pool_wrapper (xpool=3D<value opti= mized out>) at ../../../openldap-re24/libraries/libldap_r/tpool.c:685 #19 0x00007f2b04ebdfc7 in start_thread (arg=3D<value optimized out>) at pth= read_create.c:297 #20 0x00007f2b0324f5ad in clone () from /usr/lib/debug/libc.so.6 #21 0x0000000000000000 in ?? () (gdb) -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: 08 July 2009 19:15 To: Alister Winfield; openldap-its(a)openldap.org Subject: Re: (ITS#6201) Double free in syncprov --On Wednesday, July 08, 2009 4:59 PM +0000 alister.winfield(a)sns.bskyb.com wrote: > Full_Name: Alister Winfield > Version: 2.4.16 > OS: Debian Lenny > URL: > Submission from: (NULL) (90.207.245.9) > > > I'm testing 2.4.16 and have stumbled across a problem. Please re-test and follow up with current RE24 CVS, as numerous fixes have = been made since the 2.4.16 release. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trade marks of British Sky Broadcas= ting Group plc and are used under licence. British Sky Broadcasting Limited= (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554= 332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscr= ibers Services Limited (Registration No. 2340150) are direct or indirect su= bsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735)= . All of the companies mentioned in this paragraph are incorporated in Engl= and and Wales and share the same registered office at Grant Way, Isleworth,= Middlesex TW7 5QD.

1 0

Re: (ITS#6201) Double free in syncprov
by quanah＠zimbra.com 08 Jul '09

08 Jul '09

--On Wednesday, July 08, 2009 4:59 PM +0000 alister.winfield(a)sns.bskyb.com wrote: > Full_Name: Alister Winfield > Version: 2.4.16 > OS: Debian Lenny > URL: > Submission from: (NULL) (90.207.245.9) > > > I'm testing 2.4.16 and have stumbled across a problem. Please re-test and follow up with current RE24 CVS, as numerous fixes have been made since the 2.4.16 release. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6200) slapd crashes under load w/ syncrepl
by quanah＠zimbra.com 08 Jul '09

08 Jul '09

--On Wednesday, July 08, 2009 4:44 PM +0000 imf(a)u.washington.edu wrote: > Full_Name: Tracy Stenvik > Version: 2.4.16 (+db-4.7.25pl4) > OS: Red Hat Enterprise Linux Server release 5.3 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (140.142.111.41) > > > In evaluating 2.4.16 (to upgrade our 2.3.39-based directory service) we > have encountered some serious issues. A similated production-level load > that 2.3.39 (with slurpd running) handles easily causes 2.4.16 (and > 2.4.15) to crash within 5 minutes to 24 hours. Please re-test with current RE24 from CVS, as numerous fixes have been made and 2.4.17 is imminent. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6201) Double free in syncprov
by alister.winfield＠sns.bskyb.com 08 Jul '09

08 Jul '09

Full_Name: Alister Winfield Version: 2.4.16 OS: Debian Lenny URL: Submission from: (NULL) (90.207.245.9) I'm testing 2.4.16 and have stumbled across a problem. compiled: openldap2.4.16 db4.7.25 Imported ~2,500,000 entries then selected 80000 random entries from the ou=<n>,ou=radiusUsers,dc=sky,dc=com trees and started making lots of deletes. WIthout a slave active I haven't 'yet' seen any crashes. With an active syncrepl slave, however, I get the following crash at random points (unfortunately it can take many 1000's of updates to trigger this which takes a while. (gdb) c Continuing. [New Thread 0x471f8950 (LWP 20035)] [New Thread 0x479f9950 (LWP 20036)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x439f1950 (LWP 19973)] 0x00007fe0426a6ed5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x00007fe0426a6ed5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007fe0426a83f3 in *__GI_abort () at abort.c:88 #2 0x00007fe0426e33a8 in __libc_message (do_abort=2, fmt=0x7fe0427925f0 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:170 #3 0x00007fe0426e8948 in malloc_printerr (action=2, str=0x7fe0427926d8 "double free or corruption (out)", ptr=<value optimized out>) at malloc.c:5891 #4 0x00007fe0426eaa56 in *__GI___libc_free (mem=0x7fe042788fa0) at malloc.c:3626 #5 0x00007fe040750801 in syncprov_search_cleanup (op=0x7fdce01eb4a0, rs=0x439f0d30) at ../../../../openldap-2.4.16/servers/slapd/overlays/syncprov.c:2024 #6 0x00000000004415c0 in ?? () #7 0x00000000004440a9 in ?? () #8 0x0000000000444cf5 in slap_send_ldap_result () #9 0x00007fe040753713 in syncprov_op_search (op=0x7fdce01eb4a0, rs=0x439f0d30) at ../../../../openldap-2.4.16/servers/slapd/overlays/syncprov.c:2437 #10 0x000000000049629a in overlay_op_walk () #11 0x0000000000496d93 in ?? () #12 0x0000000000494c10 in ?? () #13 0x000000000049629a in overlay_op_walk () #14 0x0000000000496d93 in ?? () #15 0x0000000000434581 in fe_op_search () #16 0x0000000000434d7c in do_search () #17 0x00000000004323d6 in ?? () #18 0x00007fe044da566a in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at ../../../openldap-2.4.16/libraries/libldap_r/tpool.c:663 #19 0x00007fe0443b2fc7 in start_thread (arg=<value optimized out>) at pthread_create.c:297 #20 0x00007fe0427445ad in clone () from /usr/lib/debug/libc.so.6 #21 0x0000000000000000 in ?? () (gdb) slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /data/ldap-2.4.16/etc/ldap/schema/core.schema include /data/ldap-2.4.16/etc/ldap/schema/cosine.schema include /data/ldap-2.4.16/etc/ldap/schema/nis.schema include /data/ldap-2.4.16/etc/ldap/schema/inetorgperson.schema include /data/ldap-2.4.16/etc/ldap/schema/sky.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org loglevel 0 concurrency 512 threads 1024 tool-threads 128 idletimeout 5 pidfile /data/ldap-2.4.16/var/run/slapd.pid argsfile /data/ldap-2.4.16/var/run/slapd.args # Load dynamic backend modules: modulepath /data/ldap-2.4.16/libexec/ldap #moduleload back_bdb.la moduleload back_hdb.la moduleload syncprov.la moduleload accesslog.la ####################################################################### # BDB database definitions ####################################################################### access to * by dn.base="cn=admin,dc=test" read by * break database hdb suffix cn=accesslog directory /bigdata/ldap-2.4.16-splitdb/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=admin,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # RADIUS DB-0 ACCESSLOG DB database hdb suffix cn=accesslog0 directory /bigdata/ldap-2.4.16-splitdb/accesslog0 rootdn cn=accesslog0 index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE cachesize 100000 dncachesize 100000 idlcachesize 500000 limits dn.exact="cn=admin,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # RADIUS DB-0 database hdb subordinate suffix "ou=0,ou=radiusUsers,dc=test" directory /bigdata/ldap-2.4.16-splitdb/radiusUsers/0 rootdn "cn=admin,dc=test" cachesize 400000 dncachesize 400000 idlcachesize 800000 # Indices to maintain index objectClass eq index entryUUID eq index entryCSN,contextCSN eq index cn eq,sub,pres overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 40000 overlay accesslog logdb cn=accesslog0 logops writes logsuccess TRUE logpurge 00+20:00 17+12:00 limits dn.exact="cn=admin,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # ------------------------------------------------------- # RADIUS DB-1 ACCESSLOG DB # ------------------------------------------------------- database hdb suffix cn=accesslog1 directory /bigdata/ldap-2.4.16-splitdb/accesslog1 rootdn cn=accesslog1 index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart cachesize 100000 dncachesize 100000 idlcachesize 500000 overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=admin,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # RADIUS DB-1 database hdb subordinate suffix "ou=1,ou=radiusUsers,dc=test" rootdn "cn=admin,dc=test" directory /bigdata/ldap-2.4.16-splitdb/radiusUsers/1 cachesize 400000 dncachesize 400000 idlcachesize 800000 # Indices to maintain index objectClass eq index entryUUID eq index entryCSN,contextCSN eq index cn eq,sub,pres overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 40000 overlay accesslog logdb cn=accesslog1 logops writes logsuccess TRUE logpurge 00+20:00 17+12:00 limits dn.exact="cn=admin,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # ------------------------------------------------------- # RADIUS DB-2 ACCESSLOG DB # ------------------------------------------------------- database hdb suffix cn=accesslog2 directory /bigdata/ldap-2.4.16-splitdb/accesslog2 rootdn cn=accesslog2 index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart cachesize 100000 dncachesize 100000 idlcachesize 500000 overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=admin,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # RADIUS DB-2 database hdb subordinate suffix "ou=2,ou=radiusUsers,dc=test" rootdn "cn=admin,dc=test" directory /bigdata/ldap-2.4.16-splitdb/radiusUsers/2 cachesize 400000 dncachesize 400000 idlcachesize 800000 # Indices to maintain index objectClass eq index entryUUID eq index entryCSN,contextCSN eq index cn eq,sub,pres overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 40000 overlay accesslog logdb cn=accesslog2 logops writes logsuccess TRUE logpurge 00+20:00 17+12:00 limits dn.exact="cn=admin,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ... ... Repeated up until ou=7,ou=radiusUsers,dc=test. # ---------- # ROOT DB # ---------- database hdb suffix "dc=test" rootdn "cn=admin,dc=test" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw password # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /bigdata/ldap-2.4.16-splitdb/root cachesize 1000000 dncachesize 5000000 idlcachesize 8000000 # Indices to maintain index objectClass eq index entryUUID eq index entryCSN,contextCSN eq index cn eq,sub,pres overlay glue overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 40000 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 00+20:00 17+12:00 limits dn.exact="cn=admin,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

1 0

(ITS#6200) slapd crashes under load w/ syncrepl
by imf＠u.washington.edu 08 Jul '09

08 Jul '09

Full_Name: Tracy Stenvik Version: 2.4.16 (+db-4.7.25pl4) OS: Red Hat Enterprise Linux Server release 5.3 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (140.142.111.41) In evaluating 2.4.16 (to upgrade our 2.3.39-based directory service) we have encountered some serious issues. A similated production-level load that 2.3.39 (with slurpd running) handles easily causes 2.4.16 (and 2.4.15) to crash within 5 minutes to 24 hours. Without replication active, 2.4.16 survived 24 hours under load. As soon as replication was activated however, the server crashed within 5 minutes. We've tried several syncrepl variants (as described below) but none appear stable. In analyzing the various crash dumps, most of the trouble appears to lie in the caching code. It has a nasty habit of returing nulls when nulls are not expected. Our simulated load consists of an arbitrary mix of adds/modifies/searches to various objects in the directory. This load is defined as "N" instances of the "Stressor" test, as discussed on the "GDS Stress Test Findings" page at, http://wiki.cac.washington.edu/display/infra/GDS+Stress+Test+Findings Following, you will find a series of crash dumps, along with a few comments. Also included are sections the various slapd.confs we were testing with. Please contact me if you require additional information. delta syncrepl crash -------------------- (gdb) where #0 0xb7b7abab in strncmp () from /lib/libc.so.6 #1 0x08143ea4 in bdb_rdn_cmp (v_e1=0xf069be8, v_e2=0xf73cb48) at cache.c:301 #2 0x081d00ee in avl_insert (root=0x8622088, data=0xf069be8, fcmp=0x8143e55 <bdb_rdn_cmp>, fdup=0x81d10a0 <avl_dup_error>) at avl.c:95 #3 0x08144692 in hdb_cache_find_parent (op=0xf95ea78, txn=0xe7def98, id=343637, res=0x14b3ade0) at cache.c:593 #4 0x08144dc9 in hdb_cache_find_id (op=0xf95ea78, tid=0xe7def98, id=343637, eip=0x14b3ade0, flag=0, lock=0x14b3adc4) at cache.c:905 #5 0x0810b6a0 in hdb_search (op=0xf95ea78, rs=0x14bfc0e8) at search.c:705 #6 0x080e9b02 in overlay_op_walk (op=0xf95ea78, rs=0x14bfc0e8, which=op_search, oi=0x85aeed8, on=0x0) at backover.c:669 #7 0x080e9cb7 in over_op_func (op=0xf95ea78, rs=0x14bfc0e8, which=op_search) at backover.c:721 #8 0x080e9d3b in over_op_search (op=0xf95ea78, rs=0x14bfc0e8) at backover.c:743 #9 0x0806f0b3 in fe_op_search (op=0xf95ea78, rs=0x14bfc0e8) at search.c:366 #10 0x0806ea53 in do_search (op=0xf95ea78, rs=0x14bfc0e8) at search.c:217 #11 0x0806b959 in connection_operation (ctx=0x14bfc1d0, arg_v=0xf95ea78) at connection.c:1097 #12 0x0806be33 in connection_read_thread (ctx=0x14bfc1d0, argv=0x23) at connection.c:1223 #13 0x081d74a1 in ldap_int_thread_pool_wrapper (xpool=0x8561178) at tpool.c:663 #14 0xb7e4d49b in start_thread () from /lib/libpthread.so.0 #15 0xb7bdc42e in clone () from /lib/libc.so.6 (gdb) p *(EntryInfo *)v_e1 $2 = {bei_parent = 0x8622058, bei_id = 343637, bei_lockpad = 0, bei_state = 132, bei_finders = 0, bei_nrdn = {bv_len = 45, bv_val = 0xf7af1f8 "serialNumber=40442595174b5ebf53167252b5cbcc34"}, bei_rdn = {bv_len = 45, bv_val = 0xf36d700 "serialNumber=40442595174B5EBF53167252B5CBCC34"}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__data = {__lock = 1, __count = 0, __owner = 32550, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000&\177\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 1}, bei_lrunext = 0x8978ad0, bei_lruprev = 0x0} (gdb) p *(EntryInfo *)v_e2 $3 = {bei_parent = 0x0, bei_id = 410257, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 45, bv_val = 0x0}, bei_rdn = { bv_len = 45, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, bei_lrunext = 0x8978ad0, bei_lruprev = 0x0} In bdb_rdn_cmp() you're comparing e1->bei_nrdn.bv_val to e2->bei_nrdn.bv_val but the latter is null even though e2->bei_nrdn.bv_len is not zero. standard syncrepl crash ----------------------- (gdb) where #0 0xb7d9f300 in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x081d8645 in ldap_pvt_thread_mutex_lock (mutex=0x34) at thr_posix.c:296 #2 0x08145bc0 in bdb_cache_delete_internal (cache=0xa25cc04, e=0x147e6d38, decr=0) at cache.c:1372 #3 0x08144b08 in hdb_cache_lru_purge (bdb=0xa25cbc8) at cache.c:776 #4 0x081452d1 in hdb_cache_find_id (op=0x11923ca8, tid=0x1316aa48, id=280869, eip=0x2bffcbfc, flag=0, lock=0x2bffcc54) at cache.c:1053 #5 0x0814b2f7 in hdb_dn2entry (op=0x11923ca8, tid=0x1316aa48, dn=0xa25e3bc, e=0x2bffcc64, matched=0, lock=0x2bffcc54) at dn2entry.c:67 #6 0x08151845 in hdb_entry_get (op=0x11923ca8, ndn=0xa25e3bc, oc=0xa2549f0, at=0xa23ebb0, rw=0, ent=0x2bffceac) at id2entry.c:354 #7 0x080e936d in overlay_entry_get_ov (op=0x11923ca8, dn=0xa25e3bc, oc=0xa2549f0, ad=0xa23ebb0, rw=0, e=0x2bffceac, on=0x0) at backover.c:364 #8 0x080e941f in over_entry_get_rw (op=0x11923ca8, dn=0xa25e3bc, oc=0xa2549f0, ad=0xa23ebb0, rw=0, e=0x2bffceac) at backover.c:396 #9 0x0807cfc3 in be_entry_get_rw (op=0x11923ca8, ndn=0xa25e3bc, oc=0xa2549f0, at=0xa23ebb0, rw=0, e=0x2bffceac) at backend.c:1346 #10 0x0807d1a2 in fe_acl_group (op=0x11923ca8, target=0x0, gr_ndn=0xa25e3bc, op_ndn=0x11923d44, group_oc=0xa2549f0, group_at=0xa23ebb0) at backend.c:1402 #11 0x0807d8c3 in backend_group (op=0x11923ca8, target=0x0, gr_ndn=0xa25e3bc, op_ndn=0x11923d44, group_oc=0xa2549f0, group_at=0xa23ebb0) at backend.c:1597 #12 0x080d32e2 in limits_get (op=0x11923ca8, limit=0x11923cdc) at limits.c:117 #13 0x080d588d in limits_check (op=0x11923ca8, rs=0x2bffe0e8) at limits.c:1106 #14 0x0806f095 in fe_op_search (op=0x11923ca8, rs=0x2bffe0e8) at search.c:364 #15 0x0806ea53 in do_search (op=0x11923ca8, rs=0x2bffe0e8) at search.c:217 #16 0x0806b959 in connection_operation (ctx=0x2bffe1d0, arg_v=0x11923ca8) at connection.c:1097 #17 0x0806be33 in connection_read_thread (ctx=0x2bffe1d0, argv=0x1d) at connection.c:1223 #18 0x081d74a1 in ldap_int_thread_pool_wrapper (xpool=0xa211178) at tpool.c:663 #19 0xb7d9d49b in start_thread () from /lib/libpthread.so.0 #20 0xb7b2c42e in clone () from /lib/libc.so.6 (gdb) p *e->bei_parent Cannot access memory at address 0x0 In bdb_cache_delete_internal(), e->bei_parent is null. 2-way multimaster syncrepl crash -------------------------------- (gdb) where #0 0x08149c1a in hdb_delete (op=0xc01caa8, rs=0x2ecfc0e8) at delete.c:217 #1 0x080e9b02 in overlay_op_walk (op=0xc01caa8, rs=0x2ecfc0e8, which=op_delete, oi=0x88b4550, on=0x0) at backover.c:669 #2 0x080e9cb7 in over_op_func (op=0xc01caa8, rs=0x2ecfc0e8, which=op_delete) at backover.c:721 #3 0x080e9de5 in over_op_delete (op=0xc01caa8, rs=0x2ecfc0e8) at backover.c:773 #4 0x0808ae88 in fe_op_delete (op=0xc01caa8, rs=0x2ecfc0e8) at delete.c:174 #5 0x0808abdb in do_delete (op=0xc01caa8, rs=0x2ecfc0e8) at delete.c:95 #6 0x0806b959 in connection_operation (ctx=0x2ecfc1d0, arg_v=0xc01caa8) at connection.c:1097 #7 0x0806be33 in connection_read_thread (ctx=0x2ecfc1d0, argv=0x22) at connection.c:1223 #8 0x081d74a1 in ldap_int_thread_pool_wrapper (xpool=0x8867178) at tpool.c:663 #9 0xb7e4749b in start_thread () from /lib/libpthread.so.0 #10 0xb7bd642e in clone () from /lib/libc.so.6 (gdb) p eip $1 = (EntryInfo *) 0x0 In hdb_delete(), eip is null. 2-way multimaster syncrepl crash -------------------------------- (gdb) where #0 0x080956db in slap_acl_get (a=0x8b9ba80, count=0x37f5d824, op=0x8c5d948, e=0x37f5dad0, desc=0x8b9b9f0, val=0x0, matches=0x37f5d1c4, state=0x37f5d97c) at acl.c:599 #1 0x080949b9 in slap_access_allowed (op=0x8c5d948, e=0x37f5dad0, desc=0x8b9b9f0, val=0x0, access=ACL_WDEL, state=0x37f5d97c, maskp=0x37f5d8e8) at acl.c:236 #2 0x08094cd5 in fe_access_allowed (op=0x8c5d948, e=0x37f5dad0, desc=0x8b9b9f0, val=0x0, access=ACL_WDEL, state=0x37f5d97c, maskp=0x37f5d8e8) at acl.c:360 #3 0x0809503c in access_allowed_mask (op=0x8c5d948, e=0x37f5dad0, desc=0x8b9b9f0, val=0x0, access=ACL_WDEL, state=0x37f5d97c, maskp=0x0) at acl.c:462 #4 0x08098b8f in acl_check_modlist (op=0x8c5d948, e=0x37f5dad0, mlist=0x34afa7c8) at acl.c:1986 #5 0x0810373a in hdb_modify_internal (op=0x8c5d948, tid=0x961aa10, modlist=0x34afa7c8, e=0x37f5dad0, text=0x37f5f0fc, textbuf=0x37f5db18 "", textlen=256) at modify.c:88 #6 0x08105292 in hdb_modify (op=0x8c5d948, rs=0x37f5f0e8) at modify.c:590 #7 0x080e9b02 in overlay_op_walk (op=0x8c5d948, rs=0x37f5f0e8, which=op_modify, oi=0x8bbb550, on=0x0) at backover.c:669 #8 0x080e9cb7 in over_op_func (op=0x8c5d948, rs=0x37f5f0e8, which=op_modify) at backover.c:721 #9 0x080e9d7f in over_op_modify (op=0x8c5d948, rs=0x37f5f0e8) at backover.c:755 #10 0x08088a89 in fe_op_modify (op=0x8c5d948, rs=0x37f5f0e8) at modify.c:301 #11 0x080884c8 in do_modify (op=0x8c5d948, rs=0x37f5f0e8) at modify.c:175 #12 0x0806b959 in connection_operation (ctx=0x37f5f1d0, arg_v=0x8c5d948) at connection.c:1097 #13 0x0806be33 in connection_read_thread (ctx=0x37f5f1d0, argv=0x22) at connection.c:1223 #14 0x081d74a1 in ldap_int_thread_pool_wrapper (xpool=0x8b6e178) at tpool.c:663 #15 0xb7e6749b in start_thread () from /lib/libpthread.so.0 #16 0xb7bf642e in clone () from /lib/libc.so.6 (gdb) p e->e_nname $3 = {bv_len = 77, bv_val = 0x0} In slap_acl_get(), e->e_nname.bv_val (e->e_ndn) is null. delta syncrepl slapd.conf ------------------------- serverID 1 ldap://rufus01.u.washington.edu:290 serverID 2 ldap://rufus04.u.washington.edu:290 gentlehup on idletimeout 600 sizelimit 20000 sortvals member # ===== Replication db ==== database hdb suffix "cn=log" directory /data/au20aa_log rootdn "cn=Manager,dc=washington,dc=edu" #index objectClass eq #index entryUUID,entryCSN eq index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-reloadhint true syncprov-nopresent true # ===== Primary db === database hdb suffix "dc=washington,dc=edu" rootdn "cn=Manager,dc=washington,dc=edu" include /usr/local/openldap-2.4.16/etc/openldap/private/slapd-pw.conf directory /data/au20aa index entryCSN eq index entryUUID eq checkpoint 10000 15 cachesize 90000 idlcachesize 180000 overlay syncprov #syncprov-sessionlog 100 syncprov-checkpoint 1000 60 # accesslog overlay definitions for primary database overlay accesslog logdb cn=log logops writes logsuccess true # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 standard syncrepl slapd.conf ---------------------------- serverID 1 ldap://rufus01.u.washington.edu:290 serverID 2 ldap://rufus04.u.washington.edu:290 gentlehup on idletimeout 600 sizelimit 20000 sortvals member # ===== Primary db ===== database hdb suffix "dc=washington,dc=edu" rootdn "cn=Manager,dc=washington,dc=edu" include /usr/local/openldap-2.4.16/etc/openldap/private/slapd-pw.conf directory /data/au20aa index entryCSN eq index entryUUID eq checkpoint 10000 15 cachesize 90000 idlcachesize 180000 overlay syncprov #syncprov-sessionlog 100 syncprov-checkpoint 1000 60 2-way multimaster syncrepl slapd.conf ------------------------------------- serverID 1 ldap://rufus01.u.washington.edu:290 serverID 2 ldap://rufus04.u.washington.edu:290 gentlehup on idletimeout 600 sizelimit 20000 sortvals member # ===== Primary db ===== database hdb suffix "dc=washington,dc=edu" rootdn "cn=Manager,dc=washington,dc=edu" include /usr/local/openldap-2.4.16/etc/openldap/private/slapd-pw.conf directory /data/au20aa index entryCSN eq index entryUUID eq checkpoint 10000 15 cachesize 90000 idlcachesize 180000 overlay syncprov #syncprov-sessionlog 100 syncprov-checkpoint 1000 60 ### ### ----------- Replication ### syncrepl rid=101 provider=ldap://rufus01.u.washington.edu:290 searchbase="dc=washington,dc=edu" bindmethod=sasl saslmech=external starttls=yes tls_cert=/usr/local/openldap-2.4.16/etc/openldap/rufus04.crt tls_key=/usr/local/openldap-2.4.16/etc/openldap/private/rufus04.key filter="(objectClass=*)" attrs="*,+" schemachecking=off scope=sub type=refreshAndPersist retry="60 +" syncrepl rid=102 provider=ldap://rufus04.u.washington.edu:290 searchbase="dc=washington,dc=edu" bindmethod=sasl saslmech=external starttls=yes tls_cert=/usr/local/openldap-2.4.16/etc/openldap/rufus04.crt tls_key=/usr/local/openldap-2.4.16/etc/openldap/private/rufus04.key filter="(objectClass=*)" attrs="*,+" schemachecking=off scope=sub type=refreshAndPersist retry="60 +" mirrormode yes

1 0

(ITS#6199) [JLDAP] SASL integrity & confidentiality
by ioplex＠gmail.com 07 Jul '09

07 Jul '09

Full_Name: Michael B Allen Version: JLDAP OS: Linux URL: http://www.ioplex.com/~miallen/openldap-jldap-saslwrap.diff Submission from: (NULL) (71.187.189.103) It would be fabulous if SASL integrity and confidentiality worked in JLDAP. I just tried and failed to add support for it. I could be just misguided but it seems that because the ASN.1 routines encoded and decoded BER directly to and from the socket element by element, there is a fairly low-level issue with wrapping and unwrapping entire message buffers. But I was unable to pinpoint the precise cause. See the URL for my crude patch to test SASL wrap / unwrap. Of course you'll need a SASL client and mechanism that supports at least integrity. Since com.novell.ldap.Connection.writeMessage encodes the entire message before writing it to the socket, the SASL wrap works. However, reading data from the input stream has a strange off-by-one problem. The first byte is missing. But since the first 4 bytes are the big endian SASL buffer size, I can hack to code to skip it and it is unwrapped properly (although it looks like a referral so I think perhaps my search() test program isn't quite right either). It then hangs in LDAPSearchResults.hasMore: at java.lang.Object.wait(Object.java:474) at com.novell.ldap.MessageAgent.getLDAPMessage(MessageAgent.java:399) - locked <0x89152240> (a com.novell.ldap.MessageVector) at com.novell.ldap.LDAPMessageQueue.getResponse(LDAPMessageQueue.java:175) at com.novell.ldap.LDAPMessageQueue.getResponse(LDAPMessageQueue.java:126) at com.novell.ldap.LDAPSearchResults.getBatchOfResults(LDAPSearchResults.java:338) at com.novell.ldap.LDAPSearchResults.resetVectors(LDAPSearchResults.java:213) at com.novell.ldap.LDAPSearchResults.hasMore(LDAPSearchResults.java:175) at org.ietf.ldap.LDAPSearchResults.hasMore(LDAPSearchResults.java:89) Unfortunately this looks like a fairly low-level architectual issue so I'll have to fall-back to JNDI. But hopefully this will help someone who wants to add this critical functionality in the future. Using the builtin integrity and confidentiality offered by mechanisms like GSSAPI is pretty important IMO. At least it's quite a bit more graceful than using TLS.

1 0

Re: (ITS#6195) Replications with 2.3.43 master to 2.4.16 slave is failing
by quanah＠zimbra.com 07 Jul '09

07 Jul '09

--On Thursday, July 02, 2009 10:49 PM +0000 quanah(a)zimbra.com wrote: > --On Thursday, July 02, 2009 3:40 PM -0700 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: Fixed with the CSN normalization commit. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 07 Jul '09

07 Jul '09

Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: CVS HEAD (2.4.16+) >> OS: Fedora >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.16-libldif-20090702.patch >> Submission from: (NULL) (76.113.59.19) >> >> >> This patch allows liblutil to provide the LDIF reading and writing >> functions as >> public APIs in a libldif, and exposes ldif.h to the public API. > > See also ITS#4033; ldif.h only parses LDIF into chunks/records, it's > still up to the caller to turn these records into something > meaningful. In fact libldif used to be a library of its own, but in > RE22 we made the decision to merge it into liblutil because its > functionality is so limited. I don't expect we'll reverse this > decision unless/until it gets enough parsing added to it to make it > more generally useful. I think it's very useful as it is - the mozldap libldif (which is almost identical in functionality to my proposed openldap libldif) is used in several different applications in the 389 directory server suite. What more does it need? Some sort of higher level "entry" and "attribute" abstraction? > >> This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not >> assigned rights and/or interest in this work to any party. I, Richard >> Megginson am authorized by Red Hat, Inc., my employer, to release this >> work under the following terms. >> >> Red Hat, Inc. hereby place the following modifications to OpenLDAP >> Software (and only these modifications) into the public domain. Hence, >> these modifications may be freely used and/or redistributed for any >> purpose with or without attribution and/or other notice. >

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by hyc＠symas.com 07 Jul '09

07 Jul '09

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: CVS HEAD (2.4.16+) > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.16-libldif-20090702.patch > Submission from: (NULL) (76.113.59.19) > > > This patch allows liblutil to provide the LDIF reading and writing functions as > public APIs in a libldif, and exposes ldif.h to the public API. See also ITS#4033; ldif.h only parses LDIF into chunks/records, it's still up to the caller to turn these records into something meaningful. In fact libldif used to be a library of its own, but in RE22 we made the decision to merge it into liblutil because its functionality is so limited. I don't expect we'll reverse this decision unless/until it gets enough parsing added to it to make it more generally useful. > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not > assigned rights and/or interest in this work to any party. I, Richard > Megginson am authorized by Red Hat, Inc., my employer, to release this > work under the following terms. > > Red Hat, Inc. hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

I've been trying to factor this MUSTRELEASE/MUSTBEFREED stuff out to some macros. Easier said than done, I ended up with the macro monstrosity below. Do I put that in slap.h? Or a separate slap-response.h file? Generally the idea is that most code which modifies rs->sr_<entry/matched/ref/ctrls> (as opposed to initializing) should use these macros, which obey sr_flag and dispose of the old value if needed. There won't be that many callers actually, mostly overlays. There is overlay code which need to be rearranged a bit or which can't use this, and there is overlay code I don't understand at all and don't dare touch. Oh, and this seems to be wrong for how sr_ctrls are set up, which seems to be allocated differently some places. I'm just including that for reference for now, won't commit it yet in any case. Finally, code which aborts normal processing of some response and instead send an error often needs to be fixed - it often doesn't flush SlapReply data, and the data to be flushed and maybe freeed can be lost because it's overwritten. Generally I think code which modifies sr_type (or in some cases calls a function which will do so) should be responsible for flushing old SlapReply data first. #define REP_ENTRY_MUSTFLUSH (REP_ENTRY_MUSTBEFREED|REP_ENTRY_MUSTRELEASE) #define REP_ENTRY_MASK (REP_ENTRY_MODIFIABLE |REP_ENTRY_MUSTFLUSH) #define REP_MATCHED_MUSTFLUSH REP_MATCHED_MUSTBEFREED #define REP_REF_MUSTFLUSH REP_REF_MUSTBEFREED #define REP_CTRLS_MUSTFLUSH REP_CTRLS_MUSTBEFREED /* Macros updating freeable members of SlapReply, mostly for overlays. */ /* * Ensure rs->sr_entry is modifiable, by duplicating it if necessary. * Obey sr_flags. Set REP_ENTRY_<MODIFIABLE, and MUSTBEFREED if duplicated>. * Do <postmodActions> if the entry was replaced. */ #define RS_MODIFIABLE_ENTRY(op, rs, on, postmodActions) do { \ SlapReply *const rmeRS = (rs); \ if ( rmeRS->sr_flags & REP_ENTRY_MODIFIABLE ) break; \ RS_REPLACE_ENTRY( op, rmeRS, on, entry_dup( rmeRS->sr_entry ), 0 ); \ rmeRS->sr_flags |= REP_ENTRY_MODIFIABLE | REP_ENTRY_MUSTBEFREED; \ postmodActions; \ } while (0) /* Reset rs->sr_<member> if REP_<member>_MUSTBEFREED/MUSTRELEASE says so. */ #define RS_FLUSH_ENTRY(op, rs, on) RS_FLUSH(ENTRY, op, rs, on, 1, {}, {}) #define RS_FLUSH_CTRLS(op, rs) RS_FLUSH(CTRLS, op, rs, -, 1, {}, {}) #define RS_FLUSH_MATCHED( rs) RS_FLUSH(MATCHED, -, rs, -, 1, {}, {}) #define RS_FLUSH_REF( rs) RS_FLUSH(REF, -, rs, -, 1, {}, {}) /* Flush and set rs->sr_<member>. Set REP_<member>_MUSTBEFREED if <isDup>. */ #define RS_REPLACE_ENTRY(op,rs,on,v,isDup) RS_REPLACE(ENTRY,op,rs,on, v,isDup) #define RS_REPLACE_CTRLS(op,rs,v,isDup) RS_REPLACE(CTRLS, op,rs,-, v,isDup) #define RS_REPLACE_MATCHED( rs,v,isDup) RS_REPLACE(MATCHED, -,rs,-, v,isDup) #define RS_REPLACE_REF( rs,v,isDup) RS_REPLACE(REF, -,rs,-, v,isDup) /* Helpers for the above */ #define SR_ENTRY sr_entry #define SR_CTRLS sr_ctrls #define SR_MATCHED sr_matched #define SR_REF sr_ref typedef Entry *SR_ENTRY_t; typedef LDAPControl **SR_CTRLS_t; typedef const char *SR_MATCHED_t; typedef BerVarray SR_REF_t; #define RS_FREE_ENTRY(op, rs, on)\ if ((rs)->sr_flags & REP_ENTRY_MUSTBEFREED) { \ assert (!(rs)->sr_flags & REP_ENTRY_MUSTRELEASE); \ entry_free((rs)->sr_entry); \ } \ else if (on == NULL) be_entry_release_rw(op, (rs)->sr_entry, 0);\ else overlay_entry_release_ov(op, (rs)->sr_entry, 0, on) #define RS_FREE_CTRLS(op, rs, on) slap_free_ctrls( op, (rs)->sr_ctrls ) #define RS_FREE_MATCHED(op, rs, on) ch_free( (char *) (rs)->sr_matched ) #define RS_FREE_REF(op, rs, on) ber_bvarray_free( (rs)->sr_ref ) #define RS_FLUSH(MEMBER, op, rs, on, reset, preActions, postActions) do { \ SlapReply *const rfRS = (rs); \ preActions; \ if ( rfRS->sr_flags & REP_##MEMBER##_MUSTFLUSH ) { \ if ( rfRS->SR_##MEMBER ) { \ RS_FREE_##MEMBER( op, rfRS, on ); \ if ( reset ) rfRS->SR_##MEMBER = NULL; \ } \ } \ rfRS->sr_flags &= ~REP_##MEMBER##_MASK; \ postActions; \ } while (0) #define RS_REPLACE(MEMBER, op, rs, on, val, isDup) \ RS_FLUSH( MEMBER, op, rs, on, 0, \ SR_##MEMBER##_t const rfNewval = (val), \ if ( isDup ) rfRS->sr_flags |= REP_##MEMBER##_MUSTBEFREED; \ rfRS->SR_##MEMBER = rfNewval ) /* Warn if something re#defines the following, which would break RS_REPLACE */ #define ENTRY ENTRY #define CTRLS CTRLS #define MATCHED MATCHED #define REF REF

1 0

Re: (ITS#5892) slapadd doesn't fail on invalid include statements
by hyc＠symas.com 07 Jul '09

07 Jul '09

aredridel(a)nbtsc.org wrote: > Full_Name: Aria Stewart > Version: 2.4.13 > OS: PLD Linux (Th) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:8935:7:21b:fcff:fe77:1757) > > > An ldif file with include statements in the form of: > > include: /filename > > rather than > > include: file:///filename > > silently fail. Slapadd stops at that point, but does not print an error message. Oops, the library has provided an error message for this instance since 2.4.5beta (September 2007) but slapadd wasn't enabling the display of that message by default. This is now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6101) Uninitialized SlapReply components
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

I wrote: > We need to check > grep -nH -e 'SlapReply[<tab> ]*[a-zA-Z]' *.c */*.c > for other cases. Not for this ITS. Just moved sru_search first in the union. It's not always clear to me which code is responsible for initializing SlapReply anyway. Fixed two other simple cases: - result.c:send_ldap_disconnect() should reset rs->sr_rspdata. - sasl.c: should (re)set rs->sr_sasldata before doing send_ldap_sasl(). -- Hallvard

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 07 Jul '09

07 Jul '09

--On Tuesday, July 07, 2009 4:41 PM +0000 quanah(a)zimbra.com wrote: > Also, please confirm what BDB version you are using, including if it has > all patches applied and compile options for BDB, and which backend you > are using. Hi Jorge, Please also confirm that you have writetimeout configured in your slapd configuration. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 07 Jul '09

07 Jul '09

--On Tuesday, July 07, 2009 12:51 PM +0000 jorge.perez(a)adaptia.net wrote: Hello, > > The problem still reproduces. Threads hung on the same > ptread_cond_wait.call. This time the assert has not failed. > > Thread 18 (Thread 1390426432 (LWP 17780)): > ---Type <return> to continue, or q <return> to quit--- ># 0=C2=A0 0x00002b5a8515b1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 ># 1=C2=A0 0x00000000004525a4 in send_ldap_ber (op=3D<value optimized out>, > ber=3D0x52e01150) at result.c:156 ># 2=C2=A0 0x000000000045449e in slap_send_search_entry ># (op=3D0x2b5a849138f4, > rs=3D0x52e02da0) at result.c:1259 > Hi Jorge, We're going to need more information from you than you are providing. Please make sure you: (a) build openldap without optimization (-O0) (b) are gdbing the process, not a core file (c) Send a full backtrace of everything: thr apply all bt full Also, please confirm what BDB version you are using, including if it has all patches applied and compile options for BDB, and which backend you are using. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6197) ldap_err2string()/ldap_perror() strangeness
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

Also ldap_err2string(), unlike ldap_perror(), does not pass messages from recognized result codes through _() - i.e. the optional gettext(). I'll fix that too. -- Hallvard

1 0

Re: (ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

hyc(a)symas.com writes: > This code has changed in HEAD. Closing this ITS. Hm? The unlock-lock is still there. If it still needs to let through another thread to c_write1_mutex I don't see how the connection_valid() test in front of it helps. -- Hallvard

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 07 Jul '09

07 Jul '09

On Mon, Jul 6, 2009 at 9:32 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wro= te: > > --On Monday, July 06, 2009 6:07 PM +0000 jorge.perez(a)adaptia.net wrote: > >> >> With the debug symbols there's an assert that fails in slapd_clr_write >> method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): > > Thanks. =C2=A0The hang should really be fixed now. :P =C2=A0Please re-syn= c RE24 and test again. =C2=A0Thank you! Hello, The problem still reproduces. Threads hung on the same ptread_cond_wait.call. This time the assert has not failed. Thread 18 (Thread 1390426432 (LWP 17780)): ---Type <return> to continue, or q <return> to quit--- #0=C2=A0 0x00002b5a8515b1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1=C2=A0 0x00000000004525a4 in send_ldap_ber (op=3D<value optimized out>, ber=3D0x52e01150) at result.c:156 #2=C2=A0 0x000000000045449e in slap_send_search_entry (op=3D0x2b5a849138f4, rs=3D0x52e02da0) at result.c:1259 Regards

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by jsafrane＠redhat.com 07 Jul '09

07 Jul '09

On 02/10/2009 09:53 AM, hyc(a)symas.com wrote: > I opted for this approach, now checked into HEAD. Please test. After few months in production it seems the bug is gone. Thanks a lot for the fix! Jan

1 0

Re: (ITS#6198) Authorization for extensions
by hyc＠symas.com 07 Jul '09

07 Jul '09

Michael Ströder wrote: > Howard Chu wrote: >> Ugh, no. There's no way any sysadmin is going to remember what each OID >> means. > > There are tools to display them: > http://demo.web2ldap.de:1760/web2ldap?ldap://ldap.uninett.no/??base > > There also could be GUI tools to display ACLs to humans. None of which may be accessible when trying to diagnose a crashed system. It must always be practical to manually edit a slapd configuration. >> Each exop will be given a "friendly name" like WhoAmI, ModifyPwd, >> etc. > Who maintains the list of friendly names? Yes, the OpenLDAP project can > maintain a proprietary list like all other LDAP vendors do. :-( > Probably that's another topic for cross-vendor coordination... Interoperability is not a requirement for slapd configuration elements. However, any shortname already present in RFCs would be obvious first choices. E.g., "passwdModify" (RFC 3062, section 2) and "whoami" (RFC4532, section 2) (derived by dropping the letters "OID" from the name of the OID definition). Or just accept any oidmacros, as some of the other config items already do. On that score I believe we should promote more pervasive use OID macros instead of numeric OIDs, because that greatly enhances comprehension by human administrators. I believe we should define macros for all of the syntaxes etc. already in common use in slapd and document them, guaranteeing that they will be available for everyone else who uses OpenLDAP to also take advantage of them. (Note that back-config already has several hardcoded, but they're decorated with "OM" prefix and not documented for public consumption. For real use they should be unadorned, using plain names such as "integer" or "directoryString" ...) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6198) Authorization for extensions
by michael＠stroeder.com 07 Jul '09

07 Jul '09

Howard Chu wrote: > Michael Ströder wrote: >> hyc(a)OpenLDAP.org wrote: >>> Full_Name: Howard Chu >>> Version: HEAD/2.5 >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (76.91.220.157) >>> Submitted by: hyc >>> >>> >>> The access control mechanism needs to be extended to control actions, >>> not just >>> objects, to control who may use various LDAP Controls and Extended >>> Operations. >> >> +1 >> >>> E.g. >>> access to control=<oid> by<who> >>> access to op=<operation or oid> by<who> >> ^^^^^^^^^ >> What is "operation" supposed to be? I'd prefer only to allow "oid" since >> OIDs are the only identifiers clearly specified in RFCs and I-Ds. > > Ugh, no. There's no way any sysadmin is going to remember what each OID > means. There are tools to display them: http://demo.web2ldap.de:1760/web2ldap?ldap://ldap.uninett.no/??base There also could be GUI tools to display ACLs to humans. > Each exop will be given a "friendly name" like WhoAmI, ModifyPwd, > etc. Who maintains the list of friendly names? Yes, the OpenLDAP project can maintain a proprietary list like all other LDAP vendors do. :-( Probably that's another topic for cross-vendor coordination... Ciao, Michael.

1 0

Re: (ITS#6198) Authorization for extensions
by hyc＠symas.com 07 Jul '09

07 Jul '09

Michael Ströder wrote: > hyc(a)OpenLDAP.org wrote: >> Full_Name: Howard Chu >> Version: HEAD/2.5 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc >> >> >> The access control mechanism needs to be extended to control actions, not just >> objects, to control who may use various LDAP Controls and Extended Operations. > > +1 > >> E.g. >> access to control=<oid> by<who> >> access to op=<operation or oid> by<who> > ^^^^^^^^^ > What is "operation" supposed to be? I'd prefer only to allow "oid" since > OIDs are the only identifiers clearly specified in RFCs and I-Ds. Ugh, no. There's no way any sysadmin is going to remember what each OID means. Each exop will be given a "friendly name" like WhoAmI, ModifyPwd, etc. Don't make the same mistake the original LDAP implementers did - numeric OIDs are for machine consumption only; they should always be mapped to mnemonic names for use by humans. (Technically they should be mapped to *localized* names; obviously the names were not intended to be part of the protocol specification. This is another glaring flaw in the LDAP specifications...) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6198) Authorization for extensions
by michael＠stroeder.com 07 Jul '09

07 Jul '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/2.5 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > The access control mechanism needs to be extended to control actions, not just > objects, to control who may use various LDAP Controls and Extended Operations. +1 > E.g. > access to control=<oid> by <who> > access to op=<operation or oid> by <who> ^^^^^^^^^ What is "operation" supposed to be? I'd prefer only to allow "oid" since OIDs are the only identifiers clearly specified in RFCs and I-Ds. Ciao, Michael.

1 0

(ITS#6198) Authorization for extensions
by hyc＠OpenLDAP.org 06 Jul '09

06 Jul '09

Full_Name: Howard Chu Version: HEAD/2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc The access control mechanism needs to be extended to control actions, not just objects, to control who may use various LDAP Controls and Extended Operations. E.g. access to control=<oid> by <who> access to op=<operation or oid> by <who> Perhaps the control= / op= specifier should be usable in combination with the other <what> specifiers; I haven't thought too deeply about it. It only makes sense in limited contexts, since various extensions may not even affect any particular directory object.

1 0

Re: (ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by hyc＠symas.com 06 Jul '09

06 Jul '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > send_ldap_ber() has a suspicious-looking waitloop doing this: > > if ( ldap_pvt_thread_mutex_trylock(&conn->c_mutex )) { > ldap_pvt_thread_mutex_unlock(&conn->c_write1_mutex ); > ldap_pvt_thread_mutex_lock(&conn->c_write1_mutex ); > > Unlock does not mean a thread waiting for c_write1_mutex will acquire > it immediately. Such a thread may have to wait until it is scheduled, > at which time the looping thread has locked the mutex again. This code has changed in HEAD. Closing this ITS. > > On the Linux box on my desk, a pure unlock-lock loop goes through > 50000-100000 iterations before another thread waiting for the lock > acquires it. OTOH, on a heavily used box it takes ~50 iterations. > > A sched_yield() between the unlock and lock reduces #iterations to 1. > No idea if that is the right solution, nor how serious the problem is. > > The lock/unlock statements themselves are from result.c rev 1.323, > but then with some more locking between them which disappeared in > later revisions. > > My lock-unlock test program: > > #include<pthread.h> > #include<sched.h> > #include<stdio.h> > #include<stdlib.h> > #include<sys/select.h> > > static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; > static unsigned count; > > static void *waiter(void *arg) { > pthread_mutex_lock(&m); > printf("Locked after %u iterations.\n", count); > exit(0); > } > > int main() { > pthread_t t; > pthread_mutex_lock(&m); > pthread_create(&t, NULL, waiter, NULL); > select(0, NULL, NULL, NULL,&(struct timeval){0, 100000}); > for (count = 1 ;; ++count) { > pthread_mutex_unlock(&m); > pthread_mutex_lock(&m); > } > } > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 06 Jul '09

06 Jul '09

--On Monday, July 06, 2009 6:07 PM +0000 jorge.perez(a)adaptia.net wrote: > Hi, > > Sorry for the HTML email. > > With the debug symbols there's an assert that fails in slapd_clr_write > method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): Thanks. The hang should really be fixed now. :P Please re-sync RE24 and test again. Thank you! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6197) ldap_err2string()/ldap_perror() strangeness
by h.b.furuseth＠usit.uio.no 06 Jul '09

06 Jul '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_err2string() and ldap_perror() use ldap_int_error(), which walks an array looking for the result code. That's silly, I'll replace it with a macroized switch statement unless someone protests. Compilers will usually turn that into a binary search or better. A prebuilt hash would be better, but would complicate source code maintenance. I might do that someday if anyone cares. Also don't see why ldap_perror() outputs a less informative error string than ldap_err2string() for unknown result codes. ldap_perror says "unknown result code" (with lowercase initial), while err2string says "Unknown <API error/(extension) error/(private extension) error/error". Looks like ldap_perror() could be improved by calling ldap_err2string(). (Yes I know ldap_perror is deprecated. See if I care, I like it.)

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 06 Jul '09

06 Jul '09

Hi, Sorry for the HTML email. With the debug symbols there's an assert that fails in slapd_clr_write method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): (gdb) bt #0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 #1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 #2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000043e447 in slapd_clr_write (s=3D<value optimized out>, wake=3D0) at daemon.c:939 #4 0x00000000004422dc in connection_write (s=3D403) at connection.c:1855 #5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<value optimized out>) at daemon.c:2567 #6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 #7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 #8 0x0000000000000000 in ?? () Without debug symbols, using gdb to attach to the process it can be seen all the threads hang on the pthread_cond_wait in send_ldap_ber method in result.c. Best regards. On Mon, Jul 6, 2009 at 7:29 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wro= te: > > --On Monday, July 06, 2009 7:22 AM +0000 jorge.perez(a)adaptia.net wrote: > >> --001636c5b1542f27b3046e045d1b >> Content-Type: text/plain; charset=3DUTF-8 >> Content-Transfer-Encoding: 7bit >> >>> >>> >>> Although with a slapd without debug symbols it works ok, there's an >>> assert that fails in slapd_clr_write method, ("assert( >>> SLAP_SOCK_IS_ACTIVE( s ))"): >>> >>> (gdb) bt >>> # 0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 >>> # 1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 >>> # 2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 >>> # 3 0x000000000043e447 in slapd_clr_write (s=3D<value optimized out>, >>> # wake=3D0) >>> at daemon.c:939 >>> # 4 0x00000000004422dc in connection_write (s=3D403) at connection.c:18= 55 >>> # 5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<value optimized out= >) >>> # at >>> daemon.c:2567 >>> # 6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 >>> # 7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 >>> # 8 0x0000000000000000 in ?? () >>> >>> >> Hello, >> >> The problem still reproduces, all connection hangups after a weekend >> overloading the server.. > > Can you please stop writing HTML email? thanks. ;) > > Also, can you please re-compile with debugging symbols available, and pro= vide a backtrace of the hung server? :) > > Thanks, > Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: =C2=A0the leader in open source messaging and collaboration

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 06 Jul '09

06 Jul '09

--On Monday, July 06, 2009 7:22 AM +0000 jorge.perez(a)adaptia.net wrote: > --001636c5b1542f27b3046e045d1b > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 7bit > >> >> >> Although with a slapd without debug symbols it works ok, there's an >> assert that fails in slapd_clr_write method, ("assert( >> SLAP_SOCK_IS_ACTIVE( s ))"): >> >> (gdb) bt >> # 0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 >> # 1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 >> # 2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 >> # 3 0x000000000043e447 in slapd_clr_write (s=<value optimized out>, >> # wake=0) >> at daemon.c:939 >> # 4 0x00000000004422dc in connection_write (s=403) at connection.c:1855 >> # 5 0x00000000004410e6 in slapd_daemon_task (ptr=<value optimized out>) >> # at >> daemon.c:2567 >> # 6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 >> # 7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 >> # 8 0x0000000000000000 in ?? () >> >> > Hello, > > The problem still reproduces, all connection hangups after a weekend > overloading the server.. Can you please stop writing HTML email? thanks. ;) Also, can you please re-compile with debugging symbols available, and provide a backtrace of the hung server? :) Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 06 Jul '09

06 Jul '09

rmeggins(a)redhat.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms020502060206020809020001 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Hallvard B Furuseth wrote: >> The latest liblutil/passwd.c breaks with ./configure --enable-lmpasswd >> and OpenSSL: >> >> passwd.c:660: error: expected declaration specifiers or '...' before '(' token >> passwd.c:660: error: expected declaration specifiers or '...' before '&' token >> passwd.c:661: error: conflicting types for 'DES_set_key' >> /usr/include/openssl/des.h:222: error: previous declaration of 'DES_set_key' >> >> Preprocessor output for passwd.c shows that this in passwd.c: >> static void >> des_set_key( des_key *key, unsigned char *keyData) { ... } >> conflicts with this macro from /usr/include/openssl/des_old.h: >> #define des_set_key(k,ks) DES_set_key((k),&(ks)) >> which when expanded tries to conflict with this prototype from >> /usr/include/openssl/des.h: >> int DES_set_key(const_DES_cblock *key,DES_key_schedule *schedule); >> >> > I think Howard was going to omit the passwd.c changes. I applied the DES changes, and dropped the SHA1 changes. The version now in HEAD also avoids this naming conflict. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 06 Jul '09

06 Jul '09

This is a cryptographically signed message in MIME format. --------------ms020502060206020809020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hallvard B Furuseth wrote: > The latest liblutil/passwd.c breaks with ./configure --enable-lmpasswd > and OpenSSL: > > passwd.c:660: error: expected declaration specifiers or '...' before '(' token > passwd.c:660: error: expected declaration specifiers or '...' before '&' token > passwd.c:661: error: conflicting types for 'DES_set_key' > /usr/include/openssl/des.h:222: error: previous declaration of 'DES_set_key' > > Preprocessor output for passwd.c shows that this in passwd.c: > static void > des_set_key( des_key *key, unsigned char *keyData) { ... } > conflicts with this macro from /usr/include/openssl/des_old.h: > #define des_set_key(k,ks) DES_set_key((k),&(ks)) > which when expanded tries to conflict with this prototype from > /usr/include/openssl/des.h: > int DES_set_key(const_DES_cblock *key,DES_key_schedule *schedule); > > I think Howard was going to omit the passwd.c changes. --------------ms020502060206020809020001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA2MTUwNTE5WjAjBgkqhkiG9w0BCQQxFgQUEhRXD3S8 y7XRMK4qRv/cvAGaP7MwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQAsIFbd928YyHFnVXHDB6vIbO0MX7chq9nDKj4l HeCgXft1yEARDQ8ra3s4hApdNnE1PicCx2yrmPuQivjRo7tsZ2CCIBvH8aIrbxhEa0ZJ2USC pTgNIG2lk1cFiQ7c09NZSFwuU+s0Vp5M7b+U68VkJ+UV1WLeslYJT3QubNvz91C5uVeldQQ/ gPjbKVS74MN1bCDtPfHMIkhvSSR4Fmv8/89ZEAjYHE4m02ppr4ij8foA62jdESzJ2RXDdl7q spoxNwUqBKKJnlO11+40BXlWH2Vr+ssPoyEczDwfYbQkYnUNmgQKaNjp2Bs8sZAj0CpdhRI/ mhCTUoQQXZHSVBOPAAAAAAAA --------------ms020502060206020809020001--

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 06 Jul '09

06 Jul '09

--001636c5b1542f27b3046e045d1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > > Although with a slapd without debug symbols it works ok, there's an assert > that fails in slapd_clr_write method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): > > (gdb) bt > #0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 > #1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 > #2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 > #3 0x000000000043e447 in slapd_clr_write (s=<value optimized out>, wake=0) > at daemon.c:939 > #4 0x00000000004422dc in connection_write (s=403) at connection.c:1855 > #5 0x00000000004410e6 in slapd_daemon_task (ptr=<value optimized out>) at > daemon.c:2567 > #6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 > #7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 > #8 0x0000000000000000 in ?? () > > Hello, The problem still reproduces, all connection hangups after a weekend overloading the server.. Regards --001636c5b1542f27b3046e045d1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"borde= r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le= ft: 1ex;"><div class=3D"gmail_quote"><div><br>Although with a slapd without= debug symbols it works ok, there's an assert that fails in slapd_clr_w= rite method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"):<br> <br><font size=3D"3">(gdb) bt <br>#0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 <br>#1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 <br>#2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 <br>#3 0x000000000043e447 in slapd_clr_write (s=3D<value optimized out&= gt;, wake=3D0) at daemon.c:939 <br>#4 0x00000000004422dc in connection_write (s=3D403) at connection.c:18= 55 <br>#5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<value optimized = out>) at daemon.c:2567 <br>#6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 <br>#7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 <br>#8 0x0000000000000000 in ?? ()</font><br><br></div></div></blockquote>= <div><br>Hello,<br> <br> The problem still reproduces, all connection hangups after a weekend overlo= ading the server..<br> <br> Regards<br>=C2=A0</div></div><br> --001636c5b1542f27b3046e045d1b--

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 03 Jul '09

03 Jul '09

h.b.furuseth(a)usit.uio.no wrote: > The latest liblutil/passwd.c breaks with ./configure --enable-lmpasswd > and OpenSSL: > > passwd.c:660: error: expected declaration specifiers or '...' before '(' token > passwd.c:660: error: expected declaration specifiers or '...' before '&' token > passwd.c:661: error: conflicting types for 'DES_set_key' > /usr/include/openssl/des.h:222: error: previous declaration of 'DES_set_key' > > Preprocessor output for passwd.c shows that this in passwd.c: > static void > des_set_key( des_key *key, unsigned char *keyData) { ... } > conflicts with this macro from /usr/include/openssl/des_old.h: > #define des_set_key(k,ks) DES_set_key((k),&(ks)) > which when expanded tries to conflict with this prototype from > /usr/include/openssl/des.h: > int DES_set_key(const_DES_cblock *key,DES_key_schedule *schedule); > Fixed in HEAD. We should probably update from the old (des_*) to new (DES_*) as well. Already did this for the identical code in smbk5pwd.c... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by h.b.furuseth＠usit.uio.no 03 Jul '09

03 Jul '09

The latest liblutil/passwd.c breaks with ./configure --enable-lmpasswd and OpenSSL: passwd.c:660: error: expected declaration specifiers or '...' before '(' token passwd.c:660: error: expected declaration specifiers or '...' before '&' token passwd.c:661: error: conflicting types for 'DES_set_key' /usr/include/openssl/des.h:222: error: previous declaration of 'DES_set_key' Preprocessor output for passwd.c shows that this in passwd.c: static void des_set_key( des_key *key, unsigned char *keyData) { ... } conflicts with this macro from /usr/include/openssl/des_old.h: #define des_set_key(k,ks) DES_set_key((k),&(ks)) which when expanded tries to conflict with this prototype from /usr/include/openssl/des.h: int DES_set_key(const_DES_cblock *key,DES_key_schedule *schedule); -- Hallvard

1 0

(ITS#6196) back-config: multiple olcDbIndex Attributes can be added for the same Attributetype
by ralf＠OpenLDAP.org 03 Jul '09

03 Jul '09

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.223.21) Submitted by: ralf With ldapmodify I can add the following LDIF to cn=config: ------------------------------- dn: olcDatabase={1}hdb,cn=config add: olcdbindex olcdbindex: cn pres olcdbindex: cn eq ------------------------------- The server accepts it and seems to work fine after that. Restarting the server however fails after that. Error message is: 'duplicate index definition for attr "cn"' The ldapmodify should have returned that error already IMO. I am currently working on a fix. Should appear soon in HEAD.

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 03 Jul '09

03 Jul '09

--001636c5acf83a095e046dc7f0ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Wed, Jul 1, 2009 at 7:02 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, June 29, 2009 10:15 AM +0200 Jorge Perez Burgos < > jorge.perez(a)adaptia.net> wrote: > > Hello, >> >> I still reproduce this problem with 2.4.17-prerelease. I have a client >> that request a lof of operations at the same time through a connection. >> The slapd seems to overload and finally close the connection sending a >> reset to the client and when this happens the connection hungs eating the >> CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the >> same point of the first trace sent in this report. >> > > This should now really be fixed in HEAD and RE24. Please test. Although with a slapd without debug symbols it works ok, there's an assert that fails in slapd_clr_write method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): (gdb) bt #0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 #1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 #2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000043e447 in slapd_clr_write (s=<value optimized out>, wake=0) at daemon.c:939 #4 0x00000000004422dc in connection_write (s=403) at connection.c:1855 #5 0x00000000004410e6 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2567 #6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 #7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 #8 0x0000000000000000 in ?? () Best Regards --001636c5acf83a095e046dc7f0ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Jul 1, 2009 at 7:02 PM, Quanah Gibson-Mo= unt <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com" target=3D"_b= lank">quanah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt= 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div>--On Monday, June 29, 2009 10:15 AM +0200 Jorge Perez = Burgos <<a href=3D"mailto:jorge.perez@adaptia.net" target=3D"_blank">jor= ge.perez(a)adaptia.net</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hello,<br> <br> I still reproduce this problem with 2.4.17-prerelease. I have a client<br> that request a lof of operations at the same time through a connection.<br> The slapd seems to overload and finally close the connection sending a<br> reset to the client and when this happens the connection hungs eating the<b= r> CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the<br> same point of the first trace sent in this report.<br> </blockquote> <br></div></div> This should now really be fixed in HEAD and RE24. =C2=A0Please test.</block= quote><div><br>Although with a slapd without debug symbols it works ok, the= re's an assert that fails in slapd_clr_write method, ("assert( SLA= P_SOCK_IS_ACTIVE( s ))"):<br> <br><font size=3D"3">(gdb) bt <br>#0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 <br>#1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 <br>#2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 <br>#3 0x000000000043e447 in slapd_clr_write (s=3D<value optimized out&= gt;, wake=3D0) at daemon.c:939 <br>#4 0x00000000004422dc in connection_write (s=3D403) at connection.c:18= 55 <br>#5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<value optimized = out>) at daemon.c:2567 <br>#6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 <br>#7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 <br>#8 0x0000000000000000 in ?? ()</font><br><br><br>Best Regards<br></div= ></div><br> --001636c5acf83a095e046dc7f0ae--

1 0

Re: (ITS#6195) Replications with 2.3.43 master to 2.4.16 slave is failing
by quanah＠zimbra.com 02 Jul '09

02 Jul '09

--On Thursday, July 02, 2009 3:40 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > So, it appears to me that even though it must have at some point accepted > the first change, the entry on the server is not truly updated to reflect > that for some reason? That, or it "skipped" that change for reasons > unknown to me. Adding to the mystery, is what the server believes the entry looks like, even across restarts: dn: uid=acyen,cn=accounts,dc=stanford,dc=edu suSeasSunetID: acyen suDialinStatus: active suCreateAgent: AccountSlog suService: dialin suService: afs suService: leland suService: email suService: pts suService: seas suService: kerberos suEmailAdmin: acyen suSeasUriRouteTo: /~acyen suName: XXXXXXX uid: acyen suNameLF: XXXXXXXX suSeasStatus: active suKerberosStatus: active suEntryStatus: active suAccountStatus: active krb5PrincipalName: XXXXXXXX suSeasLocal: XXXXXXXXX suEmailAccountType: personal suAfsStatus: active suEmailStatus: active suMailDrop: XXXXXXXXX suCreateAPI: JNDI suKrb4Name: XXXXXXXXXX suPtsStatus: active suLelandStatus: active gecos: XXXXXX cn: XXXXXXX suAfsHomeDirectory: /afs/ir/users/a/c/acyen suPtsUid: 28906 loginShell: /bin/tcsh uidNumber: 28906 gidNumber: 37 homeDirectory: /afs/ir/users/a/c/acyen objectClass: posixAccount objectClass: suPtsService objectClass: suAccount objectClass: suOperational objectClass: suAfsService objectClass: suEmailService objectClass: suLelandService objectClass: suDialinService objectClass: suKerberosService objectClass: suSeasService suIdentifies: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,d c=edu seeAlso: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,dc=edu owner: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,dc=edu description: XXXXXXXXXX suEmailQuota: 1000 suDescription: XXXXXXXXXX structuralObjectClass: suAccount entryUUID: bd300052-dbd5-102c-8575-cd5814f999c3 creatorsName: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu createTimestamp: 20080701162309Z modifiersName: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu modifyTimestamp: 20090210171734Z entryCSN: 20090702065034.772554Z#000000#000#000000 entryDN: uid=acyen,cn=accounts,dc=stanford,dc=edu subschemaSubentry: cn=Subschema hasSubordinates: FALSE The first change, which we'd think had gone across given it is stuck on the second change, never appears to have been applied, but nothing was ever logged about this. The attributes and objectClass that were supposed to be deleted are still present. The value changes that were supposed to occur haven't. Now, the entryCSN is: 20090702065034.772554Z#000000#000#000000 vs the change time which is: 20090702070150.000014Z so clearly, the entry has never been updated with the change. Yet it *should* have been. How did we end up skipping a change from 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#6195) Replications with 2.3.43 master to 2.4.16 slave is failing
by quanah＠zimbra.com 02 Jul '09

02 Jul '09

--On Thursday, July 02, 2009 10:15 PM +0000 whm(a)stanford.edu wrote: > It looks like there is an attempt to remove objectclass=posixaccount > without removing gecos at the same time. The slapd -d -1 output of this system is quite interesting. First, here's the changelogs from the master. Note that there are *two* of them. In the first one, "gecos" is deleted: dn: reqStart=20090702070150.000014Z,cn=accesslog objectClass: auditModify reqStart: 20090702070150.000014Z reqEnd: 20090702070150.000016Z reqType: modify reqSession: 12280 reqAuthzID: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu reqDN: uid=acyen,cn=Accounts,dc=Stanford,dc=edu reqResult: 0 reqMod: gecos:- reqMod: cn:- reqMod: description:- reqMod: loginShell:- reqMod: uidNumber:- reqMod: gidNumber:- reqMod: homeDirectory:- reqMod: objectClass:= suPtsService reqMod: objectClass:= suAccount reqMod: objectClass:= suOperational reqMod: objectClass:= suAfsService reqMod: objectClass:= suEmailService reqMod: objectClass:= suLelandService reqMod: objectClass:= suDialinService reqMod: objectClass:= suKerberosService reqMod: objectClass:= suSeasService reqMod: suAfsStatus:= frozen reqMod: suSeasStatus:= frozen reqMod: suEmailStatus:= frozen reqMod: suLelandStatus:= frozen reqMod: suIdentifies:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=S tanford,dc=edu reqMod: seeAlso:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanfo rd,dc=edu reqMod: owner:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford ,dc=edu reqMod: suDialinStatus:= frozen reqMod: suPtsStatus:= frozen reqMod: suDescription:= XXXXXXX reqMod: entryCSN:= 20090702070150Z#000002#00#000000 reqMod: modifiersName:= cn=slog-accounts,cn=service,cn=applications,dc=stanfor d,dc=edu reqMod: modifyTimestamp:= 20090702070150Z So, you can see gecos is clearly deleted here. In fact, it is the very first thing deleted. The second change is where things are failing: dn: reqStart=20090702075511.000006Z,cn=accesslog objectClass: auditModify reqStart: 20090702075511.000006Z reqEnd: 20090702075511.000007Z reqType: modify reqSession: 13583 reqAuthzID: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu reqDN: uid=acyen,cn=Accounts,dc=Stanford,dc=edu reqResult: 0 reqMod: krb5PrincipalName:- reqMod: suKrb4Name:- reqMod: suKerberosStatus:- reqMod: objectClass:= suPtsService reqMod: objectClass:= suAccount reqMod: objectClass:= suOperational reqMod: objectClass:= suAfsService reqMod: objectClass:= suEmailService reqMod: objectClass:= suLelandService reqMod: objectClass:= suDialinService reqMod: objectClass:= suSeasService reqMod: suIdentifies:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=S tanford,dc=edu reqMod: seeAlso:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanfo rd,dc=edu reqMod: owner:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford ,dc=edu reqMod: suDescription:= XXXXXXX reqMod: suService:= dialin reqMod: suService:= afs reqMod: suService:= leland reqMod: suService:= email reqMod: suService:= pts reqMod: suService:= seas reqMod: suAccountStatus:= inactive reqMod: entryCSN:= 20090702075511Z#000000#00#000000 reqMod: modifiersName:= cn=slog-accounts,cn=service,cn=applications,dc=stanfor d,dc=edu reqMod: modifyTimestamp:= 20090702075511Z Now, the replica was loaded from an LDIF taken on 2009/07/01, so it should have taken both of these changes just fine: dn: dc=stanford,dc=edu objectClass: dcObject objectClass: organization o: Stanford University dc: stanford l: Palo Alto structuralObjectClass: organization entryUUID: e67c08ca-adc9-102a-8f07-03156481d080 creatorsName: cn=manager,dc=stanford,dc=edu modifiersName: cn=manager,dc=stanford,dc=edu createTimestamp: 20060722123236Z modifyTimestamp: 20060722123236Z contextCSN: 20090701110754Z#000000#00#000000 The slapd -d -1 log shows it is clearly processing the second change and failing there: 0000: 82 04 37 04 2c 72 65 71 53 74 61 72 74 3d 32 30 ..7.,reqStart=20 0010: 30 39 30 37 30 32 30 37 35 35 31 31 2e 30 30 30 090702075511.000 0020: 30 30 36 5a 2c 63 6e 3d 61 63 63 65 73 73 6c 6f 006Z,cn=accesslo 0030: 67 30 82 04 05 30 13 04 07 72 65 71 54 79 70 65 g0...0...reqType 0040: 31 08 04 06 6d 6f 64 69 66 79 30 33 04 05 72 65 1...modify03..re 0050: 71 44 4e 31 2a 04 28 75 69 64 3d 61 63 79 65 6e qDN1*.(uid=acyen 0060: 2c 63 6e 3d 41 63 63 6f 75 6e 74 73 2c 64 63 3d ,cn=Accounts,dc= 0070: 53 74 61 6e 66 6f 72 64 2c 64 63 3d 65 64 75 30 Stanford,dc=edu0 0080: 82 03 87 04 06 72 65 71 4d 6f 64 31 82 03 7b 04 .....reqMod1..{. 0090: 13 6b 72 62 35 50 72 69 6e 63 69 70 61 6c 4e 61 .krb5PrincipalNa 00a0: 6d 65 3a 2d 04 0c 73 75 4b 72 62 34 4e 61 6d 65 me:-..suKrb4Name 00b0: 3a 2d 04 12 73 75 4b 65 72 62 65 72 6f 73 53 74 :-..suKerberosSt 00c0: 61 74 75 73 3a 2d 04 1a 6f 62 6a 65 63 74 43 6c atus:-..objectCl 00d0: 61 73 73 3a 3d 20 73 75 50 74 73 53 65 72 76 69 ass:= suPtsServi 00e0: 63 65 04 17 6f 62 6a 65 63 74 43 6c 61 73 73 3a ce..objectClass: 00f0: 3d 20 73 75 41 63 63 6f 75 6e 74 04 1b 6f 62 6a = suAccount..obj 0100: 65 63 74 43 6c 61 73 73 3a 3d 20 73 75 4f 70 65 ectClass:= suOpe 0110: 72 61 74 69 6f 6e 61 6c 04 1a 6f 62 6a 65 63 74 rational..object 0120: 43 6c 61 73 73 3a 3d 20 73 75 41 66 73 53 65 72 Class:= suAfsSer (etc). bdb_modify_internal: 0x00074e3f: uid=acyen,cn=accounts,dc=stanford,dc=edu <= acl_access_allowed: granted to database root bdb_modify_internal: delete krb5PrincipalName bdb_modify_internal: delete suKrb4Name bdb_modify_internal: delete suKerberosStatus bdb_modify_internal: replace objectClass bdb_modify_internal: replace suIdentifies bdb_modify_internal: replace seeAlso bdb_modify_internal: replace owner bdb_modify_internal: replace suDescription bdb_modify_internal: replace suService bdb_modify_internal: replace suAccountStatus bdb_modify_internal: replace entryCSN bdb_modify_internal: replace modifiersName bdb_modify_internal: replace modifyTimestamp oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suPtsService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suAccount" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suOperational" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suAfsService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suEmailService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suLelandService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suDialinService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suSeasService" oc_check_allowed type "suSeasSunetID" oc_check_allowed type "suDialinStatus" oc_check_allowed type "suCreateAgent" oc_check_allowed type "suEmailAdmin" oc_check_allowed type "suSeasUriRouteTo" oc_check_allowed type "suName" oc_check_allowed type "uid" oc_check_allowed type "suNameLF" oc_check_allowed type "suSeasStatus" oc_check_allowed type "suEntryStatus" oc_check_allowed type "suSeasLocal" oc_check_allowed type "suEmailAccountType" oc_check_allowed type "suAfsStatus" oc_check_allowed type "suEmailStatus" oc_check_allowed type "suMailDrop" oc_check_allowed type "suCreateAPI" oc_check_allowed type "suPtsStatus" oc_check_allowed type "suLelandStatus" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "gecos" Entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), attribute 'gecos' not allowed entry failed schema check: attribute 'gecos' not allowed hdb_modify: modify failed (65) So, it appears to me that even though it must have at some point accepted the first change, the entry on the server is not truly updated to reflect that for some reason? That, or it "skipped" that change for reasons unknown to me. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 02 Jul '09

02 Jul '09

This is a cryptographically signed message in MIME format. --------------ms090702060406060604010109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: current CVS HEAD (as of July 2, 2009) >> OS: Fedora >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.16-moznss-20090702.patch >> >> This is a new patch - diffs from older patch >> 1) Implements tls_m.c MozNSS crypto - including parsing of openssl-style >> cipher suite configuration - things still missing >> 1a) support for multiple MozNSS initialize - work is being done upstream >> to support this >> 1b) support for reading PEM files - there is now a PEM PKCS11 module in >> Fedora which is being incorporated into NSS upstream > > Thanks, I've committed most of this patch. I've omitted the SHA1/MD5 > patches since I think it's better to use our bundled version uniformly > for password hashing. > > For doc purposes, it's simple for us to point people at openssl.org or > gnutls.org; what's a canonical URL to direct people to for MozNSS? I'm not sure - looks like migration is underway to both https://wiki.mozilla.org/NSS and https://developer.mozilla.org/en/NSS but they both refer back to the old "homepage" at http://www.mozilla.org/projects/security/pki/nss/ > >> 2) removes pkg-config stuff from configure.in - user must specify >> include path and lib path in environment > > Ok. The configure patches are in too, so moznss may be selected. But I > think we'll wait on making this generally available until we know what > the story will be for PEM and multi-init. Ok --------------ms090702060406060604010109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwNzAyMjIzNDQyWjAjBgkqhkiG9w0BCQQxFgQUBzW+vw+d Q7cfKi6VjU3nO4/Q+WcwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQB7RxgkWvk/Ve15UeL2O2vKELQZrH6PZWNKgAJx qbGMwrGIlZK4PBV4gIelgjnYJ7DGGTmNck0OCsFg6t9a7jPHPZNJZoNsCw/OZKQsh0vELmvC +dTAFn37JWKV5Td/1KWnDcWpR1XW3Vb7pw/rIs4kFr2IPSMWvKrnMzOQULqAfVrXiI0E0kky +sS3wiTKSb2m5XnsXdfkiHsOrqNkkOXk3Bf8sSS6PhZzwSsEiOuC7xHFTnQq56UCLWNdltEP acZggyGp4eTOxSDwcoEqpdpi91s6YcGoIWbLgsC21446js3qpG5QoR2HTLUqCOPkeA+LZtho Q/rrhJwlvXZlw/7SAAAAAAAA --------------ms090702060406060604010109--

1 0

(ITS#6195) Replications with 2.3.43 master to 2.4.16 slave is failing
by whm＠stanford.edu 02 Jul '09

02 Jul '09

Full_Name: Bill MacAllister Version: 2.3.43+ and 2.4.16+ OS: debian 4 and 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) I have a master server that is running 2.3.43 and a slave running 2.4.16. When the master/replica databases are created an entry has an objectclass=posixaccount and gecos=some-name. When the objectclass/gecos is deleted from the master entry replication on the slave fails with: Jul 2 11:16:46 ldap-liv1 slapd[30523]: Entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), attribute 'gecos' not allowed Jul 2 11:16:46 ldap-liv1 slapd[30523]: entry failed schema check: attribute 'gecos' not allowed Jul 2 11:16:46 ldap-liv1 slapd[30523]: null_callback : error code 0x41 Jul 2 11:16:46 ldap-liv1 slapd[30523]: syncrepl_message_to_op: rid=000 be_modify uid=acyen,cn=Accounts,dc=Stanford,dc=edu (65) Jul 2 11:16:46 ldap-liv1 slapd[30523]: do_syncrepl: rid=000 rc 65 retrying Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 fd=13 ACCEPT from IP=171.67.22.24:42094 (IP=0.0.0.0:389) Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=0 BIND dn="" method=128 Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=0 RESULT tag=97 err=0 text= Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=1 SRCH base="dc=stanford,dc=edu" scope=0 deref=0 filter="(objectClass=*)" Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=2 UNBIND Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 fd=13 closed Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 fd=13 ACCEPT from IP=171.67.16.36:35971 (IP=0.0.0.0:389) Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=0 BIND dn="" method=128 Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=0 RESULT tag=97 err=0 text= Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=1 SRCH base="dc=stanford,dc=edu" scope=0 deref=0 filter="(objectClass=*)" Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=2 UNBIND Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 fd=13 closed Jul 2 11:17:28 ldap-liv1 slapd[30523]: connection_read(13): no connection! Jul 2 11:17:46 ldap-liv1 slapd[30523]: Entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), attribute 'gecos' not allowed Jul 2 11:17:46 ldap-liv1 slapd[30523]: entry failed schema check: attribute 'gecos' not allowed Jul 2 11:17:46 ldap-liv1 slapd[30523]: null_callback : error code 0x41 Jul 2 11:17:46 ldap-liv1 slapd[30523]: syncrepl_message_to_op: rid=000 be_modify uid=acyen,cn=Accounts,dc=Stanford,dc=edu (65) Jul 2 11:17:46 ldap-liv1 slapd[30523]: do_syncrepl: rid=000 rc 65 retrying It looks like there is an attempt to remove objectclass=posixaccount without removing gecos at the same time. I have re-created the slave database a second time just to make sure there was nothing that I missed with the initial load.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 02 Jul '09

02 Jul '09

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: current CVS HEAD (as of July 2, 2009) > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.16-moznss-20090702.patch > > This is a new patch - diffs from older patch > 1) Implements tls_m.c MozNSS crypto - including parsing of openssl-style > cipher suite configuration - things still missing > 1a) support for multiple MozNSS initialize - work is being done upstream > to support this > 1b) support for reading PEM files - there is now a PEM PKCS11 module in > Fedora which is being incorporated into NSS upstream Thanks, I've committed most of this patch. I've omitted the SHA1/MD5 patches since I think it's better to use our bundled version uniformly for password hashing. For doc purposes, it's simple for us to point people at openssl.org or gnutls.org; what's a canonical URL to direct people to for MozNSS? > 2) removes pkg-config stuff from configure.in - user must specify > include path and lib path in environment Ok. The configure patches are in too, so moznss may be selected. But I think we'll wait on making this generally available until we know what the story will be for PEM and multi-init. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 02 Jul '09

02 Jul '09

Full_Name: Rich Megginson Version: CVS HEAD (2.4.16+) OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.16-libldif-20090702.patch Submission from: (NULL) (76.113.59.19) This patch allows liblutil to provide the LDIF reading and writing functions as public APIs in a libldif, and exposes ldif.h to the public API. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not assigned rights and/or interest in this work to any party. I, Richard Megginson am authorized by Red Hat, Inc., my employer, to release this work under the following terms. Red Hat, Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 02 Jul '09

02 Jul '09

Full_Name: Rich Megginson Version: current CVS HEAD (as of July 2, 2009) OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.16-moznss-20090702.patch This is a new patch - diffs from older patch 1) Implements tls_m.c MozNSS crypto - including parsing of openssl-style cipher suite configuration - things still missing 1a) support for multiple MozNSS initialize - work is being done upstream to support this 1b) support for reading PEM files - there is now a PEM PKCS11 module in Fedora which is being incorporated into NSS upstream 2) removes pkg-config stuff from configure.in - user must specify include path and lib path in environment This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not assigned rights and/or interest in this work to any party. I, Richard Megginson am authorized by Red Hat, Inc., my employer, to release this work under the following terms. Red Hat, Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#6193) OpenLDAP 2.4.16 does not compile on Windows
by frank.offermanns＠caseris.de 02 Jul '09

02 Jul '09

Hello, you are right, the Version 2.4.16 has this problem. I had the same=20 problem. You have to compile the version from CVS HEAD. There the=20 configure file has been fixed. Best regards, Frank Offermanns -- -- Frank Offermanns | Entwicklung | CASERIS GmbH=20 Fon: +49 2402 7654-566 Fax: +49 2402 7654-8566 | E-Mail: Frank.Offermanns(a)caseris.com=20 -- CASERIS GmbH | Am Birkenfeld 1-3 | D-52222 Stolberg Gesch=E4ftsf=FChrer Dipl.-Ing. Stefan Preu=DF | Registergericht: Amtsgerich= t=20 Aachen, HRB 14758 -- CAESAR und CASERIS - Ihr Team f=FCr die Zukunft --

1 0

RE: (ITS#6193) OpenLDAP 2.4.16 does not compile on Windows
by emmanuel.duru＠atosorigin.com 02 Jul '09

02 Jul '09

One just has to patch three makefiles to build this release, that's no problem for me... > -----Message d'origine----- > De=A0: Howard Chu [mailto:hyc@symas.com] > Envoy=E9=A0: jeudi 2 juillet 2009 10:56 > =C0=A0: emmanuel.duru(a)atosorigin.com > Cc=A0: openldap-its(a)openldap.org > Objet=A0: Re: (ITS#6193) OpenLDAP 2.4.16 does not compile on Windows >=20 > emmanuel.duru(a)atosorigin.com wrote: > > Full_Name: Emmanuel Duru > > Version: 2.4.16 > > OS: Windows > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.78.0.134) > > > > > > OpenLDAP 2.4.16 does not compile on Windows. > > When compiling liblber and libldap, there are undefined references = to > winsock > > functions. > > The last version I used was OpenLDAP 2.4.13 and it worked fine. > > Comparing both versions, I see that there misses -lws2_32 in liblber = and > libldap > > makefiles in 2.4.16 release. >=20 > That's interesting. At least one other person (ITS#6174) disagrees = with > you. > Seems there's something wrong with your build environment. Since other > folks > are building on Windows, I don't believe this is a bug in OpenLDAP. >=20 > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6193) OpenLDAP 2.4.16 does not compile on Windows
by hyc＠symas.com 02 Jul '09

02 Jul '09

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.16 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.134) > > > OpenLDAP 2.4.16 does not compile on Windows. > When compiling liblber and libldap, there are undefined references to winsock > functions. > The last version I used was OpenLDAP 2.4.13 and it worked fine. > Comparing both versions, I see that there misses -lws2_32 in liblber and libldap > makefiles in 2.4.16 release. That's interesting. At least one other person (ITS#6174) disagrees with you. Seems there's something wrong with your build environment. Since other folks are building on Windows, I don't believe this is a bug in OpenLDAP. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6193) OpenLDAP 2.4.16 does not compile on Windows
by emmanuel.duru＠atosorigin.com 02 Jul '09

02 Jul '09

Full_Name: Emmanuel Duru Version: 2.4.16 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.134) OpenLDAP 2.4.16 does not compile on Windows. When compiling liblber and libldap, there are undefined references to winsock functions. The last version I used was OpenLDAP 2.4.13 and it worked fine. Comparing both versions, I see that there misses -lws2_32 in liblber and libldap makefiles in 2.4.16 release.

1 0

Re: (ITS#6174) Backtrace for a segfault
by hyc＠symas.com 01 Jul '09

01 Jul '09

Please do not send HTML or MIME emails, the contents are unintelligible. frank.offermanns(a)caseris.de wrote: > Dies ist eine mehrteilige Nachricht im MIME-Format. > --=_alternative 002BEC64C12575DF_= > Content-Type: text/plain; charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hello, > > for this test setup i got an empty database and tried to add 20000 Users=20 > under o=3Dcaesar,ou=3DUsers,o=3Dtestcas at server1 (windos vista) while try= > ing=20 > to add 20000 Users under o=3Dcaesar,ou=3DUsers,o=3Dtestxp at server2 (Windo= > ws=20 > XP). The slapd.exe on the XP Server crashed. Compiled the version from=20 > HEAD with Mingw/MSYS for windows. > - > Frank Offermanns | Entwicklung | CASERIS GmbH=20 > Fon: +49 2402 7654-566 > Fax: +49 2402 7654-8566 | E-Mail: Frank.Offermanns(a)caseris.com=20 > -- > CASERIS GmbH | Am Birkenfeld 1-3 | D-52222 Stolberg > Gesch=E4ftsf=FChrer Dipl.-Ing. Stefan Preu=DF | Registergericht: Amtsgerich= > t=20 > Aachen, HRB 14758 > > --=_alternative 002BEC64C12575DF_= > Content-Type: text/html; charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6192) OpenLDAP doesn't support SHA-256 signed certificates
by hyc＠symas.com 01 Jul '09

01 Jul '09

sjv(a)genoscope.cns.fr wrote: > Full_Name: Simon Vallet > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.83.221.39) > > > Hi, > > trying to use SHA-256 signed certificates for SSL connections to an OpenLDAP > server leads to the following OpenSSL error messages : > > TLS certificate verification: Error, certificate signature failure > tls_write: want=7, written=7 > 0000: 15 03 01 00 02 02 33 ......3 > TLS trace: SSL3 alert write:fatal:decrypt error > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS: can't connect: error:0D0C50A1:asn1 encoding > routines:ASN1_item_verify:unknown message digest algorithm. > > This is due to OpenLDAP not explicitly enabling SHA-2 ciphers after calling > SSLeay_add_ssl_algorithms(), which only enables some digest algorithms. > > As SHA-256 is becoming more common and as it is, in fact, mandated by TLS 1.2, I > think OpenLDAP should support it. > > For a similar problem, you might want to take a look at > http://bugs.exim.org/show_bug.cgi?id=674 Thanks for the report. I've chosen to call OpenSSL_add_all_digests() in our init. Note that this has no impact on the actual TLS protocol handshake, since OpenSSL still only supports TLSv1.0. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 01 Jul '09

01 Jul '09

--On Monday, June 29, 2009 10:15 AM +0200 Jorge Perez Burgos <jorge.perez(a)adaptia.net> wrote: > Hello, > > I still reproduce this problem with 2.4.17-prerelease. I have a client > that request a lof of operations at the same time through a connection. > The slapd seems to overload and finally close the connection sending a > reset to the client and when this happens the connection hungs eating the > CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the > same point of the first trace sent in this report. This should now really be fixed in HEAD and RE24. Please test. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6192) OpenLDAP doesn't support SHA-256 signed certificates
by sjv＠genoscope.cns.fr 01 Jul '09

01 Jul '09

Full_Name: Simon Vallet Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.83.221.39) Hi, trying to use SHA-256 signed certificates for SSL connections to an OpenLDAP server leads to the following OpenSSL error messages : TLS certificate verification: Error, certificate signature failure tls_write: want=7, written=7 0000: 15 03 01 00 02 02 33 ......3 TLS trace: SSL3 alert write:fatal:decrypt error TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm. This is due to OpenLDAP not explicitly enabling SHA-2 ciphers after calling SSLeay_add_ssl_algorithms(), which only enables some digest algorithms. As SHA-256 is becoming more common and as it is, in fact, mandated by TLS 1.2, I think OpenLDAP should support it. For a similar problem, you might want to take a look at http://bugs.exim.org/show_bug.cgi?id=674 Simon

1 0

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by michael＠stroeder.com 01 Jul '09

01 Jul '09

hyc(a)symas.com wrote: > Thanks, fixed in HEAD. Seems to work now. Ciao, Michael.

1 0

Re: (ITS#6084) ppolicy should allow scheduled password expiration
by Guillaume.Rousse＠inria.fr 01 Jul '09

01 Jul '09

Howard Chu a écrit : > Guillaume Rousse wrote: >> Howard Chu a écrit : >>> Since the ppolicy module's behavior is dictated by the Behera draft, any >>> suggestions for changes in this area should probably first be raised on >>> the ietf-ldapext mailing list. >> Right, but openldap implementation already have extension, such >> pwdCheckModule. Additional extension could be implemented, before >> getting standardized. >> >> Also, the ietf-ldapext seems to be an highly-technical list, and I don't >> feel confortable enough to post this kind of request directly there. >> Discussing various limitations of ppolicy among openldap users first >> would probably allow openldap core team to suggest a more polished >> extension request themselves. > > The draft doesn't say anything about setting pwdAccountLockedTime to a > value in the future; since it doesn't preclude it I've fixed up the code > to handle this case. However, it's not a good solution for your purpose, > since the pwdAccountLockedTime value is automatically replaced with the > current time if too many Bind failures occur, and it's automatically > deleted when a password is changed. We'll leave this in HEAD on an > experimental basis for now, until a real solution is spec'd out. Indeed. Moreover, a variable date field is not a practical field for sorting out valid accounts in search requests, for authorization purposes. Anyway, thanks for the change. -- BOFH excuse #320: You've been infected by the Telescoping Hubble virus.

1 0

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by hyc＠symas.com 01 Jul '09

01 Jul '09

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Ströder >>>>> Version: HEAD synced now >>>>> OS: openSUSE Linux 11.1 >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (84.163.60.129) >>>> >>>>> Setting up policy state forwarding test... >>>>> Starting slapd consumer on TCP/IP port 9012... >>>>> Configuring syncprov on provider... >>>>> Using ldapsearch to check that slapd is running... >>>>> Waiting 5 seconds for slapd to start... >>>>> Configuring syncrepl on consumer... >>>>> ldapmodify failed (21)! >>>>>>>>>> ./scripts/test022-ppolicy failed (exit 21) >>>>> make[2]: *** [bdb-mod] Error 21 >>>>> make[2]: Leaving directory >>>>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>>>> make[1]: *** [test] Error 2 >>>>> make[1]: Leaving directory >>>>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>>>> make: *** [test] Error 2 >>>> >>>> Please provide a tarball of the testrun directory. >>> >>> Here it is: >>> http://www.stroeder.com/temp/openldap/its-6191-testrun-test022-ppolicy_fail… >>> >> >> Looks like you don't have back-ldap enabled in your slapd. What were >> your configure flags? > > See my build script below (lines wrapped herein). Thanks, fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by michael＠stroeder.com 01 Jul '09

01 Jul '09

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Ströder >>>> Version: HEAD synced now >>>> OS: openSUSE Linux 11.1 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (84.163.60.129) >>> >>>> Setting up policy state forwarding test... >>>> Starting slapd consumer on TCP/IP port 9012... >>>> Configuring syncprov on provider... >>>> Using ldapsearch to check that slapd is running... >>>> Waiting 5 seconds for slapd to start... >>>> Configuring syncrepl on consumer... >>>> ldapmodify failed (21)! >>>>>>>>> ./scripts/test022-ppolicy failed (exit 21) >>>> make[2]: *** [bdb-mod] Error 21 >>>> make[2]: Leaving directory >>>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>>> make[1]: *** [test] Error 2 >>>> make[1]: Leaving directory >>>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>>> make: *** [test] Error 2 >>> >>> Please provide a tarball of the testrun directory. >> >> Here it is: >> http://www.stroeder.com/temp/openldap/its-6191-testrun-test022-ppolicy_fail… >> > > Looks like you don't have back-ldap enabled in your slapd. What were > your configure flags? See my build script below (lines wrapped herein). Note that this worked until your recent changes to ppolicy. Ciao, Michael. --------------------------- snip --------------------------- OPENLDAP_VERSION=$1 BDB_PREFIX="/dummy" SSL_PREFIX="/dummy" KRB5_PREFIX="/dummy" SASL_PREFIX="/dummy" OPENLDAP_PREFIX="/opt/openldap-${OPENLDAP_VERSION}" export CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER" export CPPFLAGS="-I${SSL_PREFIX}/include -I${BDB_PREFIX}/include -I${KRB5_PREFIX}/include -I${SASL_PREFIX}/include -DDEVEL" #export CPPFLAGS="-I${SSL_PREFIX}/include -I${BDB_PREFIX}/include" export LDFLAGS="-L${BDB_PREFIX}/lib -L${SSL_PREFIX}/lib -L${KRB5_PREFIX}/lib -L${SASL_PREFIX}/lib -Wl,-R${SSL_PREFIX}/lib -Wl,-R${BDB_PREFI X}/lib,-R${SASL_PREFIX}/lib,-R${KRB5_PREFIX}/lib" make distclean ./configure \ --prefix=${OPENLDAP_PREFIX} \ --enable-dynamic=yes \ --enable-ndb=no \ --enable-modules \ --enable-backends=mod \ --enable-overlays=mod \ --enable-perl=no \ --enable-shell=no \ --enable-local=yes \ --enable-slapi=yes \ --with-cyrus-sasl=yes \ --with-kerberos=yes \ --with-tls=yes \ --with-threads=yes \ --with-odbc=auto \ --enable-crypt=yes \ --enable-spasswd=yes \ --enable-lmpasswd=yes \ --enable-shared=yes make depend make ulimit -c unlimited export SLEEP1=7 export SLEEP2=15 export SLAPD_DEBUG=16389 rm ./tests/core.* make test

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs