- openldap-bugs - openldap.org

(ITS#4831) dynlist returns bad data
by quanah＠stanford.edu 02 Feb '07

02 Feb '07

Full_Name: Quanah Gibson-Mount Version: 2.3.33 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In doing a base query of a dynamic group I had created, I found that the information returned when using the dynlist overlay is bogus. ldapsearch -LLL -Q -h ldap-dev1 -s base -b "cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu" | more was the query run. It returns: dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu objectClass: groupOfURLs objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: suPerson cn: registry-consult cn: member A's cn cn: member B's cn ..... description: member A's description description: member B's description ...... displayName: member A's displayName givenName: member A's givenName givenName: member B's givenName .... etc, for every populated attribute in the *objects of the members*. This seems horribly broken to me. Note that this is an unmodified version of dynlist (pure 2.3.33) --Quanah

1 0

(ITS#4830) test030-relay fails with back-meta
by ahasenack＠terra.com.br 02 Feb '07

02 Feb '07

Full_Name: Andreas Hasenack Version: 2.3.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) Hello, while running make test on a 2.3.33 build, I get an error in test030-relay when using the meta backend: (...) Using meta backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Search failed (255)! ./scripts/relay: line 78: kill: (31577) - Processo inexistente >>>>> ./scripts/test030-relay failed (exit 255) make: ** [bdb-yes] Erro 255 The log shows: $ tail testrun/slapd.1.log conn=3 op=1 >>> meta_search_dobind_init[0] conn=3 op=1 <<< meta_search_dobind_init[0]=1 ==> rewrite_context_apply [depth=1] string='o=Example,c=US' ==> rewrite_rule_apply rule='((.+),)?o=Example,[ ]?c=US$' string='o=Example,c=US' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'dc=example,dc=com'} [rw] searchBase: "o=Example,c=US" -> "dc=example,dc=com" ==> rewrite_context_apply [depth=1] string='(objectClass=*)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: symbol lookup error: +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: ldap_back_proxy_authz_ctrl

1 0

(ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 02 Feb '07

02 Feb '07

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, If we are to suppose that slapd-config is to provide 100% remote configuration, then directories should be created as set in: olcDbDirectory set_lg_dir Questions/Needs: 1. How to handle existing directories on mkdir? 2. Some global cn=config setting to say what cn=config is allowed to do 3. Plus many more I'm sure. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

syncrepl only works as rootdn
by Christopher Cowart 02 Feb '07

02 Feb '07

Hello, I have 3 installations of openldap-server-2.3.33 running on FreeBSD 6.1-REL: ldap-master, ldap1, ldap2. I am using syncrepl to replicate ldap-master to ldap1 and ldap2. The replicated directory is missing entire ou branches in my tree. I have created the following objects in my directory: cn=syncrepl-ldap1,dc=example,dc=com cn=syncrepl-ldap2,dc=example,dc=com I've made the following configurations on the provider: | access to * | by dn.regex="cn=syncrepl-(ldap1|ldap2),dc=example,dc=com" read | by * break | | # More ACLs Follow | | # For Sync Replication | overlay syncprov | syncprov-checkpoint 100 10 | syncprov-sessionlog 100 And on the consumer (ldap1): | # Sync Replication | syncrepl rid=001 | provider=ldaps://ldap-master.example.com/ | type=refreshAndPersist | interval=00:01:00:00 | searchbase="dc=example,dc=com" | scope=sub | schemachecking=off | bindmethod=simple | binddn="cn=syncrepl-ldap1,dc=example,dc=com" | credentials=supersecret Now, when I query: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(ou=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services | ou: System Accounts | ou: System Groups But: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap1.example.com/' '(ou=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services You'll notice that the "System Accounts" and "System Groups" ou's are not visible in the replicated directory. Odd. Next, I run the query: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(objectClass=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services | ou: System Accounts | ou: System Groups But the syncrepl process is binding as "cn=syncrepl-ldap1": $ ldapsearch -D 'cn=syncrepl-ldap1,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(objectClass=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services So, if I configure the consumer to bind as my rootdn (cn=admin), the entire directory gets replicated (as the final ldapsearch's would imply). My question is how do I properly configure the ACLs here? Shouldn't the 'read *' at the beginning of my ACL declarations match? I'm attaching the full list of my ACLs to the message. Thanks for any help or pointers you can offer. -- Chris Cowart Network and Infrastructure Systems Administrator RSSP-IT, UC Berkeley "May all your pushes be popped"

2 1

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

01 Feb '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Howard Chu wrote: >>> michael.stroeder(a)t-systems.com wrote: >>>> 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) >>> Hmm, all tests are passing for me right now. >>> >> Never mind. I just refreshed back-ldap and back-meta and test032 is failing >> for me now too. > > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Looks fine now, thanks. -- -- 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#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

ando(a)sys-net.it wrote: > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Fixed in HEAD, please test. BTW, the bug showed up essentially because the output was sort of incorrectly diverted to the file that gets checked. Generally speaking, it might impact re23 as well, although that test is currently succeeding. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

hyc(a)symas.com wrote: > Howard Chu wrote: >> michael.stroeder(a)t-systems.com wrote: >>> 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) >> Hmm, all tests are passing for me right now. >> > Never mind. I just refreshed back-ldap and back-meta and test032 is failing > for me now too. I've recently added some diagnostics messages to proxy failures, to indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts to contact the remote target. Apparently, slapo-chain(5) leaves 'round some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. p.

1 0

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

01 Feb '07

Howard Chu wrote: > michael.stroeder(a)t-systems.com wrote: >> 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) > > Hmm, all tests are passing for me right now. > Never mind. I just refreshed back-ldap and back-meta and test032 is failing for me now too. -- -- 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#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

michael.stroeder(a)t-systems.com wrote: > 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) Hmm, all tests are passing for me right now. -- -- 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#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 01 Feb '07

01 Feb '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 01 Feb '07

01 Feb '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 01 Feb '07

01 Feb '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 31 Jan '07

31 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 30 Jan '07

30 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 29 Jan '07

29 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 29 Jan '07

29 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 29 Jan '07

29 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

Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by hyc＠symas.com 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. 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

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: >> 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. dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu objectClass: person objectClass: inetOrgPerson objectClass: ncsuPerson uid: XXX cn: XXX sn: XXX title: Sophomore ncsuTwoPartName: XXX organizationalStatus: registered o: NC State University gn: XXX ncsuMiddleName: XXX initials: XXX displayName: XXX ncsuAltDisplayName: XXX ncsuCampusID: XXX ncsuClassCode: SO ou: Political Science - Int Politics Conc ncsuCurriculumCode: LIP ou: B A - History ncsuCurriculumCode: LAH mail: XXX ncsuPrimaryEMail: XXX registeredAddress: XXX postalAddress: XXX telephoneNumber: XXX l: Graham st: NC postalCode: XXX ncsuPrimaryRole: student 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) I moved away from 2.2 because it looks like you all don't support it anymore and I started running into stability problems. (which we have not narrowed down to be OpenLDAP's 'fault'.. just upgrading OpenLDAP was a good first and easy step 1, and actually seems to have helped) Daniel > -- > -- 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 28 Jan '07

28 Jan '07

> ando(a)sys-net.it wrote: >> ... >> Core was generated by `../../../servers/slapd/slapd -F slapd.d/ -h >> ldap://:9011 >> -s0 -dstats'. > > Recall from > http://www.openldap.org/lists/openldap-devel/200701/msg00077.html > the trick to keep the consumer from starting only works if the providerURI > matches a listenerURI. The providerURI is ldap://localhost:9011 which does > not match what you used here. right, I completely overlooked that :) p.

1 0

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

28 Jan '07

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. > > Same happens when re-starting slapd with the consumer's database. > > The problem is related to the pending CSN being a NULL berval; the assertion > occurs while trying to copy it, since the source of a ber copy cannot be NULL. > If it is correct that pending CSN be NULL, the test must be performed before > calling ber_bvreplace(); otherwise, this needs to be fixed. > > At this point I suggest that test049 includes stopping and restarting both (when > this bug is fixed), re-checking that contents match. > > <producer> > ... > Core was generated by `../../../servers/slapd/slapd -F slapd.d/ -h ldap://:9011 > -s0 -dstats'. Recall from http://www.openldap.org/lists/openldap-devel/200701/msg00077.html the trick to keep the consumer from starting only works if the providerURI matches a listenerURI. The providerURI is ldap://localhost:9011 which does not match what you used here. The other half of this ITS remains to be investigated... > Program terminated with signal 6, Aborted. > ... > (gdb) bt > #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x00fbf7a5 in raise () from /lib/tls/libc.so.6 > #2 0x00fc1209 in abort () from /lib/tls/libc.so.6 > #3 0x00fb8d91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x08218a30 in ber_bvreplace_x (dst=0xb6d15ff4, src=0x97ae258, ctx=0x0) > at memory.c:703 > #5 0x080f34d1 in slap_queue_csn (op=0xb6d15f30, csn=0xb6d15bf0) > at ctxcsn.c:167 > #6 0x080e91bc in syncrepl_del_nonpresent (op=0xb6d15f30, si=0x977ea68, > uuids=0x0, cookiecsn=0xb6d15d9c) at syncrepl.c:2097 > #7 0x080e49a0 in do_syncrep2 (op=0xb6d15f30, si=0x977ea68) at syncrepl.c:728 > #8 0x080e58e1 in do_syncrepl (ctx=0xb6d162a4, arg=0x977a008) > at syncrepl.c:1010 > #9 0x081e5948 in ldap_int_thread_pool_wrapper (xpool=0x9701bc8) at tpool.c:704 > #10 0x00692371 in start_thread () from /lib/tls/libpthread.so.0 > #11 0x0105fffe in clone () from /lib/tls/libc.so.6 > </producer> > > <consumer> > ... > Core was generated by `../../../servers/slapd/slapd -F slapd.d/ -h ldap://:9011 > -s0 -dstats'. > Program terminated with signal 6, Aborted. > ... > (gdb) bt > #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x00f057a5 in raise () from /lib/tls/libc.so.6 > #2 0x00f07209 in abort () from /lib/tls/libc.so.6 > #3 0x00efed91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x08218a30 in ber_bvreplace_x (dst=0xb6cd7ff4, src=0x8dec878, ctx=0x0) > at memory.c:703 > #5 0x080f34d1 in slap_queue_csn (op=0xb6cd7f30, csn=0xb6cd7bf0) > at ctxcsn.c:167 > #6 0x080e91bc in syncrepl_del_nonpresent (op=0xb6cd7f30, si=0x8db80b0, > uuids=0x0, cookiecsn=0xb6cd7d9c) at syncrepl.c:2097 > #7 0x080e49a0 in do_syncrep2 (op=0xb6cd7f30, si=0x8db80b0) at syncrepl.c:728 > #8 0x080e58e1 in do_syncrepl (ctx=0xb6cd82a4, arg=0x8da5408) > at syncrepl.c:1010 > #9 0x081e5948 in ldap_int_thread_pool_wrapper (xpool=0x8d3fbc8) at tpool.c:704 > #10 0x003cb371 in start_thread () from /lib/tls/libpthread.so.0 > #11 0x00fa5ffe in clone () from /lib/tls/libc.so.6 > </consumer> > > > -- -- 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

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

28 Jan '07

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. Same happens when re-starting slapd with the consumer's database. The problem is related to the pending CSN being a NULL berval; the assertion occurs while trying to copy it, since the source of a ber copy cannot be NULL. If it is correct that pending CSN be NULL, the test must be performed before calling ber_bvreplace(); otherwise, this needs to be fixed. At this point I suggest that test049 includes stopping and restarting both (when this bug is fixed), re-checking that contents match. <producer> ... Core was generated by `../../../servers/slapd/slapd -F slapd.d/ -h ldap://:9011 -s0 -dstats'. Program terminated with signal 6, Aborted. ... (gdb) bt #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00fbf7a5 in raise () from /lib/tls/libc.so.6 #2 0x00fc1209 in abort () from /lib/tls/libc.so.6 #3 0x00fb8d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x08218a30 in ber_bvreplace_x (dst=0xb6d15ff4, src=0x97ae258, ctx=0x0) at memory.c:703 #5 0x080f34d1 in slap_queue_csn (op=0xb6d15f30, csn=0xb6d15bf0) at ctxcsn.c:167 #6 0x080e91bc in syncrepl_del_nonpresent (op=0xb6d15f30, si=0x977ea68, uuids=0x0, cookiecsn=0xb6d15d9c) at syncrepl.c:2097 #7 0x080e49a0 in do_syncrep2 (op=0xb6d15f30, si=0x977ea68) at syncrepl.c:728 #8 0x080e58e1 in do_syncrepl (ctx=0xb6d162a4, arg=0x977a008) at syncrepl.c:1010 #9 0x081e5948 in ldap_int_thread_pool_wrapper (xpool=0x9701bc8) at tpool.c:704 #10 0x00692371 in start_thread () from /lib/tls/libpthread.so.0 #11 0x0105fffe in clone () from /lib/tls/libc.so.6 </producer> <consumer> ... Core was generated by `../../../servers/slapd/slapd -F slapd.d/ -h ldap://:9011 -s0 -dstats'. Program terminated with signal 6, Aborted. ... (gdb) bt #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00f057a5 in raise () from /lib/tls/libc.so.6 #2 0x00f07209 in abort () from /lib/tls/libc.so.6 #3 0x00efed91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x08218a30 in ber_bvreplace_x (dst=0xb6cd7ff4, src=0x8dec878, ctx=0x0) at memory.c:703 #5 0x080f34d1 in slap_queue_csn (op=0xb6cd7f30, csn=0xb6cd7bf0) at ctxcsn.c:167 #6 0x080e91bc in syncrepl_del_nonpresent (op=0xb6cd7f30, si=0x8db80b0, uuids=0x0, cookiecsn=0xb6cd7d9c) at syncrepl.c:2097 #7 0x080e49a0 in do_syncrep2 (op=0xb6cd7f30, si=0x8db80b0) at syncrepl.c:728 #8 0x080e58e1 in do_syncrepl (ctx=0xb6cd82a4, arg=0x8da5408) at syncrepl.c:1010 #9 0x081e5948 in ldap_int_thread_pool_wrapper (xpool=0x8d3fbc8) at tpool.c:704 #10 0x003cb371 in start_thread () from /lib/tls/libpthread.so.0 #11 0x00fa5ffe in clone () from /lib/tls/libc.so.6 </consumer>

1 0

Re: (ITS#4821) test043 cores; apparently incorrect resource usage
by ando＠sys-net.it 28 Jan '07

28 Jan '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> hyc(a)symas.com wrote: >> >>> Working now with patched libldap_r/tpool.c >> But now it leaks a lot at shutdown... > > Sigh, previous patch was missing a line. OK now. Comfirmed. I'll close this ITS. Thanks, p.

1 0

Re: (ITS#4821) test043 cores; apparently incorrect resource usage
by hyc＠symas.com 28 Jan '07

28 Jan '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: > >> Working now with patched libldap_r/tpool.c > > But now it leaks a lot at shutdown... Sigh, previous patch was missing a line. OK now. -- -- 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 hyc＠symas.com 27 Jan '07

27 Jan '07

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 27 Jan '07

27 Jan '07

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): dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify replace: ou ou: Political Science - Int Politics Conc ou: B A - History - replace: ncsucurriculumcode ncsucurriculumcode: LIP ncsucurriculumcode: LAH And I get: modifying entry "uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu" ldap_modify: Type or value exists (20) additional info: modify/replace: ou: value #1 already exists (and again, I can 'fix' it by doing a delete: ou and then redoing the replace; ncsucurriculumcode fails in exactly the same way; after deleting and redoing the replace, i can replace the ou over and over and over again with the same data and it's fine every time from then on) Entry as it stood before running that statement was (as produced by slapcat): dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu objectClass: person objectClass: inetOrgPerson objectClass: ncsuPerson uid: XXX cn: xxx sn: XXX title: Sophomore ncsuTwoPartName: XXX organizationalStatus: registered o: NC State University givenName: XXX ncsuMiddleName: XXX initials: XXX displayName: XXX ncsuAltDisplayName: XXX ncsuCampusID: XXX ncsuClassCode: SO ou: Political Science - Int Politics Conc ncsuCurriculumCode: LIP ou: B A - History ncsuCurriculumCode: LAH mail: ztmiller(a)gmail.com ncsuPrimaryEMail: XXX registeredAddress: XXX postalAddress: XXX telephoneNumber: XXX l: Graham st: NC postalCode: 27253 ncsuPrimaryRole: student structuralObjectClass: inetOrgPerson entryUUID: d10a18fe-4286-102b-89b0-9fbe6f44e542 creatorsName: cn=XXX,dc=ncsu,dc=edu modifiersName: cn=xxX,dc=ncsu,dc=edu createTimestamp: 20070127191747Z modifyTimestamp: 20070127191747Z entryCSN: 20070127191747Z#000014#00#000000 Note that yes, I am replacing the setting with exactly what it was before, for testing purposes, but there's no reason that shouldn't work, correct? Daniel > Daniel Henninger wrote: > >> RE23... ;D Does that mean I should wait for the next minor release? Or >> shall I pull from CVS/SVN? or? > > You can pull the current slapd/entry.c from CVS (use the > OPENLDAP_REL_ENG_2_3 > tag) if you want to patch your current builds. The fix will be in 2.3.34. > > -- > -- 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#4821) test043 cores; apparently incorrect resource usage
by ando＠sys-net.it 27 Jan '07

27 Jan '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: > >> Working now with patched libldap_r/tpool.c > > But now it leaks a lot at shutdown... I've plugged the config related leaks; what appears to be missing is the companion of connection_fake_init() that takes care of destroying the slab. BTW, there's a SLAPI-related connection_fake_destroy() which has nothing to do with the purpose... p.

1 0

Re: (ITS#4821) test043 cores; apparently incorrect resource usage
by ando＠sys-net.it 27 Jan '07

27 Jan '07

hyc(a)symas.com wrote: > Working now with patched libldap_r/tpool.c But now it leaks a lot at shutdown... <producer> ==5246== 24,118,976 (1,728 direct, 24,117,248 indirect) bytes in 54 blocks are definitely lost in loss record 5 of 8 ==5246== at 0x4004405: malloc (vg_replace_malloc.c:149) ==5246== by 0x8217EC7: ber_memalloc_x (memory.c:226) ==5246== by 0x809ECCC: ch_malloc (ch_malloc.c:54) ==5246== by 0x80DD5A1: slap_sl_mem_create (sl_malloc.c:122) ==5246== by 0x8081145: connection_fake_init (connection.c:1997) ==5246== by 0x8070E03: config_back_db_open (bconfig.c:5272) ==5246== by 0x808D1F0: backend_startup_one (backend.c:212) ==5246== by 0x808D67D: backend_startup (backend.c:303) ==5246== by 0x80B47B5: slap_startup (init.c:248) ==5246== by 0x8062D75: main (main.c:923) </producer> <consumer> ==5265== 5,243,255 (375 direct, 5,242,880 indirect) bytes in 12 blocks are definitely lost in loss record 3 of 7 ==5265== at 0x4004405: malloc (vg_replace_malloc.c:149) ==5265== by 0x8217EC7: ber_memalloc_x (memory.c:226) ==5265== by 0x81FAA5E: ldap_dn2bv_x (getdn.c:3027) ==5265== by 0x8096621: dnNormalize (dn.c:485) ==5265== by 0x80EBB59: parse_syncrepl_line (syncrepl.c:3039) ==5265== by 0x80EDB0E: add_syncrepl (syncrepl.c:3408) ==5265== by 0x80EED08: syncrepl_config (syncrepl.c:3670) ==5265== by 0x8073163: config_set_vals (config.c:305) ==5265== by 0x807364E: config_add_vals (config.c:374) ==5265== by 0x80745EE: read_config_file (config.c:731) ==5265== by 0x806C3A2: read_config (bconfig.c:3440) ==5265== by 0x8062668: main (main.c:745) ... ==5301== 23,068,672 bytes in 8 blocks are possibly lost in loss record 7 of 7 ==5301== at 0x4004405: malloc (vg_replace_malloc.c:149) ==5301== by 0x8217EC7: ber_memalloc_x (memory.c:226) ==5301== by 0x809ECCC: ch_malloc (ch_malloc.c:54) ==5301== by 0x80DD5AF: slap_sl_mem_create (sl_malloc.c:123) ==5301== by 0x8081145: connection_fake_init (connection.c:1997) ==5301== by 0x8070E03: config_back_db_open (bconfig.c:5272) ==5301== by 0x808D1F0: backend_startup_one (backend.c:212) ==5301== by 0x808D67D: backend_startup (backend.c:303) ==5301== by 0x80B47B5: slap_startup (init.c:248) ==5301== by 0x8062D75: main (main.c:923) </consumer> p.

1 0

Re: (ITS#4821) test043 cores; apparently incorrect resource usage
by hyc＠symas.com 27 Jan '07

27 Jan '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >> >>> #4 0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0, >>> manage=0, add_soc=1, text=0xb6f10738, >>> textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87 >>> 87 assert( a->a_vals[0].bv_val != NULL ); >> The two things were actually unrelated. The latter is now fixed in >> HEAD; I still get two cores, but both are related to calling >> bdb_locker_id_free() at shutdown with an invalid environment. > > I see that as well, looking into it. That invocation of bdb_locker_id_free() > should of course not be happening. > Working now with patched libldap_r/tpool.c -- -- 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#4821) test043 cores; apparently incorrect resource usage
by hyc＠symas.com 27 Jan '07

27 Jan '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> #4 0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0, >> manage=0, add_soc=1, text=0xb6f10738, >> textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87 >> 87 assert( a->a_vals[0].bv_val != NULL ); > > The two things were actually unrelated. The latter is now fixed in > HEAD; I still get two cores, but both are related to calling > bdb_locker_id_free() at shutdown with an invalid environment. I see that as well, looking into it. That invocation of bdb_locker_id_free() should of course not be happening. -- -- 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#4821) test043 cores; apparently incorrect resource usage
by ando＠sys-net.it 27 Jan '07

27 Jan '07

ando(a)sys-net.it wrote: > #4 0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0, > manage=0, add_soc=1, text=0xb6f10738, > textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87 > 87 assert( a->a_vals[0].bv_val != NULL ); The two things were actually unrelated. The latter is now fixed in HEAD; I still get two cores, but both are related to calling bdb_locker_id_free() at shutdown with an invalid environment. p.

1 0

(ITS#4821) test043 cores; apparently incorrect resource usage
by ando＠sys-net.it 27 Jan '07

27 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux 2.6 (CentOS 4.4) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando test43 results in a couple of core dumps. The first occurs to the producer. Valgrind is showing ==1654== Invalid read of size 4 ==1654== at 0x8148BC3: bdb_locker_id_free (cache.c:1360) ==1654== by 0x81E5F7A: ldap_pvt_thread_pool_context_reset (tpool.c:903) ==1654== by 0x80B48EF: slap_destroy (init.c:275) ==1654== by 0x8062E2B: main (main.c:954) ==1654== Address 0x4ED36A0 is 520 bytes inside a block of size 680 free'd ==1654== at 0x4004EFA: free (vg_replace_malloc.c:235) ==1654== by 0x8217E09: ber_memfree_x (memory.c:149) ==1654== by 0x8217E6D: ber_memfree (memory.c:162) ==1654== by 0x58E09E: __os_free (in /lib/tls/i686/libdb-4.2.so) ==1654== by 0x56D6E6: __dbenv_close (in /lib/tls/i686/libdb-4.2.so) ==1654== by 0x56D816: __dbenv_close_pp (in /lib/tls/i686/libdb-4.2.so) ==1654== by 0x80FE3D8: bdb_db_close (init.c:512) ==1654== by 0x80F1430: over_db_close (backover.c:195) ==1654== by 0x808D7A4: backend_shutdown (backend.c:352) ==1654== by 0x80B4846: slap_shutdown (init.c:258) ==1654== by 0x8062E0A: main (main.c:947) bdb_locker_id_free() is passed to ldap_pvt_thread_pool_setkey() as cleanup function, but apparently the keys are cleaned up __after__ the key (the db env) has already been destroyed (in bdb_do_close()). The second core occurs again in the producer, since the test doesn't realize it cored and thus tries to restart it, according to the test pattern. Valgrind in this case only reports slapd: schema_check.c:87: entry_schema_check: Assertion `a->a_vals[0].bv_val != ((void *)0)' failed. If the same problem is reproduced without valgrind (the vgcore appears to be screwed), a NULL attribute seems to be left 'round: (gdb) bt #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x003d57a5 in raise () from /lib/tls/libc.so.6 #2 0x003d7209 in abort () from /lib/tls/libc.so.6 #3 0x003ced91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0, manage=0, add_soc=1, text=0xb6f10738, textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87 #5 0x08144565 in bdb_add (op=0xb6f10760, rs=0xb6f10724) at add.c:97 #6 0x080f1c30 in overlay_op_walk (op=0xb6f10760, rs=0xb6f10724, which=op_add, oi=0x89e5968, on=0x0) at backover.c:507 #7 0x080f1de5 in over_op_func (op=0xb6f10760, rs=0xb6f10724, which=op_add) at backover.c:559 #8 0x080f1ef1 in over_op_add (op=0xb6f10760, rs=0xb6f10724) at backover.c:605 #9 0x081a308d in accesslog_response (op=0x8a84160, rs=0xb6f111c8) at accesslog.c:1279 #10 0x080f1560 in over_back_response (op=0x8a84160, rs=0xb6f111c8) at backover.c:237 #11 0x08090f2d in slap_response_play (op=0x8a84160, rs=0xb6f111c8) at result.c:317 #12 0x080910cd in send_ldap_response (op=0x8a84160, rs=0xb6f111c8) at result.c:391 #13 0x08091dd2 in slap_send_ldap_result (op=0x8a84160, rs=0xb6f111c8) at result.c:638 #14 0x08103653 in bdb_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:784 #15 0x080f1c30 in overlay_op_walk (op=0x8a84160, rs=0xb6f111c8, which=op_modrdn, oi=0x89fb040, on=0x0) at backover.c:507 #16 0x080f1de5 in over_op_func (op=0x8a84160, rs=0xb6f111c8, which=op_modrdn) at backover.c:559 #17 0x080f1ecf in over_op_modrdn (op=0x8a84160, rs=0xb6f111c8) at backover.c:599 #18 0x0809e220 in fe_op_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:318 #19 0x0809db83 in do_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:185 #20 0x0807ef0f in connection_operation (ctx=0xb6f112a4, arg_v=0x8a84160) at connection.c:1129 #21 0x0807f3dc in connection_read_thread (ctx=0xb6f112a4, argv=0x10) at connection.c:1257 #22 0x081e57a8 in ldap_int_thread_pool_wrapper (xpool=0x89bd968) at tpool.c:704 #23 0x00692371 in start_thread () from /lib/tls/libpthread.so.0 #24 0x00475ffe in clone () from /lib/tls/libc.so.6 (gdb) frame 4 #4 0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0, manage=0, add_soc=1, text=0xb6f10738, textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87 87 assert( a->a_vals[0].bv_val != NULL ); (gdb) p a $1 = (Attribute *) 0xb6f78e34 (gdb) p a->a_vals $2 = 0x8a93ef8 (gdb) p a->a_vals[0] $3 = {bv_len = 0, bv_val = 0x0} No solution comes to mind right now for the first problem; I'm investigating the second to see where the NULL attr comes from. p.

1 0

Re: (ITS#4820) More issues with modify opattrs in syncrepl
by ando＠sys-net.it 27 Jan '07

27 Jan '07

Howard Chu wrote: > I guess we could just set DBFLAG_NOLASTMOD on the db. We really only > need to make sure a structuralObjectClass and entryUUID gets set for an > Add operation. Just ot avoid overloading stuff, I prefer to add a field to the rs_modify structure that prevents from creating the operational attrs. There might be cases where occasionally we want opattrs and occasionally we don't, and having to create a copy of the BackendDB structure just to toggle a flag seems to be an overkill. I'm about to commit a patch to this. The fix allows to ask for most of the operational attrs in test017 and test018 (only entryCSN can't be checked only because it gets out of sort, I need to find why). In test019, if all modify opattrs are requested there are even more out of sort stuff, so I'm not going to touch it. In any case, I've checked that apart from the print order the values are all in sync. About print ordering, I guess a workaround would be to sort each LDIF line when comparing outputs. This would cure the tests, but it might still overload mods checking in syncrepl; redesigning syncrepl so that out-of-order is no longer an issue could be an option. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs