openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#6425) Uninitialized var in syncrepl
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.20 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard In syncrepl.c lines 1001-1010: LDAPControl **next; rctrlp = ldap_control_find( LDAP_CONTROL_SYNC_DONE, rctrls, &next ); if ( next && ldap_control_find( LDAP_CONTROL_SYNC_DONE, next, NULL ) ) 'next' in the last line is uninitalized if 2nd line failed. Seen in testrun/srv2/valgrind.* with './run -b null test050' and and slapd under valgrind.

1 0

ITS#6423 slapo-collect & slapo-valsort could suffer from the same issue
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

This should now be fixed in HEAD, collect.c 1.17 <- 1.16 valsort.c 1.27 <- 1.26 please review and test. p.

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

Fixed in HEAD; the fix is in overlays/dynlist.c 1.68->1.69 Please test and report. Thanks, p.

1 0

(ITS#6424) slapd-meta pseudoroot* directives deprecated
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.247) Submitted by: ando The man page erroneously reports them. A fix is coming. See also ITS#6418. p.

1 0

ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

The problem is that back-relay presents slapo-rwm(3) an entry with both REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a consequence, the entry is released (namely, freed) before it is returned by the frontend. As far as I understand, the two flags should be mutually exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is supposed to be a copy of an entry that may need to be released, or an entry created from scratch and thus not stored anywhere. I have a quick fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in tracking where the issue occurs. Unless I track it, I'll commit the quick fix. p.

1 0

(ITS#6423) slapo-rwm and dynlist overlay
by leo＠strike.wu.ac.at 08 Dec '09

08 Dec '09

Full_Name: Leo Bergolth Version: 2.4.20 OS: linux URL: http://leo.kloburg.at/tmp/dynlist-rwm.log Submission from: (NULL) (137.208.89.66) When using the relay backend, entries that have attributes expanded by the dynlist overlay are not shown in the virtual naming context. (Not even those attributes that are not created dynamically, only an empty dn is shown for those entries.) Example: # real naming context: -------------------- 8< -------------------- $ ldapsearch -LLL -h bach-s49 -b 'dc=wu-wien,dc=ac,dc=at' -x '(cn=dynlisttest)' dn: cn=dynlisttest,ou=LDAPgroups,dc=wu-wien,dc=ac,dc=at objectClass: wuDynGroupOfNames objectClass: groupOfURLs objectClass: top cn: dynlisttest memberURL: ldap:///dc=wu-wien,dc=ac,dc=at??sub?(&(objectclass=wuPerson)(uid=be rgolth*)) member: uid=bergolth,ou=users,dc=wu-wien,dc=ac,dc=at member: uid=bergolth2,ou=LDAPusers,dc=wu-wien,dc=ac,dc=at -------------------- 8< -------------------- # virtual naming context: -------------------- 8< -------------------- $ ldapsearch -LLL -h bach-s49 -b 'dc=wu,dc=ac,dc=at' -x '(cn=dynlisttest)' dn: -------------------- 8< -------------------- According to Pierangelo Maserati it seems to be a bug in slapo-rwm. http://thread.gmane.org/gmane.network.openldap.technical/207/focus=210 # dynlist config: -------------------- 8< -------------------- dn: olcOverlay={0}dynlist,olcDatabase={1}bdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}posixGroup labeledURI memberUid:uid olcDlAttrSet: {1}wuDynGroupOfNames memberURL member -------------------- 8< -------------------- # relay rwm config: -------------------- 8< -------------------- dn: olcOverlay={0}rwm,olcDatabase={3}relay,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "dc=wu-wien,dc=ac,dc=at" -------------------- 8< -------------------- The debug output of the second ldapsearch can be found at the specified URL. Thanks, --leo

1 0

Re: (ITS#6422) configure does not locate ndbclient library
by quanah＠zimbra.com 08 Dec '09

08 Dec '09

--On Tuesday, December 08, 2009 7:19 PM +0330 afshin afzali <a.afzali2003(a)gmail.com> wrote: > Hi, > Thanks for your reply. After inspection in config.log, I found that ld > could not find libstdc++ although it there in /usr/lib and /usr/lib64. I > just add a symbolic link to libstdc++.so.6.0.8 then bingo! THE ISSUE HAS > RESOLVED > > Best Regards, I've closed this ITS based on the response. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6422) configure does not locate ndbclient library
by quanah＠zimbra.com 08 Dec '09

08 Dec '09

--On Tuesday, December 08, 2009 9:47 AM +0000 a.afzali2003(a)gmail.com wrote: > Full_Name: afshin afzali > Version: openldap-2.4.19 > OS: CentOS 5 - 64Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.182.20.153) > > > Hi Guys, > As you can find bellow, although I've installed MySQL-Cluster-gpl-Devel > package (there is mysql_config & ndbclient library), counfigure does not > locate ndbclient library. Also I've upgrade libtools! > > Best Regards, > -- Afshin > > > > [root@dc1 openldap-2.4.19]# mysql_config --libs > -rdynamic -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc > [root@dc1 openldap-2.4.19]# ls -l /usr/lib64/mysql/ > total 51780 > -rw-r--r-- 1 root root 10786 Nov 17 03:50 libdbug.a > -rw-r--r-- 1 root root 1056714 Nov 17 03:50 libheap.a > -rw-r--r-- 1 root root 120260 Nov 16 21:39 libmygcc.a > -rw-r--r-- 1 root root 3801024 Nov 17 03:50 libmyisam.a > -rw-r--r-- 1 root root 1417762 Nov 17 03:50 libmyisammrg.a > -rw-r--r-- 1 root root 10142882 Nov 17 03:50 libmysqlclient.a > -rwxr-xr-x 1 root root 1034 Nov 17 03:50 libmysqlclient.la > -rw-r--r-- 1 root root 10143082 Nov 17 03:50 libmysqlclient_r.a > -rwxr-xr-x 1 root root 1080 Nov 17 03:50 libmysqlclient_r.la > -rw-r--r-- 1 root root 2554406 Nov 17 03:49 libmystrings.a > -rw-r--r-- 1 root root 1799740 Nov 17 03:50 libmysys.a > -rw-r--r-- 1 root root 21375162 Nov 17 03:50 libndbclient.a > -rwxr-xr-x 1 root root 1427 Nov 17 03:50 libndbclient.la > -rw-r--r-- 1 root root 90374 Nov 17 03:50 libvio.a > -rw-r--r-- 1 root root 308548 Nov 17 03:49 libz.a > -rwxr-xr-x 1 root root 878 Nov 17 03:49 libz.la > [root@dc1 openldap-2.4.19]# ./configure --enable-ndb --disable-bdb > --disable-hdb > Configuring OpenLDAP 2.4.19-Release ... > checking for ndb_init in -lndbclient... no > configure: error: could not locate ndbclient library > [root@dc1 openldap-2.4.19]# And what does the config.log show for why this linking failed? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 08 Dec '09

08 Dec '09

Am Dienstag 08 Dezember 2009 11:53:41 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: > >> --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > >>> ------------------------------------ > >>> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > >>> type="refreshAndPersist" starttls=critical bindmethod="simple" > >>> binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > >>> ------------------------------------ > >>> > >>> Question is if this is a bug in the documentation or in the code. I > >>> think it's the latter. > >> > >> Howard believes this is fixed in head with servers/slapd/config.c 1.508 > >> -> 1.509. Can you please test and let us know the result? > > > > It solves the problem only partially. It still doesn't work when using > > "ldaps://" uris AFAICS. > > The code was assuming that at least one of the other TLS config keywords > would also be used in these situations. Most of the time the slapd TLS > config would only be appropriate for server use, and would need to be > overridden when acting as a client. > > Anyway, this is now fixed in HEAD. Confirmed. -- Ralf

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by hyc＠symas.com 08 Dec '09

08 Dec '09

rhafer(a)suse.de wrote: > Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: >> --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: >>> ------------------------------------ >>> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" >>> type="refreshAndPersist" starttls=critical bindmethod="simple" >>> binddn="uid=syncrepl,dc=test" credentials="XXXXXX" >>> ------------------------------------ >>> >>> Question is if this is a bug in the documentation or in the code. I think >>> it's the latter. >> >> Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> >> 1.509. Can you please test and let us know the result? > It solves the problem only partially. It still doesn't work when using > "ldaps://" uris AFAICS. The code was assuming that at least one of the other TLS config keywords would also be used in these situations. Most of the time the slapd TLS config would only be appropriate for server use, and would need to be overridden when acting as a client. Anyway, 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

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