openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6003) translucent overlay test case fails when openldap is compiled with PIE
by hyc＠symas.com 06 Mar '09

06 Mar '09

mathias.gug(a)canonical.com wrote: > Full_Name: Mathias Gug > Version: 2.4.15 > OS: Ubuntu Linux (Jaunty 9.04) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.56.226.136) > > > When compiling 2.4.15 with PIE enabled, test034-translucent fails. Disabling PIE > makes the test successful. > > 2.4.14 builds correctly (with PIE enabled) and test034-translucent doesn't > fail. > > The detail build log can be found at: > > http://people.ubuntu.com/~mathiaz/openldap_2.4.15-1ubuntu1_20090304-1744 > 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

(ITS#6003) translucent overlay test case fails when openldap is compiled with PIE
by mathias.gug＠canonical.com 06 Mar '09

06 Mar '09

Full_Name: Mathias Gug Version: 2.4.15 OS: Ubuntu Linux (Jaunty 9.04) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.56.226.136) When compiling 2.4.15 with PIE enabled, test034-translucent fails. Disabling PIE makes the test successful. 2.4.14 builds correctly (with PIE enabled) and test034-translucent doesn't fail. The detail build log can be found at: http://people.ubuntu.com/~mathiaz/openldap_2.4.15-1ubuntu1_20090304-1744

1 0

Re: (ITS#6001) SID of queued CSN must match that of op
by hyc＠symas.com 06 Mar '09

06 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > All CSNs in the queue is currently considered when committed CSNs are fetched. > This creates race conditions where a CSN not matching the current op could be > returned. A fix that only considers CSNs with the same SID as the one in the op > is coming. > > Rein Tollevik > Basefarm AS > > So even with this fix in HEAD, test058 still reports 2 errors for me. Are these patches really ready for test? (Or 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

Re: (ITS#6002) slaptest dynlist conversion problem
by hyc＠symas.com 05 Mar '09

05 Mar '09

derek(a)umiacs.umd.edu wrote: > Full_Name: Derek Yarnell > Version: 2.4.15 > OS: Red Hat Enterprise Linux 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.8.120.187) > > > When I go to create a slapd.d cn=config directory with the following in my bdb > database using the dynlist overlay, > > overlay dynlist > dynlist-attrset groupOfNames labeledURI member > > I get the following portion of the cn=config directory structure, > > # cat olcOverlay\=\{1\}dynlist.ldif > dn: olcOverlay={1}dynlist > objectClass: olcOverlayConfig > objectClass: olcDynamicList > olcOverlay: {1}dynlist > olcDlAttrSet: {0}groupOfNames groupOfNames member > structuralObjectClass: olcDynamicList > entryUUID: 6daa3d54-ec05-432a-bdf0-9d3ded5aed23 > creatorsName: cn=config > createTimestamp: 20090305215204Z > entryCSN: 20090305215204.399170Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090305215204Z > > The problem is that olcDlAttrSet this is not right and the 2nd groupOfNames > should be labeledURI. This obviously causes slapd to not start correctly and I > have to hand correct. > Thanks for the report, 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

(ITS#6002) slaptest dynlist conversion problem
by derek＠umiacs.umd.edu 05 Mar '09

05 Mar '09

Full_Name: Derek Yarnell Version: 2.4.15 OS: Red Hat Enterprise Linux 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.8.120.187) When I go to create a slapd.d cn=config directory with the following in my bdb database using the dynlist overlay, overlay dynlist dynlist-attrset groupOfNames labeledURI member I get the following portion of the cn=config directory structure, # cat olcOverlay\=\{1\}dynlist.ldif dn: olcOverlay={1}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {1}dynlist olcDlAttrSet: {0}groupOfNames groupOfNames member structuralObjectClass: olcDynamicList entryUUID: 6daa3d54-ec05-432a-bdf0-9d3ded5aed23 creatorsName: cn=config createTimestamp: 20090305215204Z entryCSN: 20090305215204.399170Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090305215204Z The problem is that olcDlAttrSet this is not right and the 2nd groupOfNames should be labeledURI. This obviously causes slapd to not start correctly and I have to hand correct.

1 0

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 9:05 PM +0000 quanah(a)zimbra.com wrote: > --On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> One every few runs (1/75 roughly) test056 does not read the current >> connection from slapd, thus failing the check for the monitor1.out block. >> >> The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be >> missing from the results returned when searching the subtree rooted at >> "cn=Connections,cn=Monitor". >> >> Not clear how this can happen, the logs do not show enough details, and >> the behavior is too erratic to trace. > > It seems to be missing a lot. I get hundreds of: > slapd-read PID=10541: ldap_search_ext_s(cn=Database > 1,cn=Databases,cn=Monitor): No such object (32) > matched: cn=Databases,cn=Monitor test039 is one of several where I see this: slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor PID=29590 - Read done (32). PID=29604 - Bind done (0). PID=29576 - Search done (0). PID=18701 - Add/Delete done (0). PID=18699 - Modrdn done (0). PID=18656 - Search done (0). PID=18627 - Add/Delete done (0). PID=18615 - Search done (0). PID=24501 - Search done (0). PID=25038 - Search done (0). PID=24259 - Search done (0). PID=21968 - Search done (0). PID=25300 - Search done (0). PID=25898 - Search done (0). PID=27976 - Search done (0). PID=18617 - Modrdn done (0). PID=18646 - Modrdn done (0). Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... >>>>> Test succeeded --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > One every few runs (1/75 roughly) test056 does not read the current > connection from slapd, thus failing the check for the monitor1.out block. > > The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be > missing from the results returned when searching the subtree rooted at > "cn=Connections,cn=Monitor". > > Not clear how this can happen, the logs do not show enough details, and > the behavior is too erratic to trace. It seems to be missing a lot. I get hundreds of: slapd-read PID=10541: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6001) SID of queued CSN must match that of op
by rein＠OpenLDAP.org 05 Mar '09

05 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein All CSNs in the queue is currently considered when committed CSNs are fetched. This creates race conditions where a CSN not matching the current op could be returned. A fix that only considers CSNs with the same SID as the one in the op is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by ando＠sys-net.it 05 Mar '09

05 Mar '09

hyc(a)symas.com wrote: >> When slapd is configured to host a database with empty suffix (""), an entry >> with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter >> behavior is appropriate, while the former should be denied. > > No, you need to be able to slapadd the context entry, in particular to restore > a contextCSN. OK, but then no corresponding add operation can be performed, as far as I understand. I think we should provide a means to allow this operation, e.g. with a specific control. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 4:58 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > When slapd is configured to host a database with empty suffix (""), an > entry with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the > latter behavior is appropriate, while the former should be denied. I disagree. When you configure a database with "", and you slapcat it, it generates the empty suffix entry, which is used to store the contextCSN for replication. You *must* be able to export it and reload it for sync-replication. For example, from slapcat: dn: objectClass: glue structuralObjectClass: glue contextCSN: 20060825091501Z#000000#00#000000 entryCSN: 20060825091501Z#000000#00#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20060825091501Z entryUUID: 956a60ba-c8a6-102a-86ac-5d3a048562c0 creatorsName: uid=zimbra,cn=admins,cn=zimbra createTimestamp: 20060825165749Z --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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