March 2007 - openldap-bugs

Re: (ITS#4892) slapd HEAD crashes with ldapi:// and SASL EXTERNAL
by michael＠stroeder.com 22 Mar '07

22 Mar '07

Debug output related to this: ---------------------------- `slapd -d 255` --------------------------- daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy >>> >>> slap_listener(ldapi://%2fhome%2fmichael%2fBizness%2fOpenLDAP%2fODD_2006%2fslapd-socket) daemon: listen=8, new connection on 15 daemon: added 15r (active) listener=(nil) daemon: activity on 2 descriptors daemon: activity on: 15r daemon: read active on 15 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(15) connection_get(15): got connid=0 connection_read(15): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 18 02 01 01 60 13 02 0....`.. ldap_read: want=18, got=18 0000: 01 03 04 00 a3 0c 04 08 45 58 54 45 52 4e 41 4c ........EXTERNAL 0010: 04 00 .. ber_get_next: tag 0x30 len 24 contents: ber_dump: buf=0x08247cb0 ptr=0x08247cb0 end=0x08247cc8 len=24 0000: 02 01 01 60 13 02 01 03 04 00 a3 0c 04 08 45 58 ...`..........EX 0010: 54 45 52 4e 41 4c 04 00 TERNAL.. ber_get_next ldap_read: want=8 error=Resource temporarily unavailable do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x08247cb0 ptr=0x08247cb3 end=0x08247cc8 len=21 0000: 60 13 02 01 03 04 00 a3 0c 04 08 45 58 54 45 52 `..........EXTER 0010: 4e 41 4c 04 00 NAL.. ber_scanf fmt ({m) ber: ber_dump: buf=0x08247cb0 ptr=0x08247cba end=0x08247cc8 len=14 0000: 00 0c 04 08 45 58 54 45 52 4e 41 4c 04 00 ....EXTERNAL.. ber_scanf fmt (m) ber: ber_dump: buf=0x08247cb0 ptr=0x08247cc6 end=0x08247cc8 len=2 0000: 00 00 .. ber_scanf fmt (}}) ber: ber_dump: buf=0x08247cb0 ptr=0x08247cc8 end=0x08247cc8 len=0 >>> >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech EXTERNAL ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 SASL Canonicalize [conn=0]: authcid="gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth" slap_sasl_getdn: conn 0 id=gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth [len=59] ==>slap_sasl2dn: converting SASL name gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth' ==> rewrite_rule_apply rule='gidnumber=([0-9]+)\+uidnumber=([0-9]+),cn=peercred,cn=external,cn=auth' string='gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))'} [rw] authid: "gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth" -> "ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))" slap_parseURI: parsing ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100)) ldap_url_parse_ext(ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))) str2filter "(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))" put_filter: "(&(objectClass=posixAccount)(uidNumber=500)(gidNumber=100))" put_filter: AND put_filter_list "(objectClass=posixAccount)(uidNumber=500)(gidNumber=100)" put_filter: "(objectClass=posixAccount)" put_filter: simple put_simple_filter: "objectClass=posixAccount" put_filter: "(uidNumber=500)" put_filter: simple put_simple_filter: "uidNumber=500" put_filter: "(gidNumber=100)" put_filter: simple put_simple_filter: "gidNumber=100" begin get_filter AND begin get_filter_list begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0xb1f76154 ptr=0xb1f76156 end=0xb1f76197 len=65 0000: a3 1b 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 04 ....objectClass. 0010: 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 a3 10 04 .posixAccount... 0020: 09 75 69 64 4e 75 6d 62 65 72 04 03 35 30 30 a3 .uidNumber..500. 0030: 10 04 09 67 69 64 4e 75 6d 62 65 72 04 03 31 30 ...gidNumber..10 0040: 30 0 end get_filter 0 begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0xb1f76154 ptr=0xb1f76173 end=0xb1f76197 len=36 0000: 00 10 04 09 75 69 64 4e 75 6d 62 65 72 04 03 35 ....uidNumber..5 0010: 30 30 a3 10 04 09 67 69 64 4e 75 6d 62 65 72 04 00....gidNumber. 0020: 03 31 30 30 .100 end get_filter 0 begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0xb1f76154 ptr=0xb1f76185 end=0xb1f76197 len=18 0000: 00 10 04 09 67 69 64 4e 75 6d 62 65 72 04 03 31 ....gidNumber..1 0010: 30 30 00 end get_filter 0 end get_filter_list end get_filter 0 >>> >>> dnNormalize: <ou=Users,ou=odd2006,dc=block-floete,dc=de> => ldap_bv2dn(ou=Users,ou=odd2006,dc=block-floete,dc=de,0) <= ldap_bv2dn(ou=Users,ou=odd2006,dc=block-floete,dc=de)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=users,ou=odd2006,dc=block-floete,dc=de)=0 <<< dnNormalize: <ou=users,ou=odd2006,dc=block-floete,dc=de> slap_sasl2dn: performing internal search (base=ou=users,ou=odd2006,dc=block-floete,dc=de, scope=2) => hdb_search bdb_dn2entry("ou=users,ou=odd2006,dc=block-floete,dc=de") entry_decode: "" <= entry_decode() => access_allowed: auth access to "ou=Users,ou=odd2006,dc=block-floete,dc=de" "entry" requested => dn: [4] ou=users,ou=odd2006,dc=block-floete,dc=de => acl_get: [4] matched => acl_get: [4] attr entry => acl_mask: access to entry "ou=Users,ou=odd2006,dc=block-floete,dc=de", attr "entry" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: * <= acl_mask: [2] applying read(=rscxd) (stop) <= acl_mask: [2] mask: read(=rscxd) => slap_access_allowed: auth access granted by read(=rscxd) => access_allowed: auth access granted by read(=rscxd) search_candidates: base="ou=users,ou=odd2006,dc=block-floete,dc=de" (0x00000002) scope=2 => hdb_dn2idl("ou=users,ou=odd2006,dc=block-floete,dc=de") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [5941c014] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=0 last=0 <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=0 last=0 <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=2 last=0 <= bdb_filter_candidates: id=0 first=2 last=0 bdb_search_candidates: id=0 first=2 last=0 hdb_search: no candidates send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=0 matched="" text="" <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=0]: slapAuthcDN="gidNumber=100+uidNumber=500,cn=peercred,cn=external,cn=auth" ./start-slapd.sh: line 12: 4310 Segmentation fault ${OPENLDAP_PREFIX}/libexec/slapd -d 255 -h "ldap://0.0.0.0:2006 ldapi://%2fhome%2fmichael%2fBizness%2fOpenLDAP%2fODD_2006%2fslapd-socket" -n slapd-odd2006 -u michael -o slp=off -f ${LOCALCONFIG}/slapd.conf

1 0

Re: Tranlucent Overlay (ITS#4889)
by hyc＠symas.com 22 Mar '07

22 Mar '07

ando(a)sys-net.it wrote: > ghenry(a)suretecsystems.com wrote: > >> That's strange though, as I merely followed the slapd-ldap(5) man page: > > Slapo-rwm(5) works just fine by itself; the point is that when it was > designed there was no cleanup hook in the callback structure, so it was > __permmently replacing__ the original values of request DN and DN-valued > attributes instead of __temporarily replace__ them and set the original > values back when done. So it interacts poorly with other, more recent > overlays. Given that this particular rwm invocation isn't doing anything, it should be easy enough to just comment it out and see if the problem still occurs. Curious that your opening log says "No dynamic config support for database bdb." Are you sure you have a clean install here? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Tranlucent Overlay (ITS#4889)
by ando＠sys-net.it 22 Mar '07

22 Mar '07

ghenry(a)suretecsystems.com wrote: > That's strange though, as I merely followed the slapd-ldap(5) man page: Slapo-rwm(5) works just fine by itself; the point is that when it was designed there was no cleanup hook in the callback structure, so it was __permmently replacing__ the original values of request DN and DN-valued attributes instead of __temporarily replace__ them and set the original values back when done. So it interacts poorly with other, more recent overlays. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4888) Enhance back-sql with paged results
by ando＠sys-net.it 22 Mar '07

22 Mar '07

adamson(a)andrew.cmu.edu wrote: > When I checked on the patch file in my Emacs window this morning I saw the > "modified buffer" flag was still on because I hadn't saved the final > version. Grrrr. It included the function declarations and one last fix. > Sorry about that. :) > When I extract the last ID number from the cookie, I > have to make sure we're in the same objectClass as when the ID number was > saved. > I've replaced the patch file on my web server. If it doesn't fix the > root entry bug you're seeing, could you show me the search you're > performing? I'll have to more closely follow what's happening in the > switch ( bsi.bsi_scope ) { > segment around line 2115 in backsql_search() to see if there is some > special case for the root entry. It works now, thanks. I'll commit the patch, but I think we should definitely move the cookie stuff to the frontend and generalize the cookie stuff to use bervals before we close this ITS. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: Tranlucent Overlay (ITS#4889)
by ghenry＠suretecsystems.com 22 Mar '07

22 Mar '07

<quote who="Pierangelo Masarati"> > In re23 slapo-rwm should not be used in conjunction with other overlays; > there > is a number of reports about interoperability issues, and only recently > Howard > fixed (I should say "reworked") it in HEAD/re24. Can you reproduce the > same > issue with HEAD? Will do later this week. That's strange though, as I merely followed the slapd-ldap(5) man page: suffixmassage, map, rewrite* These directives are no longer supported by back-ldap; their functionality is now delegated to the rwm overlay. Essentially, add a statement overlay rwm first, and prefix all rewrite/map statements with rwm- to obtain the original behavior. See slapo-rwm(5) for details. Maybe a man page patch is needed to stop others hitting this. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4876) Multiple levels of uniqueness
by hyc＠symas.com 22 Mar '07

22 Mar '07

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.33 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > > > In using the uniqueness overlay, I found there are times I want to apply > uniqueness rules differently based on (sub)tree. For example, I might like > something along these lines where the db starts at dc=stanford,dc=edu: The unique overlay in HEAD now supports this functionality. See the updated manpage. test024 has also been updated accordingly, if you need examples. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4892) slapd HEAD crashes with ldapi:// and SASL EXTERNAL
by michael＠stroeder.com 22 Mar '07

22 Mar '07

Full_Name: Michael Ströder Version: HEAD OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.31.177) HI! slapd.conf contains (identiation and line-wrapping may be screwed up: # EXTERNAL over Unix Domain socket authz-regexp "gidnumber=([0-9]+)\\+uidnumber=([0-9]+),cn=peercred,cn=external,cn=auth" "ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=$2)(gidNumber=$1))" Ciao, Michael. $ ldapwhoami -H ldapi://%2fhome%2fmichael%2fBizness%2fOpenLDAP%2fODD_2006%2fslapd-socket -Y EXTERNAL SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

1 0

(ITS#4891) OpenLDAP with dynlist crash
by socrtp-ldap＠soclab.eu.org 22 Mar '07

22 Mar '07

Full_Name: Piotr Stolc Version: 2.3.34 OS: Gentoo, NetBSD URL: http://lysergic.soclab.eu.org/dynlist-bug.ldif Submission from: (NULL) (195.8.99.234) I found this bug while trying to run OpenLDAP with dynlist overlay and my own schema. The functionality of dynlist overlay works ok, but when browsing LDAP tree with PHPLDAPAdmin the server dies. I spent a few hours debugging the problem (accesslog overlay is cool :)) and created simple sample entries using default schemas. Here is what I have found: OpenLDAP server dies on this query: $ ldapsearch -D cn=Manager,dc=test,dc=pl -W -x -h 10.1.1.15 -b dc=test,dc=pl -s one dn Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=test,dc=pl> with scope oneLevel # filter: (objectclass=*) # requesting: dn # # Manager, test.pl dn: cn=Manager,dc=test,dc=pl # testGroup, test.pl dn: ou=testGroup,dc=test,dc=pl ldap_result: Can't contact LDAP server (-1) It has also problem with another query - one of the slapd processes locks up with nearly 100% CPU usage: $ ldapsearch -D cn=Manager,dc=test,dc=pl -W -x -h 10.1.1.15 -b cn=testList,dc=test,dc=pl -s one mail The following query works fine and shows that dynlist overlay is working: $ ldapsearch -D cn=Manager,dc=test,dc=pl -W -x -h 10.1.1.15 -b cn=testList,dc=test,dc=pl mail The problem shows up with the latest stable version of OpenLDAP 2.3.34 on Gentoo Linux and with OpenLDAP 2.3.32 on NetBSD. I've pasted into URL field link to the LDIF with the sample dc=test,dc=pl structure that shows the error. Here is the config for "dc=test,dc=pl" I've used: database bdb suffix "dc=test,dc=pl" rootdn "cn=Manager,dc=test,dc=pl" rootpw secret directory /var/lib/openldap-data-test index cn eq overlay dynlist dynlist-attrset groupOfURLs memberURL

1 0

(ITS#4890) Enhancement: Default Values overlay (patch)
by docelic＠mail.inet.hr 22 Mar '07

22 Mar '07

Full_Name: Davor Ocelic Version: CVS-HEAD OS: Linux URL: http://www.hcoop.net/~docelic/openldap-slapd.overlays.defvals.patch Submission from: (NULL) (213.147.110.16) Hello, Attached is a patch which adds a "Default Attribute Values" functionality to OpenLDAP. It is implemented as an overlay named "defvals", and the patch is done against cvs-head of today. Complete documentation is included in the slapo-defvals(5) manual page. The overlay code itself is commented as well, as a help for others writing overlays. Feel free to trim comments or improve code as you see fit. Davor Ocelic

1 0

Re: (ITS#4888) Enhance back-sql with paged results
by adamson＠andrew.cmu.edu 22 Mar '07

22 Mar '07

Hi Pierangelo > Let me note that the patch doesn't build fine (you need to declare in > advance the static functions you're only defining at the end), and it > seems to work incorrectly. By running the simple sql-test000 with mysql > (which fails because now the order has changed; my fault: should have > added -S "" to searches), if I search without the control, I correctly > get 6 entries and a referral; if I search with paged results and a page > size less than 6, I only get 5 entries. The root entry is missing, but > I have no idea of the reason, I couldn't infer anything from the code or > the logs. Can you check? When I checked on the patch file in my Emacs window this morning I saw the "modified buffer" flag was still on because I hadn't saved the final version. Grrrr. It included the function declarations and one last fix. Sorry about that. When I extract the last ID number from the cookie, I have to make sure we're in the same objectClass as when the ID number was saved. I've replaced the patch file on my web server. If it doesn't fix the root entry bug you're seeing, could you show me the search you're performing? I'll have to more closely follow what's happening in the switch ( bsi.bsi_scope ) { segment around line 2115 in backsql_search() to see if there is some special case for the root entry. -Mark Adamson Carnegie Mellon

1 0

(ITS#4889) Tranlucent Overlay
by ghenry＠suretecsystems.com 22 Mar '07

22 Mar '07

Full_Name: Gavin Henry Version: 2.3.34 OS: FC6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Dear All, Just been playing iwth slapo-translucent, and ldapmodified an entry on the remote side successfully. However, when I search for that entry, after the first or second search, slapd aborts. I merely changed a birthday and title for my own ghenry entry Here my slapd.conf: ------------------------- include /usr/local/etc/openldap/schema/core.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb.la moduleload back_ldap.la moduleload translucent.la moduleload rwm.la database bdb directory /usr/local/var/openldap-data cachesize 10000 suffix "dc=suretecsystems,dc=com" rootdn "cn=manager,dc=suretecsystems,dc=com" rootpw secret index default eq index objectClass,uid,dc,o,ou overlay translucent overlay rwm uri ldap://192.168.10.103:389 lastmod off idassert-bind binddn="cn=manager,dc=suretecsystems,dc=com" credentials=secret rwm-map objectclass * * rwm-map attribute * * ------------------------- Using db-4.2.52 and the 5 patches. He's a gdb session: [Thread debugging using libthread_db enabled] [New Thread -1209051456 (LWP 4529)] @(#) $OpenLDAP: slapd 2.3.34 (Mar 20 2007 14:53:32) $ ghenry@suretec:/home/ghenry/openldap/openldap-2.3.34/servers/slapd WARNING: No dynamic config support for database bdb. WARNING: No dynamic config support for overlay rwm. WARNING: No dynamic config support for overlay translucent. bdb_db_open: unclean shutdown detected; attempting recovery. slapd starting [New Thread -1547441264 (LWP 4532)] conn=0 fd=15 ACCEPT from IP=127.0.0.1:33269 (IP=0.0.0.0:389) [New Thread -1557931120 (LWP 4534)] conn=0 op=0 BIND dn="" method=128 conn=0 op=0 RESULT tag=97 err=0 text= [New Thread -1569473648 (LWP 4535)] conn=0 op=1 SRCH base="dc=suretecsystems,dc=com" scope=2 deref=0 filter="(uid=ghenry)" request done: ld 0x8e0dd10 msgid 1 request done: ld 0x8e0dd10 msgid 2 conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=0 op=2 UNBIND conn=0 fd=15 closed *** glibc detected *** /usr/local/libexec/slapd: corrupted double-linked list: 0x08e19458 *** ======= Backtrace: ========= /lib/libc.so.6[0xb0448b] /lib/libc.so.6[0xb066f3] /lib/libc.so.6(__libc_calloc+0x8d)[0xb07bdd] /lib/libc.so.6(open_memstream+0x5d)[0xafce7d] /lib/libc.so.6(__vsyslog_chk+0x76)[0xb69656] /lib/libc.so.6(syslog+0x2a)[0xb69bfa] /usr/local/libexec/slapd[0x80687e5] /usr/local/libexec/slapd[0x8068c9c] /usr/local/lib/libldap_r-2.3.so.0[0x11b56d] /lib/libpthread.so.0[0xc133db] /lib/libc.so.6(clone+0x5e)[0xb6d26e] ======= Memory map: ======== 00110000-00148000 r-xp 00000000 fd:00 10953537 /usr/local/lib/libldap_r-2.3.so.0.2.22 00148000-0014a000 rwxp 00037000 fd:00 10953537 /usr/local/lib/libldap_r-2.3.so.0.2.22 0014a000-0014f000 rwxp 0014a000 00:00 0 0014f000-0015a000 r-xp 00000000 fd:00 10953351 /usr/local/lib/liblber-2.3.so.0.2.22 0015a000-0015b000 rwxp 0000a000 fd:00 10953351 /usr/local/lib/liblber-2.3.so.0.2.22 0015b000-0015f000 r-xp 00000000 fd:00 11025778 /usr/lib/sasl2/libcrammd5.so.2.0.22 0015f000-00160000 rwxp 00003000 fd:00 11025778 /usr/lib/sasl2/libcrammd5.so.2.0.22 00160000-0023b000 r-xp 00000000 fd:00 11031861 /usr/lib/sasl2/libsasldb.so.2.0.22 0023b000-0023d000 rwxp 000db000 fd:00 11031861 /usr/lib/sasl2/libsasldb.so.2.0.22 0023d000-00251000 r-xp 00000000 fd:00 820357 /usr/local/libexec/openldap/back_ldap-2.3.so.0.2.22 00251000-00253000 rwxp 00013000 fd:00 820357 /usr/local/libexec/openldap/back_ldap-2.3.so.0.2.22 00253000-0025e000 r-xp 00000000 fd:00 2290131 /lib/libgcc_s-4.1.1-20070105.so.1 0025e000-0025f000 rwxp 0000a000 fd:00 2290131 /lib/libgcc_s-4.1.1-20070105.so.1 0027c000-00282000 r-xp 00000000 fd:00 10928729 /usr/lib/libltdl.so.3.1.4 00282000-00283000 rwxp 00005000 fd:00 10928729 /usr/lib/libltdl.so.3.1.4 002e2000-002e9000 r-xp 00000000 fd:00 10929498 /usr/lib/libwrap.so.0.7.6 002e9000-002ea000 rwxp 00007000 fd:00 10929498 /usr/lib/libwrap.so.0.7.6 002ea000-003a5000 r-xp 00000000 fd:00 393521 /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so 003a5000-003a7000 rwxp 000bb000 fd:00 393521 /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so 003f3000-003fc000 r-xp 00000000 fd:00 2289320 /lib/libnss_files-2.5.so 003fc000-003fd000 r-xp 00008000 fd:00 2289320 /lib/libnss_files-2.5.so 003fd000-003fe000 rwxp 00009000 fd:00 2289320 /lib/libnss_files-2.5.so 004ca000-004ce000 r-xp 00000000 fd:00 11028143 /usr/lib/sasl2/liblogin.so.2.0.22 004ce000-004cf000 rwxp 00003000 fd:00 11028143 /usr/lib/sasl2/liblogin.so.2.0.22 00504000-00528000 r-xp 00000000 fd:00 820345 /usr/local/libexec/openldap/back_bdb-2.3.so.0.2.22 00528000-00529000 rwxp 00024000 fd:00 820345 /usr/local/libexec/openldap/back_bdb-2.3.so.0.2.22 00529000-00535000 rwxp 00529000 00:00 0 00695000-00696000 r-xp 00695000 00:00 0 [vdso] 0071d000-00721000 r-xp 00000000 fd:00 820437 /usr/local/libexec/openldap/translucent-2.3.so.0.2.22 00721000-00722000 rwxp 00003000 fd:00 820437 /usr/local/libexec/openldap/translucent-2.3.so.0.2.22 007fe000-00809000 r-xp 00000000 fd:00 11025782 /usr/lib/sasl2/libdigestmd5.so.2.0.22 00809000-0080a000 rwxp 0000b000 fd:00 11025782 /usr/lib/sasl2/libdigestmd5.so.2.0.22 00916000-00929000 r-xp 00000000 fd:00 2290139 /lib/libnsl-2.5.so 00929000-0092a000 r-xp 00012000 fd:00 2290139 /lib/libnsl-2.5.so 0092a000-0092b000 rwxp 00013000 fd:00 2290139 /lib/libnsl-2.5.so 0092b000-0092d000 rwxp 0092b000 00:00 0 0092f000-0093e000 r-xp 00000000 fd:00 2290132 /lib/libresolv-2.5.so 0093e000-0093f000 r-xp 0000e000 fd:00 2290132 /lib/libresolv-2.5.so 0093f000-00940000 rwxp 0000f000 fd:00 2290132 /lib/libresolv-2.5.so 00940000-00942000 rwxp 00940000 00:00 0 0099a000-0099e000 r-xp 00000000 fd:00 11021253 /usr/lib/sasl2/libanonymous.so.2.0.22 0099e000-0099f000 rwxp 00003000 fd:00 11021253 /usr/lib/sasl2/libanonymous.so.2.0.22 009a5000-009a7000 r-xp 00000000 fd:00 2290133 /lib/libcom_err.so.2.1 009a7000-009a8000 rwxp 00001000 fd:00 2290133 /lib/libcom_err.so.2.1 009aa000-00a2e000 r-xp 00000000 fd:00 10928447 /usr/lib/libkrb5.so.3.2 00a2e000-00a30000 rwxp 00084000 fd:00 10928447 /usr/lib/libkrb5.so.3.2 00a32000-00a39000 r-xp 00000000 fd:00 10928445 /usr/lib/libkrb5support.so.0.1 00a39000-00a3a000 rwxp 00006000 fd:00 10928445 /usr/lib/libkrb5support.so.0.1 00a3c000-00a61000 r-xp 00000000 fd:00 10928446 /usr/lib/libk5crypto.so.3.0 00a61000-00a62000 rwxp 00025000 fd:00 10928446 /usr/lib/libk5crypto.so.3.0 00a83000-00a9c000 r-xp 00000000 fd:00 2289282 /lib/ld-2.5.so 00a9c000-00a9d000 r-xp 00018000 fd:00 2289282 /lib/ld-2.5.so 00a9d000-00a9e000 rwxp 00019000 fd:00 2289282 /lib/ld-2.5.so 00aa0000-00bd7000 r-xp 00000000 fd:00 2289319 /lib/libc-2.5.so 00bd7000-00bd9000 r-xp 00137000 fd:00 2289319 /lib/libc-2.5.so 00bd9000-00bda000 rwxp 00139000 fd:00 2289319 /lib/libc-2.5.so 00bda000-00bdd000 rwxp 00bda000 00:00 0 00c08000-00c0a000 r-xp 00000000 fd:00 2289374 /lib/libdl-2.5.so 00c0a000-00c0b000 r-xp 00001000 fd:00 2289374 /lib/libdl-2.5.so 00c0b000-00c0c000 rwxp 00002000 fd:00 2289374 /lib/libdl-2.5.so 00c0e000-00c21000 r-xp 00000000 fd:00 2289321 /lib/libpthread-2.5.so 00c21000-00c22000 r-xp 00012000 fd:00 2289321 /lib/libpthread-2.5.so 00c22000-00c23000 rwxp 00013000 fd:00 2289321 /lib/libpthread-2.5.so 00c23000-00c25000 rwxp 00c23000 00:00 0 00c27000-00c39000 r-xp 00000000 fd:00 10928409 /usr/lib/libz.so.1.2.3 00c39000-00c3a000 rwxp 00011000 fd:00 10928409 /usr/lib/libz.so.1.2.3 00c49000-00c51000 r-xp 00000000 fd:00 820429 /usr/local/libexec/openldap/rwm-2.3.so.0.2.22 00c51000-00c52000 rwxp 00008000 fd:00 820429 /usr/local/libexec/openldap/rwm-2.3.so.0.2.22 00da4000-00da8000 r-xp 00000000 fd:00 11028147 /usr/lib/sasl2/libplain.so.2.0.22 00da8000-00da9000 rwxp 00003000 fd:00 11028147 /usr/lib/sasl2/libplain.so.2.0.22 06574000-06690000 r-xp 00000000 fd:00 2290134 /lib/libcrypto.so.0.9.8b 06690000-066a2000 rwxp 0011c000 fd:00 2290134 /lib/libcrypto.so.0.9.8b 066a2000-066a6000 rwxp 066a2000 00:00 0 066a8000-066d2000 r-xp 00000000 fd:00 10928450 /usr/lib/libgssapi_krb5.so.2.2 066d2000-066d3000 rwxp 00029000 fd:00 10928450 /usr/lib/libgssapi_krb5.so.2.2 066d5000-06716000 r-xp 00000000 fd:00 2290135 /lib/libssl.so.0.9.8b 06716000-0671a000 rwxp 00040000 fd:00 2290135 /lib/libssl.so.0.9.8b 06aeb000-06af0000 r-xp 00000000 fd:00 2290136 /lib/libcrypt-2.5.so 06af0000-06af1000 r-xp 00004000 fd:00 2290136 /lib/libcrypt-2.5.so 06af1000-06af2000 rwxp 00005000 fd:00 2290136 /lib/libcrypt-2.5.so 06af2000-06b19000 rwxp 06af2000 00:00 0 06dcb000-06de3000 r-xp 00000000 fd:00 10928451 /usr/lib/libsasl2.so.2.0.22 06de3000-06de4000 rwxp 00017000 fd:00 10928451 /usr/lib/libsasl2.so.2.0.22 08048000-0811d000 r-xp 00000000 fd:00 10953555 /usr/local/libexec/slapd 0811d000-08121000 rw-p 000d4000 fd:00 10953555 /usr/local/libexec/slapd 08121000-08124000 rw-p 08121000 00:00 0 08d12000-08e2d000 rw-p 08d12000 00:00 0 a1b00000-a1b21000 rw-p a1b00000 00:00 0 a1b21000-a1c00000 ---p a1b21000 00:00 0 a1c3a000-a1d3b000 rw-p a1c3a000 00:00 0 a1d3b000-a1d3c000 ---p a1d3b000 00:00 0 a1d3c000-a283d000 rw-p a1d3c000 00:00 0 a283d000-a283e000 ---p a283d000 00:00 0 a283e000-a323e000 rw-p a283e000 00:00 0 a323e000-a323f000 ---p a323e000 00:00 0 a323f000-a3c3f000 rw-p a323f000 00:00 0 a3c3f000-a3c45000 rw-s 00000000 fd:00 821479 /usr/local/var/openldap-data/__db.005 a3c45000-a3cb3000 rw-s 00000000 fd:00 821478 /usr/local/var/openldap-data/__db.004 a3cb3000-a3ef3000 rw-s 00000000 fd:00 821477 /usr/local/var/openldap-data/__db.003 a3ef3000-b7ef5000 rw-s 00000000 fd:00 820670 /usr/local/var/openldap-data/__db.002 b7ef5000-b7efa000 rw-p b7ef5000 00:00 0 b7f0e000-b7f12000 rw-s 00000000 fd:00 820669 /usr/local/var/openldap-data/__db.001 b7f12000-b7f13000 rw-p b7f12000 00:00 0 bfe20000-bfe36000 rw-p bfe20000 00:00 0 [stack] Program received signal SIGABRT, Aborted. [Switching to Thread -1569473648 (LWP 4535)] 0x00695402 in __kernel_vsyscall () (gdb) bt #0 0x00695402 in __kernel_vsyscall () #1 0x00ac8d40 in raise () from /lib/libc.so.6 #2 0x00aca591 in abort () from /lib/libc.so.6 #3 0x00afe33b in __libc_message () from /lib/libc.so.6 #4 0x00b0448b in malloc_consolidate () from /lib/libc.so.6 #5 0x00b066f3 in _int_malloc () from /lib/libc.so.6 #6 0x00b07bdd in calloc () from /lib/libc.so.6 #7 0x00afce7d in open_memstream () from /lib/libc.so.6 #8 0x00b69656 in __vsyslog_chk () from /lib/libc.so.6 #9 0x00b69bfa in syslog () from /lib/libc.so.6 #10 0x080687e5 in connection2anonymous () #11 0x08068c9c in connection2anonymous () #12 0x0011b56d in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:478 #13 0x00c133db in start_thread () from /lib/libpthread.so.0 #14 0x00b6d26e in clone () from /lib/libc.so.6 Please let me know what else is needed. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

RE: (ITS#4886) slapd stopping with no error message
by douglas＠gpc.edu 22 Mar '07

22 Mar '07

Thanks for the quick reply. I will try to get some things together in one or more emails. I got the following: "Bis Dienstag, den 2. April bin ich leider nicht erreichbar. Sollte Ihr Anliegen nicht so lange warten können, wenden Sie sich bitte an unsere Hotline unter der Rufnummer 0511-5181188. --------------------------------------------------------------------- Mit freundlichen Grüßen Johannes Königsmann Gutenberg Rechenzentrum GmbH & Co. KG System-Management August-Madsack-Straße 1 30559 Hannover Tel. : +49 511 518-1107 Fax : +49 511 518-1102 e-Mail: koenigsmann(a)gutenberg-rz.de Internet: www.gutenberg-rz.de _________________________________________ Gutenberg Rechenzentrum GmbH & Co. KG Sitz: Hannover Handelsregister: Hannover HRA 21 669 Geschäftsführer: Karl-Rüdiger Garbs, Dr. Claudia Hümpel" I wanted to reply to him letting him know that I did know German (wish I did), but I was a little hesitant this might not be a legitimate response to my its. Is there a way I could find out if he is legitimate or if he is not, then I would ignore it. Thanks for any help with this side question. Thanks! -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, March 22, 2007 4:36 AM To: douglas(a)gpc.edu Cc: Kurt Zeilenga Subject: Re: (ITS#4886) slapd stopping with no error message Also show the output for print *ber at the crash location Seems like something is bad in your build environment if you can get it to crash after only one search. Have you run the test suite successfully? douglas(a)gpc.edu wrote: > Full_Name: Douglas Jones > Version: 2.3.34 > OS: RHEL4 (linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (168.28.202.22) > > > Without efence, after the server has been runing between 3 and 15 days, > it varies, the sever just stops. Even using ulimit on core size, I did > not have luck getting a core file. Per recomendation of the newgroups, > I used efence and it crashed on the first lookup. I got the following under > gdb: > > (previous -d 1 output cut) > It did return the names to my client, which was good, but just crashed after > (during) that. Please let me know if I can do anythin else. Thanks! -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4888) Enhance back-sql with paged results
by ando＠sys-net.it 22 Mar '07

22 Mar '07

hyc(a)symas.com wrote: > adamson(a)cmu.edu wrote: >> Full_Name: Mark Adamson >> Version: HEAD >> OS: Solaris 2.8 >> URL: http://null.andrew.cmu.edu/openldap/sql_paged_results.patch >> Submission from: (NULL) (128.2.234.24) >> >> >> Here at Carnegie Mellon we had a need to use the LDAP_CONTROL_PAGEDRESULTS >> control with the SQL backend. The patch to add this is not hard, and was mostly >> copied from the back-bdb/search.c file. >> >> http://null.andrew.cmu.edu/openldap/sql_paged_results.patch >> >> The only challenge was the contents of the cookie that is used to maintain >> state. The slap.h file defines the PagedResultsCookie type to be an unsigned >> long, so I wanted to fit everything into that. The design idea was to keep the >> ldap_entries.id value of the last returned entry in the cookie so that >> subsequent searches could add a "AND ldap_entries.id > COOKIEVALUE" clause to >> the SQL query. However, the gathering of candidate entries is done across all >> objectClasses with avl_apply(), so if one OC returns an entry with a high >> ldap_entries.id, objectClasses that come later in the AVL could miss entries. >> For this reason, I add the oc_map_id of the last returned entry to the cookie, >> and I adjusted the avl_apply() call to run through the objectClasses in numeric >> order. In this way, when subsequent pages of entries are requested, all of the >> objectClasses that were completed by previous pages can be skipped for the new >> page. When we get to the objectClass where the previous page left off, we take >> the ldap_entries.id from the cookie and apply the above mentioned SQL clause. > > A more appropriate change would probably be to change the cookie type to > a berval so that arbitrary data may be used as needed by each backend. > Then you can set both the oc_map_id and the ldap_entries.id. > > Ultimately this sort of thing should be handled almost entirely by the > frontend, with just a single call in the backend to fill a cookie struct > for the current search state. I concur (was about to suggest the same: move parse_paged_cookie() and send_paged_response() to servers/slapd/result.c, adding as much as required to customize it from within the backend specific call. Let me note that the patch doesn't build fine (you need to declare in advance the static functions you're only defining at the end), and it seems to work incorrectly. By running the simple sql-test000 with mysql (which fails because now the order has changed; my fault: should have added -S "" to searches), if I search without the control, I correctly get 6 entries and a referral; if I search with paged results and a page size less than 6, I only get 5 entries. The root entry is missing, but I have no idea of the reason, I couldn't infer anything from the code or the logs. Can you check? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4886) slapd stopping with no error message
by hyc＠symas.com 22 Mar '07

22 Mar '07

Also show the output for print *ber at the crash location Seems like something is bad in your build environment if you can get it to crash after only one search. Have you run the test suite successfully? douglas(a)gpc.edu wrote: > Full_Name: Douglas Jones > Version: 2.3.34 > OS: RHEL4 (linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (168.28.202.22) > > > Without efence, after the server has been runing between 3 and 15 days, > it varies, the sever just stops. Even using ulimit on core size, I did > not have luck getting a core file. Per recomendation of the newgroups, > I used efence and it crashed on the first lookup. I got the following under > gdb: > > (previous -d 1 output cut) > It did return the names to my client, which was good, but just crashed after > (during) that. Please let me know if I can do anythin else. Thanks! -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4888) Enhance back-sql with paged results
by hyc＠symas.com 22 Mar '07

22 Mar '07

adamson(a)cmu.edu wrote: > Full_Name: Mark Adamson > Version: HEAD > OS: Solaris 2.8 > URL: http://null.andrew.cmu.edu/openldap/sql_paged_results.patch > Submission from: (NULL) (128.2.234.24) > > > Here at Carnegie Mellon we had a need to use the LDAP_CONTROL_PAGEDRESULTS > control with the SQL backend. The patch to add this is not hard, and was mostly > copied from the back-bdb/search.c file. > > http://null.andrew.cmu.edu/openldap/sql_paged_results.patch > > The only challenge was the contents of the cookie that is used to maintain > state. The slap.h file defines the PagedResultsCookie type to be an unsigned > long, so I wanted to fit everything into that. The design idea was to keep the > ldap_entries.id value of the last returned entry in the cookie so that > subsequent searches could add a "AND ldap_entries.id > COOKIEVALUE" clause to > the SQL query. However, the gathering of candidate entries is done across all > objectClasses with avl_apply(), so if one OC returns an entry with a high > ldap_entries.id, objectClasses that come later in the AVL could miss entries. > For this reason, I add the oc_map_id of the last returned entry to the cookie, > and I adjusted the avl_apply() call to run through the objectClasses in numeric > order. In this way, when subsequent pages of entries are requested, all of the > objectClasses that were completed by previous pages can be skipped for the new > page. When we get to the objectClass where the previous page left off, we take > the ldap_entries.id from the cookie and apply the above mentioned SQL clause. A more appropriate change would probably be to change the cookie type to a berval so that arbitrary data may be used as needed by each backend. Then you can set both the oc_map_id and the ldap_entries.id. Ultimately this sort of thing should be handled almost entirely by the frontend, with just a single call in the backend to fill a cookie struct for the current search state. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4888) Enhance back-sql with paged results
by adamson＠cmu.edu 21 Mar '07

21 Mar '07

Full_Name: Mark Adamson Version: HEAD OS: Solaris 2.8 URL: http://null.andrew.cmu.edu/openldap/sql_paged_results.patch Submission from: (NULL) (128.2.234.24) Here at Carnegie Mellon we had a need to use the LDAP_CONTROL_PAGEDRESULTS control with the SQL backend. The patch to add this is not hard, and was mostly copied from the back-bdb/search.c file. http://null.andrew.cmu.edu/openldap/sql_paged_results.patch The only challenge was the contents of the cookie that is used to maintain state. The slap.h file defines the PagedResultsCookie type to be an unsigned long, so I wanted to fit everything into that. The design idea was to keep the ldap_entries.id value of the last returned entry in the cookie so that subsequent searches could add a "AND ldap_entries.id > COOKIEVALUE" clause to the SQL query. However, the gathering of candidate entries is done across all objectClasses with avl_apply(), so if one OC returns an entry with a high ldap_entries.id, objectClasses that come later in the AVL could miss entries. For this reason, I add the oc_map_id of the last returned entry to the cookie, and I adjusted the avl_apply() call to run through the objectClasses in numeric order. In this way, when subsequent pages of entries are requested, all of the objectClasses that were completed by previous pages can be skipped for the new page. When we get to the objectClass where the previous page left off, we take the ldap_entries.id from the cookie and apply the above mentioned SQL clause. To fit both the oc_map_id and ldap_entries.id into a 32bit cookie, I had to make a sacrifice. I took 6 bits and used them for oc_map_id and the remaining 26 bits for ldap_entries.id. This means max(oc_map_id) needs to be < 64 and max(ldap_entries.id) needs to be < 134,217,728. If the PagedResultsCookie type is ever expanded to be a berval, we can store both oc_map_id and ldap_entries.id in their full glory. Anyway, try it out. It's a quick patch. -Mark Adamson Carnegie Mellon University

1 0

(ITS#4887) JLDAP - com.novell.sasl.client.DigestMD5SaslClient and RFC2831
by giovannix＠gmail.com 21 Mar '07

21 Mar '07

Full_Name: Giovanni Almeida Santos Version: 2.3.34 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.199.204.60) According to RFC2831 (Using Digest Authentication as a SASL Mechanism), the rules for a "digest-response" is defined as follows: digest-response = 1#( username | realm | nonce | cnonce | nonce-count | qop | digest-uri | response | maxbuf | charset | cipher | authzid | auth-param ) username = "username" "=" <"> username-value <"> username-value = qdstr-val ... authzid = "authzid" "=" <"> authzid-value <"> authzid-value = qdstr-val com.novell.sasl.client.DigestMD5SaslClient class does not implement that RFC at all because it does not use authzid as described above. To correct this, it is necessary modify two methods on DigestMD5SaslClient: DigestCalcHA1 and createDigestResponse. In the DigestCalcHA1 method it is necessary include the code delimited by // -->> as follows: char[] DigestCalcHA1( String algorithm, String userName, String realm, String password, String nonce, String clientNonce) throws SaslException { ... if ("md5-sess".equals(algorithm)) { md.update(hash); md.update(":".getBytes("UTF-8")); md.update(nonce.getBytes("UTF-8")); md.update(":".getBytes("UTF-8")); md.update(clientNonce.getBytes("UTF-8")); // -->> It is necessary to allow Proxy Authorization if(m_authorizationId != null && !"".equals(m_authorizationId)) { md.update(":".getBytes("UTF-8")); md.update(m_authorizationId.getBytes("UTF-8")); } // -->> End hash = md.digest(); } ... } In the createDigestResponse method it is necessary remove <code>digestResponse.append(m_authorizationId)<code> (commented below) and insert the code delimited by // -->> private String createDigestResponse( byte[] challenge) throws SaslException { ... digestResponse.append("username=\""); //digestResponse.append(m_authorizationId); // -->> It is necessary to allow Proxy Authorization digestResponse.append(m_name); if(m_authorizationId != null && !"".equals(m_authorizationId)) { digestResponse.append("\",authzid=\""); digestResponse.append(m_authorizationId); } // -->> End ... } Without these modifications, proxy authorization is not possible.

1 0

(ITS#4886) slapd stopping with no error message
by douglas＠gpc.edu 21 Mar '07

21 Mar '07

Full_Name: Douglas Jones Version: 2.3.34 OS: RHEL4 (linux) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.28.202.22) Without efence, after the server has been runing between 3 and 15 days, it varies, the sever just stops. Even using ulimit on core size, I did not have luck getting a core file. Per recomendation of the newgroups, I used efence and it crashed on the first lookup. I got the following under gdb: (previous -d 1 output cut) >>> dnPrettyNormal: <cn=Write,cn=Waiters,cn=Monitor> <<< dnPrettyNormal: <cn=Write,cn=Waiters,cn=Monitor>, <cn=write,cn=waiters,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Write,cn=Waiters,cn=Monitor) -> 0x260d9fd8 backend_startup_one: starting "o=gpc,c=us" slapd starting [New Thread 635861936 (LWP 10061)] [New Thread 631663536 (LWP 10062)] [New Thread 627465136 (LWP 10063)] [New Thread 623266736 (LWP 10064)] [New Thread 619068336 (LWP 10065)] >>> slap_listener(ldap://:389/) connection_get(33): got connid=0 connection_read(33): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 16 contents: ber_get_next do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=30 tag=97 err=0 ber_flush: 14 bytes to sd 33 connection_get(33): got connid=0 connection_read(33): checking for input on id=0 ber_get_next Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 635861936 (LWP 10061)] ber_get_next (sb=0x25f2ffe8, len=0x25e6427c, ber=0x25f65fd4) at io.c:551 551 if (*ber->ber_ptr & 0x80) { /* multi-byte */ (gdb) bt full #0 ber_get_next (sb=0x25f2ffe8, len=0x25e6427c, ber=0x25f65fd4) at io.c:551 l = Variable "l" is not available. (gdb) thread apply all bt Thread 6 (Thread 619068336 (LWP 10065)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x004e7b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x0812d25b in ldap_int_thread_pool_wrapper (xpool=0xb725df58) at tpool.c:490 #3 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 5 (Thread 623266736 (LWP 10064)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x004e7b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x0812d25b in ldap_int_thread_pool_wrapper (xpool=0xb725df58) at tpool.c:490 #3 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 4 (Thread 627465136 (LWP 10063)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x004e7b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #2 0x0812d25b in ldap_int_thread_pool_wrapper (xpool=0xb725df58) at tpool.c:490 #3 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 3 (Thread 631663536 (LWP 10062)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0036ba19 in mprotect () from /lib/tls/libc.so.6 #2 0x0814fb3f in Page_AllowAccess (address=0x25fa8000, size=475136) at page.c:149 #3 0x0814f6be in free (address=0xb7ea4ff0) at efence.c:694 #4 0x003232b5 in tzset_internal () from /lib/tls/libc.so.6 #5 0x00323d0e in tzset () from /lib/tls/libc.so.6 #6 0x003288ae in strftime_l () from /lib/tls/libc.so.6 #7 0x0036af6b in vsyslog () from /lib/tls/libc.so.6 #8 0x0036b4df in syslog () from /lib/tls/libc.so.6 #9 0x0806ab08 in slap_send_ldap_result (op=0x25f61e58, rs=0x25a66230) at result.c:585 #10 0x08075952 in fe_op_bind (op=0x25f61e58, rs=0x25a66230) at bind.c:327 #11 0x0807523d in do_bind (op=0x25f61e58, rs=0x25a66230) at bind.c:200 #12 0x0805eac4 in connection_operation (ctx=0x25a662b0, arg_v=0x25f61e58) at connection.c:1133 #13 0x0812d1df in ldap_int_thread_pool_wrapper (xpool=0xb725df58) ---Type <return> to continue, or q <return> to quit--- at tpool.c:478 #14 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #15 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 2 (Thread 635861936 (LWP 10061)): #0 ber_get_next (sb=0x25f2ffe8, len=0x25e6427c, ber=0x25f65fd4) at io.c:551 #1 0x0805eed0 in connection_read (s=33) at connection.c:1528 #2 0x0805baa2 in slapd_daemon_task (ptr=0x0) at daemon.c:2461 #3 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 1 (Thread -1208731424 (LWP 10058)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x004e60fd in pthread_join () from /lib/tls/libpthread.so.0 #2 0x0805c621 in slapd_daemon () at daemon.c:2572 #3 0x0804dc9f in main (argc=13, argv=0xbff6ac14) at main.c:860 ------------------------------------------------------------------------------------ It did return the names to my client, which was good, but just crashed after (during) that. Please let me know if I can do anythin else. Thanks!

1 0

Re: (ITS#4883) test000 fails
by ando＠sys-net.it 21 Mar '07

21 Mar '07

Ralf Haferkamp wrote: > unintended or incomplete. Both. Fixed, thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4883) test000 fails
by rhafer＠suse.de 21 Mar '07

21 Mar '07

It seems that the last change in back-monitor.h was either unintended or incomplete. Reverting that change make the test suite working again. Ando, as that was your change, could you please take a deeper look? -- thanks, Ralf

1 0

(ITS#4885) incorrect response macro in ldap_result(3)
by ando＠sys-net.it 21 Mar '07

21 Mar '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando In ldap_result(3) there is mention of LDAP_RES_EXTENDED_PARTIAL, which apparently was replaced by LDAP_RES_INTERMEDIATE since 2.2 or so. p.

1 0

Re: (ITS#4884) Back-config inheritance issue
by ando＠sys-net.it 21 Mar '07

21 Mar '07

I've committed to HEAD a fix that exploits inheritance. The rationale is: - lookup the structural objectClass; starting from it, check it and subordinates for a function that successfully adds the entry - using all objectClass values, collect all, including ancestors, that may be of use in checking configuration. Passes all tests (049->051), and allows to add an overlay using only the overlay's objectClass, provided it's derived from olcOverlayConfig. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4853) A debug message is printed, from the released version
by ando＠sys-net.it 20 Mar '07

20 Mar '07

Fixed, thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4853) A debug message is printed, from the released version
by Frank.Swasey＠uvm.edu 20 Mar '07

20 Mar '07

This is a cryptographically signed message in MIME format. --------------ms010006030808080804010404 Content-Type: multipart/mixed; boundary="------------080104090705040602090506" This is a multi-part message in MIME format. --------------080104090705040602090506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The patch applied in version 1.7.2.12 of refint.c is not complete. It does remove the notice of refint_attribute values, but it leaves the refint_nothing and refint_base using LDAP_DEBUG_ANY instead of also limiting those prints to when LDAP_DEBUG_CONFIG is specified. Attached is a patch deck to correct all three Debug() calls. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --------------080104090705040602090506 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ITS4853_full.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ITS4853_full.patch" --- refint.c.UVM_refint-head 2007-01-02 16:44:08.000000000 -0500 +++ refint.c 2007-03-20 09:43:17.000000000 -0400 @@ -144,14 +144,14 @@ ip->attr = ad; ip->next = id->attrs; id->attrs = ip; - Debug(LDAP_DEBUG_ANY, "%s: line %d: new attribute <%s>\n", + Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new attribute <%s>\n", fname, lineno, argv[i]); } } else if(!strcasecmp(*argv, "refint_base")) { /* XXX only one basedn (yet) - need validate argument! */ if(id->dn.bv_val) ch_free(id->dn.bv_val); ber_str2bv( argv[1], 0, 0, &dn ); - Debug(LDAP_DEBUG_ANY, "%s: line %d: new baseDN <%s>\n", + Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new baseDN <%s>\n", fname, lineno, argv[1]); if(dnNormalize(0, NULL, NULL, &dn, &id->dn, NULL)) { Debug(LDAP_DEBUG_ANY, "%s: line %d: bad baseDN!\n", fname, lineno, 0); @@ -165,7 +165,7 @@ Debug(LDAP_DEBUG_ANY, "%s: line %d: bad nothingDN!\n", fname, lineno, 0); return(1); } - Debug(LDAP_DEBUG_ANY, "%s: line %d: new nothingDN<%s>\n", + Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new nothingDN<%s>\n", fname, lineno, argv[1]); } else { return(SLAP_CONF_UNKNOWN); --------------080104090705040602090506-- --------------ms010006030808080804010404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC AuIwggJLoAMCAQICEAq9rKiduK3HCbKzsBiBodUwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcxNzE2NTcyNloX DTA3MDcxNzE2NTcyNlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG CSqGSIb3DQEJARYURnJhbmsuU3dhc2V5QHV2bS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCzhSmesaR8qf2y5cNt0qa27m42Kq3Bwubs28CzSxR1uRUaRZUfL/C2FEFV kKSat6da5b19UEWxM1giaWvLeDtQE5Tok8GhN8LNgScTiSEM6gFWnL0o7A9W7oAj42dfFvBV md7/u7nSJoAP3Wt9cU3TBJBh99U89EzIYLNik8iVhzbwfNmisxmuR5870AHURoR1sN/X4jWx q5114Rv8r60+bVitlXL7P20Z2S9+va9+a7+C1P/yJLPq1GK8+X9uaoUaGHlapBeBYNu3QWQG Q+mF+QuidS01jbaburvJxUm7dVO3QRt1PovVhlidv89eqcH8n4h7xSG1IG3teNJkschdAgMB AAGjMTAvMB8GA1UdEQQYMBaBFEZyYW5rLlN3YXNleUB1dm0uZWR1MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAblV8ye5ZLs/y3DX0W3NU67N2T6tOSZ1609L+BRWB/Md7RDFd Cm8AXFIldDLzkyPFqs9WpgAQLvZ0gRXQ8aqwYEBB3WlZzkpUS+YTuY6X9wjcroMjHCyWNpq0 /joDumCNSEWiZJ6AZMRom9Z/P6foBxXmgCBKVq/O0mGqgArlxdkwggLiMIICS6ADAgECAhAK vayonbitxwmys7AYgaHVMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjA3MTcxNjU3MjZaFw0wNzA3MTcxNjU3MjZa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFEZy YW5rLlN3YXNleUB1dm0uZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs4Up nrGkfKn9suXDbdKmtu5uNiqtwcLm7NvAs0sUdbkVGkWVHy/wthRBVZCkmrenWuW9fVBFsTNY Imlry3g7UBOU6JPBoTfCzYEnE4khDOoBVpy9KOwPVu6AI+NnXxbwVZne/7u50iaAD91rfXFN 0wSQYffVPPRMyGCzYpPIlYc28HzZorMZrkefO9AB1EaEdbDf1+I1sauddeEb/K+tPm1YrZVy +z9tGdkvfr2vfmu/gtT/8iSz6tRivPl/bmqFGhh5WqQXgWDbt0FkBkPphfkLonUtNY22m7q7 ycVJu3VTt0EbdT6L1YZYnb/PXqnB/J+Ie8UhtSBt7XjSZLHIXQIDAQABozEwLzAfBgNVHREE GDAWgRRGcmFuay5Td2FzZXlAdXZtLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAG5VfMnuWS7P8tw19FtzVOuzdk+rTkmdetPS/gUVgfzHe0QxXQpvAFxSJXQy85MjxarP VqYAEC72dIEV0PGqsGBAQd1pWc5KVEvmE7mOl/cI3K6DIxwsljaatP46A7pgjUhFomSegGTE aJvWfz+n6AcV5oAgSlavztJhqoAK5cXZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAKvayonbitxwmys7AYgaHVMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMyMDEzNTE0NlowIwYJKoZIhvcNAQkEMRYEFH3P vHIi8xXKD1kPu1urTjvGs7UyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN BgkqhkiG9w0BAQEFAASCAQCKsfzObajHIgMefZW2QJwF0uhq3rkjCMyMCcWmuRi8jMBu1E8K 5HaZVQHExEyiDeqD+eGW1lDps4u1nP4/pIjVh94RlXUzpG0gE5zW0d56Oz+FUrjavTN2UkcX CBpYUYDjlQ9TneqvUXRWwLcJBo9JGnCElVy7o4gm/hJObB28xaxIrNv6cYmWV0khianRwtS2 cfystVgiI19NlBHPJIO8MZv6J/Do75tfaJpQBqIiSaT+XABWrtww6sjpTw9ooUzczWQEjoOF dXVjSZE+1EeWmPflbE/6qE2KCRiX8pxgswWztgLnm7lvO3qxONysME/Wc9zGqlWTHZHYHium qrEvAAAAAAAA --------------ms010006030808080804010404--

1 0

(ITS#4884) Back-config inheritance issue
by ando＠sys-net.it 20 Mar '07

20 Mar '07

Full_Name: Pierangelo Masarati Version: HEAD (re23,...) OS: irrelevant URL: Submission from: (NULL) (87.28.220.33) Submitted by: ando I think I've spotted a potential issue in back-config. When creating a custom object, say an overlay, the configuration objectClass should inherit from olcOverlayConfig. While adding the object via LDAP, however, if the ancestor class is not explicitly listed, the derived object must provide a co_ldadd() hook, otherwise addition fails. It would be more sound, IMHO, to have something like: - if the structural objectClass provides a co_ldadd() hook, use it; it is that hook's responsibility to call the superior's one if required; - if it doesn't, then climb the inheritance tree and call co_ldadd() for the first occurrence of a valid one. In case of multiple inheritance, issues may arise. In those cases, we could: - require an explicit co_ldadd() in the derived object to resolve the ambiguity (this is basically what C++ does) - otherwise, co_ldadd() should perhaps be called for the first occurrence in all branches of multiple inheritance, and it should be able to either create the entry, or modify an existing entry. handlers should be called in order of inheritance. Currently, the code uses all defined objectClasses and stops the first time a hook is available and it does not fail. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2007