openldap-bugs June 2011

openldap-bugs@openldap.org

35 participants
131 discussions

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

michael(a)stroeder.com wrote: > BTW: This is git master (formerly known as HEAD). > > See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz I see, and I was also able to reproduce it here. The difference is that on server2, 2 of the entries have objectClass: glue instead of their correct objectclasses. From the diffs, this affected cn=schema,cn=config and olcDatabase={0}config,cn=config. Looking at the logs, this happened because during a syncrepl_nonpresent pass, the UUIDs for these two entries didn't match the UUIDs sent from some other master, so syncrepl attempted to delete them. Generally this is normal - cn=schema,cn=config and olcDatabase={0},cn=config are always created automatically by each slapd, so naturally their UUIDs differ on each server. But, also generally, after the first refresh each consumer would modify their local entries and overwrite the UUIDs with the ones received from their provider. Not sure why this didn't happen this time around. (back-config explicitly prevents any attempts to delete both of these entries. When syncrepl fails to delete an entry, it does a modify to change the objectclass to glue, which explains how they got to their final state when the test aborted.) -- -- 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#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 04 Jun '11

04 Jun '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> BTW: This is git master (formerly known as HEAD). >> >> See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz > > I have the test running now, will see how it goes. It's probably a good idea > to include the git commit ID now instead of just referencing master/HEAD . I always do git pull before posting an ITS applying HEAD to make sure nothing came in after the error. Ciao, Michael.

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

michael(a)stroeder.com wrote: > BTW: This is git master (formerly known as HEAD). > > See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz I have the test running now, will see how it goes. It's probably a good idea to include the git commit ID now instead of just referencing master/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#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 04 Jun '11

04 Jun '11

BTW: This is git master (formerly known as HEAD). See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz

1 0

(ITS#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 04 Jun '11

04 Jun '11

Full_Name: Version: OS: URL: Submission from: (NULL) (84.163.63.172) test050 occasionally fails... $ ./run -l 100 -b bdb test050 [..] Cleaning up test run directory from this run. Running 19 of 100 iterations running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Inserting syncprov overlay on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Configuring syncrepl on server 2... Starting server 3 on TCP/IP port 9013... Using ldapsearch to check that server 3 is running... Configuring syncrepl on server 3... Starting server 4 on TCP/IP port 9014... Using ldapsearch to check that server 4 is running... Configuring syncrepl on server 4... Adding schema and databases on server 1... Using ldapadd to populate server 1... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read config from server 1... Using ldapsearch to read config from server 2... Using ldapsearch to read config from server 3... Using ldapsearch to read config from server 4... Comparing retrieved configs from server 1 and server 2... test failed - server 1 and server 2 configs differ

1 0

Re: (ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by jvcelak＠redhat.com 04 Jun '11

04 Jun '11

> > adding entries to LDAP database from file using ldapadd tool causes > > memory > > corruption error, when the last line of the input file is not > > terminated by '\n' > > character. > > Don't do that. I agree. But the tool should not crash on invalid output anyway. > > I am attaching proposed patch, which fixes this issue. > > The patch uses a GNU-specific function. Since GLIBC is not supported > on all of > the platforms OpenLDAP supports, the patch is not acceptable as-is. Sorry, I missed that. I will fix it and resend the patch. Jan

1 0

Re: (ITS#6946) ldapexop: ber_free_buf: Assertion failed
by hyc＠symas.com 03 Jun '11

03 Jun '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-110519-ldapexop-double-free.patch > Submission from: (NULL) (209.132.186.34) > > > Hello. > > A problem with crashing ldapexop was reported to our bugzilla. All versions > since 2.4.24 are affected. It seems that the bug was introduced by following > change in ldapexop.c. > > http://www.openldap.org/devel/cvsweb.cgi/clients/tools/ldapexop.c.diff?r1=1… > > Easy to reproduce. With clean configuration run: > $ ldapexop -H ldap:// -x whoami > anonymous > ldapexop: ../../../libraries/liblber/io.c:186: ber_free_buf: Assertion > `((ber)->ber_opts.lbo_valid==0x2)' failed. > Aborted > > Complete steps to reproduce in Fedora are specified in the original bugreport: > https://bugzilla.redhat.com/show_bug.cgi?id=699683 > > I think it is cause by double freeing the result. I am attaching a proposed > patch. Please, review my change. > > Thank you. Thanks for the report, patch applied to git. -- -- 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#6947) ldapadd crashes with LDIFs with invalid line termination
by hyc＠symas.com 03 Jun '11

03 Jun '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110519-ldif-countlines.patch > Submission from: (NULL) (209.132.186.34) > > > Hello, > > adding entries to LDAP database from file using ldapadd tool causes memory > corruption error, when the last line of the input file is not terminated by '\n' > character. Don't do that. The LDIF specification says that all LDIF elements are terminated by SEP (CR LF or LF). Anything not conforming to this is not valid LDIF. As usual, garbage-in-garbage-out. The entries are added correctly. > > All version since 2.4.23 are affected. > > $ cat>/tmp/input.ldif<< EOF >> dn: cn=A,dc=my-domain,dc=com >> objectClass: inetOrgPerson >> objectClass: organizationalPerson >> objectClass: person >> objectClass: top >> cn: A >> sn: A >> uid: A >> mail: A(a)example.com >> EOF > $ wc -c /tmp/input.ldif > 166 /tmp/input.ldif > $ truncate -s 165 /tmp/input.ldif > $ hexdump -c /tmp/input.ldif > 0000000 d n : c n = A , d c = m y - d > 0000010 o m a i n , d c = c o m \n o b j > 0000020 e c t C l a s s : i n e t O r > 0000030 g P e r s o n \n o b j e c t C l > 0000040 a s s : o r g a n i z a t i o > 0000050 n a l P e r s o n \n o b j e c t > 0000060 C l a s s : p e r s o n \n o b > 0000070 j e c t C l a s s : t o p \n c > 0000080 n : A \n s n : A \n u i d : > 0000090 A \n m a i l : A @ e x a m p l > 00000a0 e . c o m > 00000a5 > $ ldapadd -H ldap:// -D cn=Manager,dc=my-domain,dc=com -x -w password -f > /tmp/input.ldif > adding new entry "cn=A,dc=my-domain,dc=com" > > *** glibc detected *** ldapadd: free(): invalid pointer: 0x0000000001c435c8 *** > ======= Backtrace: ========= > /lib64/libc.so.6[0x3626e76d63] > ldapadd[0x404505] > /lib64/libc.so.6(__libc_start_main+0xfd)[0x3626e1ee5d] > ldapadd[0x4037e9] > ======= Memory map: ======== > ... > > I am attaching proposed patch, which fixes this issue. The patch uses a GNU-specific function. Since GLIBC is not supported on all of the platforms OpenLDAP supports, the patch is not acceptable as-is. -- -- 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#6831) Proxycache database corruption
by hyc＠symas.com 03 Jun '11

03 Jun '11

ryans(a)aweber.com wrote: > Some more information: once I changed the search base from ou=Users,dc=example,dc=com to dc=example,dc=com to "fix" the > problem for that particular user (after which the original query with the ou=Users,dc=example,dc=com search base began > working again), the following entries popped up in the log: > ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-fixing-br… > > It gets stranger, though. If I start out by using the root entry as the search base (dc=example,dc=com) with a user who > is not yet in the cache, not only will it say it is ANSWERABLE (which it clearly isn't) and then return nothing without > even trying to reach out to the upstream host, but if I then change the search base to ou=Users,dc=example,dc=com, I get > the following error on the CLI (and this is with a successful bind as the directory admin): > > > ldapsearch -x -D cn=admin,dc=example,dc=com -y /etc/ldap.secret -H ldaps://localhost -LLL -b cn=admin,dc=example,dc=com > '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe4))' uid > No such object (32) > Matched DN: dc=example,dc=com > > Debugging logs generated by that query can be found here: > ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-attempt-t… I'm not sure I reproduced all the behaviors you were seeing, but I've reproduced at least one of them and fixed it in git. Please pull the latest pcache.c and test, thanks. -- -- 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#6959) ldap_dnfree not mentioned anywhere
by hyc＠symas.com 03 Jun '11

03 Jun '11

frank.muzzulini(a)comsoft.aero wrote: > Full_Name: Frank Muzzulini > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.221.120.78) > > > Hi, > > Reading the documentation of ldap_str2dn I was wondering how to free the > allocated DN. After browsing for a while I loaded the latest tarball to see some > example code and found ldap_dnfree. > > I re-checked and indeed the function is not mentioned anywhere in the docs > ("find doc -type f | xargs grep ldap_dnfree" found nothing). Added to git, thanks for the report. -- -- 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2011