- openldap-bugs - openldap.org

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 25 Apr '09

25 Apr '09

This is a multi-part message in MIME format. --------------080405020304060402030808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Fixing this for unique_add seams easy enough (see preliminary attached patch) - fixing it for modrdn/modify seems to be another difficulty level as in order to properly apply the filter I think the full modifications have to be applied... If wanted I can produce a patch for this as well, but I would like to know if that is appreciated and if my plan for fixing looks sensible: - Pull the "modification simulation" code out of constraint.c (line 959:1040 and some more in 2.4.16) into constraints.c - Add a overlay-int.h - Make constraint.c and unique.c use that As I dont really know the openldap codebase my analysis could be completely wrong - I would appreciate some feedback. Andres --------------080405020304060402030808 Content-Type: text/x-diff; name="slapd-unique-overlay-spurious-failure-fix-add.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-unique-overlay-spurious-failure-fix-add.patch" --- openldap-2.4.16.saved/servers/slapd/overlays/unique.c 2009-04-23 23:51:37.925387747 +0200 +++ openldap-2.4.16/servers/slapd/overlays/unique.c 2009-04-26 01:58:54.566927667 +0200 @@ -1071,6 +1071,24 @@ && !dnIsSuffix( &op->o_req_ndn, &uri->ndn )) continue; + if (uri->filter.bv_val && uri->filter.bv_len){ + Filter *f = str2filter_x(op, + uri->filter.bv_val); + if(f == NULL) { + op->o_bd->bd_info = (BackendInfo *) on->on_info; + send_ldap_error(op, rs, LDAP_OTHER, + "unique_search invalid filter"); + return(rs->sr_err); + } + + if(test_filter(NULL, op->ora_e, f) == LDAP_COMPARE_FALSE){ + Debug(LDAP_DEBUG_TRACE, "==> unique_add_skip<%s>\n", + op->o_req_dn.bv_val, 0, 0); + continue; + } + filter_free_x(op, f, 1); + } + if(!(a = op->ora_e->e_attrs)) { op->o_bd->bd_info = (BackendInfo *) on->on_info; send_ldap_error(op, rs, LDAP_INVALID_SYNTAX, --------------080405020304060402030808--

1 0

Re: (ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by daniel＠pluta.biz 25 Apr '09

25 Apr '09

Hallvard B Furuseth schrieb: > Yes, the on-th-fly sorting combined with the delete-single-value > code seems broken. I'm not sure if delete-single-value could ever > be invoked Of course could it be "invoked" before: just use slapd 2.4.16 together with slapo-collect and your favorit ldapmodify client. Right after the "invocation" you'll get an error message complaining about a missing equality rule. Thus there's no hint within collect's source that the single-value delete is faulty I inserted an equality rule and began to wonder... > before you inserted an EQUALITY matching rule though. Do you mean the single-value-delete functionality has been silently "disabled" by removing the EQUALITY matching rule leaving slapo-collect's by design defective single-value-delete code block knowingly unchanged/uncommented? This seems very strange to me even more because slapo-collect is advertises as demonstration overlay (ok, a "quick hacked" one but nevertheless questionable). > I too don't know cn=config all that well:-( <speculation> Instead of correcting handling this issue only in collect.c there perhabs exists a more general possibility to pimp the cn=config internal add mechanisms regarding the handling of ordered config values? In my opinion a very important feature concerning "overlapping"... Á la: cfg_value_add(.., .., SLAPD_CFG_VALSORT_ALPHA|SLAPD_CFG_VALSORT_DN|..) only problem seems to be how to sort a configuration value like: '"ou=test,dc=foo,dc=bar" l,st' by DN's depth </speculation>

1 0

(ITS#5535) smbk5pwd uses private heimdal functions
by admin＠dmarkey.com 24 Apr '09

24 Apr '09

--000e0cd1e8fc2040e9046856eee5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review http://dmarkey.com/~dmarkey/smbk5pwd.patch to fix this. Against 2.4.16 smbk5pwd. --000e0cd1e8fc2040e9046856eee5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review <a href="http://dmarkey.com/~dmarkey/smbk5pwd.patch">http://dmarkey.com/~dmarkey/smbk5pwd.patch</a> to fix this. Against 2.4.16 smbk5pwd. --000e0cd1e8fc2040e9046856eee5--

1 0

(ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 24 Apr '09

24 Apr '09

Full_Name: Andres Freund Version: 2.4.16 OS: Linux URL: Submission from: (NULL) (85.178.193.10) If I read the code correctly the unique overlay does not check if the current operation matches the filter of a domain before doing a uniqeness check. This leads to wrongly reported errors. I noticed this after adding a uniqueness constraint on gidNumber on all posixGroup objects (i.e. ldap:///?gidNumber?sub?(objectClass=posixGroup)) - it was not possible anymore to add posixAccounts with that gidNumber. Thanks, Andres Here a modification of the testscript to reproduce the issue: --- openldap-2.4.16.saved/tests/scripts/test024-unique 2009-04-23 23:51:37.942051631 +0200 +++ openldap-2.4.16/tests/scripts/test024-unique 2009-04-25 02:50:40.975257488 +0200 @@ -425,6 +425,7 @@ changetype: modify add: olcUniqueURI olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) - delete: olcUniqueURI olcUniqueURI: ldap:///?description?one @@ -445,6 +446,7 @@ olcOverlay: {0}unique olcUniqueURI: ldap:///?employeeNumber,displayName?sub olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) EOF diff $TESTDIR/third-config.ldif $TESTDIR/third-reference.ldif > /dev/null 2>&1 @@ -473,6 +475,27 @@ exit -1 fi + +echo "Adding a record unique in all domains because of filter conditions " + +$LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \ + $TESTOUT 2>&1 << EOF +dn: uid=empty,ou=users,o=unique +objectClass: inetOrgPerson +uid: edgar +cn: empty +sn: empty +EOF + +RC=$? +if test $RC != 0 ; then + echo "spurious unique error ($RC)!" + test $KILLSERVERS != no && kill -HUP $KILLPIDS + exit -1 +fi + + + echo "Adding a record unique in one domain, non-unique in the filtered domain..." $LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \

1 0

Re: (ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

Yes, the on-th-fly sorting combined with the delete-single-value code seems broken. I'm not sure if delete-single-value could ever be invoked before you inserted an EQUALITY matching rule though. I too don't know cn=config all that well:-( -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

oops, lost a few words: I wrote: > I'll fix that and a few other comments and close this ITS, > since you've clarified issue here in ITS#6076. Since you've clarified _the other_ issue here in ITS#6076. -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

Daniel Pluta writes: > cite: "... this means longer dn's (i.e. more specific dn's) will be > found first when searching..." > > But, longer DNs do not neccessarily are more specific: > > ou=openldap,o=rockz,c=it > dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific) It's just the comment which is unclear. It should be saying that sorting normalized DNs by reverse length ensures that a DN is stored after any of its subordinate DNs. I'll fix that and a few other comments and close this ITS, since you've clarified issue here in ITS#6076. -- Hallvard

1 0

(ITS#6076)
by Daniel.Pluta＠lrz.de 24 Apr '09

24 Apr '09

sorry, there's a small cut&paste error regarding step 12.) Please ignore the first 4 lines. Only the last two lines contain the corresponding output regarding step 11.) Thanks!

1 0

(ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by daniel＠pluta.biz 24 Apr '09

24 Apr '09

Full_Name: Daniel Pluta Version: OPENLDAP_STABLE OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090424.patch Submission from: (NULL) (2001:4ca0:0:f000:ecb9:edd3:5b88:63f0) As already assumed in (ITS6072 FollowUp 5) there seems to be a bug regarding the mapping of c->valx and the to-be-deleted value of the ci->ci_next list. The origin seems to be the on-the-fly manipulation (sorting) of the ci-list that is done by insert_ordered()) whenever a new config value is added... To illustrate the problem in detail I've added some debugging output into collect.c's LDAP_MOD_DELETE-section: case LDAP_MOD_DELETE: if ( c->valx == -1 ) { /* Delete entire attribute */ collect_info *ci; while (( ci = on->on_bi.bi_private )) { on->on_bi.bi_private = ci->ci_next; ch_free( ci->ci_dn.bv_val ); ch_free( ci ); } } else { /* Delete just one value */ collect_info **cip, *ci; int i; cip = (collect_info **)&on->on_bi.bi_private; Debug(LDAP_DEBUG_TRACE, "collect_cf: LDAP_MOD_DELETE: c->valx=%d\n", c->valx, 0, 0); for ( i=0; i <= c->valx; i++, cip = &ci->ci_next ) { ci = *cip; Debug(LDAP_DEBUG_TRACE, "collect_cf: LDAP_MOD_DELETE: i=%d <--> dn=%s\n", i, ci->ci_dn.bv_val, 0); } *cip = ci->ci_next; Debug(LDAP_DEBUG_TRACE, "collect_cf: free: dn=%s\n", ci->ci_dn.bv_val, 0, 0); ch_free( ci->ci_dn.bv_val ); ch_free( ci ); } The patch against OPENLDAP_STABLE could be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-090424.patch This patch also includes the mini-enhancement proposed in ITS6072 and the micro-bugfix provided in ITS6075. ITS6075 solves a small schema-specific bug which wrongly denied deletion of single olcCollectInfo configuration values at all. Here are my 12 steps to reproduce the crash... 1.) edit collect's configuration setup in slapd.conf by adding the following lines: overlay collect collectinfo ou=customer_A,dc=foo,dc=bar l,st collectinfo ou=customer_B,dc=foo,dc=bar l,st collectinfo ou=customer_C,dc=foo,dc=bar l,st collectinfo ou=customer_D,dc=foo,dc=bar l,st collectinfo ou=customer_E,dc=foo,dc=bar l,st collectinfo ou=customer_F,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_A,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_B,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_C,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_D,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_E,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_F,dc=foo,dc=bar l,st 2.) convert ".conf" into "cn=config" format, by running: slaptest -f ... -F ... The resulting collect cn=config ldif should be similar to: dn: olcOverlay={0}collect objectClass: olcOverlayConfig objectClass: olcCollectConfig olcOverlay: {0}collect olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_a,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_a,dc=foo,dc=bar" l,st structuralObjectClass: olcCollectConfig entryUUID: 51c7d5fa-c50a-102d-9657-f3a43e5eeda2 creatorsName: cn=config createTimestamp: 20090424105633Z entryCSN: 20090424105633.913345Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090424105633Z 3.) start slapd using the generated config (slapd -F ...) 4.) start browsing cn=config everything is fine 5.) delete the follwing olcCollectInfo Value using this ldif: dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=customer_a,dc=foo,dc=bar" l,st - 6.) examine the log based on the above patch (which delivers the following debugging output) collect_cf: LDAP_MOD_DELETE: c->valx=11 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=1 <--> dn=ou=users,ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=2 <--> dn=ou=users,ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=3 <--> dn=ou=users,ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=4 <--> dn=ou=users,ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=5 <--> dn=ou=users,ou=customer_f,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=6 <--> dn=ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=7 <--> dn=ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=8 <--> dn=ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=9 <--> dn=ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=10 <--> dn=ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=11 <--> dn=ou=customer_f,dc=foo,dc=bar collect_cf: free: dn=ou=customer_f,dc=foo,dc=bar ==> Holy sh..! ou=customer_f,dc=foo,dc=bar has been deleted, instead?!?!?! 7.) Though slapd still runs, lets ask about some more details using ldapsearch: dn: olcoverlay={0}collect,olcdatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcCollectConfig olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_a,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_b,dc=foo,dc=bar" l,st olcOverlay: {0}collect ==> Impressive! It seems to be that ou=customer_a,dc=foo,dc=bar has been deleted(?!?!) 8.) ok, once again we try to delete a value: dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st - 9.) but the logging output tells us: "customer_b" gets deleted now... collect_cf: LDAP_MOD_DELETE: c->valx=7 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=1 <--> dn=ou=users,ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=2 <--> dn=ou=users,ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=3 <--> dn=ou=users,ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=4 <--> dn=ou=users,ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=5 <--> dn=ou=users,ou=customer_f,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=6 <--> dn=ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=7 <--> dn=ou=customer_b,dc=foo,dc=bar collect_cf: free: dn=ou=customer_b,dc=foo,dc=bar 10.) analog to point 7.) ldapsearch reports "customer_e" has been deleted... 11.) so far so good, now lets try to increase our level of fun and delete another olcCollectInfo-value: #!RESULT OK #!CONNECTION ldap://10.111.1.1:3890 #!DATE 2009-04-24T11:36:18.343 dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st - 12.) slapd immediatly crashes, the logging output shows: collect_cf: LDAP_MOD_DELETE: c->valx=0 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: free: i=1 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: c->valx=6 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=(null) ==> segfault, ZONK! In my opinion it seems that the crash depends on the on-th-fly sorting of the DN-list which directly depends on the timely order the DNs have been added (processed by "insert_ordered()"). I'm not sure how to "fix" this bug providing an elegant solution because I don't understand the direct/slapd-internal mapping of i to ci->cn_next in detail (usually ldap results are unordered, perhabs something special regarding back-config?). The problem seems to be located here: for ( i=0; i <= c->valx; i++, cip = &ci->ci_next ) These were my two first thoughts regarding a possible workaround: - Always deleting and adding all values, in case one value gets modified? - Using ordered-format "{n}" seems to result in "always delete / add all values", too. I would appreciate your advice!

1 0

Re: (ITS#5382) JLDAP
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__PartF5DD40B7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Jim, We have fixed the issue . We will be checking the same . Thanks for = identifying the issue . =20 regards Arpit=20 =20 --=__PartF5DD40B7.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Jim,</DIV> <DIV>    We have fixed the issue . We will be checking the = same . Thanks for identifying the issue .</DIV> <DIV> </DIV> <DIV>regards</DIV> <DIV>Arpit </DIV> <DIV> </DIV></BODY></HTML> --=__PartF5DD40B7.0__=--

1 0

Re: (ITS#5389) Contribution: JLDAP support for password policy response control
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__Part133BA653.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Raymond , =20 This is just for my understanding . Is Password Policy response is a = standard ? What is the requirement of this particular feature to be = present in JLDAP? What is this feature and how it can be used ?=20 We can take it in if this is a standard but if this is not a standard = than we cannot take this in as this will make the code bulkier.=20 =20 regards, Arpit=20 --=__Part133BA653.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Raymond ,</DIV> <DIV> </DIV> <DIV>   This is just for my understanding . Is Password Policy = response is a standard ? What is the requirement of this particular = feature to be present in JLDAP? What is this feature and how it can be = used ? </DIV> <DIV>   We can take it in if this is a standard but if this is = not a standard than we cannot take this in as this will make the code = bulkier. </DIV> <DIV> </DIV> <DIV>regards, Arpit </DIV></BODY></HTML> --=__Part133BA653.0__=--

1 0

Re: (ITS#6071) LDAP server becomes unresponsive
by carsten.rieck＠trustcenter.de 24 Apr '09

24 Apr '09

Hello, the update to OpenLDAP 2.4.16 has solved my problem with the unresponsive server. Quanah, thank you very much for your help. From my point of view, the ITS can be closed. Best regards, Carsten -- Dr. Carsten T. Rieck Development TC TrustCenter GmbH Sonninstrasse 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40-808026-0, Fax: -126 Geschaeftsfuehrung/Managing Directors: Robert Steinkrauss , Dr. Sabine Kockskaemper , HRB 96168 Email: carsten.rieck(a)trustcenter.de www.trustcenter.de This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies.

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder schrieb: > daniel(a)pluta.biz wrote: >> I could not find a suitable api-call to determine a DN's depth. > > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: > > I guess reg ex splitting won't work for arbitrary DN strings. > > Ciao, Michael. I finaly managed to upload the patch under "incoming/collect.c.patch" Instead of using posix regexp I've used the ldap_bv2dn() based methode recommended by you. I would appreciate your revise. This patch does not include slapo-collect's schema-patch that I've filed some minutes ago (see: ITS#6075) Thanks!

1 0

(ITS#6075) slapo-collect: olcCollectInfo: no equality matching rule
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Full_Name: Daniel Pluta Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch Submission from: (NULL) (91.12.202.8) It's impossible to delete one value from the multi-valued olcCollectInfo in case there are more than 1 olcCollectInfo values configured... Error: "olcCollectInfo: no equality matching rule" I've uploaded a small patch here: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch I'm not sure whether ORDERING and SUBSTRINGMATCH are neccessary, optional or even wrong(?). Perhab's they can (have to?) be omitted - please see below... Index: ldap/servers/slapd/overlays/collect.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/collect.c,v retrieving revision 1.5.2.8 diff -u -r1.5.2.8 collect.c --- ldap/servers/slapd/overlays/collect.c 22 Jan 2009 00:01:12 -0000 1.5.2.8 +++ ldap/servers/slapd/overlays/collect.c 23 Apr 2009 20:00:02 -0000 @@ -230,6 +230,9 @@ ARG_MAGIC, collect_cf, "( OLcfgOvAt:19.1 NAME 'olcCollectInfo' " "DESC 'DN of entry and attribute to distribute' " + "EQUALITY caseIgnoreMatch " + "ORDERING caseIgnoreOrderingMatch " + "SUBSTR caseIgnoreSubstringsMatch " "SYNTAX OMsDirectoryString )", NULL, NULL }, { NULL, NULL, 0, 0, 0, ARG_IGNORED } };

1 0

Re: (ITS#6073) ftp.openldap.org "no space left on device"?
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Status update: it has been fixed - proved by me with: ftp> put daniel-pluta-090423.patch local: daniel-pluta-090423.patch remote: daniel-pluta-090423.patch 227 Entering Passive Mode (204,152,186,57,229,234) 150 Opening BINARY mode data connection for 'daniel-pluta-090423.patch'. 226 Transfer complete (unique file name:daniel-pluta-090423.patch). 735 bytes sent in 0.00 secs (413.2 kB/s) Thanks for addressing/solving this issue. Kurt Zeilenga schrieb: > This problem as been addressed. > > -- Kurt > > On Apr 22, 2009, at 7:45 AM, daniel(a)pluta.biz wrote: > >> Full_Name: Daniel Pluta >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) >> >> >> ~/build/pkg$ ftp -p 204.152.186.57 >> Connected to 204.152.186.57. >> 220- OpenLDAP FTP Service >> 220 boole.openldap.org FTP server (Version 6.00LS) ready. >> Name (204.152.186.57:d): anonymous >> 331 Guest login ok, send your email address as password. >> Password: >> 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights Reserved. >> 230- COPYING RESTRICTIONS APPLY, see: >> 230- ftp://ftp.openldap.org/COPYRIGHT >> 230- ftp://ftp.openldap.org/LICENSE >> 230 Guest login ok, access restrictions apply. >> Remote system type is UNIX. >> Using binary mode to transfer files. >> ftp> cd incoming >> 250 CWD command successful. >> ftp> put collect.c.patch >> local: collect.c.patch remote: collect.c.patch >> 227 Entering Passive Mode (204,152,186,57,240,13) >> 150 Opening BINARY mode data connection for 'collect.c.patch.3'. >> 452 Error writing to file: No space left on device. >> 1833 bytes sent in 0.00 secs (1361.2 kB/s) >> ftp> >

1 0

Re: (ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-its6074-bt.txt

1 0

(ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

Full_Name: Aaron Richton Version: 2.4.16 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Still going through the logs to see what slapd was doing at the time, but my expectation is "Nothing Particularly Exciting" -- this was under production load, I wasn't poking it with a stick or anything. URI with backtrace to follow...

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder wrote: >> I could not find a suitable api-call to determine a DN's depth. >> > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: >> > I guess reg ex splitting won't work for arbitrary DN strings. > Hi Michael, after I've had a quick look into "ldap_bv2dn()" you might be right... ;-) Before I'll try to upload the patch again (see ITS#6073) I'll update my code to include your suggestion. Many thanks for your advice! Cheers Daniel

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Hallvard B Furuseth wrote: >> DNs should be ordered accoring their in-DIT depth and not accoring their >> bv_len: >> > Does that matter, as long as (child, parent) are ordered correctly? > What is the bug you are fixing? > it's regarding the mentioned "*limited* overlapping feature" within the insert_ordered()-function's comment: cite: "... this means longer dn's (i.e. more specific dn's) will be found first when searching..." But, longer DNs do not neccessarily are more specific: ou=openldap,o=rockz,c=it dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific) BTW: the use of insert_ordered() possibly cause some kind of strange (randomized) deletion of a collect_info config attribute's value in this overlay just in the case: c->type == LDAP_MOD_DELETE combined with c->valx > 1 I've noticed this behaviour during testing of my own (chaotic-)test-overlay but had no time to investigate in deep. In my opinion the effect depends on the order of ldapadds of additional DNs and the effective resulting order produced by insert_ordered in combination with "c->valx"... I would file another ITS in case I'm sure that this impressive effect is not cause by my "chaotic" component. ;-)

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 23 Apr '09

23 Apr '09

Daniel Pluta writes: > DNs should be ordered accoring their in-DIT depth and not accoring their > bv_len: Does that matter, as long as (child, parent) are ordered correctly? What is the bug you are fixing? -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by michael＠stroeder.com 23 Apr '09

23 Apr '09

daniel(a)pluta.biz wrote: > I could not find a suitable api-call to determine a DN's depth. How about using ldap_bv2dn() and count the DN components? > So I've used > posix regexp and uploaded that quick&dirty hacked patch right here: I guess reg ex splitting won't work for arbitrary DN strings. Ciao, Michael.

1 0

Re: (ITS#6071) LDAP server becomes unresponsive
by quanah＠zimbra.com 22 Apr '09

22 Apr '09

--On Wednesday, April 22, 2009 7:20 AM +0000 rs1542(a)gmx.com wrote: > Full_Name: Carsten T. Rieck > Version: 2.4.11 > OS: RedHat 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.194.157.126) > > > Hello, > > my company runs an anonymously accessible LDAP server on openLDAP 2.4.11 > with Berkeley database 4.6.21 (all recent patches applied) and RedHat 5.1 > as operating system. Please update to OpenLDAP 2.4.16, as the connection code has been significantly reworked, and some issues with using EPOLL have been addressed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6073) ftp.openldap.org "no space left on device"?
by Kurt＠OpenLDAP.org 22 Apr '09

22 Apr '09

This problem as been addressed. -- Kurt On Apr 22, 2009, at 7:45 AM, daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) > > > ~/build/pkg$ ftp -p 204.152.186.57 > Connected to 204.152.186.57. > 220- OpenLDAP FTP Service > 220 boole.openldap.org FTP server (Version 6.00LS) ready. > Name (204.152.186.57:d): anonymous > 331 Guest login ok, send your email address as password. > Password: > 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights > Reserved. > 230- COPYING RESTRICTIONS APPLY, see: > 230- ftp://ftp.openldap.org/COPYRIGHT > 230- ftp://ftp.openldap.org/LICENSE > 230 Guest login ok, access restrictions apply. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> cd incoming > 250 CWD command successful. > ftp> put collect.c.patch > local: collect.c.patch remote: collect.c.patch > 227 Entering Passive Mode (204,152,186,57,240,13) > 150 Opening BINARY mode data connection for 'collect.c.patch.3'. > 452 Error writing to file: No space left on device. > 1833 bytes sent in 0.00 secs (1361.2 kB/s) > ftp>

1 0

(ITS#6073) ftp.openldap.org "no space left on device"?
by daniel＠pluta.biz 22 Apr '09

22 Apr '09

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) ~/build/pkg$ ftp -p 204.152.186.57 Connected to 204.152.186.57. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (204.152.186.57:d): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> put collect.c.patch local: collect.c.patch remote: collect.c.patch 227 Entering Passive Mode (204,152,186,57,240,13) 150 Opening BINARY mode data connection for 'collect.c.patch.3'. 452 Error writing to file: No space left on device. 1833 bytes sent in 0.00 secs (1361.2 kB/s) ftp>

1 0

(ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 22 Apr '09

22 Apr '09

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/collect.c.patch Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) DNs should be ordered accoring their in-DIT depth and not accoring their bv_len: 1) "ou=test_ou_long,ou=test,dc=foo,dc=bar" 2) "ou=test,ou=de,ou=test,dc=foo,dc=bar" DN1' bv_len is higher than that of DN2 but DN2 is deeper located within the DIT. I could not find a suitable api-call to determine a DN's depth. So I've used posix regexp and uploaded that quick&dirty hacked patch right here: ftp://ftp.openldap.org/incoming/collect.c.patch Sorry, next time I'll respect the upload naming conventions that I've noticed a bit to late...

1 0

Re: (ITS#6051) JLDAP SASL issue
by rarpit＠novell.com 22 Apr '09

22 Apr '09

--=__Part654DCF55.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Hendrik, From Novell I am the one responsible for Jldap . Our product eDirectory = does not support CRAM authentication. So this functionality is missing . I do not know how to test it ? Can we test it against openldap server ? = =20 You were talking about some test suite in the bug . What is that test = suite ? Please if I can get that test suite I can test it . =20 regards and thanks=20 Arpit=20 >>> <hendrik.saly(a)gmx.de> 4/10/2009 2:19 PM >>> Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: Linux 2.6, Sun JDK 1.5 URL: http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/n= ovell/ldap/SaslLDAPConnection.java Submission from: (NULL) (78.43.136.21) While trying to use SASL with JLDAP i encounter a potential minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v 1.154 2006/02/09= 08:43:45 sunilk Exp $ Seems the bind method on line 1730 fails to release the bind semaphore = properly under some circumstances. I tried to use more than the wit JLDAP provided = SASL mechanisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with = a Java 1.5 sasl client. All works very well but CRAM login for example fails. I = have a workaround http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/ja= va/com/novell/ldap/SaslLDAPConnection.java but i thinks there are some problems with the bind semaphore. The wrapping code is here http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/org/mule/t= ransport/ldap/sasl/ClientFactory.java If neccessary i can provide a test suite for this. Thanks Hendrik --=__Part654DCF55.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Hendrik,</DIV> <DIV>   From Novell I am the one responsible for Jldap . Our = product eDirectory does not support CRAM authentication. So this functional= ity is missing .</DIV> <DIV>   I do not know how to test it ? Can we test it = against openldap server ?  </DIV> <DIV>  You were talking about some test suite in the bug . What is = that test suite ? Please if I can get that test suite I can test it = .</DIV> <DIV> </DIV> <DIV>regards and thanks </DIV> <DIV>Arpit >>> <hendrik.saly(a)gmx.de> 4/10/2009 2:19 = PM >>> Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: = Linux 2.6, Sun JDK 1.5 URL: <A href=3D"http://svn.muleforge.org/mule-tra= nsport-ldap/trunk/src/main/java/com/novell/ldap/SaslLDAPConnection.java">ht= tp://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell/l= dap/SaslLDAPConnection.java</A> Submission from: (NULL) (78.43.136.21)<B= R> While trying to use SASL with JLDAP i encounter a potential = minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v = 1.154 2006/02/09 08:43:45 sunilk Exp $ Seems the bind method on = line 1730 fails to release the bind semaphore properly under some = circumstances. I tried to use more than the wit JLDAP provided SASL mech= anisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with a = Java 1.5 sasl client. All works very well but CRAM login for example = fails. I have a workaround   <A href=3D"http://svn.muleforge.o= rg/mule-transport-ldap/trunk/src/main/java/com/novell/ldap/SaslLDAPConnecti= on.java">http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/c= om/novell/ldap/SaslLDAPConnection.java</A> but i thinks there are some = problems with the bind semaphore. The wrapping code is here <A = href=3D"http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/or= g/mule/transport/ldap/sasl/ClientFactory.java">http://svn.muleforge.org/mul= e-transport-ldap/trunk/src/main/java/org/mule/transport/ldap/sasl/ClientFac= tory.java</A> If neccessary i can provide a test suite for = this. Thanks Hendrik </DIV></BODY></HTML> --=__Part654DCF55.1__=--

1 0

(ITS#6071) LDAP server becomes unresponsive
by rs1542＠gmx.com 22 Apr '09

22 Apr '09

Full_Name: Carsten T. Rieck Version: 2.4.11 OS: RedHat 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.194.157.126) Hello, my company runs an anonymously accessible LDAP server on openLDAP 2.4.11 with Berkeley database 4.6.21 (all recent patches applied) and RedHat 5.1 as operating system. We encounter the problem that occasionally the LDAP server becomes unresponsive. Investigating the network in such a situation shows a large number of connections in the state CLOSE-WAIT. These connections remain persistent until the LDAP server is restarted. I am able to reproduce the issue in our test environment using a client which accesses the LDAP using libldap. In an infinite loop, the client binds to the LDAP and performs a search, but it does do a proper unbinding. After about thirty loops (depending on the number of threads configured), the LDAP server becomes unresponsive. With netstat, I see the connection still as ESTABLISHED. After killing the client, the connection is marked as CLOSE-WAIT and remains in that state until the server is restarted. Any additional attempts to bind to the server leads to a connections in state CLOSE-WAIT. I do not have a Firewall in my test environment. When the server becomes unresponsive, the log displays the message "Resource temporarily unavailable" as in the following extract: Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=7 busy Apr 21 18:31:43 test2 slapd[644]: => acl_mask: access to entry "cn=ACME Class 2 CA,o=ACME AG,ou=rootcerts,dc=acme,dc=de", attr "certificateRevocationList;binary" requested Apr 21 18:31:43 test2 slapd[644]: => acl_mask: to value by "", (=0) Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: cn=dsa-admin,ou=admin,dc=acme,dc=de Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: cn=dsa-audit,ou=admin,dc=acme,dc=de Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: anonymous Apr 21 18:31:43 test2 slapd[644]: <= acl_mask: [3] applying =rscx (stop) Apr 21 18:31:43 test2 slapd[644]: <= acl_mask: [3] mask: =rscx Apr 21 18:31:43 test2 slapd[644]: => slap_access_allowed: read access granted by =rscx Apr 21 18:31:43 test2 slapd[644]: => access_allowed: read access granted by =rscx Apr 21 18:31:43 test2 slapd[644]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero Apr 21 18:31:43 test2 slapd[644]: daemon: activity on 2 descriptors Apr 21 18:31:43 test2 slapd[644]: daemon: activity on: Apr 21 18:31:43 test2 slapd[644]: 12w Apr 21 18:31:43 test2 slapd[644]: Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=7 busy Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero In the openLDAP mailing lists I have seen other users having similar although not identical problems. The common advice of reducing the parameter idletimout did not change the behavior. I am most pleased to provide any further information. I appreciate your help. Best regards, Carsten slpad.conf ##================================= ## include /usr/machine/local/admin/openldap/config/ldapdsa/schema/core.schema include /usr/machine/local/admin/openldap/config/ldapdsa/schema/cosine.schema include /usr/machine/local/admin/openldap/config/ldapdsa/schema/inetorgperson.schema password-hash {SSHA} ###################### # generic parameters # ###################### idletimeout 2 sizelimit 1000 timelimit 2 sockbuf_max_incoming 300000 sockbuf_max_incoming_auth 5000000 threads 4 gentlehup on #################### # pid & args files # #################### pidfile /usr/machine/local/work/openldap/slapd.pid argsfile /usr/machine/local/work/openldap/slapd.args ############################################################################### ################## # ssl parameters # ################## ###################### # used cipher suites # ###################### TLSCipherSuite HIGH:MEDIUM:+SSLv3 ################### # key, certs etc. # ################### TLSVerifyClient never ############################################################################### ################################## # macro bdb database definitions # ################################## ########################################## # suffix dc=acme,dc=de # ########################################## database bdb suffix "dc=acme,dc=de" cachesize 8000 checkpoint 5 30 mode 0600 directory /usr/machine/local/persistent/openldap/acme lastmod on rootdn "cn=admin,dc=acme,dc=de" rootpw <Passphrase removed> limits anonymous size.soft=10 ########################################## # ACLs # ########################################## include /usr/machine/local/admin/openldap/config/ldapdsa/acl.conf ############# # set index # ############# index default pres,eq index objectclass index cn,sn pres,eq,sub index mail #eof ##=================================

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 21 Apr '09

21 Apr '09

bryan.mesich(a)ndsu.edu wrote: > I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 > and recompiled. Slapd answers one request and then dies with > a segmentation fault: > > connection_get(14): got connid=3D1 > connection_read(14): checking for input on id=3D1 > ber_get_next > Segmentation fault > > I can send you the full debug output if it would be helpful. I'll ask you to send it unless I can easily reproduce the issue myself. Thanks for your time. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by bryan.mesich＠ndsu.edu 20 Apr '09

20 Apr '09

--17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 20, 2009 at 12:12:48PM +0200, Pierangelo Masarati wrote: >> Full_Name: Bryan Mesich >> Version: 2.4.13 >> OS: RHEL 5.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) >> >> >> When a rwm overlay is used in conjunction with the translucent overlay, = slapd >> dies with the following error and backtrace: > > I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could = =20 > also address yours. Can you check? You need to either build HEAD code, = =20 > or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> =20 > 1.119 to 2.4.16. I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 and recompiled. Slapd answers one request and then dies with a segmentation fault: connection_get(14): got connid=3D1 connection_read(14): checking for input on id=3D1 ber_get_next Segmentation fault I can send you the full debug output if it would be helpful. Thanks, Bryan --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFJ7N6JlSl3SAlkhEcRAuOwAJ42EyL1dRJAFlZVz7zo5LMTCbgEeACePomd GlMyb+gwM6ZgvTkYl60S7h4= =t8Kh -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp--

1 0

Re: (ITS#6058) slapcat aborts on a double free
by lscamoni＠alice.it 20 Apr '09

20 Apr '09

Tested it and it seems to be fixed

1 0

Re: (ITS#6058) slapcat aborts on a double free
by luca.scamoni＠sys-net.it 20 Apr '09

20 Apr '09

Tested it and it seems to be fixed Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6058) slapcat aborts on a double free
by ando＠sys-net.it 20 Apr '09

20 Apr '09

The problem is that slapcat uses be_entry_release_r() as the complement of be->be_entry_get(), namely a run-time function as the complement of a tool function. rwm_entry_release_rw(), on the contrary, assumes that the entry it is passed was dup'ed by rwm_entry_get_rw(). I've applied a fix which **should** always work, based on the assumption that if the entry was retrieved using rwm_entry_get_rw(), and duplicated, both e->e_private and e->e_bv are NULL. p. luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Slapcat on a slapd instance using rwm overlay, aborts with: > *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** > > To simulate it's enough a slapd.conf containing something like > > # Load dynamic backend modules: > modulepath /usr/local/openldap/sbin > moduleload back_hdb.la > moduleload rwm.la > > database hdb > suffix "dc=example,dc=com" > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > directory /usr/local/openldap/var/data > index objectClass eq > index entryCSN,entryUUID eq > > overlay rwm > > Simple database: > > dn: dc=example,dc=com > objectClass: dcObject > objectClass: organization > dc: example > o: example.com > > 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6034) Assert failure - connection_state_closing
by David Angerer 20 Apr '09

20 Apr '09

Hi there, We upgraded to openldap 2.4.16 about 10 days ago. Since then we are experiencing relatively frequent core dumps (average uptime is around 2-3 days). Investigating the root cause we came across ITS#6034 which reminded us much of problem we are facing, but should be fixed in 2.4.16. Setup: Solaris 10 Openldap 2.4.16 (64bit) Berkeley DB 4.7 1 Master 5 Replicas with deltasyncrepl Cores only happened to the master so far, replicas are running stable so far. I couldn't find a reference to this ITS in the 2.4.16 changelog (probably listed as other ITS or fixed earlier). Also if the fix made it's way into 2.4.16, I am wondering why we still observe this cores. If you need further information or have any suggestions please let me know. Please find some debugging information below. Kind regards, David (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x1004dd428 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@5 a l@5 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@6 a l@6 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x1004dd670 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() o t@10 a l@10 ldap_int_thread_pool_wrapper() signal SIGABRT in __lwp_kill() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() > t@13 a l@13 ldap_int_thread_pool_wrapper() LWP suspended in slap_access_allowed() t@14 a l@14 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on 0x1004dd1e0 in __lwp_park() t@16 a l@16 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@18 a l@18 ldap_int_thread_pool_wrapper() LWP suspended in __lock_getlocker_int() (dbx) lwp l@10 Current function is connection_state_closing 686 assert( c->c_struct_state == SLAP_C_USED ); t@10 (l@10) stopped in __lwp_kill at 0xffffffff7decea00 0xffffffff7decea00: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7decea10 (dbx) where [1] __lwp_kill(0x0, 0x6, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7decea00 [2] raise(0x6, 0x0, 0x100445d58, 0xffffffffffffffff, 0xffffffff7dfe6000, 0x0), at 0xffffffff7de6b4f4 [3] abort(0x1, 0x1b8, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7de48c8c [4] __assert(0x100271f48, 0x100271f70, 0x2ae, 0x0, 0x19d138, 0x100069f70), at 0xffffffff7de48f30 =>[5] connection_state_closing(c = 0x1004dce30), line 686 in "connection.c" [6] send_ldap_ber(op = 0xffffffff733ff768, ber = 0xffffffff733ff028), line 148 in "result.c" [7] slap_send_search_entry(op = 0xffffffff733ff768, rs = 0xffffffff733ff2d0), line 1247 in "result.c" [8] syncprov_sendresp(op = 0xffffffff733ff768, opc = 0xffffffff733ff4a0, so = 0x113c0a930, e = 0xffffffff733ff500, mode = 3), line 848 in "syncprov.c" [9] syncprov_qplay(op = 0xffffffff733ff768, so = 0x113c0a930), line 913 in "syncprov.c" [10] syncprov_qtask(ctx = 0xffffffff733ffc20, arg = 0x113c0a930), line 971 in "syncprov.c" [11] ldap_int_thread_pool_wrapper(xpool = 0x10046a250), line 663 in "tpool.c" (dbx) list 680,690 680 int connection_state_closing( Connection *c ) 681 { 682 /* c_mutex must be locked by caller */ 683 684 int state; 685 assert( c != NULL ); 686 assert( c->c_struct_state == SLAP_C_USED ); 687 688 state = c->c_conn_state; 689 690 assert( state != SLAP_C_INVALID ); (dbx) print c c = 0x1004dce30 (dbx) print *c *c = { c_struct_state = 1 c_conn_state = 0 c_conn_idx = 26 c_sd = -1 c_close_reason = 0x100271eb0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x118772d90 c_starttime = 0 c_activitytime = 0 c_connid = 18446744073709551615U c_peer_domain = { bv_len = 0 bv_val = (nil) } c_peer_name = { bv_len = 0 bv_val = (nil) } c_listener = (nil) c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x1004dcf38 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x1004dcf48 } c_write1_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 4278190080U } __pthread_mutex_owner64 = 4278190080U } __pthread_mutex_data = 18446744071451976704U } c_write1_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_write2_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write2_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_writers = 0 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = (nil) c_sasl_sockctx = (nil) c_sasl_extra = (nil) c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 3 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 3 c_n_get = 4 c_n_read = 3 c_n_write = 1 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x10006b900 = &slap_send_ldap_result(Operation *op, SlapReply *rs) c_send_search_entry = 0x10006cda0 = &slap_send_search_entry(Operation *op, SlapReply *rs) c_send_search_reference = 0x10006fa80 = &slap_send_search_reference(Operation *op, SlapReply *rs) c_send_ldap_extended = 0x10006c5f8 = &slap_send_ldap_extended(Operation *op, SlapReply *rs) c_send_ldap_intermediate = 0x10006ca28 = &slap_send_ldap_intermediate(Operation *op, SlapReply *rs) }

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 20 Apr '09

20 Apr '09

bryan.mesich(a)ndsu.edu wrote: > Full_Name: Bryan Mesich > Version: 2.4.13 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) > > > When a rwm overlay is used in conjunction with the translucent overlay, slapd > dies with the following error and backtrace: I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could also address yours. Can you check? You need to either build HEAD code, or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> 1.119 to 2.4.16. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6070) slapo-rwm(5) be_entry_get() incorrect behavior when no DN rewriting occurs
by ando＠sys-net.it 20 Apr '09

20 Apr '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando To reproduce, stack a slapo-rwm with no specific instructions on top of a provider right before the syncprov overlay. A fix is coming.

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by michael＠stroeder.com 18 Apr '09

18 Apr '09

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: >> (I've stumbled across ITS#5704. Isn't that already something like this?) > > not exactly, as sets do not allow a placeholder for the naming > attribute; maybe something like "this/entryRDN.ava{0}.value" if it > existed... But given that slapd already enforces the characteristic attribute (e.g. 'cn' for 'user' on Samba4) to be part of the entry IMHO this is not needed. Provided the order of the checks are right. So this would be: constraint_attribute name set "this/cn" restrict="ldap:///dc=example,dc=com??sub?(objectClass=user)" constraint_attribute name set "this/ou" restrict="ldap:///dc=example,dc=com??sub?(objectClass=organizationalUnit)" Since uniqueness of 'cn' or 'ou' for one-level search for the above cases is already enforced wouldn't this be sufficient? Maybe I miss something though. Ciao, Michael.

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 18 Apr '09

18 Apr '09

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> ----- abartlet(a)samba.org wrote: >>> Active Directory always presents an attribute 'name' that is always >>> equal to the relative distinguished name. AD allows only one RDN, >>> but I don't mind if this can be multi-valued for the multi-RDN >>> case. It is equal to the value of the RDN as presented in the RDN. >>> >>> This is not simply the subtype 'CN -> name', but a new attribute >>> unrelated to the existing definition of 'name'. >>> >>> I don't care what name is assigned to 'name', as I can easily remap >>> attributes. >>> >>> It would be great if this could be constructed such that it may be >>> declared to be unique for a particular one-level search (also an AD >>> requirement, but not one Samba4 requires or enforces at this time). >> The only problem I see in defining such an attribute is that its >> syntax should allow the value of any syntax, so it should probably be >> octetString or something like that. > > Why? IMO such an attribute type could be declared like any other > attribute type. If its syntax does not match the syntax of the > characteristic attribute invalidAttributeSyntax should be returned. Since we're dealing with something unspecified, you can: - be "strict": only allow the creation of this attribute when the naming attribute's syntax is 2.5.5.12 (unspecified, I understand, but we live in a wild world) - be "liberal": always allow the creation of this attribute by allowing it to contain any value > I wonder what the exact requirements for the implementation within slapd > are and some very rough ideas as food for thought: > > 1. slapd shall enforce uniqueness on one-level > => I'd vote for an additional feature of slapo-unique to define the > scope of uniqueness in a very flexible way > > 2. Value of 'name' has to match the value of the characteristic > attribute. Does this 1. has to be enforced within slapd or 2. could this > be enforced within smbd? > If 1. maybe the functionality/configuration of slapo-constraint could be > extended to define things like this. > (I've stumbled across ITS#5704. Isn't that already something like this?) not exactly, as sets do not allow a placeholder for the naming attribute; maybe something like "this/entryRDN.ava{0}.value" if it existed... p. > ...more...? > > In web2ldap's plugin classes I have implemented special treatment for > non-compliant notation for the DN part of LDAP URLs to reference a DN > based on an entry's DN: > > . the entry's DN > .. the entry's parent DN > _ the best matching namingContext for the entry's DN > > This strings can be appended to DNs. For example: > > 'ou=Users,_' would always refer to entry ou=Users below an arbitrary > naming context. > > 'ou=My Stuff,.' could refer to a container below a user's entry > > Maybe something like this could be helpful for an extended configuration > of slapo-unique and slapo-constraint. > > Hmm, also > > As said only very rough ideas... > > Ciao, Michael. > > 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by michael＠stroeder.com 18 Apr '09

18 Apr '09

ando(a)sys-net.it wrote: > ----- abartlet(a)samba.org wrote: >> Active Directory always presents an attribute 'name' that is always >> equal to the relative distinguished name. AD allows only one RDN, >> but I don't mind if this can be multi-valued for the multi-RDN >> case. It is equal to the value of the RDN as presented in the RDN. >> >> This is not simply the subtype 'CN -> name', but a new attribute >> unrelated to the existing definition of 'name'. >> >> I don't care what name is assigned to 'name', as I can easily remap >> attributes. >> >> It would be great if this could be constructed such that it may be >> declared to be unique for a particular one-level search (also an AD >> requirement, but not one Samba4 requires or enforces at this time). > > The only problem I see in defining such an attribute is that its > syntax should allow the value of any syntax, so it should probably be > octetString or something like that. Why? IMO such an attribute type could be declared like any other attribute type. If its syntax does not match the syntax of the characteristic attribute invalidAttributeSyntax should be returned. I wonder what the exact requirements for the implementation within slapd are and some very rough ideas as food for thought: 1. slapd shall enforce uniqueness on one-level => I'd vote for an additional feature of slapo-unique to define the scope of uniqueness in a very flexible way 2. Value of 'name' has to match the value of the characteristic attribute. Does this 1. has to be enforced within slapd or 2. could this be enforced within smbd? If 1. maybe the functionality/configuration of slapo-constraint could be extended to define things like this. (I've stumbled across ITS#5704. Isn't that already something like this?) ...more...? In web2ldap's plugin classes I have implemented special treatment for non-compliant notation for the DN part of LDAP URLs to reference a DN based on an entry's DN: . the entry's DN .. the entry's parent DN _ the best matching namingContext for the entry's DN This strings can be appended to DNs. For example: 'ou=Users,_' would always refer to entry ou=Users below an arbitrary naming context. 'ou=My Stuff,.' could refer to a container below a user's entry Maybe something like this could be helpful for an extended configuration of slapo-unique and slapo-constraint. Hmm, also As said only very rough ideas... Ciao, Michael.

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > 2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > > 2009/4/17, Quanah Gibson-Mount <quanah(a)zimbra.com>: > > > --On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > > > > Why do you have so many threads configured? How many cpu's do you have?? > > > > > > > > > > > > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > > > > > > > > > > > I have an application which generates heavy load in slapd (many > > > > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > > > > BDB databases are situated on separate disk and BDB logs are on the other > > > > disk. But slapd performance (I mean time to answer) still cuts > > > > down during large disk IO periods 'cause these disks are used by other > > > > applications at the same time. And so I have increased number of threads > > > > from the defaults threads=32 up to 64, just to save some time for my > > > > application which requires not more then 30 ms for one search to > > > > complete. > > > > Just to be sure I have tried the default settings for threads and it's > > > > behaviour didn't changed - slapd heap memory just continuously grows (I > > > > have seen through pmap)... > > > > Also I have tried libtcmalloc which is usually recommended and solaris > > > > built in' libmtmalloc, but it didn't helped. > > > > > > > > > > Please copy replies to the bug tracker if you expect help. > > > > > > I will note that every thread consumes a large chunk of memory. I will also > > > note that the default is 16 threads, not 32. I will also note, that as far > > > as read operations are concerned, usually *fewer* threads is faster, not > > > more. > > >You appear to have quite an excessive amount of threads configured. > > > > > > I have mentioned that using the defaults didn't helped. Probably I was > mistaken about the default number of threads - but if keywords > "threads" is missing in config it simply means the defaults, right? > May be number of threads should be lower then the defaults (e.g. 6 or 8)? > Now I have 8 threads and slapd grows upto 2GB limit in 6 hours.

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > > Why do you have so many threads configured? How many cpu's do you have?? > > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > > > > > I have an application which generates heavy load in slapd (many > > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > > BDB databases are situated on separate disk and BDB logs are on the other > > disk. But slapd performance (I mean time to answer) still cuts > > down during large disk IO periods 'cause these disks are used by other > > applications at the same time. And so I have increased number of threads > > from the defaults threads=32 up to 64, just to save some time for my > > application which requires not more then 30 ms for one search to > > complete. > > Just to be sure I have tried the default settings for threads and it's > > behaviour didn't changed - slapd heap memory just continuously grows (I > > have seen through pmap)... > > Also I have tried libtcmalloc which is usually recommended and solaris > > built in' libmtmalloc, but it didn't helped. > > > > Please copy replies to the bug tracker if you expect help. > > I will note that every thread consumes a large chunk of memory. I will also > note that the default is 16 threads, not 32. I will also note, that as far > as read operations are concerned, usually *fewer* threads is faster, not > more. >You appear to have quite an excessive amount of threads configured. > I have mentioned that using the defaults didn't helped. Probably I was mistaken about the default number of threads - but if keywords "threads" is missing in config it simply means the defaults, right? May be threads should be lower then the defaults (e.g. 6 or 8)?

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by Quanah Gibson-Mount 17 Apr '09

17 Apr '09

--On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > Why do you have so many threads configured? How many cpu's do you have?? > > > >> I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from >> Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > I have an application which generates heavy load in slapd (many > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > BDB databases are situated on separate disk and BDB logs are on the other > disk. But slapd performance (I mean time to answer) still cuts > down during large disk IO periods 'cause these disks are used by other > applications at the same time. And so I have increased number of threads > from the defaults threads=32 up to 64, just to save some time for my > application which requires not more then 30 ms for one search to > complete. > Just to be sure I have tried the default settings for threads and it's > behaviour didn't changed - slapd heap memory just continuously grows (I > have seen through pmap)... > Also I have tried libtcmalloc which is usually recommended and solaris > built in' libmtmalloc, but it didn't helped. Please copy replies to the bug tracker if you expect help. I will note that every thread consumes a large chunk of memory. I will also note that the default is 16 threads, not 32. I will also note, that as far as read operations are concerned, usually *fewer* threads is faster, not more. You appear to have quite an excessive amount of threads configured. Others will have to continue the conversation on what you're seeing growth wise. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > According to ITS#5860 slapd should not allocate more memory than it was > > > specified. In fact I have the same behaviour as it was with previous > > > > > > version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for > > > set_cachesize 300 MB). But slapd process continuosly grows in memory until > > > 32-bit limit then crashes due to unavalable memory resources. I need to > > > > > > mention bdb database size is less then 1 GB. > > > After restart it rapidly consumes 1.5 GB RSS in few minutes and then it > > > grows beyond the limit during 24 hours. The more queries are processing > > > the more memory it eats. > > > > > > I am using this database for logging which size grows. > > > The question is: is it possible to use 32-bit openldap with relatively > > > large database sizes that override 32-bit per-process memory space? > > > > > > My slapd.conf contains: > > > > > > > > > threads 64 > > > > > > > Why do you have so many threads configured? How many cpu's do you have?? > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > I have an application which generates heavy load in slapd (many ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). BDB databases are situated on separate disk and BDB logs are on the other disk. But slapd performance (I mean time to answer) still cuts down during large disk IO periods 'cause these disks are used by other applications at the same time. And so I have increased number of threads from the defaults threads=32 up to 64, just to save some time for my application which requires not more then 30 ms for one search to complete. > Just to be sure I have tried the default settings for threads and it's behaviour didn't changed - slapd heap memory just continuously grows (I have seen through pmap)... > Also I have tried libtcmalloc which is usually recommended and solaris built in' libmtmalloc, but it didn't helped.

1 0

Re: (ITS#6058) slapcat aborts on a double free
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

luca(a)openldap.org writes: > Slapcat on a slapd instance using rwm overlay, aborts with: > *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** It's an invalid free() of (static EntryHeader eh).e_bv.bv_val at: ch_free (ch_malloc.c:139) hdb_tool_entry_close (back-hdb/tools.c:164) slapcat (slapcat.c:135) main (main.c:636) already freed (as (Entry *e)->e_bv.bv_val) at: ch_free (ch_malloc.c:139) entry_clean (entry.c:498) entry_free (entry.c:514) rwm_entry_release_rw (overlays/rwm.c:827) overlay_entry_release_ov (backover.c:421) over_entry_release_rw (backover.c:463) be_entry_release_rw (backend.c:867) slapcat (slapcat.c:117) main (main.c:636) I needed to prepend include servers/slapd/schema/core.schema to your config. -- Hallvard

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

eric(a)huss.org wrote: > There appears to be a couple slightly incorrect statements in the slapd.conf > manpage. It says that the argsfile and pidfile values are used "if started > without the debugging command line option". However, it doesn't appear to > make any difference whether or not you use the -d option with slapd. Fixed the doc in HEAD. Also the argsfile did not mention that the program name is written to argsfile as well as the options. -- Hallvard

1 0

Re: (ITS#6059) Abandon syncprov race condition?
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

rein(a)OpenLDAP.org writes: > I've had two cases where a delete operation was performed on the > master without being replicated to its consumers, which so far appear > to be cases of possible connection lost (abandon) race conditions. Not sure if this is the problem, but it is ugly: slapd/cancel.c sets o_abandon with op->o_conn->c_mutex locked, but waits to set o_cancel after it's unlocked. Looks like that can give slapd a chance to react to o_abandon before it "knows" that abandon is actually a cancel. > Do we need some sort of o_committed flag that can be used to prevent > o_abandon from being set or acted upon? Or handle o_abandon more like > o_cancel, i.e with multiple values, including "too late"? o_cancel is a wrapper around o_abandon, turning result code SLAPD_ABANDON into LDAP_TOO_LATE etc. However slap_send_ldap_result() and send_ldap_response() skip "if (op->o_callback) slap_response_play()" if o_abandon is set, and "send" SLAPD_ABANDON instead of the result code. Can that work right? The code looks like SLAPD_ABANDON ought to mean "nothing was done" right up till everything has had a chance to react the same way to an operation. -- Hallvard

1 0

Re: (ITS#6065) slapcat with sql (postgres) backend
by ando＠sys-net.it 17 Apr '09

17 Apr '09

frederic.bouy(a)gmail.com wrote: > Full_Name: Frederic Bouy > Version: 2.4.12 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.255.106.203) > > > When running the following command: > slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 > I get this error message: > <==backsql_load_schema_map() > ==>backsql_free_db_conn() > ==>backsql_close_db_handle(0x8290c18) > <==backsql_close_db_handle(0x8290c18) > <==backsql_free_db_conn() > <==backsql_db_open(): test succeeded, schema map loaded > slapcat: database doesn't support necessary operations. > > ldapsearch is successfull. > > Do you have any clue on how to solve this issue? The message should be pretty self explanatory. A solution consists in implementing the missing support. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6065) slapcat with sql (postgres) backend
by frederic.bouy＠gmail.com 17 Apr '09

17 Apr '09

Full_Name: Frederic Bouy Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.255.106.203) When running the following command: slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 I get this error message: <==backsql_load_schema_map() ==>backsql_free_db_conn() ==>backsql_close_db_handle(0x8290c18) <==backsql_close_db_handle(0x8290c18) <==backsql_free_db_conn() <==backsql_db_open(): test succeeded, schema map loaded slapcat: database doesn't support necessary operations. ldapsearch is successfull. Do you have any clue on how to solve this issue? Thanks for your help.

1 0

Antwort: Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 17 Apr '09

17 Apr '09

--0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: multipart/alternative; Boundary="1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841" --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable This is a full Backtrace - about 200 MB of Real Memory available(from 2= GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpthread.a(shr_xpg5.o= ) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread.a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o) No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o) No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a(shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_malloc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at search.c:1013 bdb =3D (struct bdb_info *) 0x20188b98 ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4, scopes=3D0x26379= bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98 rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result =3D 640653996, f= _un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un_ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9aac}, f_next =3D 0= x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_result =3D 640654008, = f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_un_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9ab8}, f_next =3D 0= x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_result =3D 640653972, = f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_un_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a94}, f_next =3D 0= x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 0, f_un_desc = =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra =3D 0x0, f_un_complex =3D = 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D {bv_len =3D 8,= bv_val =3D 0x102dbf2c "r\ef\erral"}} sf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 641440756, f_= un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9bf4}, f_next =3D 0= x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D {bv_len =3D 0, b= v_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x263ba824) at sear= ch.c:578 bdb =3D (struct bdb_info *) 0x20188b98 id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>} scopes =3D {0 <repeats 63759 times>, 641435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 641434656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 641434672, 0, 0, 0, 32,= 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 2567258180, 3490905504, 0= , 641434768, 4030840384, 4112, 0, 4030805596, 4030426872, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 3490902496, 0, 6414348= 00, 4030840384, 58, 22528, 0, 144, 0, 269721729, 269721729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 641434880, 4030840384= , 3490883944, 0, 641434896, 4030840384, 3490889600, 641435752, 641434896,= 4030840384, 3491274292, 0, 0, 641437345, 641437340, 1, 0, 1, 40304311= 12, 4030431112, 641434960, 0, 3490885628, 641435752, 641435008, 4030840384,= 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992, 0, 0, 641435752= , 641435008, 4031927728, 3491274292, 608035800, 641435072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0, 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3491266240, 0= , 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14, 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times>, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 678360812, bv_val = =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"}, e_attrs =3D= 0x3, e_ocflags =3D 641440736, e_bv =3D {bv_len =3D 641440832, bv_val =3D 0xf= 041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc= =3Dsozv \ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 77770, mode =3D DB_LO= CK_READ} opinfo =3D (struct bdb_op_info *) 0x0 ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backover.c:646 func =3D (BI_op_bind **) 0x200012b4 rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 on =3D (slap_overinst *) 0x20189e78 be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\001\000\000\001\001\00= 0 \001", '\0' <repeats 17 times>, "\001", be_flags =3D 2312, be_restricto= ps =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0= , sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}= , be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28, be_schemadn =3D {b= v_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, b= e_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootndn =3D {bv_len =3D 34, bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootpw =3D {bv_len =3D 5, bv_val =3D 0x20187138 "start"}, be_max_deref_depth =3D= 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms_s_soft =3D= -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide= =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D 0, bv_val =3D= 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20356508, be_pcl_mu= tex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_= cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_next =3D {stqe_next =3D 0x201= 92308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x2001e51c: 0x100d553= c <over_back_response>, sc_cleanup =3D @0x0: 0x1, sc_private =3D 0x20189d= 68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x263ba824) at searc= h.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff "dc=3Dpva,dc=3Ds= ozv \ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c out of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba95c, arg_v=3D0x243= de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, s= r_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, = sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0= x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0= , r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r= _v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 #15 0x1006c848 in connection_read_thread (ctx=3D0x263ba95c, argv=3D0x20= ) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1, arg =3D 0x0, ct= x =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x200c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8 work_list =3D (ldap_int_tpool_plist_t *) 0x200c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_key =3D 0x2001e2ac,= ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x1006b814 <conn_counter_destroy>= }, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, ltk_free =3D @0x2= 001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk_key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D 0x51eadec0,= ltk_free =3D @0x200201fc: 0x1020f550 <bdb_locker_id_free>}, {ltk_= key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0: 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0 i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c "" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpthread.a(shr_xpg5.= o) No symbol table info available. Mit freundlichen Gr=FC=DFen Howard ALLISON Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: howard.allison(a)pva.sozvers.at Internet: www.pensionsversicherung.at -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient you are notified that any dissemination, distribution, use or copying of this communication is strictly prohibited. If you received this message in error, please immediately destroy this message. --------------------------= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> This is a full Backtrace - about 200 MB of Real Mem= ory available(from 2 GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpth= read.a(shr_xpg5.o) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread= .a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o)= No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o)= No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a= (shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_mal= loc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at se= arch.c:1013 bdb =3D (struct bdb_info *) 0x20188b98<= br> ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, = rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4,= scopes=3D0x26379bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98<= br> rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result= =3D 640653996, f_un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un= _ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9a= ac}, f_next =3D 0x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_resul= t =3D 640654008, f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_u= n_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9a= b8}, f_next =3D 0x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_resul= t =3D 640653972, f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_u= n_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a= 94}, f_next =3D 0x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 0, f_un_desc =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra = =3D 0x0, f_un_complex =3D 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D= {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"}}<b= r> sf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 641440756, f_un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_= ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9b= f4}, f_next =3D 0x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D= {bv_len =3D 0, bv_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2= c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x= 263ba824) at search.c:578 bdb =3D (struct bdb_info *) 0x20188b98<= br> id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>= } scopes =3D {0 <repeats 63759 times>, 641= 435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, = 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 6414= 34656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 6414= 34672, 0, 0, 0, 32, 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 25672581= 80, 3490905504, 0, 641434768, 4030840384, 4112, 0, 4030805596, 40304268= 72, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 34909= 02496, 0, 641434800, 4030840384, 58, 22528, 0, 144, 0, 269721729, 26972= 1729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 6414= 34880, 4030840384, 3490883944, 0, 641434896, 4030840384, 3490889600, 64= 1435752, 641434896, 4030840384, 3491274292, 0, 0, 641437345, 641437340, = 1, 0, 1, 4030431112, 4030431112, 641434960, 0, 3490885628, 641435752, 6= 41435008, 4030840384, 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992= , 0, 0, 641435752, 641435008, 4031927728, 3491274292, 608035800, 641435= 072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0,= 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3= 491266240, 0, 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14= , 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times&gt= ;, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 6= 78360812, bv_val =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D = 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers= ,dc=3Dat"}, e_attrs =3D 0x3, e_ocflags =3D 641440736, e_bv =3D {bv= _len =3D 641440832, bv_val =3D 0xf041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e= 94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 7777= 0, mode =3D DB_LOCK_READ} opinfo =3D (struct bdb_op_info *) 0x0<b= r> ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x= 0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs= =3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backove= r.c:646 func =3D (BI_op_bind **) 0x200012b4 = rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D= 0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 = on =3D (slap_overinst *) 0x20189e78 = be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x= 20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\= 001\000\000\001\001\000\001", '\0' <repeats 17 times>, &quot= ;\001", be_flags =3D 2312, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, ss= s_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0,= sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_s= imple_bind =3D 0}, be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28,= be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, b= v_val =3D 0x0}, be_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootndn =3D {bv_len =3D 34,<br= > bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootpw =3D {bv_len =3D 5, bv_val =3D = 0x20187138 "start"}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D= 0, lms_s_soft =3D -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_= pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D= 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D = 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20= 356508, be_pcl_mutex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, = 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, b= e_pb =3D 0x0, be_cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_n= ext =3D {stqe_next =3D 0x20192308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x20= 01e51c: 0x100d553c <over_back_response>, sc_cleanup =3D @0x0: 0x1= , sc_private =3D 0x20189d68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x2= 63ba824) at search.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff= "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c ou= t of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba9= 5c, arg_v=3D0x243de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, = sr_msgid =3D 0, sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_r= ef =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D= {r_rspoid =3D 0x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0= , r_attr_flags =3D 0, r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_= nentries =3D 0, r_v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 = #15 0x1006c848 in connection_read_thread (ctx=3D0x263b= a95c, argv=3D0x20) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1= , arg =3D 0x0, ctx =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D= 0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x2= 00c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8= work_list =3D (ldap_int_tpool_plist_t *) 0x200= c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_ke= y =3D 0x2001e2ac, ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x= 1006b814 <conn_counter_destroy>}, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, = ltk_free =3D @0x2001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk= _key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10= 009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D= 0x51eadec0, ltk_free =3D @0x200201fc: 0x1020f550 <bdb_loc= ker_id_free>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0= : 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0</fo= nt> i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c &q= uot;" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpt= hread.a(shr_xpg5.o) No symbol table info available. Mit freundlichen Gr=FC=DFen<= b> Howard ALLISON <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"95"><img src=3D"cid:1__=3D4EBBFF08DFA38= 8418f9e8a93d(a)pva.sozvers.at" width=3D"83" height=3D"52"></td><td width=3D= "237" valign=3D"middle">Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: <a href=3D"mailto:howard.allison@pva.sozvers.at"><f= ont size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">howard.allison@= pva.sozvers.at</a><b= r> Internet: <a href=3D"http://www.pensionsversicherung.at/"><fo= nt size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">www.pensionsvers= icherung.at</a></td></tr> </table> -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen = bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the indiv= iduality or entity to which it is addressed and may contain information that is pri= vileged, confidential and exempt from disclosure. If you are not the intended re= cipient you are notified that any dissemination, distribution, use or copying of this c= ommunication is strictly prohibited. If you received this message in error, please imme= diately destroy this message. -------------------------- </body></html>= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841-- --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: image/gif; name="18476766.gif" Content-Disposition: inline; filename="18476766.gif" Content-ID: <1__=4EBBFF08DFA388418f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhUwA0APcAAA4Rm9DR2jw/qpaYw3Z4sx4hoLy9zldZsIGDtTEzpbGyztbe3lBSr6ipyY+R vDg7p2xursnL1UZJqhgaoSosoEFDpsTF1dLT2hganp+iwIaIwmNmqyEpnGxvtnt8vbe40sHC0aap z1VXsklLpoeJuxwfn46QxZmZzF1fsdHS2WxuuTQ3piAjoSotpL6/09zd3kxPrRQXnVVYpmdptoqN vczMzKutzj0/p7i60nFztVRXrHp7tJqdwKqrxlpdskJFrJKUvn+AumJktdfY3LW2zYKFvZKUxqSl xr3F1khLrSQopM3O1igrpGpstpydxNbW1v4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AADYLuB3EgMwABIBAACV8AAAOQA8AAAAAACeAgAAAQAAAIhkWAAgwBUAqAZWAAIAAAC88hIA2Vi0 d9UHAYXk8hIAAgAAACj0EgAc8xIAotfhdxIDMAASAQAAlfAAADkAPAABAAAAEgEAAJXwAAASAzAA SLkVANi1FQAgACAAAAAVACAAIAAAABUARgBlAHIAdABpAGcAAAASAAAAAAD8iOd3AAAAAAAAAADV BwGFiGRYADzzEgDxoeF3EgMwAAIDJwASAQAAlfAAADkAPAAAABMAlfAAAKqHRQASAzAAAgMnAAAB AAAkAAAAOQA8AKEAAACIZFgApPYSABgVOwB3wrR3KAM4AGhWEwAgAQAA2LUVAAAAAAAAAAAA0PMS AJUriHcINoh3/////+DzEgAec+d3AAATAAgAFAAYAQAAbJxIAGibSACJOOh3AAAAAAAAAAAAAAAA AAAAAETaRABsnEgA9MIVAHlWEwB5m0gA/////2hWEwB32EQAbJxIACH5BAEAAFAALAAAAABTADQA QAj/AKEIHEiwoMGDCBMqXMiwYcIhAyRgmEixIgYWD1BosAEiwoUhIIc4hBJBAQ0hK2LE0KFgZMIB Fi22ADEywoyJNA42mWARwcENGDqIJBhgKMMHMZPONFjEYgeDFlpMuJHCIA0nBkEwSTqRREEaSiIk tLB14gAoDWIuLTgkgFu3LpygYMGTKxCEBOomDWIQJgAPLgewyNHQQhAdD1hwpaiycYkEhKGAqHrw QsQJE5QUCeCys+fPoEMvHBKXAGIlJVJjXjyxBIUbKIo0sCDaJQm6rHPr5lrAAMMIRIwyHAJDL9e1 nSFgaFkwAgXMP4QLhGmRCc2BATZcT5hgN/KRRBRT/9wwGgbrB0sKQpgQOWGAG5iPEBwCJEEBFwad xNgdk4XvgQ2UUN0O6RVkgASY+XBBbdJBMcQHNORAwABERNDgQhdYoIAJTVRQgkos6ECDCxfWZuKJ KIL2AQFI8TcRC0wkkMADNNLYAgsCVlTACCRslyJBNuWoWwEuUtSCBB04QZtCCnQgAQ2UfTbEDMZR VIAPMwih5ZZc+pBEWRMl0ASXWpqXlHw/EiTDfot955AQMWRg0BAjVITCQU1RNINwRGDFUBBVKuWj QDSUwMKhK/RgkAuHLklQDxgo4ehACghZUQJiYXeDotx5N6iDKYQaZUFO5AhDiUStwFpOBDkBgAkJ of+glw0osFmRmwsFgEJSgMUaKEUrZDrQERgAwBxCH4h3p0BHPIcZrgPYWmQDBgHxawFeNYcgAGc5 dIRi1DYUbZGXZkpEaiVIEMSnJHWQIw2oNgTCBuGmudASRzTRgkqQsWsvQhd8AEQODDzQQgFEWqRS ai3ccEAOAyhgQbz/VmzxxRhn7FAALjQAxA5CyMAADEmUnIQOKHRQxAAcLaixSwE0kMOX5LLWgg4k BPfyQBc4cYB4uSUggRBBsIyDBREsofTSFuBgwwBFzDBCdy/OcOy/R5hpsxAEEDDDAUnc8MAKZD9w gwQ6COEBEDZMrNAFRARRAQVC/HfiESv8WrN3OBf/iJAFJCCAH2hDdKD33kUuazEB0lZEgbAPgVDE A5itwFlzVFd0g8sEEdFtbQYoYbO/CeW1uUE2WGodVC1MhALnUKTQA8UANq4W6WOxAMNBNGAWn0Ep 3GBRtgMNgKZC5+qG6xIf4OC83wSlNcNBVE5QxEEMJNWeQA4IsZAOnhpEgkXTF2TBcz6x9cABP+l9 vEAo6KBQ5qP3ZfYNDn/qgugYfD4QSAbZweGu16oY2CAhrVMe7hIiBIqU4IALoc5i6iUQIMRgewVp 0UWaYCkjLdAgF0iCcZRgt4P0oIMW2QFbbvCqhPSOIgoAgRKqhKuEKEBrFrEcQvbHGh4YRAcxYALk /wxyk4kQUDC3+lQDEoC/G6wATKwZQYOWkIBfxWAH0gHBvlgAPbxgJgF+MwD4MIAr/exNcQIZgkRi UgFOAWkEE4iBUBxChBnKz3wkmJRAzLg3AhBkV0bKQQkH4oQqxmAGsPNWDH6QSIQMAACIwwABWZQD G1zoAkBo0Q8gGBob3ABWDkkBCBQwABJ4QAU+0IEqdXAAtRWBbS5YQrwiQIMfYEYJORgcii5whCGS JIa0GwlpBiCEBCwMBgPw5css4IQmwKACN4CBEHJQBCMcoQHYxKYTjFCEHAghCSsoQGOYAAMCNOCD O6tMBFygABs4wQRAiGcInBfLRqbznvjMZ4oCAgA7 --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841--

1 0

ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by linamat＠telco.md 17 Apr '09

17 Apr '09

I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. According to ITS#5860 slapd should not allocate more memory than it was specified. In fact I have the same behaviour as it was with previous version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for set_cachesize 300 MB). But slapd process continuosly grows in memory until 32-bit limit then crashes due to unavalable memory resources. I need to mention bdb database size is less then 1 GB. After restart it rapidly consumes 1.5 GB RSS in few minutes and then it grows beyond the limit during 24 hours. The more queries are processing the more memory it eats. I am using this database for logging which size grows. The question is: is it possible to use 32-bit openldap with relatively large database sizes that override 32-bit per-process memory space? My slapd.conf contains: threads 64 concurrency 50 cachesize 200000 dncachesize 400000 idlcachesize 600000 shm_key 10 DB_CONFIG: set_cachesize 0 300097152 1 set_lk_max_locks 1000000 set_lk_max_lockers 1000000 set_lk_max_objects 1000000 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 ls -ls ./openldap-data total 1212876 -rw-r--r-- 1 slapd nobody 640 Apr 17 08:42 DB_CONFIG -rw------- 1 slapd nobody 8 Apr 16 10:50 __db.001 -rw-r--r-- 1 slapd nobody 4096 Apr 16 10:50 alock -rw------- 1 slapd nobody 6053888 Apr 17 09:50 cn.bdb -rw------- 1 slapd nobody 1024000 Apr 17 09:50 dhcpHWAddress.bdb -rw------- 1 slapd nobody 96583680 Apr 17 09:50 dn2id.bdb -rw------- 1 slapd nobody 515637248 Apr 17 09:50 id2entry.bdb -rw------- 1 slapd nobody 1343488 Apr 17 09:50 objectClass.bdb Any help would be much appreciated. Regards, Sergey.

1 0

(ITS#6064) syncrepl.c does not compile ("//" comment)
by h.b.furuseth＠usit.uio.no 16 Apr '09

16 Apr '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard C89 chokes on this comment from syncrepl.c 1.445: // add new syncrepl to end of list (same order as when deleting) Fixing.

1 0

Re: (ITS#6063) Syncrepl replication be_modify failed (18)
by michael＠stroeder.com 16 Apr '09

16 Apr '09

wan(a)ccs.neu.edu wrote: > I've been battling some issues with syncrepl for a while now, and I > can't quite figure out what has gone wrong. > [..] > and am still having issues (now at > 2.4.15) Could you please try 2.4.16 released a couple of days ago? There were four syncrepl-related fixes in this release. Not sure whether one of the fixes really solves your particular problem but please give it a try. Maybe it would also help if you try to get more detailed logs by starting slapd with -d on the console. (You might also need to use -u and/or -g option to use the demon user.) Ciao, Michael.

1 0

Re: (ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by quanah＠zimbra.com 15 Apr '09

15 Apr '09

--On Wednesday, April 15, 2009 5:52 PM +0000 rps2(a)socal.rr.com wrote: > Full_Name: Rick Stevens > Version: 2.4.16 > OS: Fedora 10, x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.200.106.34) > > > Compilation fails when compiling the libraries/liblutil/getpeereid.c > file. Under Fedora 10, one must include the line: > > #define _GNU_SOURCE > > somewhere near the top of the file to ensure the system can pick up the > size of the "ucred" structure. This is a duplicate of ITS#5464 and will be closed. The fix will be in the next release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6063) Syncrepl replication be_modify failed (18)
by wan＠ccs.neu.edu 15 Apr '09

15 Apr '09

Full_Name: Will Nowak Version: 2.4.15 OS: Ubuntu Hardy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.239.45.4) [Creating an ITS issue of the email thread with the same subject] I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong. I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listi… The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container: dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow) An incoming add for user james looks like dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow) Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves. Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed

1 0

(ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) Compilation fails when compiling the libraries/liblutil/getpeereid.c file. Under Fedora 10, one must include the line: #define _GNU_SOURCE somewhere near the top of the file to ensure the system can pick up the size of the "ucred" structure.

1 0

(ITS#6061) ./configure messups on NDB and Perl backends
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) The help text in the configure script for OpenLDAP 2.4.16 states: --enable-ndb enable MySQL NDB Cluster backend no|yes|mod [no] ... --enable-perl enable perl backend no|yes|mod [no] Which indicate that, by default, the MySQL Cluster NDB and Perl back-ends will not be built. This is not the case. The system tries to configure those back-ends. The "make depend" completes normally, but the "make" aborts when trying to compile those back-ends. In the case of the Perl back-end, configure does not find the necessary headers and reports that fact, however it does not set flags to block compilation of that module. On a separate identical machine, I did install the items necessary to build those back-ends. However, the system can't find the necessary headers even though they exist. For NDB, one must install the "mysql-devel" RPM. However, the path for finding the headers isn't correct. On Fedora 10, the include path must include "-I/usr/include/mysql/ndb/ndbapi". For Perl, one must install the "perl-devel" RPM, and the path for finding headers must include "-I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE".

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Yup this works, good work, thanks. > > Seems a tad slow though, do filters like these drastically slow down the > search? It applies some overhead: for each value of each attribute of each entry it needs to check whether the memberOf attr is present; if it is, a berval comparison is needed (compare the length first, and the value in case of match). As usual, it depends on the structure of your data. Also, but this is independent of ACL evaluation, slapo-rwm duplicates each entry as soon as it needs to do some manipulation on it (like massaging the DNs and so). If you notice any significant overhead, you might want to profile the execution of your slapd, to point out what's the actual bottleneck. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon > it would be a difficult fix? Please test HEAD (or import the latest fixes to servers/slapd/overlays/rwm.[ch] into 2.4.16, if you prefer). You need to add rwm-drop-unrequested-attrs no to your slapo-rwm configuration. I haven't documented this flag yet; I'd wait until the fix is confirmed. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by hyc＠symas.com 15 Apr '09

15 Apr '09

ando(a)sys-net.it wrote: > David wrote: >> Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon >> it would be a difficult fix? > > On the contrary, it could be relatively simple. I need to further > investigate what's happening, but I could easily reproduce the issue. > I'll be back. Fixing it for back-bdb/hdb is easy enough. For other backends that don't always return whole entries (e.g. back-ldap) there would be more problems. It's an open question whether we care about those at the moment... -- -- Howard Chu CTO, 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon > it would be a difficult fix? On the contrary, it could be relatively simple. I need to further investigate what's happening, but I could easily reproduce the issue. I'll be back. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by hyc＠symas.com 14 Apr '09

14 Apr '09

Gavin Henry wrote: > Thanks, I'll review and let you know. > > Gavin. > And while you're at it, please move the slapd config examples back to the end of the slapd config chapters where they originally came from. You can insert references like "for more detailed discussion of access controls go -there-" but the examples need to be in the config chapters. -- -- Howard Chu CTO, 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#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by Gavin Henry 14 Apr '09

14 Apr '09

Thanks, I'll review and let you know. Gavin.

1 0

(ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by jonathan＠phillipoux.net 14 Apr '09

14 Apr '09

Full_Name: Jonathan Clarke Version: 2.4 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-20090414.patch.1 Submission from: (NULL) (213.41.243.192) Hi, As noticed with Gavin on IRC, the Admin Guide doesn't have any obvious instructions on converting from old file format slapd.conf to new cn=config directory based conf - these instructions are only in the slapd-config(8) man page. Please see above patch for a suggestion to incorporating it into the admin guide. I have taken some liberties with the formatting, please feel free to amend if you like. I did put this in a top-level (H2) section, although it's short, mainly to make it obvious in the guide's contents. Any feedback is most welcome, particularly if this needs to be more detailed :) Regards, Jonathan

1 0

(ITS#6059) Abandon syncprov race condition?
by rein＠OpenLDAP.org 14 Apr '09

14 Apr '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: linux URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein I've had two cases where a delete operation was performed on the master without being replicated to its consumers, which so far appear to be cases of possible connection lost (abandon) race conditions. The log (level: stats) shows the "DEL" message of the entry, immediately followed by a "closed (connection lost)" message on the connection. Note: No "RESULT" message was logged. I haven't looked very much into this, but my theory so far is that syncprov skipped replicating of the delete op after noticing the abandon resulting from loosing the connection, even though the delete had already taken place in the local database. That it happened after a delete op might very well have been a coincident, this possible race could exist after any modify op for all I know. Do we need some sort of o_committed flag that can be used to prevent o_abandon from being set or acted upon? Or handle o_abandon more like o_cancel, i.e with multiple values, including "too late"? Rein Tollevik Basefarm AS

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 14 Apr '09

14 Apr '09

abartlet(a)samba.org wrote: >> The only problem I see in defining such an attribute is that its >> syntax should allow the value of any syntax, so it should probably be >> octetString or something like that. =20 > > I think the AD document I reference explains that only some attributes > can be an RDN, so it limits them to those with a unicode string > representation I suppose.=20 OK, I coulnd't follow up to the document you cited. > There is another attribute that follows the 'type' of RDN btw (never > seen it used, but it's in the docs).=20 > >> From the implementation point of view, what operations should it be >> used for? If you only need it to be returned with searches, and to be >> compared, then the implementation would be trivial (it could be >> dynamically generated, much like entryDN, as far as I can tell). If >> you need to search for it, namely use it in a filter, then it might be >> better to store it in the database. This would require to handle add >> and modrdn, forbid modify, and nothing else. > > Like entryDN, we need to be able to search on it, so it should probably > be persistent. Ok. Unlike entryDN, which is not persistent but evaluated on the fly based on dn2id indexes, unless we hardcode this in slapd (don't think so) we need to make the attr persistent. It's on the todo list. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

David wrote: > So, we're still in dispute, as far as if this is a real bug or not? It seems to be a bug in the design of how data is gathered in view of ACL evaluation. Or better, overlay design invalidated an assumption that was valid when the only database type available passed the entire entry to ACL evaluation *before* entry massaging. Yes, it's a bug. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6058) slapcat aborts on a double free
by luca＠OpenLDAP.org 14 Apr '09

14 Apr '09

Full_Name: Luca Scamoni Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Slapcat on a slapd instance using rwm overlay, aborts with: *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** To simulate it's enough a slapd.conf containing something like # Load dynamic backend modules: modulepath /usr/local/openldap/sbin moduleload back_hdb.la moduleload rwm.la database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /usr/local/openldap/var/data index objectClass eq index entryCSN,entryUUID eq overlay rwm Simple database: dn: dc=example,dc=com objectClass: dcObject objectClass: organization dc: example o: example.com

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

> I chatted with David about this on IRC. The situation is using > slapo-rwm on > top of back-relay, pointed at a local (back-bdb) database. He has an > ACL in > the relay database using a filter, e.g.: > access to filter=(foo=bar) by * read > > In slapo-rwm rwm_attr(), when an explicit list of attributes is > requested in a > search, any attributes that weren't requested are stripped from the > entry. > Thus, attribute foo disappears if it is not part of the attrs list, > and then > the entry cannot be retrieved by the client. > > However, if no attr list is specified then slapo-rwm passes the entire > entry > through unmolested, and the ACL works. This is because search ACLs assume they will see the whole entry regardless of what attributes were requested in the search operation. The "right" solution consists in making ACL evaluation functions fetch the attr they need from the database, rather than from the entry, as it might have already been massaged. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com 14 Apr '09

14 Apr '09

Howard, Fair comments - the package was basically wrapped up from an internal packa= ge used in HP (which indeed has internal processes to map ED accounts to th= eir equivalent AD DNs). The desire was to donate the package rather than se= e it live only in HP - at least someone might find a use for it. Clearly yo= u think that the friction of installation limits its utility - and that's a= perfectly fine observation. A lot of the "mapping" name stuff was legacy from when there was a lot more= functionality in the package, since it did NTLM authentication as well, to= a multitude of NT4 domain controllers. In that world, there really was a m= apping, but that's not true in the simplified world of Adauth. In light of the comments, it's probably better to drop the package in its e= ntirety until I have time to address the structural issues highlighted. Cheers, Neil

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by hyc＠symas.com 14 Apr '09

14 Apr '09

ando(a)sys-net.it wrote: > ----- admin(a)dmarkey.com wrote: > >> Full_Name: David Markey >> Version: 2.4.15 >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (86.47.26.12) >> >> >> When using a slapo-rwm in conjunction with filter based ACL like >> >> access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" >> >> This wont work unless the client explicitly requests the memberOf >> attribute. >> >> The client in this case in thunderbird, which doesn't request the >> memberof >> attribute > > You should specify the context of your use of slapo-rwm. The limitation > might not be in the overlay itself, but in your design of the DSA that uses > slapo-rwm. Unless a more detailed description of the configuration > highlights a true software bug or design issue, I'm keen to considering > this a user error. I chatted with David about this on IRC. The situation is using slapo-rwm on top of back-relay, pointed at a local (back-bdb) database. He has an ACL in the relay database using a filter, e.g.: access to filter=(foo=bar) by * read In slapo-rwm rwm_attr(), when an explicit list of attributes is requested in a search, any attributes that weren't requested are stripped from the entry. Thus, attribute foo disappears if it is not part of the attrs list, and then the entry cannot be retrieved by the client. However, if no attr list is specified then slapo-rwm passes the entire entry through unmolested, and the ACL works. -- -- Howard Chu CTO, 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#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 14 Apr '09

14 Apr '09

--=-z3vwQM0YDtLESpiQMoYR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-04-14 at 10:09 +0200, Pierangelo Masarati wrote: > ----- abartlet(a)samba.org wrote: >=20 > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx > > Submission from: (NULL) (59.167.251.137) > >=20 > >=20 > > Active Directory always presents an attribute 'name' that is always > > equal to the > > relative distinguished name. AD allows only one RDN, but I don't mind > > if this > > can be multi-valued for the multi-RDN case. It is equal to the value > > of the RDN > > as presented in the RDN. > >=20 > > This is not simply the subtype 'CN -> name', but a new attribute > > unrelated to > > the existing definition of 'name'. > >=20 > > I don't care what name is assigned to 'name', as I can easily remap > > attributes. > >=20 > > It would be great if this could be constructed such that it may be > > declared to > > be unique for a particular one-level search (also an AD requirement, > > but not one > > Samba4 requires or enforces at this time). =20 >=20 > The only problem I see in defining such an attribute is that its > syntax should allow the value of any syntax, so it should probably be > octetString or something like that. =20 I think the AD document I reference explains that only some attributes can be an RDN, so it limits them to those with a unicode string representation I suppose.=20 There is another attribute that follows the 'type' of RDN btw (never seen it used, but it's in the docs).=20 > From the implementation point of view, what operations should it be > used for? If you only need it to be returned with searches, and to be > compared, then the implementation would be trivial (it could be > dynamically generated, much like entryDN, as far as I can tell). If > you need to search for it, namely use it in a filter, then it might be > better to store it in the database. This would require to handle add > and modrdn, forbid modify, and nothing else. Like entryDN, we need to be able to search on it, so it should probably be persistent. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-z3vwQM0YDtLESpiQMoYR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJ5En/z4A8Wyi0NrsRAr6BAJ9TfUOgXqi25ArjKIXGVWDacL770gCgql6i 64vwlQj1AfncVVS2bCJlH5g= =31Zg -----END PGP SIGNATURE----- --=-z3vwQM0YDtLESpiQMoYR--

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 14 Apr '09

14 Apr '09

----- abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 10 > URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx > Submission from: (NULL) (59.167.251.137) > > > Active Directory always presents an attribute 'name' that is always > equal to the > relative distinguished name. AD allows only one RDN, but I don't mind > if this > can be multi-valued for the multi-RDN case. It is equal to the value > of the RDN > as presented in the RDN. > > This is not simply the subtype 'CN -> name', but a new attribute > unrelated to > the existing definition of 'name'. > > I don't care what name is assigned to 'name', as I can easily remap > attributes. > > It would be great if this could be constructed such that it may be > declared to > be unique for a particular one-level search (also an AD requirement, > but not one > Samba4 requires or enforces at this time). The only problem I see in defining such an attribute is that its syntax should allow the value of any syntax, so it should probably be octetString or something like that. From the implementation point of view, what operations should it be used for? If you only need it to be returned with searches, and to be compared, then the implementation would be trivial (it could be dynamically generated, much like entryDN, as far as I can tell). If you need to search for it, namely use it in a filter, then it might be better to store it in the database. This would require to handle add and modrdn, forbid modify, and nothing else. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

----- admin(a)dmarkey.com wrote: > Full_Name: David Markey > Version: 2.4.15 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.47.26.12) > > > When using a slapo-rwm in conjunction with filter based ACL like > > access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" > > This wont work unless the client explicitly requests the memberOf > attribute. > > The client in this case in thunderbird, which doesn't request the > memberof > attribute You should specify the context of your use of slapo-rwm. The limitation might not be in the overlay itself, but in your design of the DSA that uses slapo-rwm. Unless a more detailed description of the configuration highlights a true software bug or design issue, I'm keen to considering this a user error. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by admin＠dmarkey.com 13 Apr '09

13 Apr '09

Full_Name: David Markey Version: 2.4.15 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.47.26.12) When using a slapo-rwm in conjunction with filter based ACL like access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" This wont work unless the client explicitly requests the memberOf attribute. The client in this case in thunderbird, which doesn't request the memberof attribute

1 0

(ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 13 Apr '09

13 Apr '09

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) Samba4's provision and 'make test' seems to create some internal situation in OpenLDAP slapd where it will not accept any more connections over ldapi:/// This is best seen by building Samba4, and running TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test The slapd does not crash, but simply stops accepting new connections. Samba4 currently then crashes due to some other bug (the LDAP backend not responding is clearly untested code in Samba4). It isn't a Samba4 client bug, as ldapsearch also fails to respond. This seems very, very similar to ITS#5261

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 13 Apr '09

13 Apr '09

On 10 Apr 2009, at 02:02, Howard Chu wrote: > Nothing obvious is jumping out here. Can you run a few of these > slapds with libefence or valgrind? I'll see what I can do. >> (gdb) p q1->first >> $3 = (Filter *) 0xb1f0d4c0 >> (gdb) p q2->first >> Cannot access memory at address 0x83e58959 > > print *q1 > > up > print *root (gdb) p *q1 $1 = {filter = 0xa, first = 0xb1f0d4c0, qbase = 0x825d7d0, scope = 0, q_uuid = {bv_len = 2985341416, bv_val = 0x1d <Address 0x1d out of bounds>}, q_sizelimit = 2147483647, qtemp = 0xb1f0d4c0, expiry_time = 136697880, next = 0xb1f10cd8, prev = 0xb1f031e0, lru_up = 0x1d, lru_down = 0x69647062, rwlock = {__data = {__lock = 1852386930, __nr_readers = 1684352614, __readers_wakeup = 778264878, __writer_wakeup = 27509, __nr_readers_queued = 21, __nr_writers_queued = 2985295944, __flags = 72 'H', __shared = 0 '\0', __pad1 = 240 '?', __pad2 = 177 '?', __writer = 0}, __size = "r.inf.ed.ac.uk\000\000\025\000\000\000H\000?H\000? \000\000\000", __align = 1852386930}} (gdb) up #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, fcmp=0x81764d8 <pcache_query_cmp>) at tavl.c:202 202 side = fcmp( data, p->avl_data ); (gdb) p *root $2 = (Avlnode *) 0x81d8ac4 (gdb) p **root $3 = {avl_data = 0x83e58955, avl_link = {0x7d8318ec, 0x24750008}, avl_bits = "?D", avl_bf = 36 '$'} (gdb) Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 12 Apr '09

12 Apr '09

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 10 URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx Submission from: (NULL) (59.167.251.137) Active Directory always presents an attribute 'name' that is always equal to the relative distinguished name. AD allows only one RDN, but I don't mind if this can be multi-valued for the multi-RDN case. It is equal to the value of the RDN as presented in the RDN. This is not simply the subtype 'CN -> name', but a new attribute unrelated to the existing definition of 'name'. I don't care what name is assigned to 'name', as I can easily remap attributes. It would be great if this could be constructed such that it may be declared to be unique for a particular one-level search (also an AD requirement, but not one Samba4 requires or enforces at this time). Andrew Bartlett

1 0

Re: (ITS#6050) make install overwrites schema dir
by michael＠stroeder.com 11 Apr '09

11 Apr '09

tmackey(a)zetta.net wrote: > Running make install leaves an existing slapd.conf alone, but happily nukes and > replaces the existing schema directory, taking with it any additional or custom > schema, leaving you with only the ones installed by default (hooray for svn and > backups!). You SHOULD place additional schema files (not shipped with OpenLDAP) in a separate directory. You SHOULD NOT customize/tweak the schema files shipped with OpenLDAP. Ciao, Michael.

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by hyc＠symas.com 10 Apr '09

10 Apr '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: > I suppose there could be a flag to _not_ start the indexing task when > you add an index via cn=config, so you always must slapindex. I'd rather not. >> I suppose we should save the last entryID that was indexed at shutdown time, >> so that the indexer task can resume at the next startup. We'd also need some >> coordination with slapindex, so that if you ran slapindex after shutdown, it >> would erase the saved status. Rather than add any fields to the DB index >> files, it would probably be OK to write the status in the cn=config tree. > > Or a status file in the database directory. > > A cn=config attribute would make it messy to swap database directories > around, since one must also modify cn=config when doing so. OK, a status file. It would record the old and new index masks for the attributes being reindexed, and the entryID where it stopped. If slapindex is run without a specific list of attributes, (reindex everything) it should remove and ignore the status file. If slapindex is run with a specific list of attributes, and those attributes are in the status file, it should use the saved status and remove the specified attributes from the status file. (Deleting the file if there are no other attributes remaining.) Otherwise, when slapd starts, it should read the status file and resume the indexing task. -- -- Howard Chu CTO, 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#6054) back-bdb indexing routines do not check for slap_sl_malloc() failure, leading to segfaults
by hyc＠symas.com 10 Apr '09

10 Apr '09

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) > > Looking back through the call chain, do_syncrepl() sets op->o_tmpmemctx to > NULL: > > /* use global malloc for now */ > op->o_tmpmemctx = NULL; > op->o_tmpmfuncs =&ch_mfuncs; This should be removed. > so generalizedTimeIndexer()'s call to slap_sl_malloc() falls back to > ber_memalloc_x() due to the null ctx. If malloc() fails there, NULL is > eventually returned to the original caller of slap_sl_malloc(), likely resulting > in a segfault. And slap_sl_malloc() should be changed in this case to assert() just like ch_malloc() does. > All of the indexing routines seem to ignore slap_sl_malloc()'s return value, > opening them up to this problem, too. Someone else will need to step in with a > proper fix since I don't know much about slapd internals, but it seems that if > these routines are being called with a deliberate null ctx, they should be > checking for malloc failure. A cursory glance around back-bdb indicates that > indexing function callers already handle failure return codes gracefully. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6054) back-bdb indexing routines do not check for slap_sl_malloc() failure, leading to segfaults
by jwm＠horde.net 10 Apr '09

10 Apr '09

Full_Name: John Morrissey Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) Our gdb harness around slapd(8) recently caught a SIGSEGV: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x5c6fcb90 (LWP 9059)] generalizedTimeIndexer (use=163, flags=4, syntax=0x8c73f58, mr=0x8c77f90, prefix=0x8cbed6c, values=0xbf5b6698, keysp=0x5c6fb2b4, ctx=0x0) at /tmp/buildd/openldap-2.4.16/servers/slapd/schema_init.c:5615 schema_init.c:5615: keys[j].bv_val = NULL; [...] Thread 11 (Thread 0x5c6fcb90 (LWP 9059)): #0 generalizedTimeIndexer (use=163, flags=4, syntax=0x8c73f58, mr=0x8c77f90, prefix=0x8cbed6c, values=0xbf5b6698, keysp=0x5c6fb2b4, ctx=0x0) at /tmp/buildd/openldap-2.4.16/servers/slapd/schema_init.c:5615 i = <value optimized out> j = 1 keys = (BerVarray) 0x0 tmp = "\000Iﬁ@" bvtmp = {bv_len = 5, bv_val = 0x5c6fb267 ""} tm = {tm_sec = 25, tm_min = 39, tm_hour = 18, tm_mday = 9, tm_mon = 3, tm_year = 109, tm_usec = 5, tm_usub = 147681736} tt = {tt_sec = 73, tt_gsec = 0, tt_usec = 5} __PRETTY_FUNCTION__ = "generalizedTimeIndexer" #1 0xb777f25e in indexer (op=0x5c6fbd50, txn=0xbf5b7130, ad=0x8cbedf0, atname=0x8cbed6c, vals=0xbf5b6698, id=786532, opid=1, mask=<value optimized out>) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:205 rc = <value optimized out> db = (DB *) 0x8d7b168 keys = <value optimized out> __PRETTY_FUNCTION__ = "indexer" #2 0xb777f916 in index_at_values (op=0x5c6fbd50, txn=0xbf5b7130, ad=0xb7c7b160, type=0x8cbed30, tags=0x8cbee00, vals=0xbf5b6698, id=786532, opid=1) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:337 rc = <value optimized out> mask = <value optimized out> ixop = 1 ai = <value optimized out> #3 0xb777faa7 in bdb_index_entry (op=0x5c6fbd50, txn=0xbf5b7130, opid=1, e=0xa3b1e154) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:557 rc = 0 ap = (Attribute *) 0xa37a7a7c #4 0xb7773268 in bdb_add (op=0x5c6fbd50, rs=0x5c6fb774) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/add.c:383 bdb = (struct bdb_info *) 0x8cd71c8 pdn = {bv_len = 6, bv_val = 0xbf5b8fc0 "cn=log"} p = (Entry *) 0x61a22034 oe = (Entry *) 0xa3b1e154 ei = (EntryInfo *) 0x8d735c8 textbuf = "\020\000P^\020w[øQ»∫∑∆\231∫∑HW\\ø\230\037\000\000Q»∫∑\004¥o\\Ï∆∫∑\020\000P^H\000P^8\000\000\000H\000P^\025\000\000\000-\000\000\000\005\000\000\000\000\000\000\000,¥o\\Hi[ø\001\000\000\000\000\000\000\000\220\003P^h[ø\004\000\000\000\020w[ø¥o\\\017s¿∑V\\øV\\ø@\000P^@\000P^@i[ø1Î∂∑\005\000\000\000@\000P^Ëh[øÙ\237«∑\000\000\000\000!\000\000\000ˇˇˇˇ\206Â∫∑\020\000P\017\000\000\000\000ˇˇˇ\017", '\0' <repeats 24 times>, "!\000\0000Á\221[ø∏¥o\\Ù\237"... children = (AttributeDescription *) 0x8c7dba0 entry = (AttributeDescription *) 0x8c7da08 ltid = (DB_TXN *) 0xbf5c3598 lt2 = (DB_TXN *) 0xbf5b7130 rtxn = <value optimized out> eid = 786532 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8cd71c8}, boi_txn = 0xbf5c3598, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\0', boi_flag = 0 '\0'} lock = {off = 193944, ndx = 386, gen = 3765, mode = DB_LOCK_READ} num_retries = 0 success = <value optimized out> postread_ctrl = <value optimized out> ctrls = {0x0, 0x80e2ed3, 0xbf5b91e7, 0x0, 0x10, 0xb7f6891c} num_ctrls = <value optimized out> #5 0x080d8be9 in syncrepl_entry (si=0x8cd8050, op=0x5c6fbd50, entry=0xa3b1e154, modlist=0x5c6fbce8, syncstate=1, syncUUID=0x5c6fbcb0, syncCSN=0xbf5b91f8) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:2187 be = (Backend *) 0x8cd70c8 cb = {sc_next = 0x0, sc_response = 0x80d2260 <null_callback>, sc_cleanup = 0, sc_private = 0x8cd8050} syncuuid_inserted = 0 syncUUID_strrep = {bv_len = 36, bv_val = 0xbf5b9220 "7eef2b58-b981-102d-8a6a-27f91e6cbe6f"} rs_search = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_delete = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_add = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_modify = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} f = {f_choice = 163, f_un = {f_un_result = 1550825600, f_un_desc = 0x5c6fb880, f_un_ava = 0x5c6fb880, f_un_ssa = 0x5c6fb880, f_un_mra = 0x5c6fb880, f_un_complex = 0x5c6fb880}, f_next = 0x0} ava = {aa_desc = 0x8c7a840, aa_value = {bv_len = 16, bv_val = 0xbf5b86d7 "~Ô+Xπ\201\020-\212j'˘\036læo"}} rc = 0 pdn = {bv_len = 0, bv_val = 0x0} dni = {new_entry = 0xa3b1e154, dn = {bv_len = 0, bv_val = 0x0}, ndn = {bv_len = 0, bv_val = 0x0}, nnewSup = {bv_len = 0, bv_val = 0x0}, renamed = 0, delOldRDN = 0, modlist = 0x5c6fbce8, mods = 0x0, oldNattr = 0x0, oldDesc = 0x0, newDesc = 0x0} retry = 1 freecsn = 1 nullattr = (AttributeDescription *) 0x0 __PRETTY_FUNCTION__ = "syncrepl_entry" opattrs = {0x81a6540, 0x81a6520, 0x81a6524, 0x8165a88} #6 0x080dafac in do_syncrep2 (op=0x5c6fbd50, si=0x8cd8050) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:892 rctrlp = <value optimized out> rctrls = (LDAPControl **) 0xbf5b41c0 berbuf = {buffer = "\002\000\001", '\0' <repeats 17 times>, "\206[ø\025\207[ø\025\207[ø", '\0' <repeats 12 times>, "h\037fQ+\230\021\b\022", '\0' <repeats 11 times>, "\n\000\000\000øo\\ˇˇˇ\021", '\0' <repeats 18 times>, "@¿o\\∏Â∑∑\000\000\000\000,#\0000\n\000 uT¿o\\∏Â∑∑žˇˇˇ\020\000\000\000\000\000\000\000\000\000\000ž\037fQžˇˇˇ\001", '\0' <repeats 11 times>, "+m uxH>\200\000\000\000\000\000\000\000\000ˇˇˇˇ\006\000\000\000Ï≈∑§Ï≈∑\224\214∫∑ˇˇˇˇ&\000\000\000Ù\237«∑Oøo\\\214ªo\\\215\237∫"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 ""} msg = (LDAPMessage *) 0xbf5b4ac8 retoid = 0x0 retdata = (struct berval *) 0x0 entry = (Entry *) 0xb7c7b160 syncstate = 1 syncUUID = {bv_len = 16, bv_val = 0xbf5b86d7 "~Ô+Xπ\201\020-\212j'˘\036læo"} syncCookie = {ctxcsn = 0xbf5b91f8, octet_str = {bv_len = 44, bv_val = 0xbf5b9198 "csn=20090409183925Z#000000#00#000000,rid=002"}, rid = 2, sid = -1, numcsns = 1, sids = 0xbf5b9210, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0xbf5b4a60, octet_str = {bv_len = 44, bv_val = 0xbf5b4188 "csn=20090409183916Z#000001#00#000000,rid=002"}, rid = 2, sid = -1, numcsns = 1, sids = 0xbf5b85c0, sc_next = {stqe_next = 0x0}} cookie = {bv_len = 44, bv_val = 0xbf5b86e9 "csn=20090409183925Z#000000#00#000000,rid=002"} rc = 0 err = 0 len = 44 psub = (struct berval *) 0x8cd7dc8 modlist = (Modifications *) 0xbf5ba250 match = <value optimized out> m = 148286664 tout_p = (struct timeval *) 0x5c6fbca0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 syncUUIDs = (BerVarray) 0x0 si_tag = 0 #7 0x080ddca4 in do_syncrepl (ctx=0x5c6fc248, arg=0x8cd7ea8) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:1361 si = (syncinfo_t *) 0x8cd8050 conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x81172c9 ""}, c_peer_name = {bv_len = 0, bv_val = 0x81172c9 ""}, c_listener = 0x8119260, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x808aea0 <slap_send_ldap_result>, c_send_search_entry = 0x80885e0 <slap_send_search_entry>, c_send_search_reference = 0x8087da0 <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {ob_op = {o_hdr = 0x5c6fbe28, o_tag = 104, o_time = 1239302589, o_tincr = 0, o_bd = 0x8cd70c8, o_req_dn = {bv_len = 38, bv_val = 0xbf5b8f70 "reqStart=20090409183925.000005Z,cn=log"}, o_req_ndn = {bv_len = 38, bv_val = 0xbf5b8fa0 "reqStart=20090409183925.000005Z,cn=log"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xa3b1e154}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 2746343764, bv_val = 0x1 <Address 0x1 out of bounds>}, rb_edn = {bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 135668576, bv_val = 0x5c6fb88c "£"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 84 'T'}, rs_increment = 1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 84 'T'}, rs_deleteoldrdn = 1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x8162360 "\001"}, rs_newSup = 0x5c6fb88c, rs_nnewSup = 0x30}, oq_search = {rs_scope = 2, rs_deref = -1548623532, rs_slimit = 1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x8162360, rs_filter = 0x5c6fb88c, rs_filterstr = {bv_len = 48, bv_val = 0xbf5ba2d0 "¢[øv\a\b4\020"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xa3b1e154 "d"}, rs_flags = 1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xa3b1e154 "d"}, rs_flags = 1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 135668576, bv_val = 0x5c6fb88c "£"}, rs_mods = 0x30, rs_modtail = 0xbf5ba2d0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 14 times>, "\002", '\0' <repeats 16 times>, o_controls = 0x5c6fbf54, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 14, bv_val = 0x8cd70b0 "cn=root,cn=log"}, sai_ndn = {bv_len = 14, bv_val = 0x8cd7e90 "cn=root,cn=log"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x5c6fb870, o_ctrls = 0x0, o_csn = {bv_len = 32, bv_val = 0xbf5b6948 "20090409183925Z#000000#00#000000"}, o_private = 0x0, o_extra = {slh_first = 0x5c6fb4e0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 4294967295, oh_conn = 0x5c6fbfd4, oh_msgid = 0, oh_protocol = 0, oh_tid = 1550830480, oh_threadctx = 0x5c6fc248, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x8161214, oh_counters = 0x81a62c0, oh_log_prefix = "conn=-1 op=0", '\0' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = {0x5c6fbc10, 0x0 <repeats 31 times>}} rc = 147681480 dostop = <value optimized out> s = <value optimized out> i = <value optimized out> defer = <value optimized out> fail = <value optimized out> be = (Backend *) 0x8cd70c8 #8 0x08077e6b in connection_read_thread (ctx=0x5c6fc248, argv=0x15) at /tmp/buildd/openldap-2.4.16/servers/slapd/connection.c:1225 No locals. #9 0xb7f7a5c8 in ldap_int_thread_pool_wrapper (xpool=0x8c80560) at /tmp/buildd/openldap-2.4.16/libraries/libldap_r/tpool.c:663 task = (ldap_int_thread_task_t *) 0x8e313c0 work_list = <value optimized out> ctx = {ltu_id = 1550830480, ltu_key = {{ltk_key = 0x8076090, ltk_data = 0x5b8025e8, ltk_free = 0x8076160 <conn_counter_destroy>}, {ltk_key = 0x80ced40, ltk_data = 0x5b8009c0, ltk_free = 0x80cec20 <slap_sl_mem_destroy>}, {ltk_key = 0x8d5edf8, ltk_data = 0x5b8026d8, ltk_free = 0xb7788ee0 <bdb_reader_free>}, {ltk_key = 0x808b890, ltk_data = 0x0, ltk_free = 0x808b680 <slap_op_q_destroy>}, {ltk_key = 0xb777b100, ltk_data = 0x58ff9008, ltk_free = 0xb777b1f0 <search_stack_free>}, {ltk_key = 0x8d5ca30, ltk_data = 0x56c81ce0, ltk_free = 0xb7788ee0 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x54de7778, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = <value optimized out> keyslot = 902 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #10 0xb7c83f3b in start_thread (arg=0x5c6fcb90) at pthread_create.c:297 __res = <value optimized out> __ignore1 = <value optimized out> __ignore2 = <value optimized out> pd = (struct pthread *) 0x5c6fcb90 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211551756, 0, 4001536, 1550828744, -880287418, -2072111471}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0xb7c83e9b}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> robust = <value optimized out> #11 0xb7c0abee in clone () from /usr/lib/debug/libc.so.6 fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres = {mnt_fsname = 0x0, mnt_dir = 0x0, mnt_type = 0x0, mnt_opts = 0x0, mnt_freq = 0, mnt_passno = 0}, fs_ret = {fs_spec = 0x0, fs_file = 0x0, fs_vfstype = 0x0, fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0, fs_passno = 0}} __elf_set___libc_subfreeres_element_fstab_free__ = (const void *) 0xb7c48820 generalizedTimeIndexer() segfaults since it assumes slap_sl_malloc() always succeeds: keys = slap_sl_malloc( sizeof( struct berval ) * (i+1), ctx ); [...] keys[j].bv_val = NULL; keys[j].bv_len = 0; Looking back through the call chain, do_syncrepl() sets op->o_tmpmemctx to NULL: /* use global malloc for now */ op->o_tmpmemctx = NULL; op->o_tmpmfuncs = &ch_mfuncs; so generalizedTimeIndexer()'s call to slap_sl_malloc() falls back to ber_memalloc_x() due to the null ctx. If malloc() fails there, NULL is eventually returned to the original caller of slap_sl_malloc(), likely resulting in a segfault. All of the indexing routines seem to ignore slap_sl_malloc()'s return value, opening them up to this problem, too. Someone else will need to step in with a proper fix since I don't know much about slapd internals, but it seems that if these routines are being called with a deliberate null ctx, they should be checking for malloc failure. A cursory glance around back-bdb indicates that indexing function callers already handle failure return codes gracefully.

1 0

(ITS#6053) gnutls doen't initialize gnutls_x509_privkey_t structure, leading to TLS init def ctx failed: -50
by jwm＠horde.net 10 Apr '09

10 Apr '09

Full_Name: John Morrissey Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) tlsg_ctx_init() doesn't initialize the gnutls_x509_privkey_t structure before passing it to gnutls_x509_privkey_import. This yields: main: TLS init def ctx failed: -50 on slapd startup. gnutls error -50 is GNUTLS_E_INVALID_REQUEST. Initializing the structure with gnutls_x509_privkey_init() allows slapd startup to succeed. [jwm@coral.lab.isis:pts/1 ~> dpkg -l libgnutls26 [...] ii libgnutls26 2.6.4-2 the GNU TLS library - runtime library --- openldap-2.4.16.orig/libraries/libldap/tls_g.c +++ openldap-2.4.16/libraries/libldap/tls_g.c @@ -354,6 +354,9 @@ gnutls_x509_crt_t certs[VERIFY_DEPTH]; unsigned int max = VERIFY_DEPTH; + rc = gnutls_x509_privkey_init(&key); + if ( rc < 0 ) return -1; + /* OpenSSL builds the cert chain for us, but GnuTLS * expects it to be present in the certfile. If it's * not, we have to build it ourselves. So we have to

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 10 Apr '09

10 Apr '09

luca.scamoni(a)sys-net.it ha scritto: > luca.scamoni(a)sys-net.it ha scritto: New update The problem is still there. Same call in bdb_rdn_cmp. strncmp fails because one of the berval passed to the function has inconsistent values between bv_len and bv_val Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6052) Small typo in SASL chapter (15) in administration guide
by kkalev＠gmail.com 10 Apr '09

10 Apr '09

Full_Name: Kostas Kalevras Version: 2.4 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.102.247.75) In OpenLDAP 2.4 Administration Guide, chapter 15 (Using SASL) in 15.3.3.1. Notes on Proxy Authorization Rules the documentation states that the administrator can use regular expression matching like: authzTo: dn.regex=^uid=[^,]*,dc=example,dc=com$ I believe the correct form should be: authzTo: dn.regex:"^uid=[^,]*,dc=example,dc=com$" Notice the : instead of = and the quotes around the regular expression.

1 0

(ITS#6051) JLDAP SASL issue
by hendrik.saly＠gmx.de 10 Apr '09

10 Apr '09

Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: Linux 2.6, Sun JDK 1.5 URL: http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell… Submission from: (NULL) (78.43.136.21) While trying to use SASL with JLDAP i encounter a potential minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v 1.154 2006/02/09 08:43:45 sunilk Exp $ Seems the bind method on line 1730 fails to release the bind semaphore properly under some circumstances. I tried to use more than the wit JLDAP provided SASL mechanisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with a Java 1.5 sasl client. All works very well but CRAM login for example fails. I have a workaround http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell… but i thinks there are some problems with the bind semaphore. The wrapping code is here http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/org/mule/t… If neccessary i can provide a test suite for this. Thanks Hendrik

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by hyc＠symas.com 09 Apr '09

09 Apr '09

toby(a)inf.ed.ac.uk wrote: > OK, this is my first crash since moving to 2.4.16: > > Slightly different from the previous ones, but is coming through > pcache.c:remove_from_template and, according to slapd log, was > removing queries from cache when crash occurred: > > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 5 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 26 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 4 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 25 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 3 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 24 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 2 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 23 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 1 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 22 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 0 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 21 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e6eb0 > > > Here's the backtrace: > > Program terminated with signal 11, Segmentation fault. > #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) > at pcache.c:694 > 694 return pcache_filter_cmp( q1->first, q2->first ); > (gdb) bt > #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) > at pcache.c:694 > #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, > fcmp=0x81764d8<pcache_query_cmp>) at tavl.c:202 > #2 0x08177ab4 in remove_from_template (qc=0xb1f0e900, > template=0x94e6eb0) > at pcache.c:1302 > #3 0x0817b57d in consistency_check (ctx=0xb44201d0, arg=0x9537c50) > at pcache.c:2597 > #4 0x0819fd01 in ldap_int_thread_pool_wrapper (xpool=0x94a8fa0) at > tpool.c:663 > #5 0x009c546b in start_thread () from /lib/libpthread.so.0 > #6 0x0091cdbe in clone () from /lib/libc.so.6 > (gdb) > (gdb) p q1->first > $3 = (Filter *) 0xb1f0d4c0 > (gdb) p q2->first > Cannot access memory at address 0x83e58959 > > Let me know what else would be useful from this backtrace. Nothing obvious is jumping out here. Can you run a few of these slapds with libefence or valgrind? -- -- Howard Chu CTO, 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#6050) make install overwrites schema dir
by hyc＠symas.com 09 Apr '09

09 Apr '09

tmackey(a)zetta.net wrote: > Full_Name: Theral Mackey > Version: 2.4.16 > OS: Linux/Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.200.8.2) > > > Running make install leaves an existing slapd.conf alone, but happily nukes and > replaces the existing schema directory, taking with it any additional or custom > schema, leaving you with only the ones installed by default (hooray for svn and > backups!). No, it doesn't. > For consistency, it should probably either nuke slapd.conf as well, or leave an > existing schema dir alone (I vote for option 2). > fix should be as simple as an 'if [ ! -d $base/schema ] ; then (mkdir, cp > schemas, etc) ; fi' around where it drops the schemas in place in the Makefile Since you're already looking in the Makefile, you should see this for the install-schema: rule... ### install-schema: FORCE @if test -d $(DESTDIR)$(schemadir) ; then \ echo "MOVING EXISTING SCHEMA DIR to $(DESTDIR)$(schemadir).$$$$" ; \ mv $(DESTDIR)$(schemadir) $(DESTDIR)$(schemadir).$$$$ ; \ fi $(MKDIR) $(DESTDIR)$(schemadir) ### The existing schema directory is simply renamed / moved out of the way. If you had any custom schema files stored there, they are still there. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6050) make install overwrites schema dir
by tmackey＠zetta.net 09 Apr '09

09 Apr '09

Full_Name: Theral Mackey Version: 2.4.16 OS: Linux/Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.200.8.2) Running make install leaves an existing slapd.conf alone, but happily nukes and replaces the existing schema directory, taking with it any additional or custom schema, leaving you with only the ones installed by default (hooray for svn and backups!). For consistency, it should probably either nuke slapd.conf as well, or leave an existing schema dir alone (I vote for option 2). fix should be as simple as an 'if [ ! -d $base/schema ] ; then (mkdir, cp schemas, etc) ; fi' around where it drops the schemas in place in the Makefile

1 0

Re: (ITS#5856) adauth overlay contribution
by hyc＠symas.com 09 Apr '09

09 Apr '09

neil.dunbar(a)hp.com wrote: > On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote: >> Andrew: >>> One suggestion following a very quick scan of the code: I think it >>> would be worth bringing the warning about turning off TLS checks >>> into the manual page. >> >> Agreed. Done. >> >>> In particular, there is no reason for this >>> to be AD-specific and it should be easy to adapt it to authenticate >>> against any [collection of] remote LDAP servers. >> >> Actually, it may not be AD specific as is. > > Are we any further forward to getting this rolled into contrib? Is there > more we need to do to make it fit better? The tarball has been sitting > there a while, it would seem. I've reviewed the package and have some comments. I'm puzzled by the design of this overlay; in ActiveDirectory a user can exist in only one domain and there is a one-to-one mapping between their domain name and the suffix of their LDAP DN. As such, the lookup of the adauth_domain_attribute seems clumsy and unnecessary. The adauth_default_realm and adauth_default_domain terms are confusing. Your adauth_default_realm item is really just the hostname of a particular server. Your use of the word "realm" is basically inconsistent with common usage of this term. The usage for adauth_mapping is clumsy; you could simply have made it a list of LDAP URLs and not bothered with an external file. Is there a commonly used external file that other software uses, that prompted this approach? The description of adauth_dn_attribute is misleading. Is it a DN, or is it a userPrincipalName? In what way is this a "map" at all? Examining the code, it is simply "the DN of the user to Bind against on the remote LDAP server" - it is not a map, nor is it a userPrincipalName. I wonder in what context this overlay is easily used. If I have 100,000 users in my LDAP directory, I don't want to maintain 100,000 AD_DN attributes for them; I want a simple rule that actually performs an algorithmic mapping of their local DN to their remote DN. I suppose using an AD_DN attribute for the users whose DNs don't easily map might be a good fallback, but it shouldn't be the primary mechanism for linking a local user to a remote user. I would re-use the authz-regexp machinery here. It seems there's a lot of AD-specific overhead in this code, for what is really a pretty simple and generic operation - passthru Bind to a remote LDAP server. I would have used the back-ldap/chain.c code instead, which would also provide connection pooling and the other benefits of back-ldap's already comprehensive support for communicating with remote LDAP servers. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6049) Client tools' help inaccurate
by jzeleny＠redhat.com 09 Apr '09

09 Apr '09

Full_Name: Jan Zeleny Version: 2.4.15 OS: Fedora 11 URL: http://jzeleny.fedorapeople.org/patches/openldap/openldap-options.patch Submission from: (NULL) (62.40.79.66) Client tools share a part of help printed to stdout. In this shared help, there are some options, even if they are not in fact supported by all client tools. I've made a simple patch to resolve this minor issue.

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 09 Apr '09

09 Apr '09

OK, this is my first crash since moving to 2.4.16: Slightly different from the previous ones, but is coming through pcache.c:remove_from_template and, according to slapd log, was removing queries from cache when crash occurred: Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 5 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 26 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 4 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 25 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 3 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 24 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 2 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 23 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 1 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 22 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 0 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 21 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e6eb0 Here's the backtrace: Program terminated with signal 11, Segmentation fault. #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) at pcache.c:694 694 return pcache_filter_cmp( q1->first, q2->first ); (gdb) bt #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) at pcache.c:694 #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, fcmp=0x81764d8 <pcache_query_cmp>) at tavl.c:202 #2 0x08177ab4 in remove_from_template (qc=0xb1f0e900, template=0x94e6eb0) at pcache.c:1302 #3 0x0817b57d in consistency_check (ctx=0xb44201d0, arg=0x9537c50) at pcache.c:2597 #4 0x0819fd01 in ldap_int_thread_pool_wrapper (xpool=0x94a8fa0) at tpool.c:663 #5 0x009c546b in start_thread () from /lib/libpthread.so.0 #6 0x0091cdbe in clone () from /lib/libc.so.6 (gdb) (gdb) p q1->first $3 = (Filter *) 0xb1f0d4c0 (gdb) p q2->first Cannot access memory at address 0x83e58959 Let me know what else would be useful from this backtrace. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 08 Apr '09

08 Apr '09

luca.scamoni(a)sys-net.it ha scritto: > Howard Chu ha scritto: >> This trace is bogus, there's no call from slapd_daemon_destroy() to >> epoll_wait() in the code. And you wouldn't have gotten to >> slapd_daemon_destroy() unless you were shutting down. >> >> >> This is also bogus; is this an optimized compile? It's always hard to >> tell how much to trust the debugger here; if there are no further stack >> frames then possibly the stack was overwritten. But if you compiled with >> any type of optimization, and didn't use -fno-omit-frame-pointer, then >> that may be all that's happening here. >> > I managed to find out how to reproduce the issue. Now it's deterministic > and happens with openldap-2.4.16. > The segfault can be caused by performing an ldapmodify on a specific > entry replacing a binary attribute certificateRevocationList. > > I'm sending privately the backtrace analized with gdb and the slapd.conf > file Another update The issue seems to be in the order in which rwm and syncprov are invoked. If the slapd.conf file contains: database hdb [...] overlay rwm [...] overlay syncprov [...] the modification causes slapd to segfault if the two overlays are swapped database hdb [...] overlay syncprov [...] overlay rwm [...] it doesn't. So there is something wrong in the interaction between these two Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by Kurt＠OpenLDAP.org 07 Apr '09

07 Apr '09

On Apr 7, 2009, at 5:50 AM, h.b.furuseth(a)usit.uio.no wrote: > Kurt(a)OpenLDAP.org writes: >> This problem has been fixed. Unfortunately, there will be a hole in >> the archives unless someone happens to have a decent mbox archives >> for >> backfill (maybe one of the 3rd party mail archives have mbox archives >> available). > > I'm getting backups of my last weeks' mail now, roughly in STMP stream > format as far as I can tell. Will send it later. Need to filter out > the openldap messages and check that I got it right first. The archives were backfilled late yesterday.... -- Kurt

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by Duncan.Gibb＠SiriusIT.co.uk 07 Apr '09

07 Apr '09

h.b.furuseth(a)usit.uio.no wrote: KZ> Unfortunately, there will be a hole in the archives unless someone KZ> happens to have a decent mbox archives for backfill HBF> I'm getting backups of my last weeks' mail now, roughly in STMP HBF> stream format as far as I can tell. Will send it later. We should have archives of traffic on openldap-its, -technical, -devel, and -bugs (under Cyrus, so not in mbox format). Give me a shout if you would like them exported. Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by h.b.furuseth＠usit.uio.no 07 Apr '09

07 Apr '09

Kurt(a)OpenLDAP.org writes: > This problem has been fixed. Unfortunately, there will be a hole in > the archives unless someone happens to have a decent mbox archives for > backfill (maybe one of the 3rd party mail archives have mbox archives > available). I'm getting backups of my last weeks' mail now, roughly in STMP stream format as far as I can tell. Will send it later. Need to filter out the openldap messages and check that I got it right first. -- Hallvard

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 07 Apr '09

07 Apr '09

> When a program aborts it will print an error message on stderr. It > would be useful to have that message. Long since disappeared for this case, I'm afraid. I'll try and get it in the future. > Can you please update to RE24, the 2.4.16 candidate, and see if the > behavior has changed? Also, can you please be sure to compile > without optimization (or with frame pointers intact; gcc > -fno-omit-frame-pointer); there seem to be a few functions missing > in these stack traces. > > Also grab the latest overlays/pcache.c (1.168). It probably won't > fix things, but it should make the crashes a little more obvious. OK, I've built 2.4.16 (which I see has the new pcache.c) with no optimisation (-O0 and -fno-omit-frame-pointer) and will put in place in our test lab. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 07 Apr '09

07 Apr '09

Howard Chu ha scritto: > > This trace is bogus, there's no call from slapd_daemon_destroy() to > epoll_wait() in the code. And you wouldn't have gotten to > slapd_daemon_destroy() unless you were shutting down. > > > This is also bogus; is this an optimized compile? It's always hard to > tell how much to trust the debugger here; if there are no further stack > frames then possibly the stack was overwritten. But if you compiled with > any type of optimization, and didn't use -fno-omit-frame-pointer, then > that may be all that's happening here. > I managed to find out how to reproduce the issue. Now it's deterministic and happens with openldap-2.4.16. The segfault can be caused by performing an ldapmodify on a specific entry replacing a binary attribute certificateRevocationList. I'm sending privately the backtrace analized with gdb and the slapd.conf file Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by Kurt＠OpenLDAP.org 06 Apr '09

06 Apr '09

On Apr 6, 2009, at 2:27 PM, ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Just a quick ticket to mention that since the upgrade all the > mailing list > archives have stopped at March. This problem has been fixed. Unfortunately, there will be a hole in the archives unless someone happens to have a decent mbox archives for backfill (maybe one of the 3rd party mail archives have mbox archives available). -- Kurt

1 0

(ITS#6048) All mailing list archives have stopped at March
by ghenry＠OpenLDAP.org 06 Apr '09

06 Apr '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Just a quick ticket to mention that since the upgrade all the mailing list archives have stopped at March. Thanks.

1 0

Re: (ITS#6047) bdb cache seg. fault
by rein＠OpenLDAP.org 06 Apr '09

06 Apr '09

quanah(a)zimbra.com wrote: > --On Monday, April 06, 2009 6:15 PM +0000 rein(a)OpenLDAP.org wrote: >> I have had a couple of seg. faults in back-bdb cache.c during full resync >> of a consumer. The default bdb *cachesize configuration was being used >> (which was way too low now that cache limits are enforced more >> strictly..). Some info from two of the core files are listed below, the >> core files are available for further analyze. > > DB_CONFIG cachesize or slapd.conf cachesize? DB_CONFIG: set_cachesize 0 75497472 0 set_lk_max_locks 10000 set_lk_max_objects 5000 No *cachesize directives in slapd.conf. Rein

1 0

Re: (ITS#6047) bdb cache seg. fault
by quanah＠zimbra.com 06 Apr '09

06 Apr '09

--On Monday, April 06, 2009 6:15 PM +0000 rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: 2.4.16 > OS: linux > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > I have had a couple of seg. faults in back-bdb cache.c during full resync > of a consumer. The default bdb *cachesize configuration was being used > (which was way too low now that cache limits are enforced more > strictly..). Some info from two of the core files are listed below, the > core files are available for further analyze. DB_CONFIG cachesize or slapd.conf cachesize? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs