openldap-bugs

openldap-bugs@openldap.org

1 participants
20985 discussions

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by quanah＠stanford.edu 14 Dec '06

14 Dec '06

--On Thursday, December 14, 2006 1:52 AM +0000 seuler.shi(a)gmail.com wrote: > 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:) Why are you using BDB Replication? That isn't supported. Use slurpd, syncrepl, or delta-syncrepl. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: ITS#4545 bug in libldap
by hyc＠symas.com 14 Dec '06

14 Dec '06

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> 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 > I told it to stop searching referrals (treat it as an error ... :) Commenting out that change had no effect, which makes sense. That change only affected the clients, not slapd. I tried again with chase-referrals TRUE in the slapd.3.conf, and that seems to have been the difference. Without the patch, slapd.3.log is 3.4GB. With the patch it's only 400MB and there are no leaked requests. Probably I had forgotten that I'd enabled chase-referrals when I submitted the original ITS, since they're originally disabled in this test. -- -- 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#4778) Problem using Berkeley DB replication in OpenLDAP
by seuler.shi＠gmail.com 14 Dec '06

14 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 14 Dec '06

14 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 13 Dec '06

13 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 13 Dec '06

13 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 13 Dec '06

13 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 13 Dec '06

13 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 13 Dec '06

13 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

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