openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5231) test045 failure in HEAD/RE24
by hyc＠symas.com 12 Nov '07

12 Nov '07

Gavin Henry wrote: > <quote who="hyc(a)OpenLDAP.org"> >> Full_Name: Howard Chu >> Version: HEAD/RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.168.84.21) >> Submitted by: hyc >> >> >> The comparison fails after the first modify step, an entry that should >> have been >> deleted is still present on the slave. >> >> The presentlist is still left over from the initial query, and hasn't been >> emptied yet. This appears to be a missing step when the initial query >> transitions from Refresh to Persist mode. > On RE24 mine on AMD64 Dual doesn't get that far. It dies on test033 with: > > Comparison failed - database not created correctly. > > I'll provide all details shortly, or best to create a new ticket? I already fixed that in HEAD. See the commit logs. -- -- Howard Chu Chief Architect, 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#5231) test045 failure in HEAD/RE24
by ghenry＠suretecsystems.com 12 Nov '07

12 Nov '07

<quote who="hyc(a)OpenLDAP.org"> > Full_Name: Howard Chu > Version: HEAD/RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.168.84.21) > Submitted by: hyc > > > The comparison fails after the first modify step, an entry that should > have been > deleted is still present on the slave. > > The presentlist is still left over from the initial query, and hasn't been > emptied yet. This appears to be a missing step when the initial query > transitions from Refresh to Persist mode. > > On RE24 mine on AMD64 Dual doesn't get that far. It dies on test033 with: Comparison failed - database not created correctly. I'll provide all details shortly, or best to create a new ticket? >

1 0

(ITS#5231) test045 failure in HEAD/RE24
by hyc＠OpenLDAP.org 12 Nov '07

12 Nov '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc The comparison fails after the first modify step, an entry that should have been deleted is still present on the slave. The presentlist is still left over from the initial query, and hasn't been emptied yet. This appears to be a missing step when the initial query transitions from Refresh to Persist mode.

1 0

Re: (ITS#5227) old dsn acceptance
by ando＠sys-net.it 12 Nov '07

12 Nov '07

hyc(a)symas.com wrote: > It seems a bit odd to be introducing support for that format now in 2.4, when > it was completely unsupported in 2.2 and 2.3. I.e., why wasn't this issue > raised during the migration to/thru either 2.2 or 2.3? Probably because until 2.4 #define csnValidate blobValidate and as such any incompatible CSN was silently ignored. So this has always been broken, only 2.4 detects the inconsistency, but behaved badly (assert) until your fix. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5228) Patches for minor typos in man pages
by ghenry＠OpenLDAP.org 12 Nov '07

12 Nov '07

<quote who="Sam Varshavchik"> > No problem. > > Here are the fixes diff-ed against CVS HEAD: > > http://www.tldp.org/manpages/openldap-2.4.6-manpatch.txt > > This is also attached to this message. Thanks, I'll get to this soon. Gavin.

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by hyc＠symas.com 12 Nov '07

12 Nov '07

Dan.Oscarsson(a)tietoenator.com wrote: > Full_Name: Dan Oscarsson > Version: 2.3.32 > OS: SLES 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.15.240.60) > From this I suspect that it is the cache of which parent node belongs to > that gets corrupted. Or can it be something else? > What more could I do to trace down the bug? > I do not know if the above information is enough for you to find what is > wrong? Cannot include data as it contains company internal information and > a simple test program did not give the same error. > I have looked at the code, but it takes some time to understand it when > doing it for the first time. maybe som debugging code could be added > find the place where the bug is. This isn't a lot of information to go on. If you can create a test program that shows the problem occurring, using dummy data, that would help. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5230) pagedresults ignores sizelimit for rootDN
by hyc＠OpenLDAP.org 12 Nov '07

12 Nov '07

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Performing a search as rootDN with both an explicit sizelimit and pagedresults causes the sizelimit to be ignored. Using the sizelimit and no pagedresults correctly honors the specified limit. This may also affect RE23, I haven't looked.

1 0

Re: (ITS#5227) old dsn acceptance
by hyc＠symas.com 12 Nov '07

12 Nov '07

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.4.6 > OS: Linux EL 4 > URL: http://users.wpi.edu/~aej/schema_init.diff > Submission from: (NULL) (130.215.24.208) > > > Old CSN stamps are not accepted by 2.4.6. I guess they must be _very_ old, > since there is a "2/3" CSN conversion in the release. > > The stamps are of the form: YYYYMMDDHH:MM:SSZ That's the format from when CSNs were introduced in OpenLDAP 2.1. > Perhaps I'm the only person in the OpenLDAP universe who might see this problem, > but I adapted the 2/3 conversion for these old fields. It seems a bit odd to be introducing support for that format now in 2.4, when it was completely unsupported in 2.2 and 2.3. I.e., why wasn't this issue raised during the migration to/thru either 2.2 or 2.3? I'm inclined to reject this patch; you can fix it in LDIF using sed or perl and never have to think about it again. -- -- Howard Chu Chief Architect, 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#5225) unexpected results in slapadd
by hyc＠symas.com 12 Nov '07

12 Nov '07

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.4.6 > OS: RHEL4 i686 > URL: http://users.wpi.edu/~aej > Submission from: (NULL) (130.215.24.208) > > > Dependent on load flags (I normally have been using -w -q), I get various > results. Assertion failure, segfault, or success. > I've placed DB_CONFIG, users.ldapv2.2007.11.08.ldif, and slapd.utility5.conf in > http://users.wpi.edu/~aej/ Thanks, now fixed in HEAD. -- -- Howard Chu Chief Architect, 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#5229) `make install' writes to the source tree as root
by hyc＠symas.com 12 Nov '07

12 Nov '07

mills(a)cc.umanitoba.ca wrote: > Full_Name: Gary Mills > Version: openldap-2.3.38 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.78.105.29) > > > The usual procedure is to run `configure' and `make' in the install tree as an > ordinary user, and then to run `make install' there as root. This install > procedure > writes to the install tree as root. In some cases, it actually relinks a > shared > library as root. We build on one server and install on another, where the > install > tree is mounted read-only. These errors prevent installation in this case. > Really, it shouldn't be doing relinking at that point, when running as root. > Perhaps it could do it earlier, during the compile step. I had to do a `make > install' as root in libraries/liblber on build server and then modify the > Makefiles > in libraries/libldap and libraries/libldap_r to link with the installed > library, > in order to avoid the relink on the install server. This worked, but is not a > good solution. Agreed, it should not be relinking, ever, but that's libtool. I've submitted patches to libtool to correct this a number of times over the past several years but the problem remains, and it's our policy to avoid using customized OpenLDAP-specific versions of the GNU tools so we no longer provide patched versions of libtool in our CVS. In the meantime, there's no reason for this to be affecting your source tree. You can always build using an object tree separate from the source tree. And you can always use "make install DESTDIR=/tmp/foo" on the build system to create an alternate hierarchy that can then be copied to any other machine. Since there is no fundamental bug in OpenLDAP here, this ITS will be closed. -- -- Howard Chu Chief Architect, 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