openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

Re: (ITS#6958) slapd segmentation fault with TLSCRLCheck all
by Howard Chu 03 Jun '11

03 Jun '11

Can't reproduce this on Linux. Someone with a FreeBSD installation will have to investigate this.

1 0

Re: (ITS#6960) Out of memory erro occurs when running LDAP
by hyc＠symas.com 03 Jun '11

03 Jun '11

ArunPrasathSevugan(a)oracle.com wrote: > Full_Name: Arun Prasath > Version: 3 > OS: Window Xp > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.225.129.57) > > > Hi, > > We have a tool integrated with LDAP to load all the users in Cognos reporting. > There are about 5000+ users and while running LDAPCONFIG we have been getting > out of memory exception issue. > > In the task manage I could see the LDAP is using memory of around 3 GB and > finally errors out. > > Please help us to load the 5000+ users. It doesn't sound like you're using OpenLDAP. We have no LDAPCONFIG to run and we have no "Version 3" of our software. Please try contacting the actual vendor of your LDAP software. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6864) delta-sync - contextCSN not updating on provider
by hyc＠symas.com 03 Jun '11

03 Jun '11

yuribank(a)gmail.com wrote: > Full_Name: Yuri Bank > Version: 2.4.23-24 > OS: Linux Ubuntu 10.10 > URL: http://yuri.easytospell.net/consumer.provider.txt > Submission from: (NULL) (67.180.182.165) > > > This issue exists in both versions 2.4.23 and 2.4.24 > > I've found an interesting problem with delta-sync replication in which the > ContextCSN on my consumers is higher than the contextCSN on my provider. This is > because the Provider does not properly update its contextCSN for its base suffix > (dc=test,dc=com) when changes are made to group membership. Of couse, if it so > happens that the last change in my database was not a group membership change, > then the contextCSNs will be consistent between my consumers and provider. Sounds like this bug was introduced by patches for ITS#6766 or #6329. Both of those patches have been reverted for ITS#6915. This bug should be fixed in the current git HEAD. > > > I use the following command to check the ContextCSN on each consumer: > > Consumer: 1 > root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b > "dc=test,dc=com" contextCSN dn: dc=test,dc=com > dn: dc=test,dc=com > contextCSN: 20110313041653.752098Z#000000#000#000000 > > Consumer: 2 > ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b > "dc=test,dc=com" contextCSN dn: dc=test,dc=com > dn: dc=test,dc=com > contextCSN: 20110313041653.752098Z#000000#000#000000 > > So we can see that the two consumers have matching contextCSNs: > ContextCSN. 20110313041653.752098Z#000000#000#000000 > > Lets check the Provider now. > > Provider: > root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b > "dc=test,dc=com" ContextCSN dn: dc=test,dc=com > dn: dc=test,dc=com > contextCSN: 20110313041653.709140Z#000000#000#000000 > > The providers CSN is smaller!? > > Lets take a closer look and search cn=accesslog > > These are the last two entries: ( first the user was added, and then the user > was added to a group) > > # 20110313041653.000003Z, accesslog > dn: reqStart=20110313041653.000003Z,cn=accesslog > objectClass: auditAdd > reqStart: 20110313041653.000003Z > reqEnd: 20110313041653.000004Z > reqType: add > reqSession: 34633 > reqAuthzID: cn=admin,dc=test,dc=com > reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com > reqResult: 0 > reqMod: sn:+ Bank > reqMod: userPassword:+ {SASL}banky > reqMod: uid:+ banky > reqMod: objectClass:+ top > reqMod: objectClass:+ person > reqMod: objectClass:+ shadowAccount > reqMod: structuralObjectClass:+ person > reqMod: cn:+ Bank, Yuri(banky) > reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5 > reqMod: creatorsName:+ cn=admin,dc=test,dc=com > reqMod: createTimestamp:+ 20110313041653Z > reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000 > reqMod: modifiersName:+ cn=admin,dc=test,dc=com > reqMod: modifyTimestamp:+ 20110313041653Z > > # 20110313041653.000006Z, accesslog > dn: reqStart=20110313041653.000006Z,cn=accesslog > objectClass: auditModify > reqStart: 20110313041653.000006Z > reqEnd: 20110313041653.000007Z > reqType: modify > reqSession: 34633 > reqAuthzID: cn=admin,dc=test,dc=com > reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com > reqResult: 0 > reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com > reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000 > reqMod: modifiersName:= cn=admin,dc=test,dc=com > reqMod: modifyTimestamp:= 20110313041653Z > > You can see that the consumers have the latest entryCSN (20110313041653.752098Z) > as their contextCSN, but the provider has the entryCSN (20110313041653.709140Z) > before that as its contextCSN: > > If I search the contextCSN on -s base -b cn=accesslog it yields correctly, the > same result as the consumers: > 20110313041653.752098Z#000000#000#000000 > > > As you can see, the provider is not using the latest entryCSN as its ContextCSN, > where as the consumer nodes are. Also notice that the last modification was to > group membership. This problem only seems to exist when Adding/Removing users > from a group. > > A side effect of this issue causes brand new consumers to get stuck in an > infinite loop while syncing for the first time. > > A work around is to make a random change to a User/Person, such as injecting a > random number into their description field AFTER making a change to a group > membership. Such a change will: A. cause the Provider to correctly update its > contextCSN, B. provider and all consumer[s] will have the same contextCSN C. > brand new consumers can be added without getting stuck in an infinite loop when > syncing the database. ( they seem to get stuck on the last entry which makes > sense if the last entry has a higher entryCSN than that of the Providers > contextCSN? ) > > Confgiuration: ( See URL ) > http://yuri.easytospell.net/consumer.provider.txt > > Overlays: > syncprov > accesslog > memberof > > > Please feel free to email me about reproducing this problem. I have a lab with > various configurations and would be happy to give access to anyone interested. > > - Yuri Bank > -- -- 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:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs