openldap-bugs

openldap-bugs@openldap.org

1 participants
20953 discussions

(ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by seuler.shi＠gmail.com 13 Dec '06

13 Dec '06

Full_Name: Seuler Shi Version: 2.3.30 OS: Fedora 5 Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) Problem using BDB as backend of OpenLDAP Software version: Berkeley DB: 4.5.20 OpenLDAP:2.3.30 We want to configure the replication management in OpenLDAP's backend database. All write requests in OpenLDAP master site will spread to OpenLDAP client site for we have configured the backend database replication. We mend the source code the OpenLDAP according to the rep_mgr example provide by Berkeley DB. A test case is executed as follow: step 1: start openldap server site and client site; step 2: send write requests to the master site; step 3: search the master site and ensure the records are inserted in backend; database successfully; step 4: search the client site, but not ldap entry is displayed; step 5: kill the client site process and reboot it; step 5: search the client site right now after it reboot; Result: After step 5(reboot the client site), the search results from client site is same as the master site. At step 4: If we intend to insert an entry into the openLDAP server with BDB client configuration via ldapadd command, it will return "the entry already exists". After the failed insert operation, if search operation is executed, one entry will be displayed.Once a insert operation is tried, the number of entries in the subsequent search will increase by 1. My question: Why we can not search any info during the client is normally running? But once I rebooted the client site, it worked well and could accept search requests? How to solve this problem:)

1 0

connection_close() called with c_struct_state == SLAP_C_INACTIVE
by Pierangelo Masarati 13 Dec '06

13 Dec '06

Recently, with 2.3.30, I got an assertion during shutdown because connection_close() was called with c_struct_state == SLAP_C_INACTIVE. Unfortunately I couldn't save neither the core nor a backtrace. I guess the fix in connection.c 1.375 -> 1.376 should be backported to re23, but the code changed since then, and I fear I could break something. Is this correct? p.

2 4

Re: (ITS#4755) Show peer's name when syncrepl fails
by hyc＠symas.com 13 Dec '06

13 Dec '06

daveh(a)ci.com.au wrote: > On Thu, 16 Nov 2006, Howard Chu wrote: > >> Since the rid is supposed to be unique, would you settle for that? >> Particularly since there may be multiple sessions to the same host... > > Yes, that will do nicely. In the meantime I was getting it to print > si->si_bindconf.sb_uri.bv_val, as I sort of need it right now... > I don't have time to backport the changes from HEAD to RE23 myself, but if someone submits the patch I can commit it. -- -- 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#4545 bug in libldap
by ando＠sys-net.it 12 Dec '06

12 Dec '06

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: > >> I haven't quite figured out everything that's going on, but this patch >> definitely shows when it occurs in test036: >> > > OK, fixed in HEAD. > > By the way, the main problem appears to have already been fixed; > slapd.3.log is now only (!) 360MB. This last patch (result.c 1.141) just > cleans up two leaked requests. > CVS log for tests/scripts/test036-meta-concurrency *1.19* <http://www.openldap.org/devel/cvsweb.cgi/%7Echeckout%7E/tests/scripts/test0…> /Sun Dec 3 20:37:40 2006 UTC/; 9 days, 11 hours ago by /ando/ CVS Tags: *HEAD* Changed since *1.18*: +3 -2 lines Diffs to 1.18 <http://www.openldap.org/devel/cvsweb.cgi/tests/scripts/test036-meta-concurr…> (colored diff) <http://www.openldap.org/devel/cvsweb.cgi/tests/scripts/test036-meta-concurr…> I told it to stop searching referrals (treat it as an error ... :) p.

1 0

ITS#4510 syncrepl starttls in Admin Guide
by hyc＠symas.com 12 Dec '06

12 Dec '06

Feel free to submit a patch. This may need to be two separate patches since there are several new TLS config keywords in RE24 vs RE23. -- -- 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#3947 ldap(3) man page points to non existing man pages
by hyc＠symas.com 12 Dec '06

12 Dec '06

The two manpages listed specifically in this ITS have been added to HEAD. For anything else, it's really a dupe of ITS#2240. I'm closing this in favor of #2240. -- -- 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#4615) Possible bug in access log overlay with distributed databases
by hyc＠symas.com 12 Dec '06

12 Dec '06

This is now fixed in HEAD. ckacoroski(a)nsd.org wrote: > Full_Name: Ski Kacoroski > Version: 2.3.24 > OS: Debian Linux Sarge 3.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (152.157.64.243) > > > I have the following setup: > > dc=nsd, dc=org # superior database with accesslog nsdlog > | > -- ou=people # ou in superior database > | > -- ou=hosts # subordinate database with accesslog hostslog > > When I make a change, search, add, delete to an object in > "ou=people,dc=nsd,dc=org", I get logs in nsdlog only. This is makes sense > > When I do a search with base "dc=nsd,dc=org" and scope of base I get an entry in > nsdlog only. This makes sense. If I change the scope to one or sub I get an > entry in nsdlog and hostslog. This also makes sense to me. > > When I do the following search: > ldapsearch -x -b "ou=hosts,dc=nsd,dc=org" -h localhost "(uid=test)" with any -s > option I get entries in both nsdlog and hostslog even though the search should > just be in the "ou=hosts,dc=nsd,dc=org" database. > > Question is why I am still getting search entries in the nsdlog? Is this > expected behaviour? > Also, if I make a add to an object in "ou=hosts,,dc=nsd,dc=org" I get 3 > duplicate entries in both logs where I only expected to get entries in the > hostslog. If I change the rootdn of "ou=hosts,dc=nsd,dc=org" to be > "cn=root,ou=hosts,dc=nsd,dc=org" instead of "cn=root,dc=nsd,dc=org", I only get > 1 duplicate entry in the nsdlog (e.g. I only get the add entry, not the bind or > unbind entries as I am not binding to the rootdn in "dc=nsd,dc=org". > > Question is why I am still getting the add entry in nsdlog? Is this expected > behaviour? -- -- 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#4545 bug in libldap
by hyc＠symas.com 12 Dec '06

12 Dec '06

hyc(a)symas.com wrote: > I haven't quite figured out everything that's going on, but this patch > definitely shows when it occurs in test036: OK, fixed in HEAD. By the way, the main problem appears to have already been fixed; slapd.3.log is now only (!) 360MB. This last patch (result.c 1.141) just cleans up two leaked requests. -- -- 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#4545 bug in libldap
by hyc＠symas.com 12 Dec '06

12 Dec '06

I haven't quite figured out everything that's going on, but this patch definitely shows when it occurs in test036: Index: result.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/result.c,v retrieving revision 1.140 diff -u -r1.140 result.c --- result.c 3 Dec 2006 23:11:12 -0000 1.140 +++ result.c 12 Dec 2006 22:53:25 -0000 @@ -914,6 +914,10 @@ } if ( lr != NULL ) { + if ( tag == LDAP_RES_SEARCH_RESULT ) { + Debug( LDAP_DEBUG_TRACE, "request done: ld %p msgid %ld but mis-handled!\n", + (void *)ld, (long) id, 0 ); + } ldap_return_request( ld, lr, 0 ); lr = NULL; } The response is actually returned to the caller properly, but we never decide to "mark request completed." Setting a breakpoint here will let you poke around at it. v3ref is set to V3REF_TOAPP at this point. This should mean that the result included a referral and it will be returned to the caller, which means that we can dispose of the request, but we never do. -- -- 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#4777) translucent overlay breaks if first mod in modlist is a delete
by hyc＠symas.com 12 Dec '06

12 Dec '06

kuenne(a)rentec.com wrote: > Full_Name: Karsten Kuenne > Version: 2.3.30 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.223.241.248) > > > The following loop in translucent.c at around line 297 fails if the first mod in > the modlist is a delete and eventually crashes slapd: This is now fixed in HEAD, thanks for the report. -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs