- openldap-bugs - openldap.org

(ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by michael.stroeder＠t-systems.com 01 Feb '07

01 Feb '07

Full_Name: Michael Ströder Version: HEAD OS: opensuse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.17.145) >>>>> Starting test032-chain ... running defines.sh Running slapadd to build slapd database... Starting first slapd on TCP/IP port 9011... Starting second slapd on TCP/IP port 9012... Using ldapsearch to check that first slapd is running... Using ldapsearch to check that second slapd is running... Testing ldapsearch as anonymous for "dc=example,dc=com" on port 9011... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Reading the referral entry ou=Other,dc=example,dc=com as anonymous on port 9011... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... comparison failed - chained search didn't succeed >>>>> ./scripts/test032-chain failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#4827) test019-syncreplication-cascade
by kurt＠OpenLDAP.org 31 Jan '07

31 Jan '07

On Feb 1, 2007, at 4:26 AM, hyc(a)symas.com wrote: > Fixed now. Confirmed. Thanks, Kurt

1 0

Re: (ITS#4827) test019-syncreplication-cascade
by hyc＠symas.com 31 Jan '07

31 Jan '07

Fixed now. The fix also triggered another problem along the lines of ITS#4820; test017's comparison failed because the modifiersName attribute wasn't in the same position on the producer and the consumer. I've hacked that problem by always applying the modifiersName update. kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: HEAD > OS: MacOSX 10.4.8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.80.218.136) > > > Recent builds fail test 18: > Comparing retrieved entries from master and R1 slave... > Comparing retrieved entries from master and R2 slave... > test failed - master and R2 slave databases differ >>>>>> ./scripts/test019-syncreplication-cascade failed (exit 1) > > % diff -u testrun/server[13].flt > --- testrun/server1.flt 2007-01-31 12:31:55.000000000 -0800 > +++ testrun/server3.flt 2007-01-31 12:32:00.000000000 -0800 > @@ -66,6 +66,7 @@ > seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com > userPassword:: Ympvcm4= > homePostalAddress: 19923 Seven Mile Rd. $ South Lyon, MI 49999 > +drink: Iced Tea > description: Hiker, biker > title: Director, Embedded Systems > postalAddress: Info Tech Division $ 535 W. William St. $ Anytown, MI 48103 > @@ -74,8 +75,6 @@ > pager: +1 313 555 4474 > facsimileTelephoneNumber: +1 313 555 2177 > telephoneNumber: +1 313 555 0355 > -drink: Iced Tea > -drink: Mad Dog 20/20 > > dn: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com > objectClass: OpenLDAPperson > > > . > -- -- 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#4826) assertion in connection.c
by ando＠sys-net.it 31 Jan '07

31 Jan '07

hyc(a)symas.com wrote: > Aaron Richton wrote: >> Wow, thanks. I never worried about setting that because I was under the >> impression that Solaris should autoconf to use poll() -- doesn't >> FD_SETSIZE only matter under select()? > > In current releases slapd only uses select() or epoll() (which is > Linux-specific). So you're getting select() right now. In HEAD/2.4 there's > support for Solaris /dev/poll. ... which doesn't work right now (as far as I remember; need to look at that before Solaris 8 becomes obsolete...) p.

1 0

Re: (ITS#4826) assertion in connection.c
by hyc＠symas.com 31 Jan '07

31 Jan '07

Aaron Richton wrote: > Wow, thanks. I never worried about setting that because I was under the > impression that Solaris should autoconf to use poll() -- doesn't > FD_SETSIZE only matter under select()? In current releases slapd only uses select() or epoll() (which is Linux-specific). So you're getting select() right now. In HEAD/2.4 there's support for Solaris /dev/poll. The libldap library will use poll() on Solaris, but that's a different matter... > On Wed, 31 Jan 2007, Howard Chu wrote: > >> richton(a)nbcs.rutgers.edu wrote: >>> Full_Name: Aaron Richton >>> Version: 2.3.30 >>> OS: Solaris 9 >>> URL: Submission from: (NULL) (128.6.31.135) -- -- 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#4826) assertion in connection.c
by richton＠nbcs.rutgers.edu 31 Jan '07

31 Jan '07

Wow, thanks. I never worried about setting that because I was under the impression that Solaris should autoconf to use poll() -- doesn't FD_SETSIZE only matter under select()? On Wed, 31 Jan 2007, Howard Chu wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: 2.3.30 >> OS: Solaris 9 >> URL: Submission from: (NULL) (128.6.31.135) >> >> >> Please note this is 2.3.30, so recent RE23 connection changes might make >> this >> irrelevant: > > No, no recent changes to connection.c would affect this. If your process is > actually able to use more than 4096 connections, then you need to recompile > with a larger OPENLDAP_FD_SET_SIZE. > > Note that with dtblsize = 4096, the maximum legal descriptor number is 4095, > since descriptors are zero-based. > > I'd call this a user configuration error, nothing to investigate here. > > -- > -- 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#4826) assertion in connection.c
by hyc＠symas.com 31 Jan '07

31 Jan '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.30 > OS: Solaris 9 > URL: > Submission from: (NULL) (128.6.31.135) > > > Please note this is 2.3.30, so recent RE23 connection changes might make this > irrelevant: No, no recent changes to connection.c would affect this. If your process is actually able to use more than 4096 connections, then you need to recompile with a larger OPENLDAP_FD_SET_SIZE. Note that with dtblsize = 4096, the maximum legal descriptor number is 4095, since descriptors are zero-based. I'd call this a user configuration error, nothing to investigate here. -- -- 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#4827) test019-syncreplication-cascade
by kurt＠OpenLDAP.org 31 Jan '07

31 Jan '07

Full_Name: Kurt Zeilenga Version: HEAD OS: MacOSX 10.4.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.80.218.136) Recent builds fail test 18: Comparing retrieved entries from master and R1 slave... Comparing retrieved entries from master and R2 slave... test failed - master and R2 slave databases differ >>>>> ./scripts/test019-syncreplication-cascade failed (exit 1) % diff -u testrun/server[13].flt --- testrun/server1.flt 2007-01-31 12:31:55.000000000 -0800 +++ testrun/server3.flt 2007-01-31 12:32:00.000000000 -0800 @@ -66,6 +66,7 @@ seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com userPassword:: Ympvcm4= homePostalAddress: 19923 Seven Mile Rd. $ South Lyon, MI 49999 +drink: Iced Tea description: Hiker, biker title: Director, Embedded Systems postalAddress: Info Tech Division $ 535 W. William St. $ Anytown, MI 48103 @@ -74,8 +75,6 @@ pager: +1 313 555 4474 facsimileTelephoneNumber: +1 313 555 2177 telephoneNumber: +1 313 555 0355 -drink: Iced Tea -drink: Mad Dog 20/20 dn: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson

1 0

(ITS#4826) assertion in connection.c
by richton＠nbcs.rutgers.edu 31 Jan '07

31 Jan '07

Full_Name: Aaron Richton Version: 2.3.30 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Please note this is 2.3.30, so recent RE23 connection changes might make this irrelevant: Threw assertion 385 assert( s < dtblsize ); from connection.c. Backtrace: current thread: t@16 [1] __lwp_kill(0x0, 0x6, 0x0, 0xfec3c000, 0x0, 0x0), at 0xfec1fc54 [2] raise(0x6, 0x0, 0xd1fff638, 0x0, 0x0, 0x0), at 0xfebd0c48 [3] abort(0x3c, 0xd1fff6c8, 0x3c, 0x7efefeff, 0x81010100, 0xff0000), at 0xfebb6d50 [4] __assert(0x2314c8, 0x2314d8, 0x181, 0xd1fff86c, 0xd1fff8f0, 0xd1fff92d), at 0xfebb6ff0 =>[5] connection_init(s = 4096, listener = 0x1f4eb8, dnsname = 0x231ff0 "", peername = 0x231ff4 "", flags = 3, ssf = 0, authid = (nil)), line 385 in "connection.c" [6] connection_client_setup(s = 4096, func = 0xed908 = &`slapd`syncrepl.c`do_syncrepl(void *ctx, void *arg), arg = 0x31b4a8), line 1184 in "connection.c" [7] do_syncrepl(ctx = 0xd1fffe14, arg = 0x31b4a8), line 1099 in "syncrepl.c" [8] ldap_int_thread_pool_wrapper(xpool = 0x2c5f68), line 478 in "tpool.c" (dbx) print s s = 4096 (dbx) print dtblsize dtblsize = 4096

1 0

(ITS#4825) Native Win32 build with WGCC/Interix
by markus.duft＠salomon.at 31 Jan '07

31 Jan '07

Full_Name: Markus Duft Version: 2.3.32 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/markus.duft-31.01.2007.patch Submission from: (NULL) (193.186.16.254) Hey there. i have a patch for v2.3.32 that allowes building openldap using wgcc (interix-wgcc.sourceforge.net). The result is a native win32 binary (without dependencies to any cygwin.dll or anything like it) benefits: * fast compiler (cl.exe) * native win32, no overheads for big wrappers (there is a small wrapper though ;o) but thats statically linked (pxwc)) * debugable with Visual Studio (very cool) thats it, i'll write a FAQ for this ;o) P.S.: i know the patch is not perfect, but as a first thing it will do. there will be a second version for sure that may be nicer, so it can be incorporated with the official sources (if wanted...) Cheers, Markus

1 0

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

31 Jan '07

Howard Chu <hyc(a)symas.com> writes: > Dieter Kluenter wrote: >> Howard Chu <hyc(a)symas.com> writes: >> >>> dieter(a)dkluenter.de wrote: .......... > > I've now checked in a new configure script, regenerated from the > current 1.645 configure.in. So that would be configure 1.684. Try that > one. (The only difference between 1.683 and 1.684 is the comment > indicating the version of configure.in.) I have just co'ed a fresh CVS HEAD and configure is OK now. -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 31 Jan '07

31 Jan '07

Dieter Kluenter wrote: > 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 > Even reverting to revision 1.682 of the configure script, with the typo from configure.in 1.644, I can't reproduce that error. Perhaps you should try deleting your source tree and fetching it again. You could list your full configure command here, with all relevant environment variable settings. But it seems you have a corrupted configure script. -- -- 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 hyc＠symas.com 31 Jan '07

31 Jan '07

Dieter Kluenter wrote: > 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 . That version stamp reflects the configure.in file that was used to generate the configure script, but it isn't the actual version of the configure script. You would need to use "cvs status configure" to actually check that. I've now checked in a new configure script, regenerated from the current 1.645 configure.in. So that would be configure 1.684. Try that one. (The only difference between 1.683 and 1.684 is the comment indicating the version of configure.in.) -- -- 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#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

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

28 Jan '07

Are you by any chance using slapadd -q? As noted in the documentation, that turns off a lot of consistency checks. One of the things it turns off is the input sorting, because you're only supposed to feed valid LDIF to slapadd -q. daniel(a)ncsu.edu wrote: >> daniel(a)ncsu.edu wrote: >>> Hi Howard! As much as I hate to say this, it did not solve the problem >>> I >>> was running into. =( I rebuilt openldap with the entry.c patch and >>> rebuilt the LDAP database from scratch (pulling from sources and using >>> slapadd). Then I ran the following statement via ldapmodify (as always, >>> XXX'd out sensitive info): >> The slapcat output you provide shows that the attribute was already >> slapadded >> incorrectly. Please provide the "pulling from sources" input you used with >> slapadd for this entry. -- -- 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

> daniel(a)ncsu.edu wrote: >> Note that I have not changed anything to add the ou's as a group and the >> ncsuCurriculumCode's as a group, but from what I understood, this should >> work fine for openldap, even if it may or may not be truly legit based >> off >> the RFCs. And again, I have not changed anything in this code and have >> been adding things like this for the past 2 years with OpenLDAP 2.2 and >> earlier. I mean sure I can go edit my code to add those ou's and >> ncsucurriculumcodes in the correct order (ie, bunched together), but if >> you are saying openldap should be able to handle this, I'd like to stick >> with it and see it resolved instead of letting it be a dangling >> difference >> behavior since 2.2. If you want to make an official-like statement that >> what I'm doing there is not proper and not supported, then so be it, >> I'll >> take that as golden and adjust my code. =) (in other words, would you >> rather it be that this is flat out not supported? .. of course if it's >> not >> supported it would be nicer if openldap yelled about it instead of >> accepting it and just being mad afterwards) > > It is supposed to work. On my tests it does work. I have no idea what's > happening on your side. > > Here's a snippet from running slapadd with -d -1 for the entry I tested > with. > Since I didn't have your NCSU schema I substituted some other > attributetypes > instead, but it should be equivalent. Note that I used "ou:" and "Ou:" > which > would have triggered the error before. The fact that "ou" only turns up > once > in the oc_check_allowed messages indicates that it correctly parsed them > into > a single attribute. I'm going to send you this information "out of band". There's so much of it that printed and I'm not 100% sure what is any is not sensitive in the output. =( Daniel > > Please send your corresponding debug output for this operation. > > slapadd startup: initiated. > backend_startup_one: starting "dc=example,dc=com" > bdb_db_open: dc=example,dc=com > bdb_db_open: Warning - No DB_CONFIG file found in directory > ./testrun/db.1.a: (2) > Expect poor performance for suffix dc=example,dc=com. > bdb_db_open: dbenv_open(./testrun/db.1.a) > => str2entry: "dn: uid=XXX,ou=people,dc=example,dc=com > objectClass: person > objectClass: inetOrgPerson > objectClass: openldapperson > uid: XXX > cn: XXX > sn: XXX > title: Senior > description: XXX > organizationalStatus: registered > o: NC State University > gn: XXX > initials: XXX > displayName: XXX > personalTitle: XXX > departmentNumber: XXX > destinationIndicator: SR > Ou: Physics > businessCategory: PY > ou: B S - Philosophy > businessCategory: LSL > mail: XXX(a)unity.ncsu.edu > labeleduri: XXX(a)unity.ncsu.edu > registeredAddress: XXX > postalAddress: XXX > telephoneNumber: XXX > l: Raleigh > st: NC > postalCode: 27603 > employeeType: staff > " > >>> dnPrettyNormal: <uid=XXX,ou=people,dc=example,dc=com> > <<< dnPrettyNormal: <uid=XXX,ou=people,dc=example,dc=com>, > <uid=xxx,ou=people,dc=example,dc=com> > <= str2entry(uid=XXX,ou=people,dc=example,dc=com) -> 0x7734f0 > oc_check_required entry (uid=XXX,ou=people,dc=example,dc=com), objectClass > "OpenLDAPperson" > oc_check_allowed type "objectClass" > oc_check_allowed type "uid" > oc_check_allowed type "cn" > oc_check_allowed type "sn" > oc_check_allowed type "title" > oc_check_allowed type "description" > oc_check_allowed type "organizationalStatus" > oc_check_allowed type "o" > oc_check_allowed type "givenName" > oc_check_allowed type "initials" > oc_check_allowed type "displayName" > oc_check_allowed type "personalTitle" > oc_check_allowed type "departmentNumber" > oc_check_allowed type "destinationIndicator" > oc_check_allowed type "ou" > oc_check_allowed type "businessCategory" > oc_check_allowed type "mail" > oc_check_allowed type "labeledURI" > oc_check_allowed type "registeredAddress" > oc_check_allowed type "postalAddress" > oc_check_allowed type "telephoneNumber" > oc_check_allowed type "l" > oc_check_allowed type "st" > oc_check_allowed type "postalCode" > oc_check_allowed type "employeeType" > oc_check_allowed type "structuralObjectClass" > => bdb_tool_entry_put( -1, "uid=XXX,ou=people,dc=example,dc=com" ) > > > -- > -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs