- openldap-bugs - openldap.org

(ITS#5162) Bus Error - core dumped
by piotr.tarnowski＠us.edu.pl 02 Oct '07

02 Oct '07

Full_Name: Piotr Tarnowski (DrFugazi) Version: 2.3.38 OS: Solaris 10 U4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.158.96.61) Hello, I compiled the newest version of OpenLDAP (2.3.38) on Solaris 10 U4 (8/07) system. I tried many times with many compilation options, but I still have an error with 'gmake test': >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Waiting 5 seconds for slapd to start... 4378 Bus Error - core dumped Waiting 5 seconds for slapd to start... ------------ In tests/testrun/slapd.1.log I found: daemon: select: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read activity on 12 connection_get(12) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x001cbef0 ptr=0x001cbef0 end=0x001cbefc len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ ber_get_next ldap_read: want=8 error=Resource temporarily unavailable daemon: select: listen=8 active_threads=0 tvp=NULL do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x001cbef0 ptr=0x001cbef3 end=0x001cbefc len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0x001cbef0 ptr=0x001cbefa end=0x001cbefc len=2 0000: 00 00 .. >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 conn=0 op=0 BIND dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=0 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read activity on 12 connection_get(12) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 36 02 01 02 63 31 04 06...c1. ldap_read: want=48, got=48 0000: 11 64 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d 63 .dc=example,dc=c 0010: 6f 6d 0a 01 02 0a 01 00 02 01 00 02 01 00 01 01 om.............. 0020: 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ...objectclass0. ber_get_next: tag 0x30 len 54 contents: ber_dump: buf=0x001acdd8 ptr=0x001acdd8 end=0x001ace0e len=54 0000: 02 01 02 63 31 04 11 64 63 3d 65 78 61 6d 70 6c ...c1..dc=exampl 0010: 65 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 e,dc=com........ 0020: 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 .........objectc 0030: 6c 61 73 73 30 00 lass0. ber_get_next do_search ldap_read: want=8 error=Resource temporarily unavailable ber_scanf fmt ({miiiib) ber: ber_dump: buf=0x001acdd8 ptr=0x001acddb end=0x001ace0e len=51 0000: 63 31 04 11 64 63 3d 65 78 61 6d 70 6c 65 2c 64 c1..dc=example,d 0010: 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 01 c=com........... 0020: 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 ......objectclas 0030: 73 30 00 s0. daemon: select: listen=8 active_threads=0 tvp=NULL >>> dnPrettyNormal: <dc=example,dc=com> => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> SRCH "dc=example,dc=com" 2 0 0 0 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=0x001acdd8 ptr=0x001acdff end=0x001ace0e len=15 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. end get_filter 0 filter: (objectClass=*) ber_scanf fmt ({M}}) ber: ber_dump: buf=0x001acdd8 ptr=0x001ace0c end=0x001ace0e len=2 ----------- Output from truss: (...) 26487/3: write(2, " b d b _ d n 2 e n t r y".., 34) = 34 26487/3: write(2, " = > b d b _ d n 2 i d".., 34) = 34 26487/3: write(2, " < = b d b _ d n 2 i d".., 32) = 32 26487/3: Incurred fault #5, FLTACCESS %pc = 0x7E72B4D0 26487/3: siginfo: SIGBUS BUS_ADRALN addr=0x00000032 26487/3: Received signal #10, SIGBUS [default] 26487/3: siginfo: SIGBUS BUS_ADRALN addr=0x00000032 26392: waitid(P_PID, 26517, 0xFFBFF5C0, WEXITED|WTRAPPED|WNOWAIT) (sleeping...) (...) ------------- Is this a software error, or compiler/system issue ? I use Sun Studio 12 on sparc. Machine hardware: sun4u OS version: 5.10 Processor type: sparc Hardware: SUNW,Sun-Fire-V890 The following components are installed on your system: Sun Studio 12 Sun Studio 12 C Compiler Sun Studio 12 C++ Compiler Sun Studio 12 Tools.h++ 7.1 Sun Studio 12 C++ Standard 64-bit Class Library Sun Studio 12 Garbage Collector Sun Studio 12 Fortran 95 Sun Studio 12 Debugging Tools (including dbx) Sun Studio 12 IDE Sun Studio 12 Debugger GUI Sun Studio 12 Performance Analyzer (including collect, ...) Sun Studio 12 X-Designer Sun Studio 12 VIM editor Sun Studio 12 XEmacs editor Sun Studio 12 Performance Library Sun Studio 12 LockLint Sun Studio 12 Building Software (including dmake) Sun Studio 12 Documentation Set Sun Studio 12 /usr symbolic links and GNOME menu item version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_sparc Patch 127000-01 2007/07/18 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_sparc Patch 124872-02 2007/08/16 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19 Regards -- Piotr (DrFugazi) Tarnowski

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 02 Oct '07

02 Oct '07

--On Tuesday, October 02, 2007 2:35 AM +0000 hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: >> >>> The following files will be uploaded to the ftp site, where # will be >>> the assigned ITS number. >> >> URL's specifically are: >> >> <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> >> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> >> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> > > The pstack output is a bit odd, is this a regular debug build? With frame > pointers, etc? Can you get a stack trace in gdb? It is a regular build, and they killed and restarted it before getting any gdb information. We've asked them to please get the gdb information in the future. Since it has happened twice now for thi particular group in about a month, I'm hopeful it'll happen again before too long. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by hyc＠symas.com 02 Oct '07

02 Oct '07

quanah(a)zimbra.com wrote: > --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: > >> The following files will be uploaded to the ftp site, where # will be the >> assigned ITS number. > > URL's specifically are: > > <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> > <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> > <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> The pstack output is a bit odd, is this a regular debug build? With frame pointers, etc? Can you get a stack trace in gdb? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 02 Oct '07

02 Oct '07

--On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: > The following files will be uploaded to the ftp site, where # will be the > assigned ITS number. URL's specifically are: <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 02 Oct '07

02 Oct '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.104.138.6) Several customers have found delta-syncrepl will lock up after a time. Today it occurred again, and this time some logging data was able to be gathered. The last operation logged was a MOD op. This matches past lockups, which were also either MOD or ADD operations. The following files will be uploaded to the ftp site, where # will be the assigned ITS number. #-dbstat.delta.out.2007-10-01 which is the db_stat information for the accesslog DB #-db_stat.out.2007-10-01 which is the db_stat information for the main DB #-pstak.out.2007-10-01 which is the pstack information for the slapd process Unfortunately no GDB info was retrieved this time, and reportedly gcore hung. The most interesting part is I see no WRITE locks held in either DB, and all the client threads are hung in a mutex.

1 0

Re: (ITS#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by hyc＠symas.com 01 Oct '07

01 Oct '07

jclarke(a)linagora.com wrote: > I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and > behaviour is quite different, though the end result is the same. Due to multiple limitations, this is not expected to work in 2.3 at all. > On HEAD, things are quite different: > request done: ld 0x82c2228 msgid 2 > do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT > nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn > dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn > uid=root,dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn > uid=replicator,dc=ossa,dc=linagora,dc=org > adresse de be_modify : 80c8840 > null_callback : error code 0x32 > syncrepl_updateCookie: rid=7 be_modify failed (50) This is Insufficient Access. You have not configured the glue databases with identical rootDN's, which is clearly documented as a requirement for glued databases. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by jclarke＠linagora.com 01 Oct '07

01 Oct '07

Full_Name: Jonathan Clarke Version: 2.3.38 and HEAD (but with slightly different results) OS: Linux URL: ftp://ftp.openldap.org/incoming/unwanted-deletes-syncrepl-glue.tar.gz Submission from: (NULL) (213.41.243.192) Hi folks, I've come across an issue with a server using the glue overlay with one of it's subordinate databases syncrepl'd. There are two problems: 1) updating the root database's contextCSN 2) when replicating this whole server with syncrepl (to a 3rd server), certain updates cause many entries to be deleted from the consumer. The following "schema" should describe this setup more clearly (names TOP, MIDDLE and BOTTOM are for easy reference): TOP: |----------------------------| | One bdb backend: | | dc=ossa,dc=linagora,dc=org | |----------------------------| | MIDDLE: | |-------------------------------| | Two bdb backends + glue: | | 1) dc=ossa,dc=linagora,dc=org | | subordinate | | syncrepl from above server | | 2) dc=linagora,dc=org | | 'master' for this branch | | | | syncprov overlay | |-------------------------------| | BOTTOM: | |-------------------------------| | One bdb backend: | | dc=linagora,dc=org | | syncrepl from above server | |-------------------------------| All config files, and some sample data sets, are in the archive at the URL above. I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and behaviour is quite different, though the end result is the same. On 2.3.38: 1) Set up all three servers, make sure they're sync'ed. 2) Modify some attribute on the TOP server (I add a description to the root DN, dc=ossa,dc=linagora,dc=org) 3) Watch this modification propagate to the middle server. the contextCSN in dc=linagora,dc=org is not updated, but the one in dc=ossa,dc=linagora,dc=org is (equals to the entryCSN of the entry I modified). The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- request done: ld 0x822ec20 msgid 1 do_syncrep2: rid 007 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_entry: rid 007 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 007 be_search (0) syncrepl_entry: rid 007 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid 007 be_modify (0) request done: ld 0x822ec20 msgid 2 do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT 8>--------------------------------------------------------------- 4) Watch the BOTTOM server (see schema above) do it's syncrepl and delete some entries below the glued database (glued on MIDDLE server, not on this one). The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- request done: ld 0x822a320 msgid 1 request done: ld 0x822a320 msgid 2 do_syncrep2: rid 888 LDAP_RES_SEARCH_RESULT request done: ld 0x822a320 msgid 1 do_syncrep2: rid 888 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_entry: rid 888 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 888 be_search (0) syncrepl_entry: rid 888 dc=linagora,dc=org syncrepl_entry: rid 888 be_modify (0) syncrepl_entry: rid 888 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 888 be_search (0) syncrepl_entry: rid 888 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid 888 be_modify (0) request done: ld 0x822a320 msgid 2 do_syncrep2: rid 888 LDAP_RES_SEARCH_RESULT syncrepl_del_nonpresent: rid 888 be_delete uid=replicator,dc=ossa,dc=linagora,dc=org (0) syncrepl_del_nonpresent: rid 888 be_delete uid=root,dc=ossa,dc=linagora,dc=org (0) 8>--------------------------------------------------------------- On HEAD, things are quite different: 1) Start the TOP server. 2) Start the MIDDLE server. Errors happen immediatly, on first sync attempt. The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- slapd starting request done: ld 0x82c2228 msgid 1 syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5797e8c-0486-102c-83e0-79137da6179f syncrepl_entry: rid=7 be_search (32) syncrepl_entry: rid=7 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a2f834-0486-102c-83e1-79137da6179f syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=root,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a31526-0486-102c-83e2-79137da6179f syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=replicator,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) request done: ld 0x82c2228 msgid 2 do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn dc=ossa,dc=linagora,dc=org nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn uid=root,dc=ossa,dc=linagora,dc=org nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn uid=replicator,dc=ossa,dc=linagora,dc=org adresse de be_modify : 80c8840 null_callback : error code 0x32 syncrepl_updateCookie: rid=7 be_modify failed (50) request done: ld 0x82c2228 msgid 1 syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5797e8c-0486-102c-83e0-79137da6179f dn_callback : entries have identical CSN dc=ossa,dc=linagora,dc=org ours 20071001162546.703481Z#000000#000#000000, new 20071001162546.703481Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (dc=ossa,dc=linagora,dc=org) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a2f834-0486-102c-83e1-79137da6179f dn_callback : entries have identical CSN uid=root,dc=ossa,dc=linagora,dc=org ours 20071001162546.975377Z#000000#000#000000, new 20071001162546.975377Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=root,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (uid=root,dc=ossa,dc=linagora,dc=org) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a31526-0486-102c-83e2-79137da6179f dn_callback : entries have identical CSN uid=replicator,dc=ossa,dc=linagora,dc=org ours 20071001162546.976133Z#000000#000#000000, new 20071001162546.976133Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=replicator,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (uid=replicator,dc=ossa,dc=linagora,dc=org) 8>--------------------------------------------------------------- Obviously, the desired result is that entries are not deleted from the BOTTOM server when replication happens. I'm a bit at a loss as to the logic behind these updates, and how to go about correcting. I tried applying a patch backported from HEAD to 2.3.38 that makes syncrepl update the contextCSN in the real root (not the bdb database root). It works in that the contextCSN is updated correctly, but replication to BOTTOM still has unwanted deletes. The patch is in the archive attached (update-root-contextCSN.diff) and corresponds to revisions 1.308 and 1.309 in syncrepl.c CVS log. I am completely available to provide any more information necessary: logs, testing, gdb output, etc. Any help or pointers most welcome! Thanks in advance, Jon

1 0

Re: (ITS#4467) snprintf is consistenly used wrongly
by ando＠sys-net.it 29 Sep '07

29 Sep '07

h.b.furuseth(a)usit.uio.no wrote: > OpenLDAP is full of code like > ptr += snprintf( ptr, ... ); > and > bv.bv_len = snprintf( ... ); > <use bv>; Let me add that there seem to be occasional improper uses of sprintf() too (usually in marginal code, fortunately). 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#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 29 Sep '07

29 Sep '07

hyc(a)symas.com wrote: > Howard Chu wrote: >> I just got tripped trying to import an LDIF with a cert with 16 byte >> SerialNumber. I've patched this to just use the same hexadecimal format that >> OpenSSL uses when the number is larger than ber_int_t. We really don't want >> the format to change just because someone has a BigNum library available; it >> needs to stay consistent. > > But we still need to fix serialNumberAndIssuerNormalize() to normalize to Hex now. > And in case somebody feeds in a very large decimal integer, we still need a > multi-word decimal-to-binary converter. As such, this bug cannot be closed yet. OK. Does it make any sense to just move to a hex-only syntax, perfixed by "0x", with no sign as you mentioned earlier, or should we preserve compatibility with the original form, where the minus sign is allowed while a number not starting with "0x" should be treated as decimal? The latter would be probably better, but we'd need to convert decimal to hex, and this could fail if decimals are too large. 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#5070) Issues in X.509 certificate parsing
by hyc＠symas.com 29 Sep '07

29 Sep '07

Howard Chu wrote: > I just got tripped trying to import an LDIF with a cert with 16 byte > SerialNumber. I've patched this to just use the same hexadecimal format that > OpenSSL uses when the number is larger than ber_int_t. We really don't want > the format to change just because someone has a BigNum library available; it > needs to stay consistent. But we still need to fix serialNumberAndIssuerNormalize() to normalize to Hex now. And in case somebody feeds in a very large decimal integer, we still need a multi-word decimal-to-binary converter. As such, this bug cannot be closed yet. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5146) slapo-ppolicy
by ando＠sys-net.it 29 Sep '07

29 Sep '07

hyc(a)symas.com wrote: > Of course now that userPassword and authPassword already exist, all the good > attribute names are already gone. ;) "password"? 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

(ITS#5159) make slap_passwd_parse() non-destructive
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc In RE23 the slap_passwd_parse() function parses the exop data destructively, so it cannot be successfully parsed again by any other function that needs to. In HEAD there is a new LBER option to specify non-destructive parsing of strings, and slap_passwd_parse() has been changed to use this option.

1 0

(ITS#5158) contrib should use separate config OID arc
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc Currently we track config OID allocations in slapd/bconfig.c for both core modules and contrib modules. Since we really aren't maintaining the contrib modules, they should use a separate OID arc and the OIDs should be tracked elsewhere. This has been changed in HEAD, and contrib/ConfigOIDs now exists for tracking OIDs allocated to contrib modules.

1 0

(ITS#5157) dynlist shouldn't populate values unless requested
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc Since populating the member list in a dynamic group may be a very expensive operation, the dynlist overlay should not perform this work if the member attribute wasn't requested in the search parameters. Already fixed in HEAD.

1 0

(ITS#5156) missing slapd.d man page
by gerard.ranke＠kmt.hku.nl 27 Sep '07

27 Sep '07

Full_Name: Gerard Ranke Version: 2.3.35, 2.3.38 OS: IRIX 6.5.30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.87.216.230) Section 5.2 from the OpenLDAP Administrator's Guide mentions the slapd.d(5) man page. However, this seems to be missing from the distribution. Would it be possible to add it? Thanks for your time and effort. Best regards, Gerard Ranke

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 26 Sep '07

26 Sep '07

On Sonntag, 23. September 2007, ando(a)sys-net.it wrote: > Ralf Haferkamp wrote: > > Please note that test020 currently fails in HEAD sometime. I think this > > depends on the order in which the results for queries that hit the > > sizelimit are returned. > > I added tests for sizelimit that were consistent with my changes; > however, I'm now short of time to work on this, so feel free to back out > those test changes if you believe the code is working correctly, while > we design test improvements that are consistent with all fixes. I have rearranged the pcache test case a bit. It succeeds now on my test machine. -- Ralf

1 0

(ITS#5155) Leak in back-meta when binding as rootdn
by ando＠sys-net.it 26 Sep '07

26 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) back-meta leaks orb_edn after adding be_rootdn_bind() support (ITS#4962) p.

1 0

Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it 26 Sep '07

26 Sep '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> To reproduce: >> >> - set idlcache >> >> - search one entry, so that the idl gets cached >> >> - delete that entry, so that the idl gets cleared - but head/tail don't >> >> - search another entry so that it gets cached - head/tail are corrupted >> >> I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure >> about re23). > > Coverity shows this patch has introduced a NULL pointer dereference. > @@ -364,6 +381,9 @@ > ee = bdb->bi_idl_lru_tail; > for ( i = 0; i < 10; i++, ee = eprev ) { > eprev = ee->idl_lru_prev; > + if ( eprev == ee ) { > + eprev = NULL; > + } > if ( ee->idl_flags & CACHE_ENTRY_REFERENCED ) { > ee->idl_flags ^= CACHE_ENTRY_REFERENCED; > continue; > > What's the purpose of this change Make sure bi_idl_lru_tail gets set to NULL if purging the cache makes it empty. Perhaps it's an overshoot. > and should you be testing for a NULL > now in the for loop conditions? Yes, I realize I should test for ee != NULL in the for loop. 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#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com 26 Sep '07

26 Sep '07

> -----Original Message----- > From: Pierangelo Masarati [mailto:ando@sys-net.it] > Sent: Wednesday, September 26, 2007 2:54 PM > To: mhardin(a)symas.com > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5154) Sequential binds to back-meta cause assertion > failiure > > mhardin(a)symas.com wrote: > > Full_Name: Matthew Hardin > > Version: 2.3.38 > > OS: N/A > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (12.168.121.2) > > > > > > Multiple binds on the same connection where at least one bind ends up > being [...] > > /* FIXME: in some cases (e.g. unavailable) > > * do not assume it's not candidate; rather > > * mark this as an error to be eventually > > I think the "real" fix should be different: binds should always receive > a fresh connection from meta_back_getconn(), which shouldn't be put > into the cache at all. meta_back_bind() should cache them only in case > of success, otherwise they should be destroyed. This would allow to > remove the need to set a BINDING flag to guarantee connections used for > bind are not shared. I agree that would be a better fix. > In the meanwhile, the solution you propose should be just fine, as it > fills the hole occurring when a bind fails. > > I'll work at that ASAP. Thanks! -Matt Matthew Hardin Symas Corporation- The LDAP Guys http://www.symas.com

1 0

Re: (ITS#5121) IDL cache issue
by hyc＠symas.com 26 Sep '07

26 Sep '07

ando(a)sys-net.it wrote: > To reproduce: > > - set idlcache > > - search one entry, so that the idl gets cached > > - delete that entry, so that the idl gets cleared - but head/tail don't > > - search another entry so that it gets cached - head/tail are corrupted > > I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure > about re23). Coverity shows this patch has introduced a NULL pointer dereference. @@ -364,6 +381,9 @@ ee = bdb->bi_idl_lru_tail; for ( i = 0; i < 10; i++, ee = eprev ) { eprev = ee->idl_lru_prev; + if ( eprev == ee ) { + eprev = NULL; + } if ( ee->idl_flags & CACHE_ENTRY_REFERENCED ) { ee->idl_flags ^= CACHE_ENTRY_REFERENCED; continue; What's the purpose of this change, and should you be testing for a NULL now in the for loop conditions? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5154) Sequential binds to back-meta cause assertion failiure
by ando＠sys-net.it 26 Sep '07

26 Sep '07

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.3.38 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.168.121.2) > > > Multiple binds on the same connection where at least one bind ends up being > passed through to a target and where the credentials for that bind are incorrect > will cause back-meta to throw an assertion failure during a subsequent bind. In > this situation back-meta prints the message "slapd: bind.c:229: meta_back_bind: > Assertion `tmpmc == mc' failed". > > Analysis: > In bind.c there is no cleanup of the metaconn structure after a failed bind to a > target database. This is ordinarily not a problem, as most applications perform > an unbind immediately after a failed bind and so fail to trigger this bug. > However, applications such as pam_ldap will perform several binds to as many as > two different identities on the same connection, and the credentials for one of > those identities are routinely incorrect. This bug causes the metaconn structure > from the failed bind to be left in the mi_conninfo.lai_tree avl tree and then > found during the re-insertion of a metaconn structure from a subsequent bind > (approx between lines 209-258 in bind.c), causing the assertion failure and > killing slapd in the process. > > Note: This bug can be exploited as a DOS attack, as the behavior is relatively > easy to reproduce on an unpatched system with a short perl script. > > > Proposed Fix: > The simplest and best fix appears to be to mark the metaconn struct from the > failed bind as tainted. This causes the struct to be deleted in the call to > meta_back_release_conn around line 281. > > The patch is as follows: > > bind.c > *************** > *** 189,194 **** > --- 189,198 ---- > > if ( lerr != LDAP_SUCCESS ) { > rc = rs->sr_err = lerr; > + /* Mark the meta_conn struct as tainted so > + * it'll be freed by meta_conn_back_destroy below */ > + LDAP_BACK_CONN_TAINTED_SET( mc ); > + > /* FIXME: in some cases (e.g. unavailable) > * do not assume it's not candidate; rather > * mark this as an error to be eventually I think the "real" fix should be different: binds should always receive a fresh connection from meta_back_getconn(), which shouldn't be put into the cache at all. meta_back_bind() should cache them only in case of success, otherwise they should be destroyed. This would allow to remove the need to set a BINDING flag to guarantee connections used for bind are not shared. In the meanwhile, the solution you propose should be just fine, as it fills the hole occurring when a bind fails. I'll work at that ASAP. 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

(ITS#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com 26 Sep '07

26 Sep '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.168.121.2) Multiple binds on the same connection where at least one bind ends up being passed through to a target and where the credentials for that bind are incorrect will cause back-meta to throw an assertion failure during a subsequent bind. In this situation back-meta prints the message "slapd: bind.c:229: meta_back_bind: Assertion `tmpmc == mc' failed". Analysis: In bind.c there is no cleanup of the metaconn structure after a failed bind to a target database. This is ordinarily not a problem, as most applications perform an unbind immediately after a failed bind and so fail to trigger this bug. However, applications such as pam_ldap will perform several binds to as many as two different identities on the same connection, and the credentials for one of those identities are routinely incorrect. This bug causes the metaconn structure from the failed bind to be left in the mi_conninfo.lai_tree avl tree and then found during the re-insertion of a metaconn structure from a subsequent bind (approx between lines 209-258 in bind.c), causing the assertion failure and killing slapd in the process. Note: This bug can be exploited as a DOS attack, as the behavior is relatively easy to reproduce on an unpatched system with a short perl script. Proposed Fix: The simplest and best fix appears to be to mark the metaconn struct from the failed bind as tainted. This causes the struct to be deleted in the call to meta_back_release_conn around line 281. The patch is as follows: bind.c *************** *** 189,194 **** --- 189,198 ---- if ( lerr != LDAP_SUCCESS ) { rc = rs->sr_err = lerr; + /* Mark the meta_conn struct as tainted so + * it'll be freed by meta_conn_back_destroy below */ + LDAP_BACK_CONN_TAINTED_SET( mc ); + /* FIXME: in some cases (e.g. unavailable) * do not assume it's not candidate; rather * mark this as an error to be eventually

1 0

(ITS#5153) Performance of large multi-valued attributes
by hyc＠OpenLDAP.org 25 Sep '07

25 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc A bit late, but this is just for tracking purposes. HEAD now supports a "sortvals" directive for declaring that specific attributes' values be maintained in sorted order. This allows Compare/Filter operations on attributes with very many values to be completed more efficiently. (From O(n) to O(logn).) Modify operations are also similarly improved.

1 0

Re: (ITS#5152) too much logging
by hyc＠symas.com 25 Sep '07

25 Sep '07

babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3.32 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.11.27) > > > Hello, > > We are having hell of problems in production with # logs getting > generated..almost 4Gig worth of transaction binary/BDB logs in a day(4000 10mb > files). > > No debugging/logging turned in slapd. > > Log rotate scripts is moving the logs to diff location to keep the prod up..but > few times we ran of space and I don't find any clue on minimize and log only for > updated transactions. It seems BDB is recording every read/write(not sure)..I > can't enable Auto_Achieve as need them for recovery. > > Any known issue in the space? How to turn of unwanted logging of BDB? Learn how to use BerkeleyDB. http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/… The ITS is for reporting actual bugs in the software. There is no bug here. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by quanah＠zimbra.com 25 Sep '07

25 Sep '07

--On Monday, September 24, 2007 3:23 PM +0000 tan7f(a)virginia.edu wrote: > > --Apple-Mail-1--260703270 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > Hello OpenLdap Developers, > > I haven't heard anything about the two bugs I've submitted in the > jldap libraries, so I'd like to explain why I feel that these two > issues are important to have fixed. Note that the work on JLDAP is generally done a very different set of developers than most of the OpenLDAP folks, so how soon they'll be addressed I don't know. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5152) too much logging
by Babu.Suresh＠pacificlife.com 25 Sep '07

25 Sep '07

Guys, Any input is greatly appreciated. Please let me know if you need more details of the issue. Thank you _babu -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: Monday, September 24, 2007 3:30 PM To: Suresh, Babu Subject: Re: (ITS#5152) too much logging *** 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#5152. 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#5152) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5152) 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=5152 Please remember to retain your issue tracking number (ITS#5152) 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-2006 The OpenLDAP Foundation, All Rights Reserved. ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

(ITS#5152) too much logging
by babu.suresh＠pacificlife.com 25 Sep '07

25 Sep '07

Full_Name: Babu Version: 2.3.32 OS: RedHAT3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.181.11.27) Hello, We are having hell of problems in production with # logs getting generated..almost 4Gig worth of transaction binary/BDB logs in a day(4000 10mb files). No debugging/logging turned in slapd. Log rotate scripts is moving the logs to diff location to keep the prod up..but few times we ran of space and I don't find any clue on minimize and log only for updated transactions. It seems BDB is recording every read/write(not sure)..I can't enable Auto_Achieve as need them for recovery. Any known issue in the space? How to turn of unwanted logging of BDB? ==================Here are the detail of prod volume & DB_CONFIG file===== openldap-2.3.32&BDB 4.5.20 our ldap/BDB is generating too many logs file. Total records in ldap/BDB - 110k Reads - 10k/day Updates - 1k/day =================DB_CONFIG======= # one 0.25 GB cache #set_cachesize 0 268435456 1 set_cachesize 0 5242880 1 # Data Directory set_lk_max_locks 8000 set_lk_max_lockers 8000 set_lk_max_objects 8000 set_lg_max 8048576 ===============SLAPD.conf======== Nothing special in and inxed we have are======== #index index uid eq index cn eq index uniqueMember eq index objectClass pres,eq ============= thank you # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152

1 0

Re: (ITS#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by tan7f＠virginia.edu 24 Sep '07

24 Sep '07

--Apple-Mail-1--260703270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello OpenLdap Developers, I haven't heard anything about the two bugs I've submitted in the jldap libraries, so I'd like to explain why I feel that these two issues are important to have fixed. I'd like to create a new LdapConnection with a custom LdapSocketFactory and I want a timeout value set on the socket so that the connect method will timeout in case there is no route to the host or some other networking issue. The documentation leads me to believe that I can do the following. LdapConnection.setSocketFactory(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc = new LdapConnection(timeout); lc.connect ("127.0.0.1", 636); This won't work because the LdapConnection(int) constructor disregards the LdapSocketFactory that is set with the setSocketFactory method and instead uses the default non-SSL encrypted socket. Ok, lets try a workaround. lc = new LdapConnection(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc.setTimeout(timeout); // <--- causes a nullPointerException lc.connect("127.0.0.1", 636); // Program never even gets here. Ok, this is even worse. I now get a nullPointerException in the jldap library itself. Again, nothing in the documentation says to avoid setting the timeout until after you call connect() lc = new LdapConnection(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc.connect("127.0.0.1", 636); lc.setTimeout(timeout); Well, that works, but I'm not setting the timeout until after the connect which isn't what I need. What follows is the only way I can think of getting it to work. class TimeoutLdapSocketFactory extends LDAPJSSESecureSocketFactory { m_timeout = 0; TimeoutLdapSocketFactory() { super (); } TimeoutLdapSocketFactory(int timeout) { this(); m_timeout = timeout; } Socket createSocket (host, port) { Socket socket = super.createSocket(host,port); if (timeout > 0) socket.setSoTimeout(m_timeout); return socket; } lc = new LdapConnection(new TimeoutLdapSocket(timeout)); lc.connect("127.0.0.1", 636); That's a lot of code to do what is already there in the LdapConnection class. If either of the two bugs I've submitted is fixed, then the above use case would be easy to do with-out the uglyness above. I believe #5142 to be a serious bug indeed since it can lead to a nullPointerException in the library. Thank you, Tim Nowaczyk -- Timothy Nowaczyk Network Systems Engineer University of Virginia - ITC tan7f(a)virginia.edu --Apple-Mail-1--260703270 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPujCCBIIw ggNqoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZ8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJn aW5pYTEYMBYGA1UEBxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZp cmdpbmlhMRswGQYDVQQDExJVVkEgVVNIRVIgUEtQIENBIDExJTAjBgkqhkiG9w0BCQEWFnBraW1h c3RlckB2aXJnaW5pYS5lZHUwHhcNMDcwNzEyMjEyNzE0WhcNMjYwMjI1MDAwMDAwWjCBrzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExJTAjBgkqhkiG9w0BCQEWFnBraW1hc3RlckB2 aXJnaW5pYS5lZHUxKzApBgNVBAMTIlVWQSBTdGFuZGFyZCBBc3N1cmFuY2UgVVNIRVIgU0tQIDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbO90WPYQnSOSvhwkIlhh3fLVaHi6X2v2+ kJ7njhzZg8zYoTwMa/sag84dgGu9CCmkzvYryD23mwdQ5oZX58ZyrYCETkcuV5Aycbi70ekTrQPP 1b4x4/sK3PDFSn2S2RB1sNlYy15DI6sIO5mVrV16ML+DGBSJbwGoJRjd+2L5MxkhPJraw5+k2us7 ABxvRpFgaA4TXwJiM8/idtsTNMv2XTR6zUJ9FPq8uOMLtiupbWe2K2tXDDeBSzBu7Z7RzNzxSsZz 72PjtEHhuNQ4I1hsKx/HT2gdxrCb6KxSyGo+QbYxwj5znRkIAFNEQPh6U6EPeDuzJbY/VuFfpsil 3tPZAgMBAAGjgbYwgbMwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFAGp d8MuTIwww/Lbfd5nlCrBvuQZMB8GA1UdIwQYMBaAFDdB3axEwhAHmpxMkx2UHyiXRyUxMFMGA1Ud IARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cucGtpLnZpcmdpbmlh LmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAfEvJKxRHr9gy0MufEFva x+QQs2dUN8oocl8jxWsQrQt5Hc6Azzfn2Zp3es10iYkCGNOqj+cRtwoljuWv2yVWm869+xgxskjn uHPnaat84VzXN85i8ILbBZkVYPk1bO2SHjL97RrGvUqi2bJf8cSlzO7g+yTX9/yX0r0QKL4UNHdI p3l3OeTZ0PBLKNhlr1wb6LRpl5+lRZQPWeCij/4e3wA7v9OmWXvevT9YprYTwEmCypPUbnjFeMnP F+hwSgCC+Yov12kP3M+kDwXWpidFGk5p6nQ5c/cGGPd+x8Ek4VjjCw+7TfumwxEJSIX0NmjM+lDx ykVtAMDS11nQ65/VEjCCBVwwggREoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjEwHhcNMDcwNzExMjIyOTQ3WhcNMjYwMjI2MTgwMDAwWjCBnzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExGzAZBgNVBAMTElVWQSBVU0hFUiBQS1AgQ0Eg MTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdpbmlhLmVkdTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANnbscQ3ClhftaALCDqjnqvzU1MVfDmnSNFjSBcGyRRKxNEduA/O4/iD CQ3lKJkRdjhIXN5e5UTe6LsmMY14uPBJOVINmFPiGfsi22LxslYiaGMStWIj3lNF+ZawyUX53WDD IrjlYaBn3wi/m0tkWPLzsgeiRIovL0KVG4XRlkJ70upNCIv6GHP4W6rsa2hqC/gU1QdL+V2XJzE7 sT7l6CysRr01FiyRTOxdoSz+jJFmTTt892sWVry8B7nocD/ltffQ1pQJta4Ve/xWT+TvRPF3X7jn ggOPIYbq0mYRAhWduV1BzlBA8bkTc8AHf8ukjRGydCAPc4OXMamhJ4uETCECAwEAAaOCAeowggHm MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ3Qd2sRMIQB5qcTJMd lB8ol0clMTB9BgNVHSMEdjB0gBQmnSLq7LAPayEK9tkvIMplUOwb06FZpFcwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjGCAQQweAYIKwYBBQUHAQEEbDBqMDMGCCsGAQUFBzAChidodHRwOi8v aDEudXNoZXJjYS5vcmcvYWlhL2NhMS1jZXJ0cy5wN2IwMwYIKwYBBQUHMAKGJ2h0dHA6Ly9oMi51 c2hlcmNhLm9yZy9haWEvY2ExLWNlcnRzLnA3YjBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vaDEu dXNoZXJjYS5vcmcvY3JsL2NhMS5jcmwwJ6AloCOGIWh0dHA6Ly9oMi51c2hlcmNhLm9yZy9jcmwv Y2ExLmNybDBOBgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cudXNo ZXJjYS5vcmcvcHJhY3RpY2VzL2NhMS9jcHMucGRmMA0GCSqGSIb3DQEBBQUAA4IBAQCHbtcZxR5o 9B0MgMds0g3g9DBLZSJEi6kRY6heNocsmSsRxEsqE37R6gVtRg3xfTcjJG9E4J4fClB8EK5EDPRo UAJZExJE47aHNXT7KtHgYKqU5dQUXlGi/ZyPpJOA5Nm8xQ+wiDw3kg8AAnM1WrPNnTUiTCYEUqBI KY8AABaJ9CwVHsnu0wV04z4DtbiZgEhxBOczp8L+AveIsJhCTRc3VNlDmHPu9bh4VoyMnbzwlYKk ItLkehDC5xE2ZPTMfC0VYtL+LEDlbGfR0YpzbTzxP3X3dxsmFbIyXAfNvj5gTqViDcgN9CTzblDv oseZLtO0Te+e/YFeTRUBe/CcmUlmMIIF0DCCBLigAwIBAgIDAgQUMA0GCSqGSIb3DQEBBQUAMIGv MQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxs ZTEfMB0GA1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFz dGVyQHZpcmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBT S1AgMTAeFw0wNzA4MDgxMzAzMDBaFw0wODA4MDgxMzAzMDBaMIGVMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTEeMBwGA1UECxMVVVZBIFN0YW5kYXJkIFBLSSBV c2VyMSEwHwYJKoZIhvcNAQkBFhJ0YW43ZkB2aXJnaW5pYS5lZHUxIjAgBgNVBAMTGVRpbW90aHkg QWxsZW4gTm93YWN6eWsgMTMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKEo43l7/lWiNKOe vtraIMIje77qJCSifhZ0CtrBT15E8HPQajBcFnqJ3U//6vvrEeN79de3Gvwygia0SwkgzjtFEsh8 /fLHKvYUDDlhyJxgbaVw3Ay1Ii9cHTyA8hopglAhyVweu08hwrnmSUDBsV+ugqV3AANQ0QwkXPDs WbIbAgMBAAGjggKPMIICizALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBSt9bmjP/g2cbvyzw+7IfnWfnDliDAJBgNVHRMEAjAAMB8GA1UdIwQYMBaA FAGpd8MuTIwww/Lbfd5nlCrBvuQZMEEGA1UdEQQ6MDigIgYKKwYBBAGCNxQCA6AUDBJ0YW43ZkBW aXJnaW5pYS5FRFWBEnRhbjdmQFZpcmdpbmlhLkVEVTCCAXgGA1UdHwSCAW8wggFrMH2ge6B5hnds ZGFwOi8vd3d3LnBraS52aXJnaW5pYS5lZHUvYz1VUyxvPVVuaXZlcnNpdHklMjBvZiUyMFZpcmdp bmlhLG91PVVWQSUyMFN0YW5kYXJkJTIwQXNzdXJhbmNlJTIwVVNIRVIlMjBTS1AlMjAxLGNuPTAy MDQxNDB9oHugeYZ3bGRhcDovL3d3dy5wa2kudmlyZ2luaWEuZWR1L2NuPTAyMDQxNCxvdT1VVkEl MjBTdGFuZGFyZCUyMEFzc3VyYW5jZSUyMFVTSEVSJTIwU0tQJTIwMSxvPVVuaXZlcnNpdHklMjBv ZiUyMFZpcmdpbmlhLGM9VVMwa6BpoGeGZWh0dHA6Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9jZ2kt YmluL2dldC1jcmw/b3U9VVZBJTIwU3RhbmRhcmQlMjBBc3N1cmFuY2UlMjBVU0hFUiUyMFNLUCUy MDEmY249MDIwNDE0MFMGA1UdIARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6 Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOC AQEAY0SUBCrlT0E9VPUQy3lTVDYNQ+ewR3dPa+D4U+gqThk3mbOWSXWEOsYTw9BYOljv4UClAY5M Uhp1Iyj7twzIG8lJnZhVP3G/ToU+8fkCCPUdAH+MJ6eshdZaeEEA/a2RzB0XvvmAfYK5x3e2yYLM tOvfBHrRAl6m5O7wU2t6iykU6vGdL+MB9iqlylY2bxQ0x0NaW5KPL0XuPLgwxVvcds7eIDGOoy7+ WMDaY0miUqsq4PKjg98dnY5BaSUwGFyxhFocw8xtTVdls5VKh3jEvhYyq9ejTHFv49dEnXdmSZ1Y Z3p98sEfQ12+CtFUbzlwphhJELXdC4nm71zFPcXg8zGCA1cwggNTAgEBMIG3MIGvMQswCQYDVQQG EwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0GA1UE ChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdp bmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQIDAgQU MAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDkyNDE1MjI1OFowIwYJKoZIhvcNAQkEMRYEFD9bKXbPWwwDKjUSyibAUFSKfHnjMIHIBgkr BgEEAYI3EAQxgbowgbcwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEYMBYGA1UE BxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZpcmdpbmlhMSUwIwYJ KoZIhvcNAQkBFhZwa2ltYXN0ZXJAdmlyZ2luaWEuZWR1MSswKQYDVQQDEyJVVkEgU3RhbmRhcmQg QXNzdXJhbmNlIFVTSEVSIFNLUCAxAgMCBBQwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYD VQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZp cmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQID AgQUMA0GCSqGSIb3DQEBAQUABIGAKppmxD98ZrUSeu76i+2qXl3WV18+NCFKNFF//HeUl4aTKtEq x7K/BLdtJWyU8P+5SqoLRWG/86hBb2ERZNDozP5/6BC/0Gwuh9TUfVyRgxldQL9z8RNoMfv5T9g4 RlrQB9LGxVyAz3t7w3go8xkTBuRR2zLEn183lLBLY6CCpB8AAAAAAAA= --Apple-Mail-1--260703270--

1 0

(ITS#5151) certificateListValidate rejects valid lists
by hyc＠OpenLDAP.org 24 Sep '07

24 Sep '07

Full_Name: Howard Chu Version: HEAD/re24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc I ran into a couple problems; the check for timestamps doesn't take into account that Time is a CHOICE of UTCTime and GeneralizedTime. Also the check for the revocation list doesn't verify that it's a SEQUENCE OF SEQUENCE, so it mistakenly skips over closing signatureAlgorithm if the revocation list is absent. Will be fixed in HEAD shortly.

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by hyc＠symas.com 24 Sep '07

24 Sep '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails >> to parse it because it is an integer with length equal to 9, which is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means from > 0 up to 2^31-1... I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self-consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. I just got tripped trying to import an LDIF with a cert with 16 byte SerialNumber. I've patched this to just use the same hexadecimal format that OpenSSL uses when the number is larger than ber_int_t. We really don't want the format to change just because someone has a BigNum library available; it needs to stay consistent. Normalizing to a string format like this still seems pretty gross, but I guess that's the best we can do given dumb clients that aren't aware of schema. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 23 Sep '07

23 Sep '07

Ralf Haferkamp wrote: > Please note that test020 currently fails in HEAD sometime. I think this > depends on the order in which the results for queries that hit the > sizelimit are returned. I added tests for sizelimit that were consistent with my changes; however, I'm now short of time to work on this, so feel free to back out those test changes if you believe the code is working correctly, while we design test improvements that are consistent with all fixes. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 23 Sep '07

23 Sep '07

hyc(a)symas.com wrote: > Ralf Haferkamp wrote: >> On Freitag, 21. September 2007, hyc(a)symas.com wrote: >>> It seems to be failing for me more often than not. Why is it >>> non-deterministic? >> It seems that the order in which the entries are inserted into the cache is >> non-deterministic. Because of that the order in which they are returned from >> cache varies as well. The final test that compares the ldapsearch results >> with proxycache.out relies on the order. >> >> I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log >> it seems that sometimes the entries from Query 9 get inserted into the cache >> before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology >> Division, ...") and sometimes after. Depending on that the test either fails >> or succeeds. >> > OK, I see that as well. In fact setting a breakpoint on the Deadlock result, I > see 3 threads still trying to add entries to the cache when the deadlock > occurs. This appears to be a consequence of letting the client continue on > before the pcache overlay has finished its work. But, I thought you were > locking the cache so that requests would not run while query processing was > incomplete? I see, you're only locking individual queries. That's certainly inadequate, you'll probably have to lock the entire cache as a whole. Remember that an entry that you're adding may actually satisfy multiple queries. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 23 Sep '07

23 Sep '07

Ralf Haferkamp wrote: > On Freitag, 21. September 2007, hyc(a)symas.com wrote: >> rhafer(a)suse.de wrote: >>> Please note that test020 currently fails in HEAD sometime. I think this >>> depends on the order in which the results for queries that hit the >>> sizelimit are returned. >> It seems to be failing for me more often than not. Why is it >> non-deterministic? > It seems that the order in which the entries are inserted into the cache is > non-deterministic. Because of that the order in which they are returned from > cache varies as well. The final test that compares the ldapsearch results > with proxycache.out relies on the order. > > I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log > it seems that sometimes the entries from Query 9 get inserted into the cache > before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology > Division, ...") and sometimes after. Depending on that the test either fails > or succeeds. > OK, I see that as well. In fact setting a breakpoint on the Deadlock result, I see 3 threads still trying to add entries to the cache when the deadlock occurs. This appears to be a consequence of letting the client continue on before the pcache overlay has finished its work. But, I thought you were locking the cache so that requests would not run while query processing was incomplete? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by hyc＠symas.com 23 Sep '07

23 Sep '07

hyc(a)symas.com wrote: > There's no reason to break the core code with misfeatures like this. If you > need this behavior, write an overlay that intercepts the relevant searches and > replaces the empty attribute list with "*" and "+". Scratch that, the contrib/slapd-modules/allop overlay already does this. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by hyc＠symas.com 22 Sep '07

22 Sep '07

mspeder(a)syrtis.net wrote: > Full_Name: Matthieu Speder > Version: Latest HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Matthieu-Speder-070922.patch > Submission from: (NULL) (82.224.96.182) > > > This patch adds a new global option in configuration > (forceopattrs/olcForceOpAttrs { on | off }). Thanks for the patch. Still, the behavior you're introducing is a violation of the protocol spec. The fact that other vendors don't care to implement conformant servers doesn't really have any bearing on this; clients that expect this behavior are broken and should be fixed. > When answering a search query to rootDSE with an empty attribute query, > forceopattrs forces slapd to return all operational attributes. By default > forceopattrs is off and slapd only returns operational attributes when query > contains a plus (+), see RFC 4533. > > Unfortunately the default behavior is different from other directories (both AD > & Sun) and confuses some client applications which expect the operational > attributes with a blank query. This new config option fixes the issue if > required by client app. > > This patch does NOT change slapd default behavior. > > The patch contains both minor changes to result.c, proto-slap.h, bconfig.c and > the required additions to docs (man & guide). There's no reason to break the core code with misfeatures like this. If you need this behavior, write an overlay that intercepts the relevant searches and replaces the empty attribute list with "*" and "+". -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by mspeder＠syrtis.net 22 Sep '07

22 Sep '07

Full_Name: Matthieu Speder Version: Latest HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Matthieu-Speder-070922.patch Submission from: (NULL) (82.224.96.182) This patch adds a new global option in configuration (forceopattrs/olcForceOpAttrs { on | off }). When answering a search query to rootDSE with an empty attribute query, forceopattrs forces slapd to return all operational attributes. By default forceopattrs is off and slapd only returns operational attributes when query contains a plus (+), see RFC 4533. Unfortunately the default behavior is different from other directories (both AD & Sun) and confuses some client applications which expect the operational attributes with a blank query. This new config option fixes the issue if required by client app. This patch does NOT change slapd default behavior. The patch contains both minor changes to result.c, proto-slap.h, bconfig.c and the required additions to docs (man & guide).

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 21 Sep '07

21 Sep '07

On Freitag, 21. September 2007, hyc(a)symas.com wrote: > rhafer(a)suse.de wrote: > > Please note that test020 currently fails in HEAD sometime. I think this > > depends on the order in which the results for queries that hit the > > sizelimit are returned. > > It seems to be failing for me more often than not. Why is it > non-deterministic? It seems that the order in which the entries are inserted into the cache is non-deterministic. Because of that the order in which they are returned from cache varies as well. The final test that compares the ldapsearch results with proxycache.out relies on the order. I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log it seems that sometimes the entries from Query 9 get inserted into the cache before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology Division, ...") and sometimes after. Depending on that the test either fails or succeeds. -- Ralf

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 21 Sep '07

21 Sep '07

rhafer(a)suse.de wrote: > Please note that test020 currently fails in HEAD sometime. I think this > depends on the order in which the results for queries that hit the > sizelimit are returned. It seems to be failing for me more often than not. Why is it non-deterministic? > > Testout put is: > ------------------ > ... > ... > Successfully verified answerability > Filtering ldapsearch results... > Filtering original ldif... > Comparing filter output... > Comparison failed > ------------------ > > # diff testrun/ldif.flt testrun/ldapsearch.flt > 233,235c233,235 > < dn: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc > < =com > < mail: bjorn(a)mailgw.example.com > --- >> dn: cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example, >> dc=com >> mail: bjensen(a)mailgw.example.com > > # > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5102) back-perl build issues
by hyc＠symas.com 21 Sep '07

21 Sep '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Another thing that has nagged me ever since we unified the slap tools into >> slapd - should have renamed slapadd.c -> tooladd.c etc... > > Personally, not. Only, slap* makes them quite personal, while tool* > sounds quite generic. It's like calling them db*: could be any type of > db (no pun with Berkeley intended :). Fair enough. I think my main issue is with slapcommon.[ch], which is only related to the tools, not common to slapd as a whole. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Fwd: Solaris 10 test000 root dse bus error (ITS#5140)
by hyc＠symas.com 20 Sep '07

20 Sep '07

james.hartley(a)gmail.com wrote: > ---------- Forwarded message ---------- > From: James Hartley <james.hartley(a)gmail.com> > Date: Sep 20, 2007 11:38 AM > Subject: Re: Solaris 10 test000 root dse bus error (ITS#5140) > To: Quanah Gibson-Mount <quanah(a)zimbra.com> > > ok I used the 2.4 beta wth the same result on tests. here is the configure > command and the output of make test. Not sure if I should back up to > Berkeley 4.5 and openldap2.3.38... Since that will require rebuilding the > DB then SASL then LDAP... do you know someone that might have build and > tested openldap for solaris 10 that I can confer with directly. Yes, I've run 2.4.5 with BDB 4.6 on Solaris 10 without any difficulties. Since you're seeing a bus error the only way to diagnose this is by using a debugger to get a stack trace. > P.S. I have some scripts that you might be interested in the maintain > usr/local and help construct packages for solaris... The OpenLDAP Project doesn't maintain packages for any platform. Feel free to post your tips and scripts in the FAQ-o-Matic. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Fwd: Solaris 10 test000 root dse bus error (ITS#5140)
by ghenry＠OpenLDAP.org 20 Sep '07

20 Sep '07

Again, no HTML, please... Did you run: configure make depend make make test It looks like "make depend" was missing. Can we move this to -software(a)openldap.org rather than an ITS, as this appears to be a user build issue rather than an actual bug. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Fwd: Solaris 10 test000 root dse bus error (ITS#5140)
by james.hartley＠gmail.com 20 Sep '07

20 Sep '07

------=_Part_32258_11773747.1190318929506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: James Hartley <james.hartley(a)gmail.com> Date: Sep 20, 2007 11:38 AM Subject: Re: Solaris 10 test000 root dse bus error (ITS#5140) To: Quanah Gibson-Mount <quanah(a)zimbra.com> ok I used the 2.4 beta wth the same result on tests. here is the configure command and the output of make test. Not sure if I should back up to Berkeley 4.5 and openldap2.3.38... Since that will require rebuilding the DB then SASL then LDAP... do you know someone that might have build and tested openldap for solaris 10 that I can confer with directly. here is the output env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls --with-cyrus-sasl make[1]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta /tests' make[2]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' Initiating LDAP tests for BDB... ./run: ./schema: does not exist Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... 24854 Bus Error - core dumped Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: kill: no such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta /tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta /tests' make: *** [test] Error 2 --(hartleyj@sunv420)-(~/sunv420ldapconstruction_latest/openldap- 2.4.5beta )-- P.S. I have some scripts that you might be interested in the maintain usr/local and help construct packages for solaris... On 9/20/07, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > --On Thursday, September 20, 2007 3:54 PM +0000 james.hartley(a)gmail.com > wrote: > > > ------=_Part_30794_27537250.1190303647870 > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > Humm no real help here!! no obvious errors. here is the last few lines > > of the slapd.1.conf file. in tests. > > > > Do you have any other Ideas > > Use a supported version of BDB. OpenLDAP 2.3 series works with BDB 4.2, > 4.4, and 4.5. OpenLDAP 2.4 series works with BDB 4.2, 4.4, 4.5, and 4.6. > Since you built 2.3 against 4.6, you are trying to do something that is > not > supported. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > ------=_Part_32258_11773747.1190318929506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: James Hartley <<a href="mailto:james.hartley@gmail.com">james.hartley(a)gmail.com</a>> Date: Sep 20, 2007 11:38 AM Subject: Re: Solaris 10 test000 root dse bus error (ITS#5140) To: Quanah Gibson-Mount <<a href="mailto:quanah@zimbra.com">quanah(a)zimbra.com</a>> ok I used the 2.4 beta wth the same result on tests.   here is the configure command and the output of make test.   Not sure if I should back up to Berkeley 4.5 and openldap2.3.38...  Since that will require rebuilding the DB then SASL then LDAP... do you know someone that might have build and tested openldap for solaris 10 that I can confer with directly. here is the output env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls --with-cyrus-sasl make[1]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' make[2]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta /tests' Initiating LDAP tests for BDB... ./run: ./schema: does not exist Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... 24854 Bus Error - core dumped Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: kill: no such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' make: *** [test] Error 2 --(hartleyj@sunv420)-(~/sunv420ldapconstruction_latest/openldap- 2.4.5beta)-- P.S.  I have some scripts that you might be interested in the maintain usr/local and help construct packages for solaris... <div>On 9/20/07, Quanah Gibson-Mount <<a href="mailto:quanah@zimbra.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">quanah(a)zimbra.com</a>> wrote:<div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> --On Thursday, September 20, 2007 3:54 PM +0000 <a href="mailto:james.hartley@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">james.hartley(a)gmail.com</a> wrote: > ------=_Part_30794_27537250.1190303647870 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Humm no real help here!!  no obvious errors.  here is the last few lines > of the slapd.1.conf file. in tests. > > Do you have any other Ideas Use a supported version of BDB.  OpenLDAP 2.3 series works with BDB 4.2, 4.4, and 4.5.  OpenLDAP 2.4 series works with BDB 4.2, 4.4, 4.5, and 4.6. Since you built 2.3 against 4.6, you are trying to do something that is not supported. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote></div></div> ------=_Part_32258_11773747.1190318929506--

1 0

Re: (ITS#5149) config.status aborts with error
by hyc＠symas.com 20 Sep '07

20 Sep '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.186.237) > > > Hi config.status aborts with error, thus portable.h and other files are not > generated by configure You need to use "cvs upd -d " to get the back-sock directory. No bug here, this ITS will be closed. > config.status:842: creating servers/slapd/back-sock/Makefile > config.status:902: error: cannot find input file: > servers/slapd/back-sock/Makefile.in > .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.- > > -Dieter > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5149) config.status aborts with error
by dieter＠dkluenter.de 20 Sep '07

20 Sep '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.186.237) Hi config.status aborts with error, thus portable.h and other files are not generated by configure config.log .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- config.status:842: creating Makefile config.status:842: creating doc/Makefile config.status:842: creating doc/man/Makefile config.status:842: creating doc/man/man1/Makefile config.status:842: creating doc/man/man3/Makefile config.status:842: creating doc/man/man5/Makefile config.status:842: creating doc/man/man8/Makefile config.status:842: creating clients/Makefile config.status:842: creating clients/tools/Makefile config.status:842: creating include/Makefile config.status:842: creating libraries/Makefile config.status:842: creating libraries/liblber/Makefile config.status:842: creating libraries/libldap/Makefile config.status:842: creating libraries/libldap_r/Makefile config.status:842: creating libraries/liblunicode/Makefile config.status:842: creating libraries/liblutil/Makefile config.status:842: creating libraries/librewrite/Makefile config.status:842: creating servers/Makefile config.status:842: creating servers/slapd/Makefile config.status:842: creating servers/slapd/back-bdb/Makefile config.status:842: creating servers/slapd/back-dnssrv/Makefile config.status:842: creating servers/slapd/back-hdb/Makefile config.status:842: creating servers/slapd/back-ldap/Makefile config.status:842: creating servers/slapd/back-ldif/Makefile config.status:842: creating servers/slapd/back-meta/Makefile config.status:842: creating servers/slapd/back-monitor/Makefile config.status:842: creating servers/slapd/back-null/Makefile config.status:842: creating servers/slapd/back-passwd/Makefile config.status:842: creating servers/slapd/back-perl/Makefile config.status:842: creating servers/slapd/back-relay/Makefile config.status:842: creating servers/slapd/back-shell/Makefile config.status:842: creating servers/slapd/back-sock/Makefile config.status:902: error: cannot find input file: servers/slapd/back-sock/Makefile.in .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.- -Dieter

1 0

(ITS#5148) Segmentation Fault
by Russell.Mosemann＠cune.edu 20 Sep '07

20 Sep '07

quanah(a)zimbra.com said: > OpenLDAP 2.3 does not support BDB 4.6. Thank you. That answers my question. This ticket may be closed. -- Russell Mosemann, Ph.D. Associate Professor of Computer Science

1 0

Re: Solaris 10 test000 root dse bus error (ITS#5140)
by hyc＠symas.com 20 Sep '07

20 Sep '07

james.hartley(a)gmail.com wrote: > ------=_Part_30794_27537250.1190303647870 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Humm no real help here!! no obvious errors. here is the last few lines of > the slapd.1.conf file. in tests. > > Do you have any other Ideas Don't send HTML email to the ITS. You didn't specify which version of BDB 4.6 you're using, but I suspect your answer is here: http://www.openldap.org/lists/openldap-software/200708/msg00344.html -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Solaris 10 test000 root dse bus error (ITS#5140)
by quanah＠zimbra.com 20 Sep '07

20 Sep '07

--On Thursday, September 20, 2007 3:54 PM +0000 james.hartley(a)gmail.com wrote: > ------=_Part_30794_27537250.1190303647870 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Humm no real help here!! no obvious errors. here is the last few lines > of the slapd.1.conf file. in tests. > > Do you have any other Ideas Use a supported version of BDB. OpenLDAP 2.3 series works with BDB 4.2, 4.4, and 4.5. OpenLDAP 2.4 series works with BDB 4.2, 4.4, 4.5, and 4.6. Since you built 2.3 against 4.6, you are trying to do something that is not supported. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5148) Segmentation Fault
by hyc＠symas.com 20 Sep '07

20 Sep '07

Russell.Mosemann(a)cune.edu wrote: > Full_Name: Russell Mosemann > Version: 2.3.38 > OS: Linux 2.6.19.1 > URL: > Submission from: (NULL) (192.160.64.49) > > > Debian 3.1 > bdb 4.6.19 > OpenLDAP 2.3.38 > configure --disable-ipv6 --without-cyrus-sasl --without-tls --enable-crypt \ > --enable-wrappers --enable-hdb > gcc version 4.2.1 (Debian 4.2.1-3) > > slapcat and slapadd function without errors when loading or exporting the > database. The following segmentation fault happens on the first query to slapd. This is expected. http://www.openldap.org/lists/openldap-software/200708/msg00344.html BerkeleyDB 4.6.19 is not compatible with OpenLDAP 2.3. Use OpenLDAP 2.4 if you want to use BDB 4.6.19, or use BDB 4.6.3 or older if you want to stay on OpenLDAP 2.3. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5148) Segmentation Fault
by quanah＠zimbra.com 20 Sep '07

20 Sep '07

--On Thursday, September 20, 2007 3:44 PM +0000 Russell.Mosemann(a)cune.edu wrote: > Full_Name: Russell Mosemann > Version: 2.3.38 > OS: Linux 2.6.19.1 > URL: > Submission from: (NULL) (192.160.64.49) > > > Debian 3.1 > bdb 4.6.19 > OpenLDAP 2.3.38 OpenLDAP 2.3 does not support BDB 4.6. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: Solaris 10 test000 root dse bus error (ITS#5140)
by james.hartley＠gmail.com 20 Sep '07

20 Sep '07

------=_Part_30794_27537250.1190303647870 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Humm no real help here!! no obvious errors. here is the last few lines of the slapd.1.conf file. in tests. Do you have any other Ideas slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=include{3}" config_build_entry: "cn=include{4}" config_build_entry: "cn=include{5}" config_build_entry: "cn=include{6}" config_build_entry: "cn=include{7}" config_build_entry: "cn=include{8}" config_build_entry: "cn=include{9}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}dyngroup" config_build_entry: "cn={9}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_entry: "olcDatabase={2}monitor" backend_startup_one: starting "o=OpenLDAP Project,l=Internet" bdb_db_open: o=OpenLDAP Project,l=Internet bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: (2) Expect poor performance for suffix o=OpenLDAP Project,l=Internet. bdb_db_open: dbenv_open(./testrun/db.1.a) On 9/20/07, Gavin Henry <openldap-its(a)openldap.org> wrote: > > > Full_Name: james hartley > > Version: 2.3.27 > > OS: Solaris 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (204.140.46.100) > > > > > > built with gcc 3.4.6 using the following configure command. > > > > $env > LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" > > LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib > -L/usr/local/BerkeleyDB.4.6/lib > > \-L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib > > -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" > CPPFLAGS="-I/usr/local/include > > -I/usr/local/ssl/include \ -I/usr/local/BerkeleyDB.4.6/include > > -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt > --with-tls > > --with-cyrus-sasl > > > > compile looks good... However I get the following errors during make > test... > > I could not find anything in the archives that pointed to a > solution. Only > > others asking the same question for earlier versions of solaris ,, > specifically > > solaris 8. > > > > Can anyone give me a good lead in how to proceed. BTW I have run tests > before > I > > installed the software and after I installed the software... After the > first > > test I installed the software anyway. > > > > Thanks for any help. > > > > cd tests; make test > > make[1]: Entering directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make[2]: Entering directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > Initiating LDAP tests for BDB... > > Cleaning up test run directory leftover from previous run. > > Running ./scripts/all... > >>>>>> Executing all LDAP tests for bdb > >>>>>> Starting test000-rootdse ... > > running defines.sh > > Starting slapd on TCP/IP port 9011... > > Using ldapsearch to retrieve the root DSE... > > Waiting 5 seconds for slapd to start... > > 11851 Bus Error - core dumped > > Waiting 5 seconds for slapd to start... > > Waiting 5 seconds for slapd to start... > > Waiting 5 seconds for slapd to start... > > Waiting 5 seconds for slapd to start... > > Waiting 5 seconds for slapd to start... > > ./scripts/test000-rootdse: kill: no such process > > ldap_bind: Can't contact LDAP server (-1) > >>>>>> Test failed > >>>>>> ./scripts/test000-rootdse failed (exit 1) > > make[2]: *** [bdb-yes] Error 1 > > make[2]: Leaving directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make[1]: *** [test] Error 2 > > make[1]: Leaving directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make: *** [test] Error 2 > > > > After running make test, look at the files in the "testrun" folder. That > will > tell you the reasons why it failed. > ------=_Part_30794_27537250.1190303647870 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Humm no real help here!!  no obvious errors.  here is the last few lines of the slapd.1.conf file. in tests.  Do you have any other Ideas slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=include{3}" config_build_entry: "cn=include{4}" config_build_entry: "cn=include{5}" config_build_entry: "cn=include{6}" config_build_entry: "cn=include{7}" config_build_entry: "cn=include{8}" config_build_entry: "cn=include{9}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}dyngroup" config_build_entry: "cn={9}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_entry: "olcDatabase={2}monitor" backend_startup_one: starting "o=OpenLDAP Project,l=Internet" bdb_db_open: o=OpenLDAP Project,l=Internet bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: (2) Expect poor performance for suffix o=OpenLDAP Project,l=Internet. bdb_db_open: dbenv_open(./testrun/db.1.a) <div>On 9/20/07, Gavin Henry <<a href="mailto:openldap-its@openldap.org"> openldap-its(a)openldap.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Full_Name: james hartley > Version: 2.3.27 > OS: Solaris 10 > URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (<a href="http://204.140.46.100">204.140.46.100</a>) > > > built with gcc 3.4.6 using the following configure command. > > $env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" > LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib > \-L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib > -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include > -I/usr/local/ssl/include \ -I/usr/local/BerkeleyDB.4.6/include > -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls > --with-cyrus-sasl > > compile looks good... However I get the following errors during make test... > I could not find anything in the archives that pointed to a solution.  Only > others asking the same question for earlier versions of solaris ,, specifically > solaris 8. > > Can anyone give me a good lead in how to proceed. BTW I have run tests before I > installed the software and after I installed the software... After the first > test I installed the software anyway. > > Thanks for any help. > > cd tests; make test > make[1]: Entering directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.3.37/tests' > make[2]: Entering directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' > Initiating LDAP tests for BDB... > Cleaning up test run directory leftover from previous run. > Running ./scripts/all... >>>>>> Executing all LDAP tests for bdb >>>>>> Starting test000-rootdse ... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > 11851 Bus Error - core dumped > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: kill: no such process > ldap_bind: Can't contact LDAP server (-1) >>>>>> Test failed >>>>>> ./scripts/test000-rootdse failed (exit 1) > make[2]: *** [bdb-yes] Error 1 > make[2]: Leaving directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.3.37/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' > make: *** [test] Error 2 > After running make test, look at the files in the "testrun" folder. That will tell you the reasons why it failed. </blockquote></div> ------=_Part_30794_27537250.1190303647870--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs