- openldap-bugs - openldap.org

Re: (ITS#6364) refint needs to have rootdn set
by apm＠mutex.dk 22 Jan '10

22 Jan '10

This may be related. I've veryfied that my refint overlay is not working. However I have a rootdn defined for the database, but it is set to cn=config. Could it be that the rootdn has to be in the scope of the database for refint to work? slapd 2.4.20, back-hdb, BerkeleyDB 4.8.24 /Peter

1 0

(ITS#6459) memory leak in syncprov
by rhafer＠suse.de 21 Jan '10

21 Jan '10

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.21.216) When sending SYNC_NEW_COOKIE intermedia results syncprov_qplay() does not free the entry from the syncres structure. A fix is on the way...

1 0

(ITS#6458) syncrepl fails if attribute has no equalty maching rule
by pcernko+openldap＠mpi-sws.org 20 Jan '10

20 Jan '10

Full_Name: Patrick Cernko Version: 2.4.21 OS: Linux URL: http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… Submission from: (NULL) (139.19.3.67) Hi OpenLDAP-Programmers, although some related bug reports were posted in the past years, this issue still seems not to be fixed: OpenLDAP's syncrepl replication fails if it comes to removing one of a multi-value attribes of an object if this attribute does not have a equality matching rule defined in the schema. Modification works on the master server but fails to replicate to the slave(s) leaving them with the dit version just before and not replicating any other changes any more. I compiled a small example how to reproduce the problem with the (maybe "well-known") nisNetgroupTriple attribute from nis.schema as shipped with openldap-2.4.21: - extract the files from http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… into an empty working directory - download the tarball to that working dir and configure similar to the just extracted configure.sh - build and install it to get an install subdir in the working dir - start the master using sh master.sh in the working dir This will create the "master" database in your working dir, slapadd the dit.ldif and start a master slapd with a unix socket /tmp/master. - start the slave using sh slave.sh This will create "slave" database in your working dir and start the slave slapd with a unix socket /tmp/slave which will immediately start syncing from the running master - if you want you can search the 2 servers with install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL resp. install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL - use "python mod.py" to remove one of the nisNetgroupTriple attributes from the netgroup object - you will see a debug message from the slave server like this: bdb_modify_internal: delete nisNetgroupTriple bdb_modify_internal: 18 modify/delete: nisNetgroupTriple: no equality matching rule send_ldap_result: err=18 matched="" text="modify/delete: nisNetgroupTriple: no equality matching rule" null_callback : error code 0x12 slap_graduate_commit_csn: removing 0x29931c0 20100120124712.028626Z#000000#000#000000 syncrepl_entry: rid=001 be_modify cn=netgroup,ou=openldap (18) syncrepl_entry: rid=001 be_modify failed (18) if not, use "python mod.py add" to re-add the removed nisNetgroupTriple and try again. Sometimes, it seems to work (race condition?). - you can also verify the difference with: install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL cn=netgroup install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL cn=netgroup - from now on, the slave will fail to sync any succeeding changes, as it continuously tries to sync the modification above first. :-( Now, obviously having an attribute without equality matching rule is not a good idea in the first place. However, the (official?) nis.schema comes with such an attribute which we must use like this (e.g. we would have to patch the Solaris kernel to change it for the Solaris NFS server). It is possible to modify a nisNetgroup object like this: according to the debugging output, I guess the master removes simply ALL nisNetgroupTriple attributes and adds only the attributes that should remain. When the corresponding syncrepl_entry is handled by the slave, it seems the it in contrast tries to really only remove the 2-be-removed attribute which does not work as it cannot identify the right one due to a missing eq-match operator. I suggest the best way to solve this issue is to try to get syncrepl do exactly the same actions (not resulting changes) as the server does.

1 0

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by Guillaume.Rousse＠inria.fr 20 Jan '10

20 Jan '10

Le 18/01/2010 17:13, masarati(a)aero.polimi.it a écrit : > Could not reproduce. Apparently, it's something else that's creating > hassle. Please provide a stack backtrace. Actually, it's an assertion failure un entry.c: slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed. Abandon Here the backtrace, but compilation optimisation may hinder its usability: #0 0x00007ffff6476955 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 pid = <value optimized out> selftid = <value optimized out> #1 0x00007ffff6477f70 in abort () at abort.c:92 act = {__sigaction_handler = {sa_handler = 0x5068de, sa_sigaction = 0x5068de}, sa_mask = {__val = {140737326326544, 140737233550016, 483, 140737233550256, 140737325461350, 206158430232, 140737233550272, 140737233550048, 140737325372360, 206158430256, 140737233550296, 140737019750384, 117, 117, 0, 140737488347048}}, sa_flags = -162034579, sa_restorer = 0x50a16f} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007ffff646f861 in __assert_fail (assertion=0x5068de "e->e_private == ((void *)0)", file=<value optimized out>, line=483, function=0x506d68 "entry_clean") at assert.c:81 buf = 0x7fffe411a7f0 "slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed.\n" #3 0x000000000043c9f8 in entry_clean (e=0xbcf148) at entry.c:483 __PRETTY_FUNCTION__ = "entry_clean" #4 0x000000000043ca1d in entry_free (e=0x2997) at entry.c:514 No locals. #5 0x00000000004430f7 in slap_send_search_entry (op=0x7fffe4002950, rs=0x7ffff0e81a20) at result.c:1310 berbuf = { buffer = "\000\000\001\000\000\000\000\000?\020", '\000' <repeats 14 times>, "]\240\326\331d\355\343P\000\000\000\000\000\000\000\000]\240\326\331d\355\343Pp\265\211\000\000\000\000\000\354\237C\000\000\000\000\000\200@\000\344\377\177\000\000]\240\326\331d\355\343P\370\360\274\000\000\000\000\000\020\343\177\000\000\000\000\000\200@\000\344\377\177\000\000\v\031E", '\000' <repeats 13 times>, "\004\000\000\000\000\000\000\000\260\375\317\360\377\177", '\000' <repeats 18 times>, "\004", '\000' <repeats 102 times>, ialign = 65536, lalign = 65536, falign = 9.18354962e-41, dalign = 3.2379086165851934e-319, palign = 0x10000 <Address 0x10000 out of bounds>} ber = 0x7fffe4002950 a = 0x80bf90 i = 1 j = <value optimized out> rc = 0 bytes = 8437648 userattrs = 0 acl_state = {as_desc = 0x0, as_access = ACL_NONE, as_vd_acl = 0x0, as_vd_acl_count = 0, as_vd_mask = 1, as_result = -1, as_fe_done = 0} attrsonly = 0 ad_entry = 0x80bf90 e_flags = 0x0 #6 0x00000000004b407c in bdb_search (op=0x7fffe4002950, rs=0x7ffff0e81a20) at search.c:961 bois = {boi_oe = {oe_next = {sle_next = 0x7ffff0e80480}, oe_key = 0x89b570}, boi_txn = 0x0, boi_locks = 0x7ffff0cfff70, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 1 '\001'} blis = {bli_next = 0x0, bli_lock = {off = 398968, ndx = 98, gen = 2, mode = DB_LOCK_READ}, bli_id = 4, bli_flag = 1} scopeok = 1 bdb = 0x89b570 id = 4 cursor = 4 lastid = 18446744073709551615 candidates = {18446744073709551615, 2, 4, 4, 0, 7, 140737019654336, 0, 0, 0, 0, 140737018603728, 0, 398968, 4294967394, 1, 4, 1, 0, 9024880, 0, 140737233551920, 1099511627776, 0 <repeats 31 times>, 140737018605160, 0, 161, 140737018605160, 0, 0, 0, 0, 0, 0, 160, 140737233552240, 0, 0, 0, 4294967394, 1, 0, 0, 0, 7, 140737019654336, 0, 0, 0, 0, 0, 140737019653408, 4159, 140737019655616, 0, 18446744073709551615, 5, 8589934592, 18446744073709551615, 1, 4, 0 <repeats 130981 times>} scopes = {0 <repeats 63786 times>, 64, 0, 0, 0, 0, 0, 64, 0, 0, 206158430210, 532575944795, 140737018593312, 2064, 140737018593312, 2896, 140737019704496, 140737018593416, 140737325535154, 90, 2048, 140737019704256, 80, 6, 32, 4, 0, 2096, 0, 0, 343597383809, 532575944799, 472446402679, 0, 24, 2048, 140737018593312, 2896, 140737019704496, 140737328631424, 140737325539706, 0, 3, 140737235123824, 140737235111168, 140737235111216, 140737235111120, 3, 140737325789440, 140737019662880, 140737019703776, 140737019660544, 140737019662880, 140737019704032, 140737019660544, 140737019662880, 140737019704256, 140737019660544, 140737235123824, 140737235111168, 140737325790836, 8589934594, 140737018603072, 8589934594, 140737019662800, 4294967297, 140737019690064, 8589934594, 140737019662832, 4294967297, 140737019690064, 0 <repeats 502 times>, 17592186044416, 0, 0, 0, 0, 1048576, 0, 0, 18446726481523507198, 18446744073708503039, 18446744073709551615, 18446744073709551615, 0, 16, 0, 0, 18446726477228539902, 18446744073709518831, 18446744073709551615, 18446744073709551615, 0 <repeats 425 times>, 140737325961225, 0, 140737326101420, 90194321408, 0, 3590586904199757824, 140737235118896, 0, 0, 12884908544, 0, 4898288851081953280, 140737235118944, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140737326101420, 562962838323220, 45729780788658, 4294967296, 72058139498840072, 72058139498905608, 122509647347719, 563035852767292, 45729780788658, 12893297154, 4898288846787117064, 4898288846787182600, 9221744489062989832, 3488165888539164681, 257698037760, 5428787749601804308, 36063989980998039, 281509336449045, 562985149158339, 1125935102579651, 844464420836291, 812545396, 0 <repeats 48 times>, 140737325961225, 0, 140737326101420, 90194321408, 0, 3590586904199757824, 140737235119616, 0, 0, 12884908544, 0, 4898288851081953280, 140737235119664, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140737326101420, 562962838323220, 45729780788658, 4294967296, 72058139498840072, 72058139498905608, 122509647347719, 563035852767292...} e = 0xbcf0f8 base = {e_id = 2, e_name = {bv_len = 140737018603856, bv_val = 0x8000 <Address 0x8000 out of bounds>}, e_nname = {bv_len = 16, bv_val = 0x7fffe4103ed0 "ou=users,dc=test"}, e_attrs = 0x44471d, e_ocflags = 5254706, e_bv = {bv_len = 0, bv_val = 0x10000 <Address 0x10000 out of bounds>}, e_private = 0x7fffe41033e0} e_root = <value optimized out> matched = 0x0 ei = 0x7fffe41035c0 realbase = {bv_len = 16, bv_val = 0x7fffe4103ed0 "ou=users,dc=test"} mask = <value optimized out> manageDSAit = <value optimized out> tentries = 3 nentries = <value optimized out> idflag = 0 lock = {off = 398968, ndx = 98, gen = 2, mode = DB_LOCK_READ} opinfo = 0x0 ltid = 0x7fffe4102d20 oex = <value optimized out> #7 0x000000000049db2f in overlay_op_walk (op=0x7fffe4002950, rs=0x7ffff0e81a20, which=<value optimized out>, oi=0x89f650, on=0x0) at backover.c:669 rc = 32768 ... -- BOFH excuse #204: Just pick up the phone and give modem connect sounds. "Well you said we should get more lines so we don't have voice lines."

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 18 Jan '10

18 Jan '10

* alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2009-11-05 07:43:02 +0000]: New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed. I can make a public test server, to let some one check my configs and see faults. Also intresting have any body same failures? > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. > > > #ldd /usr/local/libexec/slapd > /usr/local/libexec/slapd: > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) > libc.so.7 => /lib/libc.so.7 (0x8015f5000) > > > > > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- alexs

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by quanah＠zimbra.com 18 Jan '10

18 Jan '10

--On Tuesday, January 19, 2010 2:02 AM +0000 j(a)gropefruit.com wrote: > I am currently in debug mode with slapd-dbg 2.4.20: > > Having run these commands: > > sudo gdb > handle SIGPIPE nostop=20 > handle SIGPIPE noprint > file /usr/sbin/slapd > set args -d -1 -u openldap -g openldap -h ldapi:/// ldaps:/// ldap:/// = > -f /etc/ldap/slapd.conf > run > > Once it crashes, I will be running: > > thr apply all bt > > After which I will upload the coredump to your FTP server. Just supply the backtrace for now, please. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 18 Jan '10

18 Jan '10

I am currently in debug mode with slapd-dbg 2.4.20: Having run these commands: sudo gdb handle SIGPIPE nostop=20 handle SIGPIPE noprint file /usr/sbin/slapd set args -d -1 -u openldap -g openldap -h ldapi:/// ldaps:/// ldap:/// = -f /etc/ldap/slapd.conf run Once it crashes, I will be running: thr apply all bt After which I will upload the coredump to your FTP server. J On Jan 18, 2010, at 00:58 , Hallvard B Furuseth wrote: > quanah(a)zimbra.com writes: >> Building unix software with debugging symbols is basic system >> administrator knowledge. There is nothing "openldap" specific about >> doing so. >=20 > Yes, there is, since OpenLDAP uses autoconf, libtool & co with = defaults > that get in the way of debugging: >=20 > Openldap 'make install' strips debugging symbols, so you must either = run > slapd from the source tree or install with 'make install STRIP=3D:' or > something, I don't remember at the moment. >=20 > Also it helps debugging to remove the optimize option which OpenLDAP > uses by default if it can compiler-specific, but with gcc that's > ./configure CFLAGS=3D"-g" >=20 >> I would suggest updating = <http://www.openldap.org/faq/data/cache/59.html>=20 >> with any information you feel specifically is lacking. >=20 > I'll make a note to update that one a bit. >=20 > --=20 > Hallvard

1 0

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by masarati＠aero.polimi.it 18 Jan '10

18 Jan '10

> Full_Name: Guillaume Rousse > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.55.250.67) > > The following configuration is supposed to map remote 'homePhone' > attribute to > 'telephoneNumber', and hide remote 'telephoneNumber' attribute: > > database relay > suffix ou=telephony,dc=test > overlay rwm > rwm-suffixmassage ou=users,dc=test > > rwm-map attribute telephoneNumber homePhone > rwm-map attribute telephoneNumber > > However, the server crashes as soon as it has to handle an entry with a > telephoneNumber attribute, as demonstrated with the simple ldif below: > > dn: dc=test > dc: test > objectClass: top > objectClass: domain > > dn: ou=users,dc=test > ou: users > objectClass: top > objectClass: organizationalUnit > > dn: cn=user1,ou=users,dc=test > objectClass: inetOrgPerson > cn: user1 > sn: user1 > > dn: cn=user2,ou=users,dc=test > objectClass: inetOrgPerson > cn: user2 > sn: user2 > telephoneNumber: +33123456789 > > Here is the relevant part of server log, with debugLevel set to trace: > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, > <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: ==> limits_get: conn=1001 op=1 > self="[anonymous]" > this="ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=users,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=users,dc=test>, > <ou=users,dc=test> > Jan 18 13:29:58 slapd[12035]: => bdb_search > Jan 18 13:29:58 slapd[12035]: bdb_dn2entry("ou=users,dc=test") > Jan 18 13:29:58 slapd[12035]: search_candidates: base="ou=users,dc=test" > (0x00000002) scope=2 > Jan 18 13:29:58 slapd[12035]: => bdb_dn2idl("ou=users,dc=test") > Jan 18 13:29:58 slapd[12035]: <= bdb_dn2idl: id=3 first=2 last=4 > Jan 18 13:29:58 slapd[12035]: => bdb_presence_candidates (objectClass) > Jan 18 13:29:58 slapd[12035]: bdb_search_candidates: id=-1 first=2 last=4 > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, > <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 > dn="ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: > <cn=user1,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: > <cn=user1,ou=telephony,dc=test>, <cn=user1,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 > dn="cn=user1,ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: > <cn=user2,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: > <cn=user2,ou=telephony,dc=test>, <cn=user2,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="(null)" Could not reproduce. Apparently, it's something else that's creating hassle. Please provide a stack backtrace. p.

1 0

(ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by Guillaume.Rousse＠inria.fr 18 Jan '10

18 Jan '10

Full_Name: Guillaume Rousse Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) The following configuration is supposed to map remote 'homePhone' attribute to 'telephoneNumber', and hide remote 'telephoneNumber' attribute: database relay suffix ou=telephony,dc=test overlay rwm rwm-suffixmassage ou=users,dc=test rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber However, the server crashes as soon as it has to handle an entry with a telephoneNumber attribute, as demonstrated with the simple ldif below: dn: dc=test dc: test objectClass: top objectClass: domain dn: ou=users,dc=test ou: users objectClass: top objectClass: organizationalUnit dn: cn=user1,ou=users,dc=test objectClass: inetOrgPerson cn: user1 sn: user1 dn: cn=user2,ou=users,dc=test objectClass: inetOrgPerson cn: user2 sn: user2 telephoneNumber: +33123456789 Here is the relevant part of server log, with debugLevel set to trace: Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: ==> limits_get: conn=1001 op=1 self="[anonymous]" this="ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=users,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=users,dc=test>, <ou=users,dc=test> Jan 18 13:29:58 slapd[12035]: => bdb_search Jan 18 13:29:58 slapd[12035]: bdb_dn2entry("ou=users,dc=test") Jan 18 13:29:58 slapd[12035]: search_candidates: base="ou=users,dc=test" (0x00000002) scope=2 Jan 18 13:29:58 slapd[12035]: => bdb_dn2idl("ou=users,dc=test") Jan 18 13:29:58 slapd[12035]: <= bdb_dn2idl: id=3 first=2 last=4 Jan 18 13:29:58 slapd[12035]: => bdb_presence_candidates (objectClass) Jan 18 13:29:58 slapd[12035]: bdb_search_candidates: id=-1 first=2 last=4 Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <cn=user1,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <cn=user1,ou=telephony,dc=test>, <cn=user1,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="cn=user1,ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <cn=user2,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <cn=user2,ou=telephony,dc=test>, <cn=user2,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="(null)"

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by h.b.furuseth＠usit.uio.no 18 Jan '10

18 Jan '10

quanah(a)zimbra.com writes: > Building unix software with debugging symbols is basic system > administrator knowledge. There is nothing "openldap" specific about > doing so. Yes, there is, since OpenLDAP uses autoconf, libtool & co with defaults that get in the way of debugging: Openldap 'make install' strips debugging symbols, so you must either run slapd from the source tree or install with 'make install STRIP=:' or something, I don't remember at the moment. Also it helps debugging to remove the optimize option which OpenLDAP uses by default if it can compiler-specific, but with gcc that's ./configure CFLAGS="-g" > I would suggest updating <http://www.openldap.org/faq/data/cache/59.html> > with any information you feel specifically is lacking. I'll make a note to update that one a bit. -- Hallvard

1 0

(ITS#6456) Feature Request
by j＠gropefruit.com 17 Jan '10

17 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Greetings, Having found out this doesn't already exist as another parameter or configuration method, I am hereby submitting a request for a particular feature. When performing idassert-bind operations, such as with back_ldap, it would be great if an option could be added which would allow specific matched client DNs to be matched and asserted as usual (e.g: the anonymous user asserting to a backend "proxyauthenticator" account) .... while other clients (flagged somehow) would pass-through as themselves. Example (as I might do it for my purposes): idassert-bind bindmethod="simple" binddn="uid=proxyauthenticator,ou=users,dc=example,dc=com" credentials="password_string" starttls="yes" tls_reqcert="never" mode="none" # anonymous clients will assert as "proxyauthenticator", since the backend may not allow anonymous binds. idassert-authzFrom "dn.exact:" # this guy will pass through as himself to the backend, as-is. idassert-passThrough "dn.exact:uid=admin,ou=users,dc=example,dc=com" This would be really helpful, not sure if its difficult to implement ...

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by quanah＠zimbra.com 17 Jan '10

17 Jan '10

--On Sunday, January 17, 2010 10:28 PM +0000 j(a)gropefruit.com wrote: > In general, a page should exist on openldap.org that details, in full, = > the debugging/core dump process and best practices.=20 Building unix software with debugging symbols is basic system administrator knowledge. There is nothing "openldap" specific about doing so. Same with debugging the core files that are generated. Here's a page on basic C compilation: <http://www.cs.rutgers.edu/LCSR-Computing/programming.html> Most specifically, note the "-g" option to CFLAGS, which instructs gcc, in this case, to include debugging symbols in the resulting compiled code. Ensure that when you install, you set STRIP="" so that the "make" program does not strip out the debugging symbols on installation. Run the new slapd that has the debugging information and get a core file. Use GDB to get a backtrace from it. Again, nothing here is specific to OpenLDAP, which is why there is no "OpenLDAP" page on how to do this. I will note the FAQ is fully interactive, allowing anyone to create an entry, if you feel so inclined. I would suggest updating <http://www.openldap.org/faq/data/cache/59.html> with any information you feel specifically is lacking. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 17 Jan '10

17 Jan '10

--Apple-Mail-1--155291042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See my inline changes: On Jan 17, 2010, at 14:13 , masarati(a)aero.polimi.it wrote: > Apart from some changes, I can't reproduce. See comments below. >=20 >> Full_Name: J >> Version: 2.4.20 >> OS: Debian-Lenny/amd64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (68.15.14.98) >>=20 >>=20 >> Host running Debian Lenny amd64 is experiencing a strange issue. = slapd is >> segfaulting for no obvious reason. Syslog output: >>=20 >> Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault = at 40 >> ip >> 7fb2b4829875 sp 44d90940 error 4 in >> back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] >=20 Is there a recommended debugging "practice" you guys recommend? And what = control do I have over the details of our DIT being produced in the core = dump? Security concerns on part of my organization may prevent such a = backtrace ... =3D( > This is not a useful bug report. You should rather follow = instructions > here <http://www.openldap.org/faq/data/cache/56.html> and provide = useful > information. A stack backtrace is essentially mandatory. Also, = details > about the DIT and the exact offending operations would be of help. >=20 >> We are running slapd 2.4.20, via this config: >>=20 >> include /etc/ldap/schema/core.schema >> include /etc/ldap/schema/cosine.schema >> include /etc/ldap/schema/nis.schema >> include /etc/ldap/schema/inetorgperson.schema >>=20 >> pidfile /var/run/slapd/slapd.pid >> argsfile /var/run/slapd/slapd.args >>=20 >> disallow bind_anon >>=20 >> loglevel 0 >> sizelimit 999999 >> idletimeout 10 >>=20 >> modulepath /usr/lib/ldap >> moduleload back_ldap >> moduleload back_hdb >> moduleload pcache >>=20 >> TLSCertificateFile /etc/ldap/ssl/wildcard.crt >> TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key >> TLSCACertificateFile /etc/ldap/ssl/wildcard.pem >>=20 >> database ldap >> uri ldaps://192.168.1.1:636/ >> suffix "ou=3Dsvcs,cn=3Dauth" >> rootdn "uid=3Dslapd,ou=3Dsvcs,cn=3Dauth" >=20 I lied. Our syntax is not cn=3Dauth, I had to sanitize it from what it = really was (security concerns for my company). But thanks for the note. > I note that "cn=3Dauth" should not be used, as this naming context is = used > internally for SASL identities. >=20 >> idassert-bind >> bindmethod=3Dsimple >> binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth" >> credentials=3D"password" >> mode=3Dnone >> idassert-authz=46rom "dn.subtree:ou=3Dsvcs,cn=3Dauth" >>=20 >> ### For some reason, we can no longer use indexes like we could in = slapd >> 2.3 >> ### while using back_ldap (uncommenting these will present slapd from >> starting). >>=20 >> #index objectClass eq >> #index uid,mail,cn eq,sub >> #index queryid eq >=20 Thanks. This is useful to know. > 2.4 is pickier about syntax. "index" has no meaning within back-ldap. = In > 2.3 unrecognized keywords were plainly ignored. >=20 >> overlay pcache >> proxycache hdb 1000 1 50 1200 >> directory "/var/lib/ldap" >> proxycachequeries 100 >> proxyattrset 0 uid mail cn >> proxytemplate (uid=3D) 0 600 >>=20 >> include /etc/ldap/acls.slapd >>=20 >> ########## >>=20 >>=20 >> My hunch, given ITS #6452 (which I remarked was "solved"), is that id >> assertion >> may cause slapd to crash when an identity tries to assert as itself? >>=20 >> e.g: uid=3Dauth,ou=3Dsvcs,cn=3Dauth >--idassert--> = uid=3Dauth,ou=3Dsvcs,cn=3Dauth by >> means >> of the idassert-authz=46rom parameter, which authorizes the entire = subtree >> in >> which this account resides. Again, just a hunch ... >=20 > I had it working auth'ing both as idassert's "binddn" and as another = user > within the allowed subtree. >=20 In general, a page should exist on openldap.org that details, in full, = the debugging/core dump process and best practices.=20 > Please improve the report and feed back. >=20 > p. >=20 --Apple-Mail-1--155291042 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">See = my inline changes:<div><br></div><div><div><div>On Jan 17, 2010, at = 14:13 , <a = href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it</a> = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>Apart from some changes, I can't reproduce.  See = comments below.<br><br><blockquote type=3D"cite">Full_Name: = J<br></blockquote><blockquote type=3D"cite">Version: = 2.4.20<br></blockquote><blockquote type=3D"cite">OS: = Debian-Lenny/amd64<br></blockquote><blockquote type=3D"cite">URL: <a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br></blockquote><blockquote type=3D"cite">Submission from: (NULL) = (68.15.14.98)<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Host running = Debian Lenny amd64 is experiencing a strange issue.  slapd = is<br></blockquote><blockquote type=3D"cite">segfaulting for no obvious = reason. Syslog output:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Jan 15 19:29:59 = ldapc1 kernel: [10702.262741] slapd[3218]: segfault at = 40<br></blockquote><blockquote = type=3D"cite">ip<br></blockquote><blockquote type=3D"cite">7fb2b4829875 = sp 44d90940 error 4 in<br></blockquote><blockquote = type=3D"cite">back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000]<br></blockquote><= br></div></blockquote><div>Is there a recommended debugging "practice" = you guys recommend? And what control do I have over the details of our = DIT being produced in the core dump?  Security concerns on part of = my organization may prevent such a backtrace ... =3D(</div><br><blockquote= type=3D"cite"><div>This is not a useful bug report.  You should = rather follow instructions<br>here <<a = href=3D"http://www.openldap.org/faq/data/cache/56.html">http://www.openlda= p.org/faq/data/cache/56.html</a>> and provide useful<br>information. =  A stack backtrace is essentially mandatory.  Also, = details<br>about the DIT and the exact offending operations would be of = help.<br><br><blockquote type=3D"cite">We are running slapd 2.4.20, via = this config:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/core.sche= ma<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/cosine.sc= hema<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/nis.schem= a<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/inetorgpe= rson.schema<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">pidfile =         /var/run/slapd/slapd.pid<b= r></blockquote><blockquote type=3D"cite">argsfile =        /var/run/slapd/slapd.args<br></b= lockquote><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite">disallow =        bind_anon<br></blockquote><block= quote type=3D"cite"><br></blockquote><blockquote type=3D"cite">loglevel =        0<br></blockquote><blockquote = type=3D"cite">sizelimit =       999999<br></blockquote><blockquote = type=3D"cite">idletimeout =     10<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">modulepath =      /usr/lib/ldap<br></blockquote><blockquote = type=3D"cite">moduleload =      back_ldap<br></blockquote><blockquote = type=3D"cite">moduleload =      back_hdb<br></blockquote><blockquote = type=3D"cite">moduleload =      pcache<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">TLSCertificateFile =      /etc/ldap/ssl/wildcard.crt<br></blockquote><= blockquote type=3D"cite">TLSCertificateKeyFile =   /etc/ldap/ssl/wildcard.key<br></blockquote><blockquote = type=3D"cite">TLSCACertificateFile =    /etc/ldap/ssl/wildcard.pem<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">database =        ldap<br></blockquote><blockquote= type=3D"cite">uri =             <a= = href=3D"ldaps://192.168.1.1:636/">ldaps://192.168.1.1:636/</a><br></blockq= uote><blockquote type=3D"cite">suffix =          "ou=3Dsvcs,cn=3Dauth= "<br></blockquote><blockquote type=3D"cite">rootdn =          "uid=3Dslapd,ou=3Dsv= cs,cn=3Dauth"<br></blockquote><br></div></blockquote><div><br></div><div>I= lied. Our syntax is not cn=3Dauth, I had to sanitize it from what it = really was (security concerns for my company).  But thanks for the = note.</div><br><blockquote type=3D"cite"><div>I note that "cn=3Dauth" = should not be used, as this naming context is used<br>internally for = SASL identities.<br><br><blockquote = type=3D"cite">idassert-bind<br></blockquote><blockquote type=3D"cite"> =   bindmethod=3Dsimple<br></blockquote><blockquote type=3D"cite">= =   binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth"<br></blockquote><blo= ckquote type=3D"cite"> =   credentials=3D"password"<br></blockquote><blockquote = type=3D"cite">   mode=3Dnone<br></blockquote><blockquote = type=3D"cite">idassert-authz=46rom = "dn.subtree:ou=3Dsvcs,cn=3Dauth"<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">### For some = reason, we can no longer use indexes like we could in = slapd<br></blockquote><blockquote = type=3D"cite">2.3<br></blockquote><blockquote type=3D"cite">### while = using back_ldap (uncommenting these will present slapd = from<br></blockquote><blockquote = type=3D"cite">starting).<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">#index =           objectClass =    eq<br></blockquote><blockquote type=3D"cite">#index =          uid,mail,cn =     eq,sub<br></blockquote><blockquote = type=3D"cite">#index =          queryid =         eq<br></blockquote><br></d= iv></blockquote><div><br></div><div>Thanks.  This is useful to = know.</div><br><blockquote type=3D"cite"><div>2.4 is pickier about = syntax.  "index" has no meaning within back-ldap.  In<br>2.3 = unrecognized keywords were plainly ignored.<br><br><blockquote = type=3D"cite">overlay =             &n= bsp;   pcache<br></blockquote><blockquote = type=3D"cite">proxycache =             &n= bsp;hdb 1000 1 50 1200<br></blockquote><blockquote type=3D"cite">directory= =             &n= bsp; "/var/lib/ldap"<br></blockquote><blockquote = type=3D"cite">proxycachequeries =       100<br></blockquote><blockquote = type=3D"cite">proxyattrset =            0 uid = mail cn<br></blockquote><blockquote type=3D"cite">proxytemplate =           (uid=3D) =  0 600<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =             &n= bsp;   /etc/ldap/acls.slapd<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">##########<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">My hunch, given = ITS #6452 (which I remarked was "solved"), is that = id<br></blockquote><blockquote = type=3D"cite">assertion<br></blockquote><blockquote type=3D"cite">may = cause slapd to crash when an identity tries to assert as = itself?<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">e.g: = uid=3Dauth,ou=3Dsvcs,cn=3Dauth >--idassert--> = uid=3Dauth,ou=3Dsvcs,cn=3Dauth by<br></blockquote><blockquote = type=3D"cite">means<br></blockquote><blockquote type=3D"cite">of the = idassert-authz=46rom parameter, which authorizes the entire = subtree<br></blockquote><blockquote = type=3D"cite">in<br></blockquote><blockquote type=3D"cite">which this = account resides.  Again, just a hunch = ...<br></blockquote><br></div></blockquote><blockquote = type=3D"cite"><div>I had it working auth'ing both as idassert's "binddn" = and as another user<br>within the allowed = subtree.<br><br></div></blockquote><div><br></div><div>In general, a = page should exist on <a href=3D"http://openldap.org">openldap.org</a> = that details, in full, the debugging/core dump process and best = practices. </div><div><br></div><blockquote type=3D"cite"><div>Please= improve the report and feed back.<br><font class=3D"Apple-style-span" = color=3D"#000000"><font class=3D"Apple-style-span" = color=3D"#144FAE"><br></font></font></div></blockquote><blockquote = type=3D"cite"><div>p.<br><br></div></blockquote></div><br></div></body></h= tml>= --Apple-Mail-1--155291042--

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by masarati＠aero.polimi.it 17 Jan '10

17 Jan '10

Apart from some changes, I can't reproduce. See comments below. > Full_Name: J > Version: 2.4.20 > OS: Debian-Lenny/amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) > > > Host running Debian Lenny amd64 is experiencing a strange issue. slapd is > segfaulting for no obvious reason. Syslog output: > > Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault at 40 > ip > 7fb2b4829875 sp 44d90940 error 4 in > back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] This is not a useful bug report. You should rather follow instructions here <http://www.openldap.org/faq/data/cache/56.html> and provide useful information. A stack backtrace is essentially mandatory. Also, details about the DIT and the exact offending operations would be of help. > We are running slapd 2.4.20, via this config: > > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > > pidfile /var/run/slapd/slapd.pid > argsfile /var/run/slapd/slapd.args > > disallow bind_anon > > loglevel 0 > sizelimit 999999 > idletimeout 10 > > modulepath /usr/lib/ldap > moduleload back_ldap > moduleload back_hdb > moduleload pcache > > TLSCertificateFile /etc/ldap/ssl/wildcard.crt > TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key > TLSCACertificateFile /etc/ldap/ssl/wildcard.pem > > database ldap > uri ldaps://192.168.1.1:636/ > suffix "ou=svcs,cn=auth" > rootdn "uid=slapd,ou=svcs,cn=auth" I note that "cn=auth" should not be used, as this naming context is used internally for SASL identities. > idassert-bind > bindmethod=simple > binddn="uid=auth,ou=svcs,cn=auth" > credentials="password" > mode=none > idassert-authzFrom "dn.subtree:ou=svcs,cn=auth" > > ### For some reason, we can no longer use indexes like we could in slapd > 2.3 > ### while using back_ldap (uncommenting these will present slapd from > starting). > > #index objectClass eq > #index uid,mail,cn eq,sub > #index queryid eq 2.4 is pickier about syntax. "index" has no meaning within back-ldap. In 2.3 unrecognized keywords were plainly ignored. > overlay pcache > proxycache hdb 1000 1 50 1200 > directory "/var/lib/ldap" > proxycachequeries 100 > proxyattrset 0 uid mail cn > proxytemplate (uid=) 0 600 > > include /etc/ldap/acls.slapd > > ########## > > > My hunch, given ITS #6452 (which I remarked was "solved"), is that id > assertion > may cause slapd to crash when an identity tries to assert as itself? > > e.g: uid=auth,ou=svcs,cn=auth >--idassert--> uid=auth,ou=svcs,cn=auth by > means > of the idassert-authzFrom parameter, which authorizes the entire subtree > in > which this account resides. Again, just a hunch ... I had it working auth'ing both as idassert's "binddn" and as another user within the allowed subtree. Please improve the report and feed back. p.

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 16 Jan '10

16 Jan '10

And just for the record, this exact config (the only difference being = the index params were uncommented) was working fine on Debian Etch / = slapd 2.3.x, which we have been using for a very long time, with no ill = effects (certainly nothing like this). We only rebuilt this same box = today with 2.4.20 on Lenny/Amd64. J=

1 0

(ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 16 Jan '10

16 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Host running Debian Lenny amd64 is experiencing a strange issue. slapd is segfaulting for no obvious reason. Syslog output: Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault at 40 ip 7fb2b4829875 sp 44d90940 error 4 in back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] We are running slapd 2.4.20, via this config: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args disallow bind_anon loglevel 0 sizelimit 999999 idletimeout 10 modulepath /usr/lib/ldap moduleload back_ldap moduleload back_hdb moduleload pcache TLSCertificateFile /etc/ldap/ssl/wildcard.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key TLSCACertificateFile /etc/ldap/ssl/wildcard.pem database ldap uri ldaps://192.168.1.1:636/ suffix "ou=svcs,cn=auth" rootdn "uid=slapd,ou=svcs,cn=auth" idassert-bind bindmethod=simple binddn="uid=auth,ou=svcs,cn=auth" credentials="password" mode=none idassert-authzFrom "dn.subtree:ou=svcs,cn=auth" ### For some reason, we can no longer use indexes like we could in slapd 2.3 ### while using back_ldap (uncommenting these will present slapd from starting). #index objectClass eq #index uid,mail,cn eq,sub #index queryid eq overlay pcache proxycache hdb 1000 1 50 1200 directory "/var/lib/ldap" proxycachequeries 100 proxyattrset 0 uid mail cn proxytemplate (uid=) 0 600 include /etc/ldap/acls.slapd ########## My hunch, given ITS #6452 (which I remarked was "solved"), is that id assertion may cause slapd to crash when an identity tries to assert as itself? e.g: uid=auth,ou=svcs,cn=auth >--idassert--> uid=auth,ou=svcs,cn=auth by means of the idassert-authzFrom parameter, which authorizes the entire subtree in which this account resides. Again, just a hunch ... Thanks J

1 0

Re: (ITS#6454) idassert-bind, etc., assistance
by quanah＠zimbra.com 14 Jan '10

14 Jan '10

--On Thursday, January 14, 2010 8:49 PM +0000 j(a)gropefruit.com wrote: > Full_Name: J > Version: 2.4.20 > OS: Debian/Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) The ITS system is for bug reports, not help with usage. I don't see any evidence here you are reporting a bug. Please use the openldap-software(a)openldap.org list if you have questions on how to set up and configure OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6454) idassert-bind, etc., assistance
by j＠gropefruit.com 14 Jan '10

14 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian/Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Is there any way to use the idassert feature ONLY for anonymous connections, while allowing all other binddns to be directly proxied as themselves? I ask because we have root LDAP servers that have ACL configurations that work for our purposes, and we don't want to change them. We also do not allow anonymous binds to our root servers. To be clear, we do not want to change anything whatsoever on our root servers. however, some clients do need to be able to bind anonymously. We're ok with this, as long as anonymous is allowed against LDAP proxies only, and not on our root LDAP servers. This way, we can control what anonymous user sees. I am trying to make the proxy behave in the following ways: * authenticated non-admin Users may bind as themselves, they can see groups, etc., (anything non-confidential) but can only see their own account (we have this one working, but is an essential element of the larger picture) * anonymous users see all of the same non-sensitive material, but no user accounts whatsoever * there are proxybind users in our DIT, one for read-ops and one for write-ops. The writer-proxybind user typically is needed for changing a users' password, etc. The read user is the one that performs lookups for strictly read-only operations. He can see all users. If I set the idassert-bind to the read-only user, then no one can do writes. If i set it to the write-user, then everyone (even those who shouldn't) can do writes (except anonymous, which is good). The understanding I have is that we should be setting the proxy user in slapd's proxy config to be the highest-privileged user that we're ok with being "asserted". For example, we're not asserting to the rootdn or anything, rather we assert to a bind user that is designed to read the very information that the proxy is designed to lookup. Here is our running config, though its been hacked up so much you should understand its probably not perfect around the edges. Also ignore the comments as they haven't been updated with the rest of the real parameters. PS - I tried to upload as anonymous to your ftp and got this: local: j-gropefruit-100114.txt remote: j-gropefruit-100114.txt 229 Entering Extended Passive Mode (|||60518|) 553 j-gropefruit-100114.txt: Permission denied. So you'll just have to read it here: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/dhcp.schema include /etc/ldap/schema/samba.schema include /usr/share/doc/libpam-ldap/ldapns.schema include /etc/ldap/schema/hdb.schema include /etc/ldap/schema/uber.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats stats2 conns parse idletimeout 0 sizelimit unlimited timelimit unlimited defaultsearchbase dc=fake,dc=example,dc=com limits dn.regex="^uid=([^,]+).,cn=plain,*" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited access to dn.base="" by * read access to dn.base="cn=Subschema" by * read ## Load modules here modulepath /usr/lib/ldap moduleload back_relay moduleload back_ldap moduleload back_hdb moduleload pcache moduleload rwm.la ## SSL/TLS TLSCertificateFile /etc/ldap/ssl/wildcard.fake.example.com.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.fake.example.com.key TLSCACertificateFile /etc/ldap/ssl/wildcard.fake.example.com.pem ## This is for SASL/GSSAPI authentication sasl-realm FAKE.EXAMPLE.COM sasl-host ds-fake-int.fake.example.com authz-regexp "uid=$.*$,cn=FAKE.EXAMPLE.COM,cn=gssapi,cn=auth" "uid=$1,cn=plain,cn=auth,dc=real,dc=example,dc=com" authz-regexp "uid=$.*$,cn=DEV.EXAMPLE.COM,cn=gssapi,cn=auth" "uid=$1,cn=plain,cn=auth,cn=dev,dc=real,dc=example,dc=com" ## Define the actual 'database', as referenced by the suffix. database ldap uri ldaps://10.9.8.7:636/ suffix "dc=real,dc=example,dc=com" rootdn "uid=rootdn,cn=plain,cn=auth,dc=real,dc=example,dc=com" overlay rwm rwm-rewriteEngine on # all dataflow from server to client rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+,)?dc=real,dc=example,dc=com$" "$1dc=fake,dc=example,dc=com" ## When proxying information, configure what identity to assert. #acl-bind # bindmethod="simple" # binddn="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" # credentials="pass" # starttls="no" # tls_reqcert="never" idassert-bind bindmethod="simple" binddn="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" credentials="pass" starttls="no" tls_reqcert="never" mode="legacy" flags="override,non-prescriptive" idassert-authzFrom "dn.subtree:cn=plain,cn=auth,dc=real,dc=example,dc=com" idassert-authzFrom "dn.subtree:cn=plain,cn=auth,dc=real,dc=example,dc=com" idassert-authzFrom "dn.exact:" chase-referrals NO rebind-as-user NO ## Cache data for PERFORMANCE - this only works when the upstream proxy ## is online. There's no way to cache data in its entirety if the provider ## goes down (that's what actual replication is for). overlay pcache proxycache hdb 2000 5 100 1800 directory "/var/lib/ldap/cache" dbconfig set_cachesize 0 4097152 0 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 1048576 dbconfig set_lg_dir /var/lib/ldap/cache dbconfig set_tmp_dir /tmp index uid,cn,sn,givenName eq,sub index uidNumber,gidNumber eq index homeDirectory,loginShell,gecos,objectClass eq proxycachequeries 10000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass proxytemplate (&(objectclass=)(uidNumber=)) 0 1200 proxytemplate (&(objectclass=)(uid=)) 0 1200 proxyattrset 1 objectclass proxytemplate (objectclass=) 1 1200 proxyattrset 2 uid proxytemplate (uid=) 2 1200 proxyattrset 3 cn nisNetgroupTriple memberNisNetgroup proxytemplate (&(objectClass=)(cn=)) 3 1200 proxyattrset 4 gidNumber proxytemplate (&(objectClass=)(memberUid=)) 4 1200 ## Set a global rule to allow everything to our service/proxy users, then forbid ## all others access, but BREAK the rule so it keeps processing the rest of the rules, ## which are all much less-permissive ... access to dn.subtree="dc=real,dc=example,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=ldapadmin,cn=ldap,cn=groups,dc=real,dc=example,dc=com" write by dn.regex="^uid=plain$modify|change$,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by dn.regex="^uid=plain$proxy|agent$,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to attrs=userPassword by self =w by * =x ## OMFGZZZZ the Solipsism rule - if you touch this I will kill you. ## This fixes the MUST-BIND-AS-SELF logic problem with Sun VDI access to dn.regex="^uid=([^,]+),cn=plain,cn=auth,dc=real,dc=example,dc=com" by dn.base,expand="uid=$1,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break ########## Relay Instance for the "fake" zone database relay suffix dc=fake,dc=example,dc=com relay dc=real,dc=example,dc=com overlay rwm rwm-suffixmassage dc=real,dc=example,dc=com rwm-rewriteEngine on rwm-normalize-mapped-attrs yes rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=real,dc=example,dc=com$" "$1dc=fake,dc=example,dc=com" access to dn.subtree="dc=fake,dc=example,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=ldapadmin,cn=ldap,cn=groups,dc=real,dc=example,dc=com" write by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to dn.children="cn=plain,cn=auth,dc=fake,dc=example,dc=com" attrs=userPassword filter=(&(uid=*)(|(objectClass=posixAccount)(objectClass=simpleSecurityObject)(objectClass=shadowAccount)(objectClass=inetOrgPerson)(objectClass=account))) by self write by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by anonymous auth by * none break access to dn.children="cn=plain,cn=auth,dc=fake,dc=example,dc=com" filter=(&(uid=*)(|(objectClass=posixAccount)(objectClass=simpleSecurityObject)(objectClass=shadowAccount)(objectClass=inetOrgPerson)(objectClass=account))) by self read by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to dn.subtree="cn=groups,dc=fake,dc=example,dc=com" filter=(|(objectClass=posixGroup)(objectClass=nisNetgroup)(objectClass=groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=organizationalRole)) by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by anonymous read by * none break access to dn.onelevel="cn=gssapi,cn=auth,dc=fake,dc=example,dc=com" by dn="uidNumber=0+gidNumber=0,cn=peercred,cn=external,cn=auth" read by * none break access to dn.onelevel="cn=FAKE.EXAMPLE.COM,cn=gssapi,cn=auth,dc=fake,dc=example,dc=com" by dn="uidNumber=0+gidNumber=0,cn=peercred,cn=external,cn=auth" write by * none break access to dn.subtree="cn=sys,dc=fake,dc=example,dc=com" by * read access to dn.subtree="cn=tester,dc=fake,dc=example,dc=com" by * read access to dn.subtree="cn=dev,dc=fake,dc=example,dc=com" by * none access to dn.subtree="cn=elements,dc=fake,dc=example,dc=com" by * none The man pages and examples on OL.org have helped tremendously, but I need some living & breathing opinions. Thanks J

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by rein＠OpenLDAP.org 14 Jan '10

14 Jan '10

On 13.01.2010 14:30, alinachegalati(a)yahoo.com wrote: > Spam detection software, running on the system "boole.openldap.org", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or label > similar future email. If you have any questions, see > The administrator of that system for details. > > Content analysis details: (5.2 points, 5.0 required) > > pts rule name description > ---- ---------------------- -------------------------------------------------- > 3.4 FH_DATE_PAST_20XX The date is grossly in the future. This is a broken spamassassin rule, it believes that the year 2010 is in the future. Run sa-update (if it works), or add to spamassassins local.cf: score FH_DATE_PAST_20XX 0 Rein

2 1

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

--0-1551663707-1263389393=:13367 Content-Type: text/plain; charset=us-ascii Workaround : count the number of timeouts per ldap connection and unbind it when it reaches a certain threshold (1000 for example). --0-1551663707-1263389393=:13367 Content-Type: text/html; charset=us-ascii <table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Workaround : count the number of timeouts per ldap connection and unbind it when it reaches a certain threshold (1000 for example).<br></td></tr></table><br> --0-1551663707-1263389393=:13367--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

--0-1599667706-1263381171=:58734 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Aditional Information : Note that the ldap connection is not un-binded, it = is simply returned to a connection pool. --- On Wed, 1/13/10, openldap-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org> = wrote: From: openldap-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: alinachegalati(a)yahoo.com Date: Wednesday, January 13, 2010, 3:05 AM *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.=A0 Your report has been assigned the tracking number ITS#6453. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers.=A0 They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message.=A0 Note that any mail sent to openldap-its(a)openldap.org with (ITS#6453) in the subject will automatically be attached to the issue report. =A0=A0=A0 mailto:openldap-its@openldap.org?subject=3D(ITS#6453) You may follow the progress of this report by loading the following URL in a web browser: =A0 =A0 http://www.OpenLDAP.org/its/index.cgi?findid=3D6453 Please remember to retain your issue tracking number (ITS#6453) on any further messages you send to us regarding this report.=A0 If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =A0=A0=A0 http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. =0A=0A=0A --0-1599667706-1263381171=:58734 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">Aditional Information : Note that the ldap co= nnection is not un-binded, it is simply returned to a connection pool.<br><= br>--- On <b>Wed, 1/13/10, openldap-its(a)OpenLDAP.org <i><openldap-its@Op= enLDAP.org></i></b> wrote:<br><blockquote style=3D"border-left: 2px soli= d rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: openlda= p-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org><br>Subject: Re: (ITS#6= 453) OpenLDAP memory leak on LDAP_TIMEOUT<br>To: alinachegalati(a)yahoo.com<b= r>Date: Wednesday, January 13, 2010, 3:05 AM<br><br><div class=3D"plainMail= "><br>*** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br><br>Thanks for yo= ur report to the OpenLDAP Issue Tracking System.  Your<br>report has b= een assigned the tracking number ITS#6453.<br><br>One of our support engine= ers will look at your report in due course.<br>Note that this may take some= time because our support engineers<br>are volunteers.  They only work on O= penLDAP when they have spare<br>time.<br><br>If you need to provide additio= nal information in regards to your<br>issue report, you may do so by replyi= ng to this message.  Note that<br>any mail sent to <a ymailto=3D"mailt= o:openldap-its@openldap.org" href=3D"/mc/compose?to=3Dopenldap-its@openldap= .org">openldap-its(a)openldap.org</a> with (ITS#6453)<br>in the subject will = automatically be attached to the issue report.<br><br>    ma= ilto:<a ymailto=3D"mailto:openldap-its@openldap.org" href=3D"/mc/compose?to= =3Dopenldap-its(a)openldap.org">openldap-its(a)openldap.org</a>?subject=3D(ITS#= 6453)<br><br>You may follow the progress of this report by loading the foll= owing<br>URL in a web browser:<br>    <a href=3D"http://www.OpenL= DAP.org/its/index.cgi?findid=3D6453" target=3D"_blank">http://www.OpenLDAP.= org/its/index.cgi?findid=3D6453</a><br><br>Please remember to retain your i= ssue tracking number (ITS#6453)<br>on any further messages you send to us regarding this= report.  If<br>you don't then you'll just waste our time and yours be= cause we<br>won't be able to properly track the report.<br><br>Please note = that the Issue Tracking System is not intended to<br>be used to seek help i= n the proper use of OpenLDAP Software.<br>Such requests will be closed.<br>= <br>OpenLDAP Software is user supported.<br>    <a href=3D"h= ttp://www.OpenLDAP.org/support/" target=3D"_blank">http://www.OpenLDAP.org/= support/</a><br><br>--------------<br>Copyright 1998-2007 The OpenLDAP Foun= dation, All Rights Reserved.<br><br></div></blockquote></td></tr></table><b= r>=0A=0A --0-1599667706-1263381171=:58734--

1 0

(ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

Full_Name: Alin Vasile Version: 2.4.19 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) Hi, We have a memory leak LDAP_TIMEOUT is encountered on ldap_search_ext_invocation and we are unable to determine if it is related to OpenLdap or not. The following summarizes our code in case the LDAP_TIMEOUT response is returned : LDAPMessage *res ; // acquire connection // perform search if(rc == LDAP_TIMEOUT) { ldap_msgfree(res); // return connection } Is ldap_msgfree(res) enough in this case ? We tested our program by enabling a low timeout and hence all ldap calls resulting in timeout. The memory leak is about 9 Megs in several minutes, at a load of 5 req/ sec. dmalloc sees the following not allocated pointers 6642692 bytes : Line 640 of "io.c" starts at address 0xff2659c4 <ber_get_next+468> and ends at 0xff2659cc <ber_get_next+476>. 2019876 bytes : Line 277 of "memory.c" starts at address 0xff26676c <ber_memcalloc_x+132> and ends at 0xff266774 <ber_memcalloc_x+140>.

1 0

Re: (ITS#6452) Able to crash slapd when using identity assertion
by j＠gropefruit.com 12 Jan '10

12 Jan '10

Nevermind, commented out the following in my relay database config area: rwm-rewriteEngine on rwm-normalize-mapped-attrs yes rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=example,dc=com$" "$1,dc=public,dc=com" No longer crashes. You may close. J On Jan 12, 2010, at 21:39 , openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6452. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6452) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6452) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6452 > > Please remember to retain your issue tracking number (ITS#6452) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

(ITS#6452) Able to crash slapd when using identity assertion
by j＠gropefruit.com 12 Jan '10

12 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Able to do all necessary identity assertion when using command-line tools (ldapsearch, ldapmodify, etc) against my server. Server is running back_ldap, back_relay, pcache and back_hdb. But when I point one of my test hosts (Debian Lenny) against this seemingly healthy server and I try to login, I get this while running slapd -d -1: [rw] searchEntryDN: "uid=jay,cn=plain,cn=auth,dc=example,dc=com" -> "uid=jay,cn=plain,cn=auth,dc=example,dc=com" slapd: /usr/src/openldap-src-2.4.20/openldap-2.4.20/servers/slapd/entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed. Aborted Why?

1 0

(ITS#6449) roadmap update
by quanah＠OpenLDAP.org 12 Jan '10

12 Jan '10

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) http://www.openldap.org/software/roadmap.html needs to be updated to note that OpenLDAP 2.3 is no longer maintained, same as 2.2 and prior.

1 0

(ITS#6448) BUS Error on Multi Master Mode
by acirulli＠gmail.com 12 Jan '10

12 Jan '10

Full_Name: Andrea Cirulli Version: 2.4.21 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.77.56.181) Hi, I have setted up two multimasters in mirror mode. After launching in debug mode with -d 16384 once I stop the slapd ( by CTRL+c ) I obtain a bus error. below the analysis of the core: [New Thread 1 (LWP 1)] Loaded symbols for /usr/lib/64//libthread.so.1 warning: Can't read pathname for load map: I/O error. warning: Can't read pathname for load map: I/O error. Core was generated by `libexec/slapd -f etc/openldap/slapd.conf -h ldap://:379 -d 16384'. Program terminated with signal 10, Bus error. #0 0x00000001001fb8f4 in avl_free () (gdb) thread apply all bt full Thread 2 (Thread 1 (LWP 1)): #0 0x00000001001fb8f4 in avl_free () No symbol table info available. #1 0x0000000100185ef0 in ?? () No symbol table info available. #2 0x0000000100185ef0 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (LWP 1 ): #0 0x00000001001fb8f4 in avl_free () No symbol table info available. #1 0x0000000100185ef0 in ?? () No symbol table info available. #2 0x0000000100185ef0 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?)

1 0

RE: (ITS#6447) Can't compile openldap with --enable-dynamic on solari sparc 10
by Biren.Patel＠directbrands.com 11 Jan '10

11 Jan '10

Please close this issue, it has been resolved. Thanks -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Monday, January 11, 2010 10:31 AM To: Patel, Biren - Direct Brands Subject: Re: (ITS#6447) Can't compile openldap with --enable-dynamic on so= lari sparc 10 *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6447. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6447) in the subject will automatically be attached to the issue report. =09mailto:openldap-its@openldap.org?subject=3D(ITS#6447) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6447 Please remember to retain your issue tracking number (ITS#6447) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________

1 0

Re: (ITS#6444) OpenLDAP 2.5 RoadMap Question
by michael＠stroeder.com 11 Jan '10

11 Jan '10

j(a)gropefruit.com wrote: > Please clarify this statement in your 2.5 roadmap: Any reason why you didn't simply post this to the openldap-software mailing list? > LDAPv3 extensions: > *LDAP Transaction support AFAIK this means implementing draft-zeilenga-ldap-txn http://tools.ietf.org/draft/draft-zeilenga-ldap-txn/ Ciao, Michael.

1 0

Re: (ITS#6444) OpenLDAP 2.5 RoadMap Question
by quanah＠zimbra.com 11 Jan '10

11 Jan '10

--On Wednesday, January 06, 2010 11:49 PM +0000 j(a)gropefruit.com wrote: > Full_Name: J > Version: 2.4.20 > OS: Debian/Lenny-AMD64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.67.92.30) > > > Please clarify this statement in your 2.5 roadmap: This is not a bug report. If you have development questions, please send them to openldap-devel(a)openldap.org for discussion. Thanks! This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6447) Can't compile openldap with --enable-dynamic on solari sparc 10
by biren.patel＠directbrands.com 11 Jan '10

11 Jan '10

Full_Name: Biren Patel Version: openldap-2.4.19 OS: SPARC Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.223.34.13) I can't compile openldap with option --enable-dynamic on SPARC Solaris 10. Receiving the error provided below. It complies fine without the --enable-dynamic but when complie PHP 5 with ldap, PHP gives me the same error. I have norrowed down to Openldap not able to compile all the libs as dynamic loadable. Please help Using gcc. Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.6 /bin/sh ../../libtool --mode=link gcc -D_AVL_H -L/usr/local/openssl/lib/ -L/usr/local/BerkeleyDB/lib -L/usr/local/lib/ -R/usr/local/BerkeleyDB/lib -R/usr/local/lib -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl -lssl -lcrypto -lresolv -lgen -lnsl -lsocket gcc -D_AVL_H -o .libs/apitest apitest.o -L/usr/local/openssl/lib/ -L/usr/local/BerkeleyDB/lib -L/usr/local/lib/ ./.libs/libldap.so /u/bpatel/openldap-2.4.21/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a -lsasl -lssl -lcrypto -lresolv -lgen -lnsl -lsocket -Wl,--rpath -Wl,/usr/local/openldap/lib -Wl,--rpath -Wl,/usr/local/BerkeleyDB/lib -Wl,--rpath -Wl,/usr/local/lib /usr/ccs/bin/ld: ./.libs/libldap.so: dlclose: invalid version 13 (max 0) ./.libs/libldap.so: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/u/bpatel/openldap-2.4.21/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/u/bpatel/openldap-2.4.21/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6446) Quickstart guide only uses slapd.conf
by gavin.henry＠gmail.com 07 Jan '10

07 Jan '10

Will update. Thanks! On 07/01/2010, quanah(a)openldap.org <quanah(a)openldap.org> wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The quickstart guide on the OpenLDAP home page only references using > slapd.conf. > It has no references to the new config backend. Since slapd.conf is > deprecated, it would be good to have a quickstart guide that reflected this. > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

(ITS#6446) Quickstart guide only uses slapd.conf
by quanah＠OpenLDAP.org 07 Jan '10

07 Jan '10

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The quickstart guide on the OpenLDAP home page only references using slapd.conf. It has no references to the new config backend. Since slapd.conf is deprecated, it would be good to have a quickstart guide that reflected this.

1 0

(ITS#6445) Duplicate free with back-relay + passwd op
by h.b.furuseth＠usit.uio.no 07 Jan '10

07 Jan '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD configured with CPPFLAGS=-DSLAP_NO_SL_MALLOC ./run test030-relay with slapd under valgrind Bad frees of op->o_req_ndn.bv_val and op->o_req_dn.bv_val: Invalid slap_sl_free() by 0x4864F1: do_extended (extended.c:187) Address 0xd8853a0 is 0 bytes inside a block of size 62 free'd by 0x487DAC: passwd_extop (passwd.c:321) by 0x486712: fe_extended (extended.c:225) by 0x486491: do_extended (extended.c:180) Invalid slap_sl_free() by 0x486515: do_extended (extended.c:189) Address 0xd8855d0 is 0 bytes inside a block of size 62 free'd by 0x487DFF: passwd_extop (passwd.c:325) by 0x486712: fe_extended (extended.c:225) by 0x486491: do_extended (extended.c:180) The four backtraces are surrounded by: at 0x4A05A31: free (vg_replace_malloc.c:325) by 0x4E707E5: ber_memfree_x (memory.c:152) by 0x4B7157: slap_sl_free (sl_malloc.c:481) <...backtrace above...> by 0x4444F8: connection_operation (connection.c:1109) by 0x444A7D: connection_read_thread (connection.c:1245) by 0x4C1AFE2: ldap_int_thread_pool_wrapper (tpool.c:685)

1 0

(ITS#6444) OpenLDAP 2.5 RoadMap Question
by j＠gropefruit.com 06 Jan '10

06 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian/Lenny-AMD64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.67.92.30) Please clarify this statement in your 2.5 roadmap: LDAPv3 extensions: *LDAP Transaction support Do you mean that SyncRepl will actually become legitimately enterprise-class, in that replication will work 100% of the time? Or does this mean transaction support for some other element unrelated to content synchronization? Why I ask: I've opened a few tickets on OpenLDAP in the past, related to replication issues involving multiple multimaster servers with a frontend employed (a hardware load balancer) to control writes. From time to time, it seems as though SyncRepl just "decides" to fail, and gives no indication ANYWHERE as to why. We log all sync activity, and we see no indication that the host is unreachable or down, and we see no performance delays when querying the DSAs manually. * All slapd servers' clocks are perfectly synchronized and are in a common time zone * Of all six multimasters, only two of them actually receive WRITES * All are 2.4.20 on amd64 kernel (Debian Lenny) * We see no discernible improvement when switching from refreshOnly to refreshAndPersist. Replication will work fine for awhile (in the most recent case, it worked for 16 days, having written test records ranging from 1000 to 50000 *repeatedly* without issues) and then just "fail" .... We have ruled out the following: * Bad hardware * slapd Configuration error (have posted our config before) * Firewall timeout issues for cross-site replication (a timeout wouldn't wait 16 days) * Firewall policies between sites (wouldn't cause it to work and then not work). * slapd segfaulting or crashing in some way This behavior is quite lackluster for a business environment and is ultimately insufficient for any legitimate application. As far as I am concerned, the results are so unbelievably inconsistent that this is an affront to the way SyncRepl is represented/advertised. If it NEVER worked at all, at least THAT would be consistent. SyncRepl rarely makes any valid attempt to "sync up" when differences are detected between DSAs - SOMETIMES it feels like it, most of the time it does not. I hate to say it, but SyncRepl is a huge pile of misrepresentation and broken promises. So: Is transaction support intended to SOLVE these issues? If not, maybe you should invent something to replace SyncRepl altogether. J

1 0

Re: (ITS#6443) test022-ppolicy failure
by hyc＠symas.com 06 Jan '10

06 Jan '10

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.4.21 > OS: CentOS 5.4 > URL: https://www.nbcs.rutgers.edu/~richton/openldap-testfail-20100106.tar.bz2 > Submission from: (NULL) (128.6.31.135) > > > During CentOS 5 x86_64 RPM build using the Buchan specfile: > >>>>>> Starting test022-ppolicy for bdb... > running defines.sh > Starting slapd on TCP/IP port 9065... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Testing account lockout... > Waiting 20 seconds for lockout to reset... > Testing password expiration > Waiting 20 seconds for password to expire... > Password expiration test failed >>>>>> ./scripts/test022-ppolicy failed for bdb (exit 1) > > and then everything exited clean. testrun directory attached. > > This is not reproducible; a subsequent rebuild from the same specfile on the > same hardware finished clean. Given that these expiration tests are timing dependent, not sure there's anything real to track down here. -- -- 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#6443) test022-ppolicy failure
by richton＠nbcs.rutgers.edu 06 Jan '10

06 Jan '10

Full_Name: Aaron Richton Version: 2.4.21 OS: CentOS 5.4 URL: https://www.nbcs.rutgers.edu/~richton/openldap-testfail-20100106.tar.bz2 Submission from: (NULL) (128.6.31.135) During CentOS 5 x86_64 RPM build using the Buchan specfile: >>>>> Starting test022-ppolicy for bdb... running defines.sh Starting slapd on TCP/IP port 9065... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Testing account lockout... Waiting 20 seconds for lockout to reset... Testing password expiration Waiting 20 seconds for password to expire... Password expiration test failed >>>>> ./scripts/test022-ppolicy failed for bdb (exit 1) and then everything exited clean. testrun directory attached. This is not reproducible; a subsequent rebuild from the same specfile on the same hardware finished clean.

1 0

Re: (ITS#6442) slaptools iteration enhancement
by masarati＠aero.polimi.it 06 Jan '10

06 Jan '10

> masarati(a)aero.polimi.it writes: >> Both changes will cause binary incompatibility; the latter will not >> require to modify custom backends (I've already modified all the >> existing backends, exploiting in most cases the new feature; in >> back-bdb there is room for minimal improvement, as DN lookahead is >> relatively straightforward, so if base/scope is defined, but no >> filter, some advantages can be expected). > > Could you put them at the end of the tool_globals variable instead? > Then the binary incompatibility will only be in tool_globals, not in the > backend structure. I suppose this variant makes a bit a mess for glue > if nothing else - I assume it would need to to save/modify/restore such > global parameters. Slap tools could accept these parameters only for > backends which which set a flag to say they handle them. > > Might even put them in a mostly empty Operation in tool_globals. Some > backends may be able to reuse existing Search code that way, and other > search-like parameters could be added later if we want. However that > introduces incompatibility after all, so maybe that's for RE25. > '#define tv_sub_ndn tv_op.o_req_ndn' can handle source code compat. I don't think we'll ever need more than a subtree specification. In any case, I think passing those parameters as args rather than as global variables makes more sense. First of all, if you look at the patches, <ftp://ftp.openldap.org/incoming/slaptools-opt1.patch> <ftp://ftp.openldap.org/incoming/slaptools-opt2.patch> backglue is sort of a nightmare. And it doesn't deal yet with gluing backends that only support one of the methods. Second, I'd prefer backends not to know about tool global variables, for basic data isolation. Take it any way 'round, binary incompatibility arises. Option 2 avoids source incompatibility, that's basically what we need. I find it utopistic to expect binary compatibility within the whole life of a minor release. We never guaranteed that, although we tried to preserve it. p.

1 0

Re: (ITS#6442) slaptools iteration enhancement
by h.b.furuseth＠usit.uio.no 06 Jan '10

06 Jan '10

masarati(a)aero.polimi.it writes: > Both changes will cause binary incompatibility; the latter will not > require to modify custom backends (I've already modified all the > existing backends, exploiting in most cases the new feature; in > back-bdb there is room for minimal improvement, as DN lookahead is > relatively straightforward, so if base/scope is defined, but no > filter, some advantages can be expected). Could you put them at the end of the tool_globals variable instead? Then the binary incompatibility will only be in tool_globals, not in the backend structure. I suppose this variant makes a bit a mess for glue if nothing else - I assume it would need to to save/modify/restore such global parameters. Slap tools could accept these parameters only for backends which which set a flag to say they handle them. Might even put them in a mostly empty Operation in tool_globals. Some backends may be able to reuse existing Search code that way, and other search-like parameters could be added later if we want. However that introduces incompatibility after all, so maybe that's for RE25. '#define tv_sub_ndn tv_op.o_req_ndn' can handle source code compat. -- Hallvard

1 0

(ITS#6442) slaptools iteration enhancement
by masarati＠aero.polimi.it 06 Jan '10

06 Jan '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.230) Submitted by: ando I've modified bi_tool_entry_first(), the call that initiates an iteration in slaptools, to allow to pass a subtree, a scope and a filter. This allows backends to only return IDs of entries that meet the specification. Currently, slapcat and slapschema can do this check downstream. This makes sense with most backends, significantly with back-bdb/hdb. However, other backends, like back-ndb and back-sql, and custom or private ones, may be able to exploit this information. I have two variants: one adds three arguments to bi_tool_entry_first(), thus breaking existing custom backends. The other adds a new call bi_tool_entry_first_x(), leaving the existing one untouched. Both changes will cause binary incompatibility; the latter will not require to modify custom backends (I've already modified all the existing backends, exploiting in most cases the new feature; in back-bdb there is room for minimal improvement, as DN lookahead is relatively straightforward, so if base/scope is defined, but no filter, some advantages can be expected). I'd be happy to receive further comments before I proceed with the commit. p.

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 06 Jan '10

06 Jan '10

Please close this its. In 2.4.21 Version works fine. Tanks Jarbas 2009/12/3 Jarbas Peixoto J=FAnior <jarbas.junior(a)gmail.com>: > Attached to the configuration file server testing openldap squeeze. > > I made some changes to the file /etc/ldap/slapd.overlay.conf being > included by /etc/ldap/slapd.conf and discovered that the problem is > with the overlay rwm, because when I comment that overlay the problem > does not appear. > > If I keep the following entries rwm overlay the problem happen again: > > moduleload rwm > overlay rwm > > Even with the other settings overlay rwm commented the problem continues. > > Any ideas? > > > 2009/12/2 Howard Chu <hyc(a)symas.com>: >> jarbas.junior(a)gmail.com wrote: >>> >>> Full_Name: Jarbas Peixoto Junior >>> Version: 2.4.11 / 2.4.17 / 2.4.20 >>> OS: Gnu/Linux Debian >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (200.152.34.143) >>> >>> >>> Possible bug in Overlay pPolicy >>> >>> I have OpenLDAP installed via the Debian Lenny package functioning >>> normally. >>> >>> Aiming to test the version of Debian Squeeze in the test machine instal= led >>> package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). >>> >>> However, when testing the overlay pPolicy noticed that a wrong password >>> authentication, runs all objects in the ldap database, causing a "delay= " >>> that >>> does not exist in version Lenny. >>> >>> Below is some information that may be useful in detecting the problem: >>> >>> File: slapd.conf >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> moduleload =A0 =A0 =A0ppolicy >>> overlay ppolicy >>> ppolicy_default >>> "cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevid= encia,dc=3Dgov,dc=3Dbr" >>> ppolicy_use_lockout >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> ldapsearch -LLL -x -H ldap://squeeze -b >>> ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevidencia,dc=3Dgov= ,dc=3Dbr >>> '(cn=3Ddefault)' >>> dn: >>> cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevide= ncia,dc=3Dgov,d >>> =A0c=3Dbr >>> objectClass: top >>> objectClass: device >>> objectClass: pwdPolicy >>> pwdAttribute: userPassword >>> description:: >>> UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M=3D >>> pwdAllowUserChange: TRUE >>> pwdFailureCountInterval: 3600 >>> pwdGraceAuthNLimit: 5 >>> pwdInHistory: 0 >>> pwdLockoutDuration: 60 >>> pwdMaxAge: 7776000 >>> pwdMinAge: 0 >>> pwdMinLength: 6 >>> pwdSafeModify: FALSE >>> pwdCheckQuality: 1 >>> pwdExpireWarning: 600 >>> cn: default >>> pwdMustChange: FALSE >>> pwdMaxFailure: 10 >>> pwdLockout: FALSE >>> >>> date ; ldapsearch -LLL -x -H ldap://squeeze -b >>> ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgov,dc=3Dbr -D >>> uid=3Djarbas.peixoto,ou=3Dpessoas,ou=3Dusuarios,dc=3Dprevidencia,dc=3Dg= ov,dc=3Dbr -w >>> wrong-password '(uid=3Djarbas.peixoto)' cn mail pwdFailureTime >>> pwdAccountLockedTime modifyTimeStamp ; date >>> Qua Dez =A02 16:14:56 AMST 2009 >>> ldap_bind: Invalid credentials (49) >>> Qua Dez =A02 16:15:36 AMST 2009 >>> >>> grep 'access_allowed: search access to' /var/log/debug | wc -l >>> 83714 >>> >>> The question is: why access all entries in LDAP? >> >> Don't know. This would have to be the result of a search operation, but >> there is no search code in ppolicy.c. Since ppolicy cannot be the culpri= t, >> we'll need to see the rest of your config to track down the issue. >> >> -- >> =A0-- Howard Chu >> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com >> =A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ >> =A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ >> >

1 0

(ITS#6441) auxprop_lookup in cyrus-sasl 2.1.24 returns status
by rein＠OpenLDAP.org 06 Jan '10

06 Jan '10

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein The upcoming 2.1.24 release of cyrus-sasl have changed the auxprop_lookup plugin from void to returning a status value. A patch that fixes it is coming. Rein Tollevik Basefarm AS

1 0

Re: ITS#6439
by h.b.furuseth＠usit.uio.no 06 Jan '10

06 Jan '10

j(a)gropefruit.com writes: > On Jan 5, 2010, at 12:56 , Hallvard B Furuseth wrote: >> Are they saying it somewhere public? I'm sure there are some OpenLDAP >> things they disagree with (I do too), but on this, RFC 4512 section 5.1 >> is quite clear, not to say loud: >> >> "The root DSE SHALL NOT be included if the client performs a subtree >> search starting from the root." > > I appreciate what you're trying to say, but let me be clear about > something. USERS do not care about RFCs. Yes, that's why I asked where they were saying it, to talk with them directly without you caught in the middle... > Fortunately, I have a solution. I was surgical in whom I was going to > argue with. I chose to argue with SUN and denounce their crappy > software. They too touted RFC this and RFC that. I told them to shove > their RFCs somewhere long and narrow. As a result, they ADMIT that its > wrong and they're going to issue a BACKPORT for my situation. Which > should have been done to begin with. Thank you. -- Hallvard

1 0

Re: (ITS#6439) rootDSE access method question
by j＠gropefruit.com 05 Jan '10

05 Jan '10

ldapclient is also used to initialize system-wide configuration of a = solaris box involving LDAP. You pass it the basic parameters needed to = perform LDAP lookups of users, groups, etc., and it generates the system = configuration. This is the message me and my associates have gathered = after all the reading we have done. (Note: This is also "similar" to the = way RedHat's LDAP configuration tool (system-config-authentication) = works, in that parameters are passed from the command line, into a = parser, which then edits files and then initialized the configuration.) Solaris 10's system, even when explicitly told to BIND WITH A PROXY USER = and NOT ANONYMOUSLY, it insists on binding anonymously. --> Our OpenLDAP system does not permit anonymous binds. This is by = design and I will not budge on this. <-- When we try to initialize ldapclient using the automatic config, it = tries to download a profile (which we have ready and waiting in our DIT) = to configure the local system - unfortunately, since its binding = anonymously, this fails. So our remaining option is to use the ldapclient utility with the MANUAL = config option, where we DON'T use a profile, rather we pass the needed = parameters to it manually, on the command line . When we configure this manually and execute the configuration changes, = we see in our slapd logs an attempt to talk to our system looking for = the supportedControl and supportedSASLMechanisms attributes -- which are = only available in the rootDSE. Unfortunately, this process uses every = scope EXCEPT base, which is the only scope that allows rootDSE to be = queried. Furthermore, I got them to admit that the very act of looking for SASL = entries when doing a SIMPLE BIND config is retarded. They agreed. So we have a few issues on Solaris' side: * Superfluous SASL queries, even in SIMPLE config. * Lack of base scope makes rootDSE query impossible * Client insists on binding anonymously, even when told NOT to They have offered to fix these things, I'm waiting on them now ... The important thing is that our slapd config is not to blame, as = everything else in our infrastructure that uses the DS system I built is = working nicely. J Solaris 10's system implicitly tries to perform=20 On Jan 5, 2010, at 15:05 , Howard Chu wrote: > j(a)gropefruit.com wrote: >> Full_Name: J >> Version: 2.4.20 >> OS: Debian-Lenny/amd64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (68.15.14.98) >>=20 >>=20 >> Certain clients (for example, a Solaris 10 host) need to query the = rootDSE of >> our OpenLDAP server. Unfortunately, due to the way their client = software is >> written, the Solaris 10 client will only be able to attempt to view = the rootDSE >> using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL = searches of >> the rootDSE. >>=20 >> Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for >> testing-purposes, so I know otherwise things should work (ACL-wise, = etc). It >> just seems to be a problem in the system-config, as the man page = clearly states >> that only the two aforementioned scopes are allowed. >>=20 >> Options? Is there a way I can alias a DN-less object? If so, is this = even >> advisable?=20 >>=20 >> Or, perhaps is there a way to store an alternate copy of the rootDSE = somewhere >> that is more "conventionally" accessible? >>=20 >> At this point, I'll consider any alternative. I reviewed the manpage = for >> slapd.conf, however the rootDSE parameter in slapd.conf seems to be = only used >> for "additions" or supplemental changes to an existing rootDSE. >=20 > Since you quoted the ldapclient docs, I have to ask what exactly = you're trying > to accomplish. Solaris ldapclient is only used to configure NSS, and = there are > no NSS tables that serve anything that could be extracted from an LDAP > server's rootDSE. What are you really trying to do? >=20 > --=20 > -- 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#6439) rootDSE access method question
by hyc＠symas.com 05 Jan '10

05 Jan '10

j(a)gropefruit.com wrote: > Full_Name: J > Version: 2.4.20 > OS: Debian-Lenny/amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) > > > Certain clients (for example, a Solaris 10 host) need to query the rootDSE of > our OpenLDAP server. Unfortunately, due to the way their client software is > written, the Solaris 10 client will only be able to attempt to view the rootDSE > using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL searches of > the rootDSE. > > Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for > testing-purposes, so I know otherwise things should work (ACL-wise, etc). It > just seems to be a problem in the system-config, as the man page clearly states > that only the two aforementioned scopes are allowed. > > Options? Is there a way I can alias a DN-less object? If so, is this even > advisable? > > Or, perhaps is there a way to store an alternate copy of the rootDSE somewhere > that is more "conventionally" accessible? > > At this point, I'll consider any alternative. I reviewed the manpage for > slapd.conf, however the rootDSE parameter in slapd.conf seems to be only used > for "additions" or supplemental changes to an existing rootDSE. Since you quoted the ldapclient docs, I have to ask what exactly you're trying to accomplish. Solaris ldapclient is only used to configure NSS, and there are no NSS tables that serve anything that could be extracted from an LDAP server's rootDSE. What are you really trying to do? -- -- 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#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 05 Jan '10

05 Jan '10

--On Tuesday, January 05, 2010 1:39 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, December 30, 2009 1:09 PM +0000 helge(a)monsternett.no > wrote: > >> On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >>> I just enabled trace loglevel, perhaps that might give us a clue on >>> what's going on. >> >> Slapd just stopped working again. Here's the (annotated) log for viewing >> and/or downloading: http://www.pastie.org/761198.txt >> >> Does this give you any clues? >> >> Tell me if I can do anything else to help. > > A fix for this has been committed to HEAD. You can apply it to the > latest source (2.4.21) if you would like to try it out: > > <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/daemon.c.diff?hid > eattic=1&r1=text&tr1=1.442&r2=text&tr2=1.443&f=u> Hm, correction, it fixes a minor shutdown issue, not your main issue. :/ --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 05 Jan '10

05 Jan '10

--On Wednesday, December 30, 2009 1:09 PM +0000 helge(a)monsternett.no wrote: > On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >> I just enabled trace loglevel, perhaps that might give us a clue on >> what's going on. > > Slapd just stopped working again. Here's the (annotated) log for viewing > and/or downloading: http://www.pastie.org/761198.txt > > Does this give you any clues? > > Tell me if I can do anything else to help. A fix for this has been committed to HEAD. You can apply it to the latest source (2.4.21) if you would like to try it out: <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/daemon.c.diff?hideat…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#6439
by j＠gropefruit.com 05 Jan '10

05 Jan '10

--Apple-Mail-21-951114980 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 5, 2010, at 12:56 , Hallvard B Furuseth wrote: > j(a)telepaths.org writes: >> For compatibility reasons, It may well be in OpenLDAP's best interest = to >> provide options such as the ones I described previously, for "broken" = or >> "substandard" clients such as the ones I am using. >=20 I do not program. > If someone (you?) cares enough, they can write an overlay to > the OpenLDAP slapd frontend which intercepts searches with > (baseObject=3D"", scope=3DwholeSubtree) and changes the scope of > the operation to baseObject. That shouldn't be much code. >=20 Thats an interesting idea nonetheless, thanks. > A server using this overlay must not have a database with suffix "", > since this would break subtree searches in that database. >=20 >> I will point out that Solaris 11 doesn't exhibit these issues ---- = But >> my company wants to use Solaris 10, which leaves me in the middle of = a >> finger pointing party between OPENLDAP and SUN. So you can = understand >> why I might be asking for something as strange as this .... >>=20 >> SUN says OpenLDAP's standard/methods are questionable & strange.=20 >> OpenLDAP says Sun's client is broken and that we should hack it. I = say >> screw Solaris 10. >=20 No this is a commercial support issue I am working on. I doubt its being = publicized anywhere. > Are they saying it somewhere public? I'm sure there are some OpenLDAP > things they disagree with (I do too), but on this, RFC 4512 section = 5.1 > is quite clear, not to say loud: >=20 > "The root DSE SHALL NOT be included if the client performs a subtree > search starting from the root." >=20 I appreciate what you're trying to say, but let me be clear about = something. USERS do not care about RFCs. Even some Administrators, = like me, don't care! We are too busy trying to make stuff work, rather = that having a debate with the makers of software as to what rules they = should be following. Fortunately, I have a solution. I was surgical in whom I was going to = argue with. I chose to argue with SUN and denounce their crappy = software. They too touted RFC this and RFC that. I told them to shove = their RFCs somewhere long and narrow. As a result, they ADMIT that its = wrong and they're going to issue a BACKPORT for my situation. Which = should have been done to begin with. Nevertheless, as I said earlier, OpenLDAP (like many other high and = mighty open source systems) should continue to follow RFCs like always. = But it won't kill anyone to offer alternatives that do NOT involve = reaching deep into the bowels of code we don't understand. Even if the = solutions are bizarre, someone out there is wasting hours and hours = trying to make his own solution work, and would be delighted to find = something native had been implemented. > (Onelevel search is not relevant in this context since it wouldn't > return the baseobject anyway.) >=20 Thanks for your input. > --=20 > Hallvard --Apple-Mail-21-951114980 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><div>On Jan 5, 2010, at 12:56 , Hallvard B Furuseth = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div><a href=3D"mailto:j@telepaths.org">j(a)telepaths.org</a> = writes:<br><blockquote type=3D"cite">For compatibility reasons, It may = well be in OpenLDAP's best interest to<br></blockquote><blockquote = type=3D"cite">provide options such as the ones I described previously, = for "broken" or<br></blockquote><blockquote type=3D"cite">"substandard" = clients such as the ones I am = using.<br></blockquote><br></div></blockquote><div><br></div><div>I do = not program.</div><br><blockquote type=3D"cite"><div>If someone (you?) = cares enough, they can write an overlay to<br>the OpenLDAP slapd = frontend which intercepts searches with<br>(baseObject=3D"", = scope=3DwholeSubtree) and changes the scope of<br>the operation to = baseObject.  That shouldn't be much = code.<br><br></div></blockquote><div><br></div><div>Thats an interesting = idea nonetheless, thanks.</div><br><blockquote type=3D"cite"><div>A = server using this overlay must not have a database with suffix = "",<br>since this would break subtree searches in that = database.<br><br><blockquote type=3D"cite">I will point out that Solaris = 11 doesn't exhibit these issues ---- But<br></blockquote><blockquote = type=3D"cite">my company wants to use Solaris 10, which leaves me in the = middle of a<br></blockquote><blockquote type=3D"cite">finger pointing = party between OPENLDAP and SUN.  So you can = understand<br></blockquote><blockquote type=3D"cite">why I might be = asking for something as strange as this ....<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">SUN says = OpenLDAP's standard/methods are questionable & strange. = <br></blockquote><blockquote type=3D"cite">OpenLDAP says Sun's client is = broken and that we should hack it.   I = say<br></blockquote><blockquote type=3D"cite">screw Solaris = 10.<br></blockquote><br></div></blockquote><div><br></div><div>No this = is a commercial support issue I am working on. I doubt its being = publicized anywhere.</div><br><blockquote type=3D"cite"><div>Are they = saying it somewhere public?  I'm sure there are some = OpenLDAP<br>things they disagree with (I do too), but on this, RFC 4512 = section 5.1<br>is quite clear, not to say = loud:<br><br></div></blockquote><blockquote = type=3D"cite"><div>  "The root DSE SHALL NOT be included if = the client performs a subtree<br>   search starting from the = root."<br><font class=3D"Apple-style-span" color=3D"#000000"><font = class=3D"Apple-style-span" = color=3D"#144FAE"><br></font></font></div></blockquote><div><br></div><div= ><div>I appreciate what you're trying to say, but let me be clear about = something.  USERS do not care about RFCs.  Even some = Administrators, like me, don't care! We are too busy trying to make = stuff work, rather that having a debate with the makers of software as = to what rules they should be = following.</div><div><br></div><div>Fortunately, I have a solution. =  I was surgical in whom I was going to argue with. I chose to argue = with SUN and denounce their crappy software.  They too touted RFC = this and RFC that.  I told them to shove their RFCs somewhere long = and narrow.  As a result, they ADMIT that its wrong and they're = going to issue a BACKPORT for my situation.  Which should have been = done to begin with.</div><div><br></div><div>Nevertheless, as I said = earlier, OpenLDAP (like many other high and mighty open source systems) = should continue to follow RFCs like always.  But it won't kill = anyone to offer alternatives that do NOT involve reaching deep into the = bowels of code we don't understand.  Even if the solutions are = bizarre, someone out there is wasting hours and hours trying to make his = own solution work, and would be delighted to find something native had = been implemented.</div><div><br></div></div><blockquote = type=3D"cite"><div>(Onelevel search is not relevant in this context = since it wouldn't<br>return the baseobject = anyway.)<br><br></div></blockquote><div><br></div><div>Thanks for your = input.</div><br><blockquote type=3D"cite"><div>-- = <br>Hallvard<br></div></blockquote></div><br></body></html>= --Apple-Mail-21-951114980--

1 0

Re: ITS#6439
by h.b.furuseth＠usit.uio.no 05 Jan '10

05 Jan '10

j(a)telepaths.org writes: > For compatibility reasons, It may well be in OpenLDAP's best interest to > provide options such as the ones I described previously, for "broken" or > "substandard" clients such as the ones I am using. If someone (you?) cares enough, they can write an overlay to the OpenLDAP slapd frontend which intercepts searches with (baseObject="", scope=wholeSubtree) and changes the scope of the operation to baseObject. That shouldn't be much code. A server using this overlay must not have a database with suffix "", since this would break subtree searches in that database. > I will point out that Solaris 11 doesn't exhibit these issues ---- But > my company wants to use Solaris 10, which leaves me in the middle of a > finger pointing party between OPENLDAP and SUN. So you can understand > why I might be asking for something as strange as this .... > > SUN says OpenLDAP's standard/methods are questionable & strange. > OpenLDAP says Sun's client is broken and that we should hack it. I say > screw Solaris 10. Are they saying it somewhere public? I'm sure there are some OpenLDAP things they disagree with (I do too), but on this, RFC 4512 section 5.1 is quite clear, not to say loud: "The root DSE SHALL NOT be included if the client performs a subtree search starting from the root." (Onelevel search is not relevant in this context since it wouldn't return the baseobject anyway.) -- Hallvard

1 0

Re: ITS#6439
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

> =46rom Solaris 10's 'ldapclient' manpage: > > defaultSearchScope=3Done | sub > > Specify the default search scope for the client's search > operations. This default can be overridden for a given > service by specifying a serviceSearchDescriptor. The > default is one level search. > > The parameter 'defaultSearchScope' only allows ONE or SUB. > > The 'serviceSearchDescriptor' is not an option, since this is designed = > to work with NSS objects like 'passwd', 'shadow', 'hosts', etc. rootDSE = > is not a service in that sense, so it won't work here. > > For compatibility reasons, It may well be in OpenLDAP's best interest to = > provide options such as the ones I described previously, for "broken" or = > "substandard" clients such as the ones I am using. > > I will point out that Solaris 11 doesn't exhibit these issues ---- But = > my company wants to use Solaris 10, which leaves me in the middle of a = > finger pointing party between OPENLDAP and SUN. So you can understand = > why I might be asking for something as strange as this .... > > SUN says OpenLDAP's standard/methods are questionable & strange. = > OpenLDAP says Sun's client is broken and that we should hack it. I say = > screw Solaris 10. OpenLDAP may be questionable & strange, I'm not going to debate it. But I pointed you to a RFC that clearly states what's the correct procedure to perform an operation. You're pointing me to the man page of a client that eventually got fixed across releases. If a client can't perform an operation dictated by an RFC, and pretends to do it another way, I'd call that "questionable & strange". > Thank you for your assistance. You can probably close this ticket. :) p.

1 0

Re: ITS#6439
by j＠telepaths.org 05 Jan '10

05 Jan '10

=46rom Solaris 10's 'ldapclient' manpage: defaultSearchScope=3Done | sub Specify the default search scope for the client's search operations. This default can be overridden for a given service by specifying a serviceSearchDescriptor. The default is one level search. The parameter 'defaultSearchScope' only allows ONE or SUB. The 'serviceSearchDescriptor' is not an option, since this is designed = to work with NSS objects like 'passwd', 'shadow', 'hosts', etc. rootDSE = is not a service in that sense, so it won't work here. For compatibility reasons, It may well be in OpenLDAP's best interest to = provide options such as the ones I described previously, for "broken" or = "substandard" clients such as the ones I am using. I will point out that Solaris 11 doesn't exhibit these issues ---- But = my company wants to use Solaris 10, which leaves me in the middle of a = finger pointing party between OPENLDAP and SUN. So you can understand = why I might be asking for something as strange as this .... SUN says OpenLDAP's standard/methods are questionable & strange. = OpenLDAP says Sun's client is broken and that we should hack it. I say = screw Solaris 10. Thank you for your assistance. You can probably close this ticket. J On Jan 5, 2010, at 10:05 , masarati(a)aero.polimi.it wrote: > The behavior you describe violates RFC 4512 (section 5.1), while = OpenLDAP > complies with it. Please note that the root DSE is accessed using a > plain, perfectly legal LDAP operation. The fact a client cannot be > configured to perform such a simple operation clearly indicates the = client > is broken. A quick answer would be "get the client fixed". >=20 > <advertisement> > I can imagine simple workarounds, consisting in few lines of code that > allow to circumvent the issue. They probably require to hire some = expert > consultant. > </advertisement> >=20 > p. >=20

1 0

ITS#6439
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

The behavior you describe violates RFC 4512 (section 5.1), while OpenLDAP complies with it. Please note that the root DSE is accessed using a plain, perfectly legal LDAP operation. The fact a client cannot be configured to perform such a simple operation clearly indicates the client is broken. A quick answer would be "get the client fixed". <advertisement> I can imagine simple workarounds, consisting in few lines of code that allow to circumvent the issue. They probably require to hire some expert consultant. </advertisement> p.

1 0

(ITS#6440) slapcat could write info about how it was run in form of LDIF comments
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.230) Submitted by: ando Something like # slapcat run by <who>@<host> on <date> ... LDIF of database # number of entries, execution time, file size, ... For backward compatibility, this would need to be enabled by a specific switch. p.

1 0

(ITS#6439) rootDSE access method question
by j＠gropefruit.com 05 Jan '10

05 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Certain clients (for example, a Solaris 10 host) need to query the rootDSE of our OpenLDAP server. Unfortunately, due to the way their client software is written, the Solaris 10 client will only be able to attempt to view the rootDSE using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL searches of the rootDSE. Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for testing-purposes, so I know otherwise things should work (ACL-wise, etc). It just seems to be a problem in the system-config, as the man page clearly states that only the two aforementioned scopes are allowed. Options? Is there a way I can alias a DN-less object? If so, is this even advisable? Or, perhaps is there a way to store an alternate copy of the rootDSE somewhere that is more "conventionally" accessible? At this point, I'll consider any alternative. I reviewed the manpage for slapd.conf, however the rootDSE parameter in slapd.conf seems to be only used for "additions" or supplemental changes to an existing rootDSE. Thanks J

1 0

Re: (ITS#6438) usage of invalid mutexint in syncprov
by hyc＠symas.com 04 Jan '10

04 Jan '10

Aaron Richton wrote: > *so = { > s_next = 0x54f778 > s_base = { > bv_len = 0 > bv_val = (nil) > } > s_eid = 2147483967U > s_op = (nil) > s_rid = -34707408 > s_sid = -32897008 > s_filterstr = { > bv_len = 0 > bv_val = (nil) > } > s_flags = 0 > s_inuse = -1 Looks like syncprov_free_syncop() was getting called twice while in the middle of freeing. A potential fix is in HEAD. -- -- 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#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

*so = { s_next = 0x54f778 s_base = { bv_len = 0 bv_val = (nil) } s_eid = 2147483967U s_op = (nil) s_rid = -34707408 s_sid = -32897008 s_filterstr = { bv_len = 0 bv_val = (nil) } s_flags = 0 s_inuse = -1 s_res = 0x523120 s_restail = (nil) s_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 0 __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 82U __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 5392720U } __pthread_mutex_owner64 = 5392720ULL } __pthread_mutex_data = 0 } }

1 0

Re: (ITS#6438) usage of invalid mutexint in syncprov
by hyc＠symas.com 04 Jan '10

04 Jan '10

richton(a)nbcs.rutgers.edu wrote: > Backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-6438-bt.txt So we passed a NULL pointer in here, odd. Thread 5 is the one that crashed; in frame 4 can you print *so ? -- -- 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#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

Backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-6438-bt.txt

1 0

(ITS#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

Full_Name: Aaron Richton Version: RE24 20091217 (2.4.21) OS: Solaris 9 URL: :wq Submission from: (NULL) (128.6.31.135) dec_mutexint was called with a NULL parameter while running the test suite. Unfortunately, the only evidence of this is a core file.

1 0

Re: (ITS#6437) sl_malloc issues
by hyc＠symas.com 04 Jan '10

04 Jan '10

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Nobody uses the pool code. I would suggest you profile it against the stack >> code before spending any time fixing it. > > The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply > the allocated amounts by 17. The stack version stays happy. I also > tried RE23 and rev 1.48 in case of code rot. (Should have tried > OpenLDAP 2.2, but would need to install an old Berkeley DB.) Adding a > sl_malloc fallback to ch_malloc instead of returning NULL didn't help. > > Anyway, I tried this because I assume the pool version is intended to > reduce the number of sl_malloc fallbacks to ch_malloc, but that almost > never happens in 'make test' with the current SLAP_SLAB_SIZE. Which > made that aspect hard to test. > > Also the pool version does a number of ch_mallocs for administration and > ch_frees them at reset. If the idea is to reduce ch_mallocs, it should > keep these blocks around. (Or allocate them with the slab.) Except the > 'slab_object's It only needs cleanup if the slab size changes, which > slapd never seems to do. This stuff was originally written to grow the slab as needed, but it was also being very braindead and would have kept a lot of excess memory lying around so I dropped that. So right, currently the slab size doesn't change. -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 04 Jan '10

04 Jan '10

> > OK. Another question - you're only using NSS_InitContext() for client > initialization. Any particular reason not to always use it? > I had coded around a bug in NSS_InitContext that caused it not to work in server mode - the MozNSS guys are aware of this issue - I'm waiting on the fix. > Also in tlsm_ctx_free() is it safe to pass a NULL to NSS_ShutdownContext()? I > think these two lines should be enclosed in "if (c->tc_initctx) {}" I'll change it to check for NULL.

1 0

Re: (ITS#4033) Enhancement requests : Need LDIF parsing API's
by rmeggins＠redhat.com 04 Jan '10

04 Jan '10

See also http://www.openldap.org/its/index.cgi/Software%20Enhancements?id=6194;selec… An API that returned LDAPMod ** and LDAPControl ** would be sufficient for all cases, including the LDAP ADD and any LDAP modify cases. The current discussion revolves around exposing the high level LDAPMod and LDAPControl APIs to the lower level libldif, or just passing the parsed values as lists of struct berval *

1 0

Re: (ITS#6437) sl_malloc issues
by h.b.furuseth＠usit.uio.no 04 Jan '10

04 Jan '10

hyc(a)symas.com writes: > Nobody uses the pool code. I would suggest you profile it against the stack > code before spending any time fixing it. The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply the allocated amounts by 17. The stack version stays happy. I also tried RE23 and rev 1.48 in case of code rot. (Should have tried OpenLDAP 2.2, but would need to install an old Berkeley DB.) Adding a sl_malloc fallback to ch_malloc instead of returning NULL didn't help. Anyway, I tried this because I assume the pool version is intended to reduce the number of sl_malloc fallbacks to ch_malloc, but that almost never happens in 'make test' with the current SLAP_SLAB_SIZE. Which made that aspect hard to test. Also the pool version does a number of ch_mallocs for administration and ch_frees them at reset. If the idea is to reduce ch_mallocs, it should keep these blocks around. (Or allocate them with the slab.) Except the 'slab_object's It only needs cleanup if the slab size changes, which slapd never seems to do. -- Hallvard

1 0

Re: (ITS#6437) sl_malloc issues
by h.b.furuseth＠usit.uio.no 02 Jan '10

02 Jan '10

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: > Go ahead and commit. In working pieces if necessary. We'll pick and choose... Committed one batch of fixes/tweaks, hopefully independent after the first one or two. Next batch will have to walk all over some of these. >> * Why is there a slap_sl_mem_detach() when there is no way to reattach >> it? As far as I can tell all the caller can do is to inspect/clean up >> the returned slab_heap itself. > > It was originally implemented in 2.2 to support psearch for sync replication. > It was obsoleted when the syncprov overlay was written in 2.3, we just never > deleted it. Go ahead and delete it. Actually I just realized the context can be used thread-less just fine, even if it's only relevant if any 3rd party modules do it. Might as well keep it in RE24, just in case. But I'll move structs slap_object and slap_heap back to sl_malloc.c, so such modules cannot mess with them. > (And remember, the point of sl_malloc is that a heap here doesn't need > any special cleanup - just free it and forget it.) Not quite, due to the ch_malloc fallbacks. Anyway, I've committed some comments with my understanding of the package. >> * Some failures assert(0)/exit() like ch_malloc.c, but without giving a >> Debug() message first. > > don't really care... I do, I've had silent exits from slapd before and hated it. -- Hallvard

1 0

Re: (ITS#6437) sl_malloc issues
by h.b.furuseth＠usit.uio.no 02 Jan '10

02 Jan '10

hyc(a)symas.com writes: > Go ahead and commit. In working pieces if necessary. We'll pick and choose... Thanks. Will do. > Nobody uses the pool code. I would suggest you profile it against the stack > code before spending any time fixing it. Right, that and detach was what I wondered most about. Beyond just "with enough changes, some will be bugs":-) Well, the current pool code blocks the "ber_len_t -> 32-bit" space optimization, which would import the alignment problem to 64-bit hosts. Will profile first. When I get time. >> * Regarding code duplication, the #ifdef SLAP_NO_SL_MALLOC code >> duplicates the !ctx code. Make that if(<enum No_sl_malloc> && !ctx) >> and the #ifdefs can be killed. > > I would personally prefer no runtime checks, and all compile-time checks. Right, but if(compile-time constant) is a compile-time check on a decent compiler. Otherwise we shouldn't be using '#define foobar do { ... } while(0)' trick to allow ';' after a macro. -- Hallvard

1 0

Re: (ITS#6437) sl_malloc issues
by hyc＠symas.com 01 Jan '10

01 Jan '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Here are a number of bugs and other issues with slapd/sl_malloc.c, and > one for ber_memcalloc. Some for RE24, likely some for RE25, but I don't > know where to cut off for RE24? (Waiting for someone to say...) Go ahead and commit. In working pieces if necessary. We'll pick and choose... > > * It claims to align on 2*sizeof(int) boundaries, but it looks like > stack:realloc and pool:mem_create can un-align to (2n+1)*sizeof(int) > boundaries on 32-bit hosts, where sizeof(ber_len_t) == sizeof(int). > > A slap_sl_realloc() fix for the stack implementation is to replace > size += pad + sizeof( ber_len_t ); > size&= ~pad; > with > size = ((size + pad)& ~pad) + sizeof( ber_len_t ); > however see the optimizations and tweaks below. Fine. > For the pool implementation, maybe slap_sl_mem_create() can just set > so->so_ptr = (char *) sh->sh_base + sizeof(ber_len_t) % (pad+1); > Unless that messes up its expectations of how much space is left, I > haven't checked. Should mem_create size be increased accordingly? Nobody uses the pool code. I would suggest you profile it against the stack code before spending any time fixing it. > Unfortunately sl_malloc.c exports its internals, so I don't know what > kind of fix would affect it: > > * Why is there a slap_sl_mem_detach() when there is no way to reattach > it? As far as I can tell all the caller can do is to inspect/clean up > the returned slab_heap itself. It was originally implemented in 2.2 to support psearch for sync replication. It was obsoleted when the syncprov overlay was written in 2.3, we just never deleted it. Go ahead and delete it. (And remember, the point of sl_malloc is that a heap here doesn't need any special cleanup - just free it and forget it.) > * slap_sl_mem_create() switching implementation stack<->pool on an old > memctx slab can crash or leak, it runs the wrong cleanup code. > > Fix: Remove code duplication, rearrange. The pool cleanup duplicates > slap_sl_mem_destroy(), except the final frees. Let destroy(key=NULL,) > mean don't free and call that. Also the create/destroy pool branches > duplicate the stack branches. > > * However, will the pool (i.e. non-stack) implementation ever be used? > If not, a simpler fix to some of this is to delete it. OTOH if it > someday may be used, hopefully some of these cleanups will be leaving > it a bit more correct, easier to read, and faster. Though I haven't > gone to the drastic step of studying it to see how it works. > > Or we could #ifdef it out by default. It's unclear to me why this is > a run-time argument to the create function instead of instead of a > -D<compiler flag>, why would the caller care? Dunno. I guess it was for quicker turnaround during testing. But afaik only Jong ever tested/used it, and no one else has spent any time on it. #if'ing it all out is fine with me. Of course, if you find that it's actually better performing than the stack version, then we can #if out the stack code instead. > > #define SLAP_SLAB_MODE<undef or 1:stack, 0:pool: -1:support both>. > #define SLAP_SLAB_ISSTACK(stack)<stack if both, else SLAP_SLAB_MODE> > > * Regarding code duplication, the #ifdef SLAP_NO_SL_MALLOC code > duplicates the !ctx code. Make that if(<enum No_sl_malloc> && !ctx) > and the #ifdefs can be killed. I would personally prefer no runtime checks, and all compile-time checks. > * Also we can throw the #ifdef NO_THREADS/#else/#endif code out to two > macros #define GET_MEMCTX()/SET_MEMCTX(). right. > * The "enough room?" test (ptr + size< endptr) is invalid, can e.g. > wrap around, when there is not enough room. Use (size< endptr-ptr). ok. > * Some failures assert(0)/exit() like ch_malloc.c, but without giving a > Debug() message first. don't really care... > * The slap_sl_malloc() pool implementation can return NULL on failure > at comment "FIXME: missing return; guessing...". For consistency it > should exit on failure like the rest of sl_malloc.c and ch_malloc.c. don't care, unless we decide to keep the pool code. Go ahead and commit. > * Realloc(last block) when the following free space is not big enough, > does not move sh_last and reclaim free space properly. > > * slap_sl_calloc()/ber_memcalloc() do not catch<count>*<size> overflow: > ber_len_t total = n * size; > if (!n&& total/n == size)<allocate...>; > > That can be optimized a bit, if anyone cares: > > #define LIM_SQRT(t) /* some value< sqrt(max value of unsigned type t) */ \ > ((0UL|(t)-1)>>31>>31> 1 ? ((t)1<<32) - 1 : \ > (0UL|(t)-1)>>31 ? 65535U : (0UL|(t)-1)>>15 ? 255U : 15U) > ... > /* sqrt test = slight optimization: often avoids the division */ > if ((n | size)<= LIM_SQRT(ber_len_t) || !n || total/n == size) ... > > * slap_sl_<malloc/realloc> increase size before proceeding, they should > reduce it before falling back to ch_malloc and for Debug messages. > > Space optimizations/cleanup: > > * To save space on 64-bit hosts: We can store store sizes (head, tail) > in 4-byte typedef ber_uint_t slap_sl_size_t instead of a ber_len_t. > > After fixing the misalignment issue above, however. > > * Also the stack implementation does not need to allocate the tail. > It can store the "block is freed" bit in the head of the _next_ block, > and only store a tail in free blocks (i.e. if that bit is set). > > I think that does add a bit of code, though it is convenient for the > "reclaim freed blocks at sh_last" code in slap_sl_free(). > > * Ignoring last point, the "reclaim" code can in any case be simplified: > /* mark it free */ > p[-1] = size |= 1; > /* reclaim free space off tail */ > if (sh->sh_last == p) { > do { > p = (slap_sllen_t*) ((char*) p - size + 1) - 1; > size = p[-1]; > } while (size& 1); > sh->sh_last = p; > } > > * Realloc can check if previous or next block is free before giving up > and doing malloc/copy/free. That does multiply its code size though. > Dunno if it's a good idea. Needs testing/timing, I guess. > > * Aligning with (size& ~pad) is wrong for non-two's complement signed > pad, it should be (size& -(pad + 1)) aka (size& -Alignment). > > All right, so I'm nitpicking. I just dislike unportable code which > isn't even simpler than the portable variant. -- -- 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#6437) sl_malloc issues
by h.b.furuseth＠usit.uio.no 01 Jan '10

01 Jan '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Here are a number of bugs and other issues with slapd/sl_malloc.c, and one for ber_memcalloc. Some for RE24, likely some for RE25, but I don't know where to cut off for RE24? (Waiting for someone to say...) * It claims to align on 2*sizeof(int) boundaries, but it looks like stack:realloc and pool:mem_create can un-align to (2n+1)*sizeof(int) boundaries on 32-bit hosts, where sizeof(ber_len_t) == sizeof(int). A slap_sl_realloc() fix for the stack implementation is to replace size += pad + sizeof( ber_len_t ); size &= ~pad; with size = ((size + pad) & ~pad) + sizeof( ber_len_t ); however see the optimizations and tweaks below. For the pool implementation, maybe slap_sl_mem_create() can just set so->so_ptr = (char *) sh->sh_base + sizeof(ber_len_t) % (pad+1); Unless that messes up its expectations of how much space is left, I haven't checked. Should mem_create size be increased accordingly? Unfortunately sl_malloc.c exports its internals, so I don't know what kind of fix would affect it: * Why is there a slap_sl_mem_detach() when there is no way to reattach it? As far as I can tell all the caller can do is to inspect/clean up the returned slab_heap itself. * slap_sl_mem_create() switching implementation stack<->pool on an old memctx slab can crash or leak, it runs the wrong cleanup code. Fix: Remove code duplication, rearrange. The pool cleanup duplicates slap_sl_mem_destroy(), except the final frees. Let destroy(key=NULL,) mean don't free and call that. Also the create/destroy pool branches duplicate the stack branches. * However, will the pool (i.e. non-stack) implementation ever be used? If not, a simpler fix to some of this is to delete it. OTOH if it someday may be used, hopefully some of these cleanups will be leaving it a bit more correct, easier to read, and faster. Though I haven't gone to the drastic step of studying it to see how it works. Or we could #ifdef it out by default. It's unclear to me why this is a run-time argument to the create function instead of instead of a -D<compiler flag>, why would the caller care? #define SLAP_SLAB_MODE <undef or 1:stack, 0:pool: -1:support both>. #define SLAP_SLAB_ISSTACK(stack) <stack if both, else SLAP_SLAB_MODE> * Regarding code duplication, the #ifdef SLAP_NO_SL_MALLOC code duplicates the !ctx code. Make that if(<enum No_sl_malloc> && !ctx) and the #ifdefs can be killed. * Also we can throw the #ifdef NO_THREADS/#else/#endif code out to two macros #define GET_MEMCTX()/SET_MEMCTX(). * The "enough room?" test (ptr + size < endptr) is invalid, can e.g. wrap around, when there is not enough room. Use (size < endptr-ptr). * Some failures assert(0)/exit() like ch_malloc.c, but without giving a Debug() message first. * The slap_sl_malloc() pool implementation can return NULL on failure at comment "FIXME: missing return; guessing...". For consistency it should exit on failure like the rest of sl_malloc.c and ch_malloc.c. * Realloc(last block) when the following free space is not big enough, does not move sh_last and reclaim free space properly. * slap_sl_calloc()/ber_memcalloc() do not catch <count>*<size> overflow: ber_len_t total = n * size; if (!n && total/n == size) <allocate...>; That can be optimized a bit, if anyone cares: #define LIM_SQRT(t) /* some value < sqrt(max value of unsigned type t) */ \ ((0UL|(t)-1) >>31>>31 > 1 ? ((t)1 <<32) - 1 : \ (0UL|(t)-1) >>31 ? 65535U : (0UL|(t)-1) >>15 ? 255U : 15U) ... /* sqrt test = slight optimization: often avoids the division */ if ((n | size) <= LIM_SQRT(ber_len_t) || !n || total/n == size) ... * slap_sl_<malloc/realloc> increase size before proceeding, they should reduce it before falling back to ch_malloc and for Debug messages. Space optimizations/cleanup: * To save space on 64-bit hosts: We can store store sizes (head, tail) in 4-byte typedef ber_uint_t slap_sl_size_t instead of a ber_len_t. After fixing the misalignment issue above, however. * Also the stack implementation does not need to allocate the tail. It can store the "block is freed" bit in the head of the _next_ block, and only store a tail in free blocks (i.e. if that bit is set). I think that does add a bit of code, though it is convenient for the "reclaim freed blocks at sh_last" code in slap_sl_free(). * Ignoring last point, the "reclaim" code can in any case be simplified: /* mark it free */ p[-1] = size |= 1; /* reclaim free space off tail */ if (sh->sh_last == p) { do { p = (slap_sllen_t*) ((char*) p - size + 1) - 1; size = p[-1]; } while (size & 1); sh->sh_last = p; } * Realloc can check if previous or next block is free before giving up and doing malloc/copy/free. That does multiply its code size though. Dunno if it's a good idea. Needs testing/timing, I guess. * Aligning with (size & ~pad) is wrong for non-two's complement signed pad, it should be (size & -(pad + 1)) aka (size & -Alignment). All right, so I'm nitpicking. I just dislike unportable code which isn't even simpler than the portable variant. * pad and order_start can be compile-time enums instead of computed at run time (if any compilers do not optimize it away already): enum { Align = 2*sizeof(int), Align_log2 = 1 + (Align>2) + (Align>4) + (Align>8) + (Align>16), pad = Align - 1, /* but drop that, it's just as easy to use Align */ order_start = Align_log2 /* which also can be dropped */ }; ... assert(Align == 1 << Align_log2); /* Adding head+tail preserves alignment */ assert(2*sizeof(ber_len_t) % Align == 0); * The pool code can be cleaned up by basing 'order' on Align-sized chunks instead of byte-sized chunks, i.e. subtract order_start from sh->sh_maxorder, order/i/j variables. Also subtract 1 from mem_create:order, so that 'order' means the same as 'order' elsewhere. (Straightforward replacement, no need to invoke the brain and understand the code:-) * The pool implementation sometimes does 1<<foo where it should do (ber_len_t)1<<foo or 1U<<foo.

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by hyc＠symas.com 30 Dec '09

30 Dec '09

vargok(a)yahoo.com wrote: > (I realize this is ridiculously late, but... well, better late than never, and this is the first I've gotten back to it.) > > Yes! It's working now in 2.4.x as expected, via the new userCertificate > stub data provided by example. FWIW, it appears to be working fine with the PostgreSQL example files as well. > > Unfortunately, it was never "back" ported to 2.3. We're currently using 2.3.43 as part of RHEL-5. Any chance it could get back-ported into the 2.3 branch? Development on 2.3 ended about a year ago. > Thanks, > Kevin > > > > ----- Original Message ---- >> From: Pierangelo Masarati<ando(a)sys-net.it> >> To: vargok(a)yahoo.com >> Cc: openldap-its(a)openldap.org >> Sent: Wed, April 11, 2007 7:06:57 PM >> Subject: Re: (ITS#4868) Binary Attribute Patch(es) >> >> ando(a)sys-net.it wrote: >> >>> Right. Time permitting, I'll check why back-sql behaves differently >>> and, in case, how to fix it. >> >> HEAD should be working as expected, now. I've also updated mysql and >> psql sql-test000 (the latter is untested, though). >> >> Please test and report. p. >> >> >> >> Ing. Pierangelo Masarati >> OpenLDAP Core Team >> >> SysNet s.r.l. >> via Dossi, 8 - 27100 Pavia - ITALIA >> http://www.sys-net.it >> --------------------------------------- >> Office: +39 02 23998309 >> Mobile: +39 333 4963172 >> Email: pierangelo.masarati(a)sys-net.it >> --------------------------------------- -- -- 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#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 30 Dec '09

30 Dec '09

(I realize this is ridiculously late, but... well, better late than never, and this is the first I've gotten back to it.) Yes! It's working now in 2.4.x as expected, via the new userCertificate stub data provided by example. FWIW, it appears to be working fine with the PostgreSQL example files as well. Unfortunately, it was never "back" ported to 2.3. We're currently using 2.3.43 as part of RHEL-5. Any chance it could get back-ported into the 2.3 branch? Thanks, Kevin ----- Original Message ---- > From: Pierangelo Masarati <ando(a)sys-net.it> > To: vargok(a)yahoo.com > Cc: openldap-its(a)openldap.org > Sent: Wed, April 11, 2007 7:06:57 PM > Subject: Re: (ITS#4868) Binary Attribute Patch(es) > > ando(a)sys-net.it wrote: > > > Right. Time permitting, I'll check why back-sql behaves differently > > and, in case, how to fix it. > > HEAD should be working as expected, now. I've also updated mysql and > psql sql-test000 (the latter is untested, though). > > Please test and report. p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > ---------------------------------------

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 30 Dec '09

30 Dec '09

On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >I just enabled trace loglevel, perhaps that might give us a clue on what's going on. Slapd just stopped working again. Here's the (annotated) log for viewing and/or downloading: http://www.pastie.org/761198.txt Does this give you any clues? Tell me if I can do anything else to help. -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 30 Dec '09

30 Dec '09

On Tue, Dec 29, 2009 at 11:00:25AM -0800, Howard Chu wrote: >Sorry, your issue was closed since we hadn't received any feedback >from you in a couple of months. > >The last trace you sent shows nothing unusual, just a bunch of >threads all waiting to write on their respective connections. If the core dump backtrace wasn't helpful, then please tell me so; I thought I had given you sufficient feedback, and that you were working on it. >Have you tried the .21 release yet? No.. I might do that next week. Is there anything else that I can do? I just enabled trace loglevel, perhaps that might give us a clue on what's going on. >-- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Helge Milde, 69701808 www.monsternett.no

1 0

(ITS#6247)
by daniel＠pluta.biz 29 Dec '09

29 Dec '09

Hi, I did just some small cleanups, but added no new functionality. I've extracted the minimalistic slapd-api modifications in an extra file called "now_slapd.patch" also contained in the tgz. The code compiles and runs against todays version of "HEAD". The new tgz-file can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091229-1.tgz Cheers Daniel

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by hyc＠symas.com 29 Dec '09

29 Dec '09

helge(a)monsternett.no wrote: > Would be nice to get some feedback on this one.. > Were using a core dump sufficient? If so, was the information helpful at all? > If there's anything more I could do, please say so. > Sorry, your issue was closed since we hadn't received any feedback from you in a couple of months. The last trace you sent shows nothing unusual, just a bunch of threads all waiting to write on their respective connections. Have you tried the .21 release yet? -- -- 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#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 29 Dec '09

29 Dec '09

Would be nice to get some feedback on this one.. Were using a core dump sufficient? If so, was the information helpful at all? If there's anything more I could do, please say so. -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by hyc＠symas.com 22 Dec '09

22 Dec '09

rmeggins(a)redhat.com wrote: > The ldif code does not currently have knowledge of any of the higher > level LDAP data types such as LDAPMod or LDAPControl - some of the > proposals would have the ldif API return these objects - Do we really > want to introduce this higher level knowledge into the relatively low > level libldif, along with the dependency on libldap? I think in order > to do this properly, we would have to introduce a new LDAP API e.g. > ldap_mods_from_ldif(const char *ldifstr, LDAPMod***, LDAPControl***) or > something like that - something that would parse the given ldif record > into those higher level data types. Should have mentioned this sooner; this ITS needs to be merged with ITS#4033. -- -- 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: Re : Re : ITS#6434
by masarati＠aero.polimi.it 22 Dec '09

22 Dec '09

KISTER RAPHAEL wrote: > I re-test with servers/slapd/overlays/rwm.c in version 1.125 and it works fine. I don't test with the next version. Fine. The other modifications are not strictly related to your issue, but rather to modifications to olcRwmMap using back-config. p.

1 0

Re : Re : ITS#6434
by kraph＠yahoo.com 22 Dec '09

22 Dec '09

Hello,=0A=0AI re-test with servers/slapd/overlays/rwm.c in version 1.125 an= d it works fine. I don't test with the next=A0version.=0A=0ARaphael KISTER= =0A=0A=0A

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 22 Dec '09

22 Dec '09

Kurt Zeilenga wrote: > On Dec 21, 2009, at 12:35 PM, Michael Ströder wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> Yes, it has long been our practice not to publish schema elements which = >>> are not yet well standardized. This would include any element which = >>> carries a OpenLDAP.666 OID. >>> >>> The idea being that use of such attributes should be limited to early = >>> adopters and such. >> Sorry, but this practice is inconsequent. > > That's your opinion. My opinion is that we should avoid publishing > ''works in progress'' in production systems. Works in progress, by their > very nature, are subject to change without notice. If you'd really like to avoid issues with attributes being falsely handled by the client because the semantics changed you would especially also have to change the attribute type's NAME. Because that's what regular naive LDAP clients look for. A fully schema-aware client like web2ldap discovers OID changes and handles things correctly. E.g. in web2ldap plugins are preferrably registered by OID (besides some exceptions in case of missing schema descriptions). If the semantics changes and you assign a new OID web2ldap would not naively just treat it the same way. One has to explicitly register a plugin class for the new OID, off course after checking that semantics are the same then. Opposite to that if e.g. the semantics of entryCSN changes and you assign a new OID of a hidden schema description there's no chance to discover that. That's simply bad and therefore I won't follow your arguments at all. BTW: OpenLDAP also prefers NAME handling over OIDs. So with an OpenLDAP deployment changing the OID of a schema descriptions has no effect. But changing the NAME does. That's what I think is inconsequent: The current practice does not avoid issues. It only makes things worse. Ciao, Michael.

1 0

Re: (ITS#6435) Hidden schema elements
by Kurt＠OpenLDAP.org 21 Dec '09

21 Dec '09

On Dec 21, 2009, at 12:35 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> Yes, it has long been our practice not to publish schema elements = which =3D >> are not yet well standardized. This would include any element which = =3D >> carries a OpenLDAP.666 OID. >>=20 >> The idea being that use of such attributes should be limited to early = =3D >> adopters and such. >=20 > Sorry, but this practice is inconsequent. That's your opinion. My opinion is that we should avoid publishing = ''works in progress'' in production systems. Works in progress, by = their very nature, are subject to change without notice. > The attributes are returned in LDAP > responses Generally because the client asked for more than it should have. = Clients really shouldn't generally be asking for * and/or +. The two exceptions are clients which are servers attempting to = server-to-server replication and clients operated by directory = administrators. Clients which are intended to support various user applications really = should ask only for what they designed to consume. > and therefore a client should be able to look up the attribute type > description in the schema e.g. to determine the syntax. I disagree. Schema may not be made available to the client for any = number of reasons. The X.500 and LDAP specifications allow for this. >=20 > Some of the OIDs are now with .666 for years. Each time this topic is = raised > nothing happens... That's because (in general) the ''works in progress'' have not be = finalized. If something hasn't changed in years, then maybe it's time = to finalize it and, in doing so, assign it final OID. -- Kurt=

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 21 Dec '09

21 Dec '09

Kurt(a)OpenLDAP.org wrote: > Yes, it has long been our practice not to publish schema elements which = > are not yet well standardized. This would include any element which = > carries a OpenLDAP.666 OID. > > The idea being that use of such attributes should be limited to early = > adopters and such. Sorry, but this practice is inconsequent. The attributes are returned in LDAP responses and therefore a client should be able to look up the attribute type description in the schema e.g. to determine the syntax. Some of the OIDs are now with .666 for years. Each time this topic is raised nothing happens... Ciao, Michael.

1 0

Re: (ITS#6436) olcRwmMap atomic modification
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

masarati(a)aero.polimi.it wrote: > olcRwmMap modification via back-config is not atomic; direct insert/delete not > allowed. A patch that implements support for this is proposed. p. The patch makes modification of this attribute consistent (all changes succeeed, or none); if modifications to olcRwmMap are followed by modifications to other attrs within the same write operation, the whole operation is not atomic. This less than ideal behavior is common to many operations allowed by back-config, though. Please test. p.

1 0

(ITS#6436) olcRwmMap atomic modification
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '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 olcRwmMap modification via back-config is not atomic; direct insert/delete not allowed. A patch that implements support for this is proposed. p.

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 21 Dec '09

21 Dec '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL: > Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) > Submitted by: rein > > Some of the operational attributes defined in the slapd source are hidden from > the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of > these elements are used in the database (as in the authz* and monitor related > attributes). Yes, see also: http://www.openldap.org/its/index.cgi?findid=5573 http://www.openldap.org/its/index.cgi?findid=5574 http://www.openldap.org/its/index.cgi?findid=5576 IIRC also a bunch of attribute types used in back-config which makes back-config almost unusable with a stock schema aware client. The standard answer by Kurt and others is that as along as an experimental OID with .666 is used a schema description should be hidden. I strongly disagree with that though. > This causes my schema-aware application to complain when it sees > (or worse tries to modify) these attributes. (Sigh!) I also had to add several work-arounds to web2ldap regarding this. > A patch that adds a new optional define that can be used to disable the schema > hiding without enabling LDAP_DEVEL is coming. Looking forward to this being committed. > A better fix would be to not hide those schema elements that is actually > being used.. Amen. Ciao, Michael.

1 0

Re: (ITS#6435) Hidden schema elements
by Kurt＠OpenLDAP.org 21 Dec '09

21 Dec '09

On Dec 21, 2009, at 8:09 AM, rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL:=20 > Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) > Submitted by: rein >=20 >=20 > Some of the operational attributes defined in the slapd source are = hidden from > the clients unless slapd is compiled with LDAP_DEVEL enabled. Yes, it has long been our practice not to publish schema elements which = are not yet well standardized. This would include any element which = carries a OpenLDAP.666 OID. The idea being that use of such attributes should be limited to early = adopters and such. > Still, some of > these elements are used in the database (as in the authz* and monitor = related > attributes). This causes my schema-aware application to complain when = it sees > (or worse tries to modify) these attributes. >=20 > A patch that adds a new optional define that can be used to disable = the schema > hiding without enabling LDAP_DEVEL is coming. A better fix would be = to not hide > those schema elements that is actually being used.. It may be that the particular schema elements simply shouldn't be behind = LDAP_DEVEL any longer, possibly because a permanent OID has yet to be = assigned to now production code. >=20 > Rein >=20

1 0

Re: Re : ITS#6434
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

KISTER RAPHAEL wrote: > Hello, > > I make a test with servers/slapd/overlays/rwm.c version 1.124. It works fine. Thank you very much for your help. I've re-fixed the problem in a different way; please re-test. Thanks, p.

1 0

Re: (ITS#6435) Hidden schema elements
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

rein(a)OpenLDAP.org wrote: > A better fix would be to not hide > those schema elements that is actually being used.. As far as I can tell, OpenLDAP's policy with respect to hiding schema definitions consists in un-hiding only those that are documented in standards track documents, or are for internal use and thus documented internally (e.g. back-config related). So the "right" fix would be to work at formalizing and submitting documents to stardards track. p.

1 0

(ITS#6435) Hidden schema elements
by rein＠OpenLDAP.org 21 Dec '09

21 Dec '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein Some of the operational attributes defined in the slapd source are hidden from the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of these elements are used in the database (as in the authz* and monitor related attributes). This causes my schema-aware application to complain when it sees (or worse tries to modify) these attributes. A patch that adds a new optional define that can be used to disable the schema hiding without enabling LDAP_DEVEL is coming. A better fix would be to not hide those schema elements that is actually being used.. Rein

1 0

Re : ITS#6434
by kraph＠yahoo.com 21 Dec '09

21 Dec '09

Hello,=0A=0AI=A0make a test=A0with servers/slapd/overlays/rwm.c=A0version= =A0=A01.124. It works fine. Thank you very much for your help.=0A=0ABest re= gards,=0A=A0Raphael KISTER=0A=0A=0A=0A----- Message d'origine ----=0ADe : P= ierangelo Masarati <masarati(a)aero.polimi.it>=0A=C0 : KISTER RAPHAEL <kraph@= yahoo.com>; openldap-its(a)openldap.org=0AEnvoy=E9 le : Lun 21 D=E9cembre 200= 9, 13 h 08 min 31 s=0AObjet=A0: ITS#6434=0A=0AThe problem has been fixed in= HEAD (servers/slapd/overlays/rwm.c 1.122 -> 1.223); please test and report= .=A0 Thanks, p.=0A=0A=0A=0A

1 0

ITS#6434
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

The problem has been fixed in HEAD (servers/slapd/overlays/rwm.c 1.122 -> 1.223); please test and report. Thanks, p.

1 0

(ITS#6434) Problem with rewrite overlay
by kraph＠yahoo.com 21 Dec '09

21 Dec '09

Full_Name: Raphaël KISTER Version: 2.4.20 OS: Linux CentOS 5.4 URL: http://www.raphael-kister.fr/openldap_its Submission from: (NULL) (88.184.63.204) I would like to use OpenLDAP as an Active Directory Proxy. I configure ldap backend and i rewrite some attributes and objectclass. When i test my configuration file, i get this error : config error processing olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config: <olcRwmMap> handler exited with 1 slaptest: bad configuration directory! This is an extract of my config file : database ldap suffix dc=CNC,dc=LOCAL rootdn "cn=admin,cn=config" uri ldap://192.168.44.88:389 lastmod off acl-authcDN cn=admin,cn=config acl-passwd secret idassert-bind bindmethod="simple" binddn="CN=srv_ldap,OU=Services-account,OU=Administration,dc=CNC,dc=LOCAL" credentials="Azerty00" mode="legacy" overlay rwm #rwm-suffixmassage dc=CNC,dc=LOCAL rwm-map objectclass inetOrgPerson user rwm-map attribute uid sAMAccountName rwm-map attribute cn cn rwm-map attribute displayName displayName rwm-map attribute givenName givenName rwm-map attribute sn sn rwm-map attribute mail mail rwm-map attribute userPassword userPassword rwm-map attribute *

1 0

(ITS#6433) patch for the sha2 module: hash methods for passwords generation
by cdelfosse＠mandriva.com 21 Dec '09

21 Dec '09

Full_Name: Cédric Delfosse Version: HEAD OS: Mandriva Linux URL: ftp://ftp.openldap.org/incoming/cedric-delfosse-091221.patch Submission from: (NULL) (62.212.120.90) Hello, this patch allows to use the {SHA256}, {SHA384} and {SHA512} password schemes (provided by the sha2 module) with LDAP Password Modify Extended Operations. This patch contains the required hash methods. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Mandriva. Mandriva has not assigned rights and/or interest in this work to any party. I, Cédric Delfosse am authorized by Mandriva, my employer, to release this work under the following terms. Mandriva hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Regards, Cédric

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 18 Dec '09

18 Dec '09

rmeggins(a)redhat.com wrote: > You are right, Howard. It works as you described. I'm not sure what > happened in my testing. Mea culpa. > > This is a new patch with the SetURL changes backed out. > > ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200… OK. Another question - you're only using NSS_InitContext() for client initialization. Any particular reason not to always use it? Also in tlsm_ctx_free() is it safe to pass a NULL to NSS_ShutdownContext()? I think these two lines should be enclosed in "if (c->tc_initctx) {}" -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

You are right, Howard. It works as you described. I'm not sure what happened in my testing. Mea culpa. This is a new patch with the SetURL changes backed out. ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200…

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 18 Dec '09

18 Dec '09

rmeggins(a)redhat.com wrote: >>> I also had to call >>> SSL_SetURL in order to put the correct hostname in the SSL socket for cert >>> validation. >> >> I explicitly withheld the hostname to force our own cert validation function >> to be used. The NSS hostname validator's behavior is inconsistent with the >> LDAP spec. >> > That's the tlsm_session_chkhost() function? The problem is that the > chkhost function is called too late - NSS attempts to perform the > verification during the handshake process - by the time > ldap_pvt_tls_check_hostname() is called in ldap_int_tls_start(), it's > too late - NSS has failed - ldap_int_tls_connect() has returned an error. That should not happen, since tlsm_bad_cert_handler() causes the bad hostname result to be returned as Success. That gives us the chance to check it on our own. It worked in my tests before... -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

This is a new patch, which #defines HAVE_NSS_INITCONTEXT based on the NSS version. ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200…

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

> > Thanks for the patch. > > Just blindly #defining HAVE_NSS_INITCONTEXT is no good. Isn't there an NSS > version symbol we can check in the preprocessor, to make sure it's 3.12.5 or > newer? Otherwise we'll need an autoconf test for the existence of the > NSS_InitCOntext() function. > Ok. I'll change it to check for NSS version >= 3.12.5 > > This allows apps and libraries to initialize NSS from different contexts. > I've > > also cleaned up some of the code around PEM file support. I also had to > call > > SSL_SetURL in order to put the correct hostname in the SSL socket for cert > > validation. > > I explicitly withheld the hostname to force our own cert validation function > to be used. The NSS hostname validator's behavior is inconsistent with the > LDAP spec. > That's the tlsm_session_chkhost() function? The problem is that the chkhost function is called too late - NSS attempts to perform the verification during the handshake process - by the time ldap_pvt_tls_check_hostname() is called in ldap_int_tls_start(), it's too late - NSS has failed - ldap_int_tls_connect() has returned an error.

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 18 Dec '09

18 Dec '09

rmeggins(a)redhat.com wrote: > Full_Name: Richard Megginson > Version: 2.4.20 > OS: Fedora 11 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200… > Submission from: (NULL) (76.113.111.209) > > > This patch adds support for the new NSS_InitContext() API (new in NSS 3.12.5). Thanks for the patch. Just blindly #defining HAVE_NSS_INITCONTEXT is no good. Isn't there an NSS version symbol we can check in the preprocessor, to make sure it's 3.12.5 or newer? Otherwise we'll need an autoconf test for the existence of the NSS_InitCOntext() function. > This allows apps and libraries to initialize NSS from different contexts. I've > also cleaned up some of the code around PEM file support. I also had to call > SSL_SetURL in order to put the correct hostname in the SSL socket for cert > validation. I explicitly withheld the hostname to force our own cert validation function to be used. The NSS hostname validator's behavior is inconsistent with the LDAP spec. -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

Full_Name: Richard Megginson Version: 2.4.20 OS: Fedora 11 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200… Submission from: (NULL) (76.113.111.209) This patch adds support for the new NSS_InitContext() API (new in NSS 3.12.5). This allows apps and libraries to initialize NSS from different contexts. I've also cleaned up some of the code around PEM file support. I also had to call SSL_SetURL in order to put the correct hostname in the SSL socket for cert validation. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not assigned rights and/or interest in this work to any party. I, Richard Megginson am authorized by Red Hat, Inc., my employer, to release this work under the following terms. Red Hat, Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by masarati＠aero.polimi.it 17 Dec '09

17 Dec '09

> Forgot to enclose the URL. > > http://folk.uio.no/hbf/OpenLDAP/slapreply-draft2.diff At a first glance, your patch makes sense. I see your concern, this approach is definitely fragile. However, I see two points: - the code is not just modified by everyone, so we can count on paying relative attention to what is done, as soon as there are clear guidelines - we should probably produce some indications about how code needs to be used. I'm not thinking about a comprehensive programming guide, but some clear guidelines about writing safe code in critical areas like this would be of help. In cases like this, I'd really prefer to be able to exploit OOP and data abstraction as in C++. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by hyc＠symas.com 16 Dec '09

16 Dec '09

rmeggins(a)redhat.com wrote: > I think this could be accomplished in one of two ways: > 1) Just have libldif return lists of struct berval* for the various data > parsed. The caller would be responsible for turning these into LDAPMod > or LDAPControl structures - the advantage is that libldif doesn't have > to know about any of these higher level structures > 2) Have libldif create LDAPMod and LDAPControl - I think this could be > accomplished by having ldif.c #include<ldap.h> to pull in the > definitions of LDAPMod and LDAPControl - would this be ok? Let's move this discussion to the openldap-devel mailing list. I'm thinking (2) is OK but I'd like to hear from other developers / potential users of this library. -- -- 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#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 16 Dec '09

16 Dec '09

I think this could be accomplished in one of two ways: 1) Just have libldif return lists of struct berval* for the various data parsed. The caller would be responsible for turning these into LDAPMod or LDAPControl structures - the advantage is that libldif doesn't have to know about any of these higher level structures 2) Have libldif create LDAPMod and LDAPControl - I think this could be accomplished by having ldif.c #include <ldap.h> to pull in the definitions of LDAPMod and LDAPControl - would this be ok?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs