- openldap-bugs - openldap.org

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

ITS#4545 bug in libldap
by hyc＠symas.com 13 Dec '06

13 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

(ITS#4777) translucent overlay breaks if first mod in modlist is a delete
by kuenne＠rentec.com 12 Dec '06

12 Dec '06

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: .... Debug(LDAP_DEBUG_TRACE, "=> translucent_modify: silently dropping delete: %s\n", m->sml_desc->ad_cname.bv_val, 0, 0); ==> for(mm = op->orm_modlist; mm->sml_next != m; mm = mm->sml_next); mm->sml_next = m->sml_next; m->sml_next = NULL; slap_mods_free(m, 1); .... I tried to come up with a fix but so far I always got a "Invalid modification" because I apparently got something wrong so I worked around it on the client side for now.

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 12 Dec '06

12 Dec '06

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> <quote who="hyc(a)symas.com"> >>> ghenry(a)suretecsystems.com wrote: >>>> Full_Name: Gavin Henry >>>> Version: 2.3.30 >>>> OS: FC6 >>>> URL: >>>> http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >>>> Submission from: (NULL) (212.159.59.85) >>>> >>>> >>>> Hi all, >>>> >>>> Monitoring section updated. Please review and provide feedback. >>> You use the term "subentries" in several places where I'm pretty sure >>> you mean "child entries"; "subentry" has a special meaning in >>> X.500/LDAP >>> that isn't relevant here. >> >> Sure, that's what I meant really ;-) >> >> I'll update it and send another patch. Or is there an easier way? > > Your original patch is already in CVS now. Just send a diff against the > CVS version. New version with TOC set to 3: http://www.suretecsystems.com/our_docs/admin_guide.patch Thanks. -- 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

Re: (ITS#4774) Add network timeout option to ldapsearch
by Kurt＠OpenLDAP.org 12 Dec '06

12 Dec '06

At 12:59 AM 12/12/2006, lukeh(a)padl.com wrote: >Full_Name: Luke Howard >Version: HEAD >OS: >URL: http://www.padl.com/~lukeh/openldap-HEAD-nto.diff >Submission from: (NULL) (203.13.32.80) > > >A customer had requested we add an option to ldapsearch to allow a network >timeout to be specified on the command line. > >A patch against HEAD is attached. > >I am aware that you can specify NETWORK_TIMEOUT in ldap.conf, and that free >command line options are precious. Given this, -e nettimeout=X might be better choice here. Or -o nettimeout=X.

1 0

(ITS#4776) slapo-chain(5) does not use the DN in the referral
by ando＠sys-net.it 12 Dec '06

12 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) When chasing a referral, if the DN in the referral differs from the one in the original request slapo-chain(5) disregards it and uses the original request DN. This behavior disagrees with that of the client library. p.

1 0

(ITS#4774) Add network timeout option to ldapsearch
by lukeh＠padl.com 12 Dec '06

12 Dec '06

Full_Name: Luke Howard Version: HEAD OS: URL: http://www.padl.com/~lukeh/openldap-HEAD-nto.diff Submission from: (NULL) (203.13.32.80) A customer had requested we add an option to ldapsearch to allow a network timeout to be specified on the command line. A patch against HEAD is attached. I am aware that you can specify NETWORK_TIMEOUT in ldap.conf, and that free command line options are precious.

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 11 Dec '06

11 Dec '06

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> <quote who="hyc(a)symas.com"> >>> ghenry(a)suretecsystems.com wrote: >>>> Full_Name: Gavin Henry >>>> Version: 2.3.30 >>>> OS: FC6 >>>> URL: >>>> http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >>>> Submission from: (NULL) (212.159.59.85) >>>> >>>> >>>> Hi all, >>>> >>>> Monitoring section updated. Please review and provide feedback. >>> You use the term "subentries" in several places where I'm pretty sure >>> you mean "child entries"; "subentry" has a special meaning in >>> X.500/LDAP >>> that isn't relevant here. >> >> Sure, that's what I meant really ;-) >> >> I'll update it and send another patch. Or is there an easier way? > > Your original patch is already in CVS now. Just send a diff against the > CVS version. Thanks. > > -- > -- 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#4770) monitoringslapd.sdf patch
by hyc＠symas.com 11 Dec '06

11 Dec '06

ghenry(a)suretecsystems.com wrote: > <quote who="hyc(a)symas.com"> >> ghenry(a)suretecsystems.com wrote: >>> Full_Name: Gavin Henry >>> Version: 2.3.30 >>> OS: FC6 >>> URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >>> Submission from: (NULL) (212.159.59.85) >>> >>> >>> Hi all, >>> >>> Monitoring section updated. Please review and provide feedback. >> You use the term "subentries" in several places where I'm pretty sure >> you mean "child entries"; "subentry" has a special meaning in X.500/LDAP >> that isn't relevant here. > > Sure, that's what I meant really ;-) > > I'll update it and send another patch. Or is there an easier way? Your original patch is already in CVS now. Just send a diff against the CVS version. -- -- 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#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 11 Dec '06

11 Dec '06

<quote who="hyc(a)symas.com"> > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.30 >> OS: FC6 >> URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >> Submission from: (NULL) (212.159.59.85) >> >> >> Hi all, >> >> Monitoring section updated. Please review and provide feedback. > > You use the term "subentries" in several places where I'm pretty sure > you mean "child entries"; "subentry" has a special meaning in X.500/LDAP > that isn't relevant here. Sure, that's what I meant really ;-) I'll update it and send another patch. Or is there an easier way? Thanks. > > -- > -- 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#4770) monitoringslapd.sdf patch
by hyc＠symas.com 11 Dec '06

11 Dec '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.30 > OS: FC6 > URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch > Submission from: (NULL) (212.159.59.85) > > > Hi all, > > Monitoring section updated. Please review and provide feedback. You use the term "subentries" in several places where I'm pretty sure you mean "child entries"; "subentry" has a special meaning in X.500/LDAP that isn't relevant here. -- -- 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#4773) syncrepl segfault with incorrect config
by ando＠sys-net.it 10 Dec '06

10 Dec '06

Adrian Bridgett wrote: > On Sat, Dec 9, 2006 at 22:29:50 +0100 (+0100), Pierangelo Masarati wrote: > >> It is already fixed in HEAD; fixing it in re23 might be too >> difficult to consider, so, since the correct behavior is clearly >> documented, it might be not worth the effort. >> > > Fair enough, I'm sure I searched through the bugs for syncrepl items > and didn't see anything, but I guess it was fixed outside of a bug > report which would explain it. > Well, AFAIR it was not fixed as a consequence of a bug report; rather, HEAD code provides support to tag overlays as specific for the global or per-database level, if their use is not appropriate at all levels. slapo-syncprov in HEAD checks if it's being instantiated at the right level, otherwise it bails out. What actually happens if it's instantiated at the wrong level, namely what causes the core dump you reported, is not ficed at all, as it makes no longer sense. That's what I meant when I said that fixing this issue in re23 might not be worth: support for tagging overlays and to check if they're appropriately instantiated is interspersed in many code changes which may not be trivial to isolate. p.

1 0

Re: (ITS#4773) syncrepl segfault with incorrect config
by adrian＠smop.co.uk 10 Dec '06

10 Dec '06

On Sat, Dec 9, 2006 at 22:29:50 +0100 (+0100), Pierangelo Masarati wrote: > It is already fixed in HEAD; fixing it in re23 might be too > difficult to consider, so, since the correct behavior is clearly > documented, it might be not worth the effort. Fair enough, I'm sure I searched through the bugs for syncrepl items and didn't see anything, but I guess it was fixed outside of a bug report which would explain it. Many thanks, Adrian -- Adrian Bridgett - adrian(a)smop.co.uk GPG key available on public key servers

1 0

Re: (ITS#4773) syncrepl segfault with incorrect config
by ando＠sys-net.it 09 Dec '06

09 Dec '06

adrian(a)smop.co.uk wrote: > Trying to add or delete entries with syncrepl overlay I was getting segfaults. > > I couldn't check against my test box (remote location, no power), but eventually > came across: > http://www.mail-archive.com/openldap-software@openldap.org/msg06772.html > > This was in fact the problem I had too - I had specified syncrepl early on > rather than after the database definition. Moving syncrepl into the correct > place fixed it. > > Two hours wasted trying to figure out what was wrong, it would be good to have > some error message in this case :-) > It is already fixed in HEAD; fixing it in re23 might be too difficult to consider, so, since the correct behavior is clearly documented, it might be not worth the effort. p.

1 0

(ITS#4773) syncrepl segfault with incorrect config
by adrian＠smop.co.uk 08 Dec '06

08 Dec '06

Full_Name: Adrian Bridgett Version: 2.3.29 OS: Linux (Debian) URL: Submission from: (NULL) (81.5.177.202) Trying to add or delete entries with syncrepl overlay I was getting segfaults. I couldn't check against my test box (remote location, no power), but eventually came across: http://www.mail-archive.com/openldap-software@openldap.org/msg06772.html This was in fact the problem I had too - I had specified syncrepl early on rather than after the database definition. Moving syncrepl into the correct place fixed it. Two hours wasted trying to figure out what was wrong, it would be good to have some error message in this case :-) The stack traces I got out weren't terribly helpful to me (from a debug build of 2.3.27 running on Debian sarge all up to date): #0 0xa7f3501f in lutil_debug (debug=255, level=4, fmt=0x4 <Address 0x4 out of bounds>) at /home/autobuild/builds/openldap2.3/openldap-2.3.27/libraries/liblber/debug.c:63 #1 0x0807f71b in fe_op_modify () #2 0x0807f0f5 in fe_op_modify () (repeat of #2) #939 0x0807f0f5 in fe_op_modify () #940 0x0807f0f5 in fe_op_modify () #941 0x0807f0f5 in fe_op_modify () #942 0x080bf2fa in overlay_op_walk () #943 0x080bf3fd in overlay_op_walk () #944 0x080bf531 in overlay_op_walk () #945 0x0807e900 in do_modify () #946 0x0806960f in connection_done () #947 0xa7f46c28 in ldap_int_thread_pool_wrapper (xpool=0x24) at /home/autobuild/builds/openldap2.3/openldap-2.3.27/libraries/libldap_r/tpool.c:478 #948 0xa7d51b63 in start_thread () from /lib/tls/libpthread.so.0 #949 0xa7ce018a in clone () from /lib/tls/libc.so.6 #0 0x0806fca8 in fe_op_add () #1 0x0806ff58 in fe_op_add () (repeat of #1) #11378 0x0806ff58 in fe_op_add () #11379 0x080bf2fa in overlay_op_walk () #11380 0x080bf3fd in overlay_op_walk () #11381 0x080bf591 in overlay_op_walk () #11382 0x0806f7af in do_add () #11383 0x0806960f in connection_done () #11384 0xa7f23c28 in ldap_int_thread_pool_wrapper (xpool=0x26) at /home/autobuild/builds/openldap2.3/openldap-2.3.27/libraries/libldap_r/tpool.c:478 #11385 0xa7d2eb63 in start_thread () from /lib/tls/libpthread.so.0 #11386 0xa7cbd18a in clone () from /lib/tls/libc.so.6 Please shout if you want any more info. Thanks for a great product, Adrian

1 0

(ITS#4772) SEGV during DEL/syncprov_qtask
by richton＠nbcs.rutgers.edu 08 Dec '06

08 Dec '06

Full_Name: Aaron Richton Version: 2.3.30 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061208-segv.txt Submission from: (NULL) (68.196.250.61) I realize I've already got #4723 open as "no idea why this is SEGV," but this trace looked notably different, so I'm filing separate. I'm going to continue debugging along the lines of #4723, which was leaning towards OpenSSL. But if anything jumps out at somebody from this trace, feel free to speak up. As it turns out, this was near a batch of a large number of DELs. Might be good to take a glance through slog or similar and see if a memory debugger comes up clean, especially with deletes...

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 07 Dec '06

07 Dec '06

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.30 >> OS: FC6 >> URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >> Submission from: (NULL) (212.159.59.85) >> >> >> Hi all, >> >> Monitoring section updated. Please review and provide feedback. >> >> Thanks, >> >> Gavin. >> >> (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) >> > At the moment the only comment I have is regarding back-monitor itself, > not the doc: I question the decision to define the monitor info > attributes as operational instead of user attributes. Requiring the use > of "+" to return all of the monitored info seems pretty unfriendly, > particularly since it causes the return of actual operational attributes > that are completely irrelevant to the purpose of monitoring. I.e., the > monitor info should be considered to be dynamically generated user > attributes, not operational attributes. OK. So what would be the next step, re-work it? Just let me know the changes so I can document them. There's nothing like documenting a moving target! ;-) 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

Re: (ITS#4770) monitoringslapd.sdf patch
by hyc＠symas.com 07 Dec '06

07 Dec '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.30 > OS: FC6 > URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch > Submission from: (NULL) (212.159.59.85) > > > Hi all, > > Monitoring section updated. Please review and provide feedback. > > Thanks, > > Gavin. > > (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) > At the moment the only comment I have is regarding back-monitor itself, not the doc: I question the decision to define the monitor info attributes as operational instead of user attributes. Requiring the use of "+" to return all of the monitored info seems pretty unfriendly, particularly since it causes the return of actual operational attributes that are completely irrelevant to the purpose of monitoring. I.e., the monitor info should be considered to be dynamically generated user attributes, not operational attributes. -- -- 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#4771) Memory Leak in connection.c
by marco.dettorre＠sys-net.it 07 Dec '06

07 Dec '06

Full_Name: Marco D'Ettorre Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.214.117.67) There is a memory leak in connection_op_queue (servers/slapd/connection.c +1821). A fix for this: --- servers/slapd/connection.c.orig 2006-12-07 18:30:14.000000000 +0100 +++ servers/slapd/connection.c 2006-12-07 19:07:09.000000000 +0100 @@ -1751,6 +1751,9 @@ { op->o_conn->c_sasl_bindop = NULL; + ch_free( op->o_callback ); + op->o_callback = NULL; + return SLAP_CB_CONTINUE; } Regards Marco

1 0

(ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 07 Dec '06

07 Dec '06

Full_Name: Gavin Henry Version: 2.3.30 OS: FC6 URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch Submission from: (NULL) (212.159.59.85) Hi all, Monitoring section updated. Please review and provide feedback. Thanks, Gavin. (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) -- 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

freeing mem from ldap_parse_result
by Dale Moore 06 Dec '06

06 Dec '06

I'm trying to write exceptionally correct code with no memory leaks. I'm calling ldap_parse_result(3). And of course one of the parameters is char ***referalsp; The documentation says to free the memory allocated to this data structure by calling the routine ldap_value_free(). But the routine ldap_value_free() is deprecated. My options are - Compile with -DLDAP_DEPRECATED = I hate to create software using deprecated API - Call ber_memvfree((void **)) instead of ldap_value_free() - Use a different mechanism to parse the message The bug I'm reporting here is - a problem with the documentation or - in the premature deprecation of ldap_value_free or - the lack of deprecation of ldap_parse_ressult() I'm not sure which. Looking for advice. Dale Moore

2 1

Re: ITS#3812 database config documentation
by raphael.ouazana＠linagora.com 06 Dec '06

06 Dec '06

On Jeu 16 novembre 2006 12:09, hyc(a)symas.com wrote: > I've committed a preliminary slapd-config.5 manpage to HEAD. In > anticipation of deleting slurpd from RE24, I have commented out all of > the slurpd-related keywords. Most of the text is the same as in > slapd.conf(5) but I've changed the organization to better reflect the > actual implementation. > > There may be options that I've missed. Please review and send patches / > corrections / comments. Thank you very much for this work. I've only some comments. Even if it is shown in the Examples part, I think the use of slapd.conf and slapd.d at the same time should be explained as it is in slapd(8). Furthermore slapd-config(5) make references to slapd-bdb(5), slapd-ldap(5) and others but these pages use old config style. Maybe you could add in a first time a note to indicate that users should add olc prefix to use these directives in cn=config branch. Of course I hope every pages will be updated one day... Raphael Ouazana. PS: I'm not able to see slapd-config(5) with man.cgi on the website (even if I use OpenLDAP 2.X-Devel). Is it normal ?

1 0

(ITS#4769) conditional as macro argument may be invalid
by ando＠sys-net.it 06 Dec '06

06 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD, >= 2.3.29 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.214.117.67) There's a conditional in a macro argument in connection.c that gcc (actually, cpp) 3.4.2 doesn't like. The fix will be shortly in HEAD/re23. p.

1 0

(ITS#4768) test043-delta-syncrepl: line 55: 10507 Aborted
by michael＠stroeder.com 05 Dec '06

05 Dec '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.177.36.63) $ ./run -b bdb test043 Cleaning up test run directory leftover from previous run. Running ./scripts/test043-delta-syncrepl... running defines.sh Starting master slapd on TCP/IP port 9011... ./scripts/test043-delta-syncrepl: line 55: 10507 Aborted $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Using ldapsearch to check that master slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./scripts/test043-delta-syncrepl: line 71: kill: (10507) - No such process

1 0

Re: (ITS#4767) test034-translucent: line 369: 9807 Segmentation fault
by michael＠stroeder.com 05 Dec '06

05 Dec '06

Seems to be ok now (synced HEAD). Ciao, Michael.

1 0

(ITS#4767) test034-translucent: line 369: 9807 Segmentation fault
by michael＠stroeder.com 04 Dec '06

04 Dec '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.3.87) [..] Testing add: valid local record... Testing search: data merging... Testing compare: valid local... Testing compare: valid remote... Testing compare: bogus local... Testing compare: bogus remote... Testing modify: nonexistent record... Testing modify: valid local record, nonexistent attribute... Testing search: specific nonexistent remote attribute... Testing modify: nonexistent local record, nonexistent attribute... ./scripts/test034-translucent: line 369: 9807 Segmentation fault $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING >$LOG2 2>&1 ldapsearch failed (255)! ./scripts/test034-translucent: line 384: kill: (9807) - No such process ------------------------------------------------------------------------- last lines of testrun/slapd.2.log => bdb_entry_get: ndn: "uid=fred,ou=users,o=translucent" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("uid=fred,ou=users,o=translucent") => bdb_dn2id("uid=fred,ou=users,o=translucent") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => translucent_modify: fabricating local add => glue_parent: fabricating glue for <ou=users,o=translucent> ==> bdb_add: o=translucent bdb_dn2entry("o=translucent") send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=68 matched="" text="" ==> bdb_add: ou=users,o=translucent bdb_dn2entry("ou=users,o=translucent") send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=68 matched="" text="" ==> bdb_add: uid=fred,ou=users,o=translucent is_entry_objectclass("uid=fred,ou=users,o=translucent", "2.5.17.0") no objectClass attribute is_entry_objectclass("uid=fred,ou=users,o=translucent", "2.5.17.0") no objectClass attribute bdb_dn2entry("uid=fred,ou=users,o=translucent") => bdb_dn2id("uid=fred,ou=users,o=translucent") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => bdb_dn2id_add( "uid=fred,ou=users,o=translucent", 0x00000007 ) bdb_idl_insert_key: 7 %ou=users,o=translucent bdb_idl_insert_key: 7 @ou=users,o=translucent <= bdb_dn2id_add: 0 => index_entry_add( 7, "uid=fred,ou=users,o=translucent" ) <= index_entry_add( 7, "uid=fred,ou=users,o=translucent" ) success => entry_encode(0x00000007): uid=fred,ou=users,o=translucent bdb_add: added id=00000007 dn="uid=fred,ou=users,o=translucent" send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=103 err=0 ber_flush2: 14 bytes to sd 12

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by hyc＠symas.com 03 Dec '06

03 Dec '06

Gang Wang wrote: > Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. > You are assuming the semantics of FD_ZERO() is to "set something as > zero", but on some system it is not. For example, implement fd_set as an > array, then 0 is a valid value. FD_ZERO() have to initialize something > as -1 ... > Funny that the code treat sd_actives differently. Thanks for pointing this out, the missing initialization has been added in CVS HEAD. -- -- 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#4766) Invalid DN not detected by bindconf_parse()
by ando＠sys-net.it 02 Dec '06

02 Dec '06

ando(a)sys-net.it wrote: > I've added optional normalization code as appropriate. > Fixed in HEAD/re23. It impacts all occurrences of bindconf_parse(), including syncrepl consumer side configuration, whenever an incorrect DN value is used as binddn, or an incorrect identity is used for authcid/authzid. p.

1 0

(ITS#4766) Invalid DN not detected by bindconf_parse()
by ando＠sys-net.it 02 Dec '06

02 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando I've added optional normalization code as appropriate. p.

1 0

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by ando＠sys-net.it 02 Dec '06

02 Dec '06

Kurt(a)OpenLDAP.org wrote: > At 11:59 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: > >> ------=_Part_1103_3773705.1164959961858 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline >> >> oh, not compiler. but at runtime the daemon will output this during >> initialization: >> ... >> slap_schema_load: AttributeType "ditStructureRules": not defined in schema >> ... >> I tested this on some mainframe. case difference does matter. when i changed >> the case, it ran ok. >> > > Seems like strcasecmp(3) routines are not ignoring case as they should. > I've made the case of those strings conform to how they're indicated in the related RFC, although attribute names MUST be case insensitive. This solves your problem in the short term, but you should really look at that strcasecmp(3) issue. p.

1 0

OpenLDAP crash on write operation with syncprov overlay enabled
by Alexandre Biancalana 01 Dec '06

01 Dec '06

Hi list, I'm migration an OpenLDAP server from Debian linux to FreeBSD 6-STABLE. I exported the database from old server with slapcat and impoted at Free without any problems. But when I enable syncprov overlay and do any write operation (ie.: ldapmodify) on the base the OpenLDAP crash with signal 11. I tested with FreeBSD 6-STABLE (cvsuped sources yesterday), FreeBSD 5-STABLE (cvsuped one month ago) with OpenLDAP 2.3 and 2.4 installed through ports and packages, on diferent machines PIII SMP, Semprom UP, Centrino UP, P4 UP. The problem just ocurs when the syncprov overlay is enabled. Trying to debug this I run slapd through gdb: Pink:/usr/local/etc/openldap # gdb /usr/local/libexec/slapd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) run -u ldap -g ldap -d 1 Starting program: /usr/local/libexec/slapd -u ldap -g ldap -d 1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...@(#) $OpenLDAP: slapd 2.3.30 (Nov 30 2006 11:44:46) $ .(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...@(#) $OpenLDAP: slapd 2.3.30 (Nov 30 2006 11:44:46) $ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 3 (LWP 100229)] 0x0807f954 in fe_op_abandon () (gdb) bt #0 0x0807f954 in fe_op_abandon () #1 0x0807f957 in fe_op_abandon () #2 0x0807f957 in fe_op_abandon () #3 0x0807f957 in fe_op_abandon () #4 0x0807f957 in fe_op_abandon () #5 0x0807f957 in fe_op_abandon () #6 0x0807f957 in fe_op_abandon () #7 0x0807f957 in fe_op_abandon () #8 0x0807f957 in fe_op_abandon () #9 0x0807f957 in fe_op_abandon () #10 0x0807f957 in fe_op_abandon () #11 0x0807f957 in fe_op_abandon () #12 0x0807f957 in fe_op_abandon () #13 0x0807f957 in fe_op_abandon () #14 0x0807f957 in fe_op_abandon () #15 0x0807f957 in fe_op_abandon () #16 0x0807f957 in fe_op_abandon () #17 0x0807f957 in fe_op_abandon () #18 0x0807f957 in fe_op_abandon () #19 0x0807f957 in fe_op_abandon () #20 0x0807f957 in fe_op_abandon () #21 0x0807f957 in fe_op_abandon () #22 0x0807f957 in fe_op_abandon () #23 0x0807f957 in fe_op_abandon () #24 0x0807f957 in fe_op_abandon () #25 0x0807f957 in fe_op_abandon () #26 0x0807f957 in fe_op_abandon () #27 0x0807f957 in fe_op_abandon () #28 0x0807f957 in fe_op_abandon () .... #29406 0x0807f957 in fe_op_abandon () #29407 0x0807f957 in fe_op_abandon () #29408 0x0807f957 in fe_op_abandon () ^^^^^^^^^ ---> This look's like never end..... Follow my slapd.conf: ============================ include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/samba.schema loglevel 1 8 16 256 512 16384 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/local/libexec/openldap moduleload back_hdb sizelimit unlimited overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 200 access to dn.base="" by self write by * auth access to attrs=userPassword by self write by * auth access to attrs=shadowLastChange by self write by * read access to * by * read by anonymous auth database hdb suffix "dc=company,dc=com" rootdn "cn=root,dc=company,dc=com" rootpw my_secret_password directory /var/db/openldap-data index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub index entryCSN eq index entryUUID eq I'm very pleased to someone that could help me to figure out where is the problem.... Best Regards, Alexandre Biancalana

2 2

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by Kurt＠OpenLDAP.org 01 Dec '06

01 Dec '06

At 11:59 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: >------=_Part_1103_3773705.1164959961858 >Content-Type: text/plain; charset=ISO-8859-1; format=flowed >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >oh, not compiler. but at runtime the daemon will output this during >initialization: >... >slap_schema_load: AttributeType "ditStructureRules": not defined in schema >... >I tested this on some mainframe. case difference does matter. when i changed >the case, it ran ok. Seems like strcasecmp(3) routines are not ignoring case as they should. >On 12/1/06, Kurt D. Zeilenga <Kurt(a)openldap.org> wrote: >> >> At 10:32 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: >> >Full_Name: Gang Wang >> >Version: 2.3.20 >> >OS: >> >URL: ftp://ftp.openldap.org/incoming/ >> >Submission from: (NULL) (202.108.130.138) >> > >> > >> >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 >> > >> > "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " >> > { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " >> > { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " >> > >> >there are some "dIT" in the strings instead of "dit". is it some kind of >> typo >> >error? I'm porting this version to some operating system. the compiler >> complains >> >... >> >> About the case difference in these strings? I doubt that. >> >> Kurt >> >> > >------=_Part_1103_3773705.1164959961858 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >oh, not compiler. but at runtime the daemon will output this during initialization: ... slap_schema_load: AttributeType "ditStructureRules": not defined in schema ... I tested this on some mainframe. case difference does matter. when i changed the case, it ran ok. > <div>On 12/1/06, Kurt D. Zeilenga <<a href="mailto:Kurt@openldap.org">Kurt(a)openldap.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> >At 10:32 PM 11/30/2006, <a href="mailto:wanggang.wang@gmail.com">wanggang.wang(a)gmail.com</a> wrote: >Full_Name: Gang Wang >Version: 2.3.20 >OS: >URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/ ></a> >Submission from: (NULL) (<a href="http://202.108.130.138">202.108.130.138</a>) > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > >        "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " > >        { "ditStructureRules", "( <a href="http://2.5.21.1">2.5.21.1</a> NAME 'dITStructureRules' " >        { "ditContentRules", "( <a href="http://2.5.21.2">2.5.21.2</a> NAME 'dITContentRules' " > > >there are some "dIT" in the strings instead of "dit". is it some kind of typo >error?  I'm porting this version to some operating system. the compiler complains >... >About the case difference in these strings?  I doubt that. Kurt </blockquote></div> > >------=_Part_1103_3773705.1164959961858--

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by hyc＠symas.com 01 Dec '06

01 Dec '06

Gang Wang wrote: > Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. > You are assuming the semantics of FD_ZERO() is to "set something as > zero", but on some system it is not. For example, implement fd_set as an > array, then 0 is a valid value. FD_ZERO() have to initialize something > as -1 ... > Funny that the code treat sd_actives differently. That's a different question than you asked at first. > BTW, I know C spec well. Then you should know your original question has no dependency on the compiler being used. Rather than waste people's time, you should ask your actual question at the outset, not some meaningless one. > > On 12/1/06, *Howard Chu* <hyc(a)symas.com <mailto:hyc@symas.com>> wrote: > > wanggang.wang(a)gmail.com <mailto:wanggang.wang@gmail.com> wrote: > > Full_Name: Gang Wang > > Version: 2.3.20 > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) ( 202.108.130.138 <http://202.108.130.138>) > > > > > > openldap-2.3.20/servers/slapd/daemon.c > > > > There is one declaration in slap_daemon structure: > > > > fd_set sd_actives; > > > > this variable is not initialized ... is this OK with all compilers? -- -- 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#4765) sd_actives in daemon.c not initialized?
by wanggang.wang＠gmail.com 01 Dec '06

01 Dec '06

------=_Part_1433_15850837.1164961653601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. You are assuming the semantics of FD_ZERO() is to "set something as zero", but on some system it is not. For example, implement fd_set as an array, then 0 is a valid value. FD_ZERO() have to initialize something as -1 ... Funny that the code treat sd_actives differently. BTW, I know C spec well. On 12/1/06, Howard Chu <hyc(a)symas.com> wrote: > > wanggang.wang(a)gmail.com wrote: > > Full_Name: Gang Wang > > Version: 2.3.20 > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (202.108.130.138) > > > > > > openldap-2.3.20/servers/slapd/daemon.c > > > > There is one declaration in slap_daemon structure: > > > > fd_set sd_actives; > > > > this variable is not initialized ... is this OK with all compilers? > > It is a basic part of the C language specification - variables declared > at file scope are implicitly initialized to zero. Perhaps you need to > study the language a bit more before trying to do any more work in 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/ > ------=_Part_1433_15850837.1164961653601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. You are assuming the semantics of FD_ZERO() is to "set something as zero", but on some system it is not. For example, implement fd_set as an array, then 0 is a valid value. FD_ZERO() have to initialize something as -1 ... Funny that the code treat sd_actives differently. BTW, I know C spec well. <div>On 12/1/06, Howard Chu <<a href="mailto:hyc@symas.com">hyc(a)symas.com </a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="mailto:wanggang.wang@gmail.com">wanggang.wang(a)gmail.com</a> wrote: > Full_Name: Gang Wang > Version: 2.3.20 > OS: > URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (<a href="http://202.108.130.138"> 202.108.130.138</a>) > > > openldap-2.3.20/servers/slapd/daemon.c > > There is one declaration in slap_daemon structure: > >     fd_set sd_actives; > > this variable is not initialized ... is this OK with all compilers? It is a basic part of the C language specification - variables declared at file scope are implicitly initialized to zero. Perhaps you need to study the language a bit more before trying to do any more work in it. --    -- Howard Chu    Chief Architect, Symas Corp.  <a href="http://www.symas.com">http://www.symas.com</a>    Director, Highland Sun        <a href="http://highlandsun.com/hyc">http://highlandsun.com/hyc </a>    OpenLDAP Core Team            <a href="http://www.openldap.org/project/">http://www.openldap.org/project/</a> </blockquote></div> ------=_Part_1433_15850837.1164961653601--

1 0

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by wanggang.wang＠gmail.com 01 Dec '06

01 Dec '06

------=_Part_1103_3773705.1164959961858 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline oh, not compiler. but at runtime the daemon will output this during initialization: ... slap_schema_load: AttributeType "ditStructureRules": not defined in schema ... I tested this on some mainframe. case difference does matter. when i changed the case, it ran ok. On 12/1/06, Kurt D. Zeilenga <Kurt(a)openldap.org> wrote: > > At 10:32 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: > >Full_Name: Gang Wang > >Version: 2.3.20 > >OS: > >URL: ftp://ftp.openldap.org/incoming/ > >Submission from: (NULL) (202.108.130.138) > > > > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > > > > "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " > > { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " > > { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " > > > >there are some "dIT" in the strings instead of "dit". is it some kind of > typo > >error? I'm porting this version to some operating system. the compiler > complains > >... > > About the case difference in these strings? I doubt that. > > Kurt > > ------=_Part_1103_3773705.1164959961858 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline oh, not compiler. but at runtime the daemon will output this during initialization: ... slap_schema_load: AttributeType "ditStructureRules": not defined in schema ... I tested this on some mainframe. case difference does matter. when i changed the case, it ran ok. <div>On 12/1/06, Kurt D. Zeilenga <<a href="mailto:Kurt@openldap.org">Kurt(a)openldap.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> At 10:32 PM 11/30/2006, <a href="mailto:wanggang.wang@gmail.com">wanggang.wang(a)gmail.com</a> wrote: >Full_Name: Gang Wang >Version: 2.3.20 >OS: >URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/ </a> >Submission from: (NULL) (<a href="http://202.108.130.138">202.108.130.138</a>) > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > >        "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " >        { "ditStructureRules", "( <a href="http://2.5.21.1">2.5.21.1</a> NAME 'dITStructureRules' " >        { "ditContentRules", "( <a href="http://2.5.21.2">2.5.21.2</a> NAME 'dITContentRules' " > >there are some "dIT" in the strings instead of "dit". is it some kind of typo >error?  I'm porting this version to some operating system. the compiler complains >... About the case difference in these strings?  I doubt that. Kurt </blockquote></div> ------=_Part_1103_3773705.1164959961858--

1 0

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by Kurt＠OpenLDAP.org 01 Dec '06

01 Dec '06

At 10:32 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: >Full_Name: Gang Wang >Version: 2.3.20 >OS: >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (202.108.130.138) > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > > "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " > { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " > { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " > >there are some "dIT" in the strings instead of "dit". is it some kind of typo >error? I'm porting this version to some operating system. the compiler complains >... About the case difference in these strings? I doubt that. Kurt

1 0

Re: (ITS#4763) slapd crashed with ldapsearch command without arguments
by hyc＠symas.com 01 Dec '06

01 Dec '06

Since it appears that you're using BerkeleyDB 4.5 which is not the default version installed on your platform, most likely you have conflicting libdb libraries loaded. If you're using the default libsasl2, then this is certainly the problem. You can find out for sure by running slapd under gdb. When it crashes use the command "info shared" to see what shared libraries are present. If you see two different versions of libdb, that's your problem. You'll need to rebuild whatever other libraries are using the other libdb version and get everything onto the same version. At any rate, I don't believe there's any bug in OpenLDAP software here. This ITS will be closed. saint.cn(a)gmail.com wrote: > Full_Name: Jack Chen > Version: 2.3.27 > OS: Redhat AS 3.0 2.4.21-40.ELsmp > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.12.9.18) > > > I found when I run ldap commands without arguments always get password imput > requirement before result. But the command always told me > "ldap_sasl_interactive_bind_s: Can't contact LDAP server". Then I found the > slapd crashed. > > Then I start slpad with command like "slpad -d 256" with root account and want > to get debug information before slpad crash. > > Then following is the startup information: > ===================================================================== > @(#) $OpenLDAP: slapd 2.3.27 (Sep 30 2006 16:10:17) $ > root@caivs:/home/jack/tools/openldap-2.3.27/servers/slapd > daemon: IPv6 socket() failed errno=97 (Address family not supported by > protocol) > bdb_db_open: unclean shutdown detected; attempting recovery. > bdb_db_open: Warning - No DB_CONFIG file found in directory > /usr/local/openldap/var/openldap-data: (2) > Expect poor performance for suffix dc=test,dc=com. > slapd starting > ===================================================================== > > And when I input command "ldapsearch" in shell with root account, and input > password with any words and return. The command tell me like following: > ===================================================================== > /usr/local/BerkeleyDB.4.5/bin:$ldapsearch > SASL/DIGEST-MD5 authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Can't contact LDAP server > ===================================================================== > > And I check the console which is running slapd, and get following information: > ===================================================================== > conn=0 fd=10 ACCEPT from IP=127.0.0.1:33518 (IP=0.0.0.0:389) > conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" > conn=0 op=0 SRCH attr=supportedSASLMechanisms > conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= > conn=0 op=1 BIND dn="" method=163 > conn=0 op=1 RESULT tag=97 err=14 text= > conn=0 op=2 BIND dn="" method=163 > /etc/sasldb2: Successful return: 0 > segment fault (core dumped) > ===================================================================== -- -- 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#4765) sd_actives in daemon.c not initialized?
by hyc＠symas.com 01 Dec '06

01 Dec '06

wanggang.wang(a)gmail.com wrote: > Full_Name: Gang Wang > Version: 2.3.20 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.108.130.138) > > > openldap-2.3.20/servers/slapd/daemon.c > > There is one declaration in slap_daemon structure: > > fd_set sd_actives; > > this variable is not initialized ... is this OK with all compilers? It is a basic part of the C language specification - variables declared at file scope are implicitly initialized to zero. Perhaps you need to study the language a bit more before trying to do any more work in 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

(ITS#4765) sd_actives in daemon.c not initialized?
by wanggang.wang＠gmail.com 01 Dec '06

01 Dec '06

Full_Name: Gang Wang Version: 2.3.20 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.108.130.138) openldap-2.3.20/servers/slapd/daemon.c There is one declaration in slap_daemon structure: fd_set sd_actives; this variable is not initialized ... is this OK with all compilers?

1 0

(ITS#4764) ditStructureRules/dITStructureRules typo error?
by wanggang.wang＠gmail.com 01 Dec '06

01 Dec '06

Full_Name: Gang Wang Version: 2.3.20 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.108.130.138) openldap-2.3.20/servers/slapd/schema_prep.c Line 370 "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " there are some "dIT" in the strings instead of "dit". is it some kind of typo error? I'm porting this version to some operating system. the compiler complains ...

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs