openldap-bugs

openldap-bugs@openldap.org

1 participants
20953 discussions

Re: (ITS#4822) After test049 is over, restarting the producer dumps core
by ando＠sys-net.it 30 Jan '07

30 Jan '07

hyc(a)symas.com wrote: > I haven't been able to reproduce this crash. I found some other problems (the > consumer wasn't able to retrieve the contextCSN at startup time because there > was no entry_fetch handler, fixed now) but none that caused a crash. I haven't identified yet what commit fixed this issue. Anyway, I've been unable to reproduce it as well, so the ITS can be closed. Thanks, p.

1 0

Re: (ITS#4822) After test049 is over, restarting the producer dumps core
by hyc＠symas.com 30 Jan '07

30 Jan '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD >> OS: Linux 2.6 (CentOS 4.4) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.72.89.40) >> Submitted by: ando >> >> >> After test049 is over, restarting the producer dumps core. This happens in the >> consumer's code (!) which, as far as I can understand, is there in cn=config >> only for the purpose of replicating to the consumer and set it to be, well, a >> consumer. > The other half of this ITS remains to be investigated... I haven't been able to reproduce this crash. I found some other problems (the consumer wasn't able to retrieve the contextCSN at startup time because there was no entry_fetch handler, fixed now) but none that caused a crash. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4824) configure does not recognise --enable-dynamic
by dieter＠dkluenter.de 30 Jan '07

30 Jan '07

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: Linux URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.187.149.11) >> Hello, >> calling ./configure results in following error >> --enable-dynamic=yes: command not found >> neither --enable-dynamic nor --enable-dynamic=yes will allow dynamic linking. > > Works for me. What revision is your configure script? Current is 1.683. pkg/ldap/configure.in,v 1.644 2007/01/10 23:54:45 hyc Exp . -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4824) configure does not recognise --enable-dynamic
by hyc＠symas.com 29 Jan '07

29 Jan '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.187.149.11) > > > Hello, > calling ./configure results in following error > --enable-dynamic=yes: command not found > neither --enable-dynamic nor --enable-dynamic=yes will allow dynamic linking. Works for me. What revision is your configure script? Current is 1.683. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4823) Cannot use zero-length IA5 String
by kurt＠OpenLDAP.org 29 Jan '07

29 Jan '07

On Jan 29, 2007, at 1:11 AM, nisimura(a)gmail.com wrote: > Full_Name: Kazu Nisumura > Version: 2.3.33 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (211.120.78.45) > > > When I was trying to add an entry like this using ldapadd(1): > > dn: cn=name,dc=example,dc=com > objectClass: inetOrgPerson > cn: name > sn: name > mail: > > slapd returned invalidAttributeSyntax(21) error on the mail (IA5 > String) > attribute. According to RFC4517, zero-length IA5 String should be > allowed. I note that while the directory service should allow such values, directory applications (e.g., client programs) and users should only provide values which make sense. An empty string (or a string consisting of just spaces) is not a valid email address and will likely lead to ill behavior. If the user represented by this entry has no email address, the mail attribute should have no value (as opposed to an empty value). But I digress...

1 0

(ITS#4824) configure does not recognise --enable-dynamic
by dieter＠dkluenter.de 29 Jan '07

29 Jan '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.187.149.11) Hello, calling ./configure results in following error --enable-dynamic=yes: command not found neither --enable-dynamic nor --enable-dynamic=yes will allow dynamic linking.

1 0

Re: (ITS#4816) slurpd generates invalid ldapadd/modify requests
by gael.roualland＠oleane.net 29 Jan '07

29 Jan '07

Hello, >> Slurpd has a bug when replicating, in the way it generates the LDAPMod array of >> the add and modify operations : if the same attribute is present several times >> (for add) or in multiple change blocks (for modify) in the replication log, it >> simply adds all occurences to the LDAPMod array, hence having one or more >> attributes repeated serveral times which violates the protocol. >> [...] > As far as I can see, slurpd merely processes the changes in the replog. If it > is generating requests out of sequence, then they must have been recorded > out-of-sequence in the log. And yet I don't see any reason why slapd would > generate the modifications out of sequence. That's right for changetype=modify, since the original code aggregates multiple values of the same attributes in a signle LDAPmod if they're given in order in the replog file. But it doesn't do that for changetype=add, which toggled the bug. I choosed to use the same code path for both for simplicity when fixing add. > What are the circumstances that cause these improper sequences to get into > the replog in the first place? In our case, it was just "add" that was problematic. Although I could imagine the replog to be generated by something else than slapd, and I'd expect slurpd to be able to process it as long as it is valid ldif ? > As for copying the code from ldapmodify.c into slurpd - probably the better > solution would be to move the relevant code from ldapmodify.c into a library. Well, the relevant code is about 20 lines long, and adapted to the way slurpd handles memory. But sure, that could be shared. For the record, the patch I uploaded has an issue with empty changes blocks, so I uploaded a fixed version as ftp://ftp.openldap.org/incoming/gael.roualland-070129.diff -- Gaël Roualland -+- gael.roualland(a)oleane.net

1 0

Re: (ITS#4816) slurpd generates invalid ldapadd/modify requests
by hyc＠symas.com 28 Jan '07

28 Jan '07

gael.roualland(a)oleane.net wrote: > Full_Name: Gaël Roualland > Version: 2.3.33 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/gael.roualland-070126.diff > Submission from: (NULL) (213.56.0.199) > > > Hello, > > Slurpd has a bug when replicating, in the way it generates the LDAPMod array of > the add and modify operations : if the same attribute is present several times > (for add) or in multiple change blocks (for modify) in the replication log, it > simply adds all occurences to the LDAPMod array, hence having one or more > attributes repeated serveral times which violates the protocol. > > This is usually fine with slapd because there is code there to accept invalid > queries from the updatedn, but it is rejected if you're not using updatedn > (which happens to be our case in a custom floating master scenario). > > The uploaded patch fixes this in slurpd by replacing its LDAPmod logic by one > based on ldapmodify which generates proper requests. I know slurpd is considered > deprecated, however this might be useful to others still using it and would > allow to remove the exception from slapd code. > > Regards, As far as I can see, slurpd merely processes the changes in the replog. If it is generating requests out of sequence, then they must have been recorded out-of-sequence in the log. And yet I don't see any reason why slapd would generate the modifications out of sequence. What are the circumstances that cause these improper sequences to get into the replog in the first place? As for copying the code from ldapmodify.c into slurpd - probably the better solution would be to move the relevant code from ldapmodify.c into a library. When we still maintained libldif as its own entity it would have made sense to put it there, but now it would seem to best fit in libldap, and perhaps the other LDIF routines in liblutil should move there as well. This would also partially address ITS#4033. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by daniel＠ncsu.edu 28 Jan '07

28 Jan '07

After talking with Howard some more, here is what we discovered: The reason I was having problems stemmed from two things: A. I am not writing out my attributes in a grouped (all ou's together) order B. I started using -q with slapadd as of the 2.3 series B explains why I didn't see it until 2.3. ;D I'm going to adjust my scripts to write out the ldif import files in proper order (easy enough) because I quite value the functionality of -q. ;D Didn't realize the ordering of attributes was important until now though, good to know! That combined with Howard's fix to the case sensitivity, I believe we're golden. Thanks much for your help with this!

1 0

(ITS#4823) Cannot use zero-length IA5 String
by nisimura＠gmail.com 28 Jan '07

28 Jan '07

Full_Name: Kazu Nisumura Version: 2.3.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (211.120.78.45) When I was trying to add an entry like this using ldapadd(1): dn: cn=name,dc=example,dc=com objectClass: inetOrgPerson cn: name sn: name mail: slapd returned invalidAttributeSyntax(21) error on the mail (IA5 String) attribute. According to RFC4517, zero-length IA5 String should be allowed.

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