openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5235) ppolicy leads to segfault
by quanah＠zimbra.com 20 Nov '07

20 Nov '07

--On November 15, 2007 9:22:41 PM +0000 dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.231.219) Dieter, Can you confirm one way or the other if the fix in HEAD from Pierangelo solved your issue? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5238) test050-syncrepl-multimaster only tests with 2 slapd instances
by ghenry＠suretecsystems.com 20 Nov '07

20 Nov '07

<quote who="richton(a)nbcs.rutgers.edu"> > HEAD test050 succeeds, Fedora 8, x86_64. Just tested again. Same here on both platforms.

1 0

Re: (ITS#5238) test050-syncrepl-multimaster only tests with 2 slapd instances
by richton＠nbcs.rutgers.edu 20 Nov '07

20 Nov '07

HEAD test050 succeeds, Fedora 8, x86_64.

1 0

(ITS#5238) test050-syncrepl-multimaster only tests with 2 slapd instances
by ghenry＠OpenLDAP.org 20 Nov '07

20 Nov '07

Full_Name: Gavin Henry Version: HEAD OS: FC8 - i386/x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry All, test050-syncrepl-multimaster only tested MMR with 2 instances of slapd. I extended the test case to use 3 instances. 3rd kept crashing. Howard has fixed in HEAD. Thanks, Gavin.

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by hyc＠symas.com 20 Nov '07

20 Nov '07

Dan.Oscarsson(a)tietoenator.com wrote: > If this looks correct to you, what code should I add to fix it? > It would be better if one of you who knows the code better than me could > do that. I can test and see if it works. > > I hope this is the only place in cache handling of an entries children, > though maybe someone with better knowledge on the code can identify > others. > > Hope this is the bug as I have used many days to trace it down and need > to do some normal work for my company. Thanks for your investigation; this explanation makes sense. You can test this simply by disabling the statement in bdb_cache_modrdn() which sets the NO_KIDS flags: Index: cache.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v retrieving revision 1.157 diff -u -r1.157 cache.c --- cache.c 12 Nov 2007 10:41:45 -0000 1.157 +++ cache.c 20 Nov 2007 15:09:29 -0000 @@ -1148,8 +1148,10 @@ free( ei->bei_nrdn.bv_val ); ber_dupbv( &ei->bei_nrdn, nrdn ); +#if 0 if ( !pei->bei_kids ) pei->bei_state |= CACHE_ENTRY_NO_KIDS | CACHE_ENTRY_NO_GRANDKIDS; +#endif #ifdef BDB_HIER free( ei->bei_rdn.bv_val ); Please try that and report your results. I don't think this is the best fix, but if it helps your test then we can refine it from there. -- -- 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#5221) cache? of parent failes for hdb
by Dan.Oscarsson＠tietoenator.com 20 Nov '07

20 Nov '07

mån 2007-11-12 klockan 15:15 -0800 skrev Quanah Gibson-Mount: > --On Monday, November 12, 2007 7:02 AM +0000 hyc(a)symas.com wrote: > > > > This isn't a lot of information to go on. If you can create a test > > program that shows the problem occurring, using dummy data, that would > > help. -- > > Also, Just some general data on what it is you are doing that is a bit more > explanative. I have now done several days of testing and think I have tracked what is wrong. All my tests have been done in 2.3.38. What my program going to do is: move one person from one branch to an other one. It does the following (in a simplified way): 1) search for the person entry using base o=xxx and filter uid=yyyy 2) does a modrdn from cn=qqq+uid=yyy,a=aaaa,b=bbbb,c=cccc,o=xxx to cn=qqq+uid=yyy,d=dddd,e=eeee,c=cccc,o=xxx I do this now on a newly started ldap server (that is cache have not been filled). This is a special case that I found triggered what is probably the bug I got previously but then the server may have been running for a long time. My analysis from all my debug prints indicate that: during 1) above the person entry is located and hdb_cache_find_parent is called which calls hdb_dn2id_parent to find the way to the root. From what I can see this constructs cache entries with one kid entry in bei_kids. It does not load all kids of each entry found along the path to root. Next in 2) modrdn is called and bdb_cache_modrdn. This removes the person entry from the a=aaaa entry. As the a=aaaa entry was cached during 1) with just setting one child instead of loading all from disk, that entry now has no children (bei_kids is NULL) so the state is set to CACHE_ENTRY_NO_KIDS. If I after this does a search with base c=cccc,o=xxx the hdb_dn2idl routine will not find all entries as the cached entry of a=aaaa,b=bbbb,c=cccc,o=xxx in hdb_dn2idl_internal has state CACHE_ENTRY_NO_KIDS and is ignored. If modrdn is step 2) before deleting the entry from its parents list of kids, had loaded all kids from disk, is should have worked. So the problem is, it my analysis is correct, is that sometimes cache entries are created which have not loaded the children from disk and then an other cache routine change the number of children in the cache without first loading the correct number of children from disk. If this looks correct to you, what code should I add to fix it? It would be better if one of you who knows the code better than me could do that. I can test and see if it works. I hope this is the only place in cache handling of an entries children, though maybe someone with better knowledge on the code can identify others. Hope this is the bug as I have used many days to trace it down and need to do some normal work for my company. Regards, Dan -- Dan Oscarsson TietoEnator Email: Dan.Oscarsson(a)tietoenator.com Box 85 201 20 Malmo, Sweden

1 0

Re: (ITS#5235) ppolicy leads to segfault
by ando＠sys-net.it 19 Nov '07

19 Nov '07

Dieter Kluenter wrote: > | #0 0xb7ac6139 in free () from /lib/libc.so.6 > | #1 0xb7f2028a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 > | #2 0x0809b1f2 in ch_free (ptr=0x2009) at ch_malloc.c:139 > | #3 0xb775358c in ppolicy_restrict (op=0xa2253d54, rs=0xa2254148) > | at ppolicy.c:1245 > | #4 0x080f0c5a in overlay_op_walk (op=0xa2253d54, rs=0xa2254148, > | which=op_search, oi=0x829d5d8, on=0x82a1190) at backover.c:642 > | #5 0x080f0e91 in over_op_func (op=0xa2253d54, rs=0xa2254148, which=op_search) > | at backover.c:704 > | #6 0x080f0f15 in over_op_search (op=0xa2253d54, rs=0xa2254148) > | at backover.c:726 > | #7 0xb773f893 in dds_expire (ctx=0xa2254238, di=0x82a4898) at dds.c:181 > | #8 0xb773fe4f in dds_expire_fn (ctx=0xa2254238, arg=0x829cc48) at dds.c:260 > | #9 0xb7f334d2 in ldap_int_thread_pool_wrapper (xpool=0x82507b0) at tpool.c:625 > | #10 0xb7d4f192 in start_thread () from /lib/libpthread.so.0 > | #11 0xb7b2102e in clone () from /lib/libc.so.6 > `---- > > ,----[ frame ] > | (gdb) frame 3 > | #3 0xb775358c in ppolicy_restrict (op=0xa2253d54, rs=0xa2254148) > | at ppolicy.c:1245 > | 1245 ch_free( pwcons[op->o_conn->c_conn_idx].dn.bv_val ); I assume op->o_conn->c_conn == -1 here, since this is an internal operation. As such, it shouldn't affect slapo-ppolicy(5). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5237) Possible documentation error in admin guide
by hyc＠symas.com 18 Nov '07

18 Nov '07

kara(a)karamcnair.com wrote: > Full_Name: Kara McNair > Version: 2.3.27 > OS: OS 10.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.80.228.143) > > > Hi there, > > I'm reading through your admin guide & on page: > http://www.openldap.org/doc/admin24/slapdconfig.html > the last line of section 6.3.2 looks to me like it might have an error in it? > > The text says: > "Some factors may not be appropriate in all environments (or any). For example, > the domain factor relies on IP to domain name lookups. As these can easily > spoofed, the domain factor should _*not*_ be avoided." > > The way it's phrased, I would have expected the final sentence to read: > "As these can easily spoofed, the domain factor should be avoided." > > (the 'not' appears to be at odds with the 'avoided') > > (also, I think there's a 'be' missing between 'easily' and 'spoofed'). > > Thanks very much for your excellent software and very thorough and helpful > documentation! Thanks for the bug report, this is now fixed in CVS. Note that you reported version 2.3.27 on your bug report; it's not a good idea to use docs that don't match the version of software you're using. I suggest you upgrade to 2.3.39 at least and use the docs bundled in that release, or switch to 2.4.6. -- -- 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#5235) ppolicy leads to segfault
by hyc＠symas.com 18 Nov '07

18 Nov '07

ando(a)sys-net.it wrote: > dieter(a)dkluenter.de wrote: > >> (gdb) bt >> #0 0xb7a67139 in free () from /lib/libc.so.6 >> #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 >> #2 0x0808f556 in ch_free () >> #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) >> at ppolicy.c:1245 > > I suspect this free occurs an internal operation initiated with > connection_fake_init(); can you check, from the core, if the value of > op->o_conn->c_conn_idx is -1? If that's the real problem, the better fix would be just to make ppolicy ignore fake connections. Certainly internal operations can never be restricted. -- -- 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#5237) Possible documentation error in admin guide
by kara＠karamcnair.com 18 Nov '07

18 Nov '07

Full_Name: Kara McNair Version: 2.3.27 OS: OS 10.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.80.228.143) Hi there, I'm reading through your admin guide & on page: http://www.openldap.org/doc/admin24/slapdconfig.html the last line of section 6.3.2 looks to me like it might have an error in it? The text says: "Some factors may not be appropriate in all environments (or any). For example, the domain factor relies on IP to domain name lookups. As these can easily spoofed, the domain factor should _*not*_ be avoided." The way it's phrased, I would have expected the final sentence to read: "As these can easily spoofed, the domain factor should be avoided." (the 'not' appears to be at odds with the 'avoided') (also, I think there's a 'be' missing between 'easily' and 'spoofed'). Thanks very much for your excellent software and very thorough and helpful documentation! Kara

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