- openldap-bugs - openldap.org

(ITS#6216) Slapd crashes when adding a backend without olcsuffix but with a olcsubordinate
by sebastien.bahloul＠gmail.com 16 Jul '09

16 Jul '09

Full_Name: Sebastien Bahloul Version: 2.X (HEAD from July, 15 2009) OS: Ubuntu 9.04 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.65.230.146) It seems that slapd crashes when I try to add a simple hdb backend (also confirmed with a bdb) without an olcSuffix attribute but with an olcSubordinate attribute value : dn: olcDatabase=hdb,cn=config objectclass: olcDatabaseConfig objectclass: olcConfig objectclass: olcHdbConfig objectclass: top olcdatabase: hdb olcdbdirectory: /tmp olcsubordinate: FALSE GDB Backtrace : conn=0 op=1 ADD dn="olcDatabase=hdb,cn=config" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd13c010950 (LWP 7210)] 0x0000000000482fd1 in glue_sub_attach (online=1) at backglue.c:1167 1167 Debug( LDAP_DEBUG_ANY, "glue: no superior found for sub %s!\n", (gdb) bt #0 0x0000000000482fd1 in glue_sub_attach (online=1) at backglue.c:1167 #1 0x0000000000408364 in config_subordinate (c=0x7fd13c00e5f0) at bconfig.c:2354 #2 0x0000000000415c33 in config_set_vals (Conf=0x7dbe20, c=0xffffffff) at config.c:325 #3 0x000000000041989d in config_parse_add (ct=0x7dbe20, c=0x7fd13c00e5f0, valx=<value optimized out>) at config.c:665 #4 0x000000000040fdea in config_add_internal (cfb=0x7e5680, e=0x19492f8, ca=0x7fd13c00e5f0, rs=<value optimized out>, renum=0x7fd13c00e5ec, op=<value optimized out>) at bconfig.c:4573 #5 0x00000000004109d3 in config_back_add (op=0x1a47b30, rs=0x7fd13c00fc70) at bconfig.c:4800 #6 0x000000000042695e in fe_op_add (op=0x1a47b30, rs=0x7fd13c00fc70) at add.c:334 #7 0x000000000042728f in do_add (op=0x1a47b30, rs=0x7fd13c00fc70) at add.c:194 #8 0x000000000041f7b7 in connection_operation (ctx=0x7fd13c00fdd0, arg_v=<value optimized out>) at connection.c:1115 #9 0x0000000000420455 in connection_read_thread (ctx=0x7fd13c00fdd0, argv=<value optimized out>) at connection.c:1251 #10 0x0000000000528010 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #11 0x00007fd1526943ba in start_thread () from /lib/libpthread.so.0 #12 0x00007fd151c10fcd in clone () from /lib/libc.so.6 #13 0x0000000000000000 in ?? ()

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 14 Jul '09

14 Jul '09

Rich Megginson wrote: > Howard Chu wrote: >> Ok. The configure patches are in too, so moznss may be selected. But I >> think we'll wait on making this generally available until we know what >> the story will be for PEM and multi-init. > Ok Fyi, the code patches are in 2.4.17, but I held back the configure patches (which are only in HEAD). So you should be able to manually define HAVE_MOZNSS for testing purposes with this release. -- -- 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#6215) liblber problems
by h.b.furuseth＠usit.uio.no 14 Jul '09

14 Jul '09

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Given these declarations: #include <lber.h> #define LBER_EXBUFSIZ 4060 /* from liblber/io.c */ static char data[8000]; struct berval bv; BerElement *ber; Buffer overrun i ber_flatten(,,0): ber = der_alloc(); ber_printf(ber, "o", data, LBER_EXBUFSIZ - 4); ber_flatten2(ber, &bv, 0); ber_flatten2(,,0) \0-terminates the Ber buffer, but does not grow it first at need. Simplest fix is to allocate an extra byte in ber_realloc(), and reduce LBER_EXBUFSIZ by 1 to compensate. I don't know how kosher it is to write into the ber buffer in the first place though. Coredump - write through NULL pointer: ber_flatten2(der_alloc(), &bv, 0); A fresh Ber has no buffers yet, the buffer pointers are NULL. \0-terminating a NULL pointer doesn't work too well. Don't know if it should be called a bug though, since ber_flatten2() doesn't work right on an incomplete Ber element either (due to seqorset stuff). The NULL pointers in a fresh ber also mean ber_write, ber_len() & co do pointer arithmetic on NULL pointers, which is not valid. Oh well, it seems to work on most machines. Buffer overrun in ber_write(): ber = der_alloc(); ber_printf(ber, "{"); ber_write(ber, data, 6000, 0); ber_write() needs buffer space and calls ber_realloc(ber, 6000). However "{" has moved ber->ber_sos->sos_ptr (the write destination) 6 bytes beyond ber->ber_end, so 6006 bytes are actually needed. ber_realloc() does not know that, and allocates 6000 bytes. It cannot happen with ber_write() called from liblber: Next liblber write after "{" will be just a few bytes with the next element's tag. ber_realloc() always allocates 4060 bytes or more - moving sos_ptr beyond ber_end again. This can only happen if a caller outside liblber generates a complete "tag, length, contents" element >= 4060 bytes and ber_write()s it in one operation. There are ber_write()s in libldap and slapd/connection.c, but haven't checked if any are at risk. Don't know where to fix it: - in ber_realloc(), most techinically correct. - in ber_write() - simpler since it already knows about sos_ptr. - in ber_start_seqorset() - always alloc a buffer, never point beyond allocated data. Cleanest but most space-costly.

1 0

(ITS#6214) slapacl causes bdb_db_close error
by dkastens＠uni-osnabrueck.de 14 Jul '09

14 Jul '09

Full_Name: Dirk Kastens Version: 2.4.17 OS: Red Hat Enterprise Linux Server release 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.173.16.92) I'm using BerkeleyDB.4.6.21 This issue existed in openldap 2.4.16, so I updated to 2.4.17, but the error still exists. When I call "slapacl", for example slapacl -b uid=xmuster,ou=people,dc=myorg -D uid=xmuster,ou=people,dc=myorg the output ends with the lines: bdb(dc=myorg): Error: closing the transaction region with active transactions bdb_db_close: database "dc=myorg": close failed: Invalid argument (22) and the database is corrupted. slapd wasn't running during execution. After running slapacl slapd starts with the message: bdb_db_open: database "dc=myorg": unclean shutdown detected; attempting recovery. This seems to be an old but re-occuring bug.

1 0

(ITS#6213) test056-monitor fails when using non-default SLAPD_BASEPORT
by rhafer＠suse.de 14 Jul '09

14 Jul '09

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.248.36) # SLAPD_BASEPORT=10000 ./run test056-monitor Cleaning up test run directory leftover from previous run. [..] Comparing filter output... comparison failed - connection monitor output is not correct The problem is that data/monitor1.out contains a hardcoded portnumber. I guess we should use @PORT1@ and have conf.sh substitute the setting. Fix is on its way to cvs.

1 0

openldap-server-2.4.16_1 segmentation fault
by Alexander Panyushkin 14 Jul '09

14 Jul '09

Hello. when i to restart the apache, slapd is segmentation fault. on the version of openldap 2.3 is an error that I need help that to decide this problem. OS - FreeBSD 7.2-RELEASE-p2 amd64 apachectl -VV Server version: Apache/2.0.63 Server built: Jul 9 2009 17:34:07 Server's Module Magic Number: 20020903:13 Server loaded: APR 0.9.17, APR-UTIL 0.9.15 Compiled using: APR 0.9.17, APR-UTIL 0.9.15 Architecture: 64-bit Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_FLOCK_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/usr/local" -D SUEXEC_BIN="/usr/local/bin/suexec" -D DEFAULT_PIDLOG="/var/run/httpd.pid" -D DEFAULT_SCOREBOARD="/var/run/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/accept.lock" -D DEFAULT_ERRORLOG="/var/log/httpd-error.log" -D AP_TYPES_CONFIG_FILE="etc/apache2/mime.types" -D SERVER_CONFIG_FILE="etc/apache2/httpd.conf" nss_ldap.conf host 127.0.0.1 base dc=informalians,dc=org ldap_version 3 port 389 scope sub timelimit 10 bind_timelimit 10 bind_policy soft nss_connect_policy oneshot idle_timelimit 300 nss_paged_results yes pagesize 1000 nss_base_passwd dc=informalians,dc=org?sub nss_base_group dc=informalians,dc=org?sub nss_base_passwd dc=informalians,dc=org?sub nss_base_shadow dc=informalians,dc=org?sub ssl off nsswitch.conf passwd: files ldap shadow: files ldap group: files ldap hosts: files dns networks: files services: files shells: files protocols: files rpc: files passwd_compat: nis group_compat: nis services_compat: nis /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf -d 1 ######################################### ... slapd starting slap_listener_activate(6): >>> slap_listener(ldap:///) connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=0 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 10 do_bind: v3 anonymous bind slap_listener_activate(6): >>> slap_listener(ldap:///) slap_listener_activate(6): >>> slap_listener(ldap:///) connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next connection_get(11): got connid=1 connection_read(11): checking for input on id=1 ber_get_next ber_get_next: tag 0x30 len 167 contents: ber_get_next conn=0 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=informalians,dc=org> <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=1 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: ==> limits_get: conn=0 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") => hdb_dn2id("dc=informalians,dc=org") >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=1 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 11 connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next <= hdb_dn2id: got id=0x1 do_bind: v3 anonymous bind entry_decode: "" <= entry_decode() search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=7, last=7 bdb_search_candidates: id=1 first=7 last=7 entry_decode: "" <= entry_decode() => send_search_entry: conn 0 dn="cn=GOsa Administrators,ou=groups,dc=informalians,dc=org" ber_flush2: 139 bytes to sd 10 slap_listener_activate(6): >>> slap_listener(ldap:///) <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 51 bytes to sd 10 connection_get(11): got connid=1 connection_read(11): checking for input on id=1 ber_get_next ber_get_next: tag 0x30 len 167 contents: connection_get(14): got connid=3 ber_get_next connection_read(14): checking for input on id=3 ber_get_next conn=1 op=1 do_search ber_scanf fmt ({miiiib) ber: ber_get_next: tag 0x30 len 12 contents: ber_get_next: tag 0x30 len 12 contents: ber_get_next ber_get_next conn=3 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> conn=2 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=2 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 >>> dnPrettyNormal: <dc=informalians,dc=org> <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: do_bind: v3 anonymous bind ber_scanf fmt ({M}}) ber: slap_listener_activate(6): <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=3 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 14 >>> slap_listener(ldap:///) do_bind: v3 anonymous bind => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=1 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=7, last=7 bdb_search_candidates: id=1 first=7 last=7 => send_search_entry: conn 1 dn="cn=GOsa Administrators,ou=groups,dc=informalians,dc=org" ber_flush2: 139 bytes to sd 11 <= send_search_entry: conn 1 exit. send_ldap_result: conn=1 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 51 bytes to sd 11 connection_get(15): got connid=4 connection_read(15): checking for input on id=4 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=4 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=4 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 15 do_bind: v3 anonymous bind connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next ber_get_next: tag 0x30 len 167 contents: ber_get_next conn=2 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=informalians,dc=org> <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=2 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=7, last=7 bdb_search_candidates: id=1 first=7 last=7 => send_search_entry: conn 2 dn="cn=GOsa Administrators,ou=groups,dc=informalians,dc=org" ber_flush2: 139 bytes to sd 12 <= send_search_entry: conn 2 exit. send_ldap_result: conn=2 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 51 bytes to sd 12 connection_get(14): got connid=3 connection_read(14): checking for input on id=3 ber_get_next ber_get_next: tag 0x30 len 167 contents: ber_get_next conn=3 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=informalians,dc=org> connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=3 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read connection_get(15): got connid=4 connection_read(15): checking for input on id=4 ber_get_next ber_get_next: tag 0x30 len 167 contents: ber_get_next conn=4 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=informalians,dc=org> <<< dnPrettyNormal: <dc=informalians,dc=org>, <dc=informalians,dc=org> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: <= get_ctrls: n=1 rc=0 err="" ==> limits_get: conn=4 op=1 self="[anonymous]" this="dc=informalians,dc=org" => hdb_search bdb_dn2entry("dc=informalians,dc=org") search_candidates: base="dc=informalians,dc=org" (0x00000001) scope=2 => hdb_dn2idl("dc=informalians,dc=org") => bdb_equality_candidates (objectClass) => key_read zsh: segmentation fault /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf -d 1 -- Best regards Alexander Panyushkin

1 0

(ITS#6212) Assert raised by slapd using back-meta
by jorge.perez＠adaptia.net 14 Jul '09

14 Jul '09

Full_Name: Jorge Perez Burgos Version: 2.4.17pre OS: SLES 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.20) An assert raises using back-meta using REL2_4 in cvs. Sometimes, less often, all threads lock at "ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );" in different parts of back-meta maybe it's related. (gdb) bt #0 0x00002ac209105d45 in raise () from /lib64/libc.so.6 #1 0x00002ac209107140 in abort () from /lib64/libc.so.6 #2 0x00002ac2090ff286 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000005b6836 in ldap_sasl_bind (ld=0x0, dn=0x94b2b0 "cn=manager,dc=operator,dc=com", mechanism=0x0, cred=0x4f5fa3a0, sctrls=0x0, cctrls=0x0, msgidp=0x4f5fa398) at sasl.c:74 #4 0x00000000005695be in meta_back_proxy_authz_bind (mc=0x18e8a60, candidate=2, op=0x2aaae262f380, rs=0x4f5fbd30, sendok=LDAP_BACK_DONTSEND) at bind.c:1526 #5 0x0000000000567379 in meta_back_single_dobind (op=0x2aaae262f380, rs=0x4f5fbd30, mcp=0x4f5fa4d8, candidate=2, sendok=LDAP_BACK_DONTSEND, nretries=10, dolock=1) at bind.c:600 #6 0x000000000056774e in meta_back_dobind (op=0x2aaae262f380, rs=0x4f5fbd30, mc=0x18e8a60, sendok=LDAP_BACK_SENDERR) at bind.c:718 #7 0x0000000000509e5d in meta_back_modify (op=0x2aaae262f380, rs=0x4f5fbd30) at modify.c:54 #8 0x000000000048b2ba in fe_op_modify (op=0x2aaae262f380, rs=0x4f5fbd30) at modify.c:301 #9 0x00000000004f51e6 in overlay_op_walk (op=0x2aaae262f380, rs=0x4f5fbd30, which=op_modify, oi=0x84a430, on=0x0) at backover.c:669 #10 0x00000000004f53e9 in over_op_func (op=0x2aaae262f380, rs=0x4f5fbd30, which=op_modify) at backover.c:721 #11 0x00000000004f54c7 in over_op_modify (op=0x2aaae262f380, rs=0x4f5fbd30) at backover.c:755 #12 0x000000000048abc8 in do_modify (op=0x2aaae262f380, rs=0x4f5fbd30) at modify.c:175 #13 0x000000000046bb42 in connection_operation (ctx=0x4f5fbe70, arg_v=0x2aaae262f380) at connection.c:1115 #14 0x000000000046c0c7 in connection_read_thread (ctx=0x4f5fbe70, argv=0x191) at connection.c:1251 #15 0x00000000005acefa in ldap_int_thread_pool_wrapper (xpool=0x81ec60) at tpool.c:698 #16 0x00002ac208594143 in start_thread () from /lib64/libpthread.so.0 #17 0x00002ac209196b8d in clone () from /lib64/libc.so.6 #18 0x0000000000000000 in ?? () (gdb)

1 0

Re: (ITS#6211) Build error: LDAP_VLV_ERROR
by hyc＠symas.com 13 Jul '09

13 Jul '09

Oops, forgot a commit. Fixed. michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD synced now > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.59.27) > > > Entering subdirectory libldap > make[2]: Entering directory > `/usr/src/michael/openldap/HEAD/openldap/libraries/libldap' > /bin/sh ../../libtool --mode=compile cc -g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER > -DDEVEL -I../../include -I../../include -I/dummy/include > -I/dummy/include -I/dummy/include -I/dummy/include -DSLAP_LIGHTWEIGHT_DISPATCHER > -DDEVEL -DLDAP_LIBRARY -c error.c > cc -g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -I../../include -I../../include > -I/dummy/include -I/dummy/include -I/dummy/include -I/dummy/include > -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -DLDAP_LIBRARY -c error.c -fPIC -DPIC -o > .libs/error.o > error.c: In function ldap_err2string: > error.c:90: error: LDAP_VLV_ERROR undeclared (first use in this function) > error.c:90: error: (Each undeclared identifier is reported only once > error.c:90: error: for each function it appears in.) > make[2]: *** [error.lo] Error 1 > make[2]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/libraries/libldap' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/libraries' > make: *** [all-common] Error 1 > > -- -- 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#6211) Build error: LDAP_VLV_ERROR� undeclared
by michael＠stroeder.com 13 Jul '09

13 Jul '09

Full_Name: Michael Ströder Version: HEAD synced now OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.59.27) Entering subdirectory libldap make[2]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/libraries/libldap' /bin/sh ../../libtool --mode=compile cc -g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -I../../include -I../../include -I/dummy/include -I/dummy/include -I/dummy/include -I/dummy/include -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -DLDAP_LIBRARY -c error.c cc -g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -I../../include -I../../include -I/dummy/include -I/dummy/include -I/dummy/include -I/dummy/include -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL -DLDAP_LIBRARY -c error.c -fPIC -DPIC -o .libs/error.o error.c: In function ldap_err2string: error.c:90: error: LDAP_VLV_ERROR undeclared (first use in this function) error.c:90: error: (Each undeclared identifier is reported only once error.c:90: error: for each function it appears in.) make[2]: *** [error.lo] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6209) openldap-snacc 2.3.6 + gcc4.4.0
by hyc＠symas.com 13 Jul '09

13 Jul '09

Closing this ITS as a duplicate of #4699 ivan.kovalenko(a)gmail.com wrote: > Full_Name: Ivan Kovalenko > Version: openldap-snacc 2.3.6 > OS: RHAS4u3 i686 > URL: > Submission from: (NULL) (217.74.34.30) > > > When compiling openldap-snacc 2.3.6 using gcc 4.4.0 an varios errors comes out > > http://ivanko.pastebin.com/f5741d572 > > So, one by one > a) bits/fpos.h not found - changed it into ios in inc/asn-chartraits.h > b) rfc1155-smi.c - i've entirely removed c-examples and c++-examples from > makefile - no chance i'd resolve those errors > c) there were some errors after correcting a) like > http://ivanko.pastebin.com/f45802da6 - also cant handle it correctly. > > System info > [ivanko@vm-ivanko openldap-2.4.16]$ uname -a; gcc -v; env|egrep '(FLAGS|LD)' > Linux vm-ivanko.rosenergo.com 2.6.9-78.EL #1 Wed Jul 9 15:27:01 EDT 2008 i686 > i686 i386 GNU/Linux > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: ./configure --prefix=/home/ivanko/local/usr/ > --with-mpfr=/home/ivanko/local/usr --with-gmp=/home/ivanko/local/usr/ > --enable-languages=c,c++,java,objc > Thread model: posix > gcc version 4.4.0 (GCC) > LDFLAGS=-I/home/ivanko/local/usr/lib > CPPFLAGS=-I/home/ivanko/local/usr/include/ > OLDPWD=/u2/ivanko/0/t/openldap-snacc-2.3.6 > LD_LIBRARY_PATH=/home/ivanko/local/usr/lib > > -- -- 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#6210) comp_match module
by ivan.kovalenko＠gmail.com 13 Jul '09

13 Jul '09

Full_Name: Ivan Kovalenko Version: 2.4.16 OS: RHAS4u3 i686 URL: Submission from: (NULL) (217.74.34.30) When running tests om comp_match module test031 (openldap-2.4.16 with enable-modules=yes with gcc3.4.5) Can see this after installing comp_match module into tests dir. slapadd init: initiated tool. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) lt_dlopenext failed: (./testdata/comp_libs/compmatch.la) ./testdata/comp_libs/compmatch.so.0: undefined symbol: BEncAsnOcts

1 0

(ITS#6209) openldap-snacc 2.3.6 + gcc4.4.0
by ivan.kovalenko＠gmail.com 12 Jul '09

12 Jul '09

Full_Name: Ivan Kovalenko Version: openldap-snacc 2.3.6 OS: RHAS4u3 i686 URL: Submission from: (NULL) (217.74.34.30) When compiling openldap-snacc 2.3.6 using gcc 4.4.0 an varios errors comes out http://ivanko.pastebin.com/f5741d572 So, one by one a) bits/fpos.h not found - changed it into ios in inc/asn-chartraits.h b) rfc1155-smi.c - i've entirely removed c-examples and c++-examples from makefile - no chance i'd resolve those errors c) there were some errors after correcting a) like http://ivanko.pastebin.com/f45802da6 - also cant handle it correctly. System info [ivanko@vm-ivanko openldap-2.4.16]$ uname -a; gcc -v; env|egrep '(FLAGS|LD)' Linux vm-ivanko.rosenergo.com 2.6.9-78.EL #1 Wed Jul 9 15:27:01 EDT 2008 i686 i686 i386 GNU/Linux Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/home/ivanko/local/usr/ --with-mpfr=/home/ivanko/local/usr --with-gmp=/home/ivanko/local/usr/ --enable-languages=c,c++,java,objc Thread model: posix gcc version 4.4.0 (GCC) LDFLAGS=-I/home/ivanko/local/usr/lib CPPFLAGS=-I/home/ivanko/local/usr/include/ OLDPWD=/u2/ivanko/0/t/openldap-snacc-2.3.6 LD_LIBRARY_PATH=/home/ivanko/local/usr/lib

1 0

Re: (ITS#6208) Timelimit exceeded error when using unlimited timelimits
by quanah＠zimbra.com 10 Jul '09

10 Jul '09

--On Friday, July 10, 2009 7:46 PM +0000 quanah(a)zimbra.com wrote: > So it looks like OpenLDAP has a hard coded 1 hour time limit. Which, of > course, is not correct. Of course, this search shouldn't take an hour, > either. Never mind, there appears to be an issue in the SASL binding so that my account isn't getting correctly mapped. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6208) Timelimit exceeded error when using unlimited timelimits
by quanah＠zimbra.com 10 Jul '09

10 Jul '09

--On Friday, July 10, 2009 6:49 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I executed the following search: > ldap-uat1:/etc/ldap# ldapsearch -LLL -Q -h ldap-uat1 -b > "dc=stanford,dc=edu" >> /dev/null > > Which ended with this error: > Time limit exceeded (3) A second run hit the same error: ldap-uat1:/root# time ldapsearch -LLL -Q -h ldap-uat1 -b "dc=stanford,dc=edu" >/dev/null Time limit exceeded (3) real 60m1.827s user 0m0.008s sys 0m0.004s So it looks like OpenLDAP has a hard coded 1 hour time limit. Which, of course, is not correct. Of course, this search shouldn't take an hour, either. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6208) Timelimit exceeded error when using unlimited timelimits
by quanah＠zimbra.com 10 Jul '09

10 Jul '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I executed the following search: ldap-uat1:/etc/ldap# ldapsearch -LLL -Q -h ldap-uat1 -b "dc=stanford,dc=edu" >/dev/null Which ended with this error: Time limit exceeded (3) Which should never happen, because my bind ID is part of the ldapadmin group, which is allowed to make searches completely free of time or sizelimit restrictions: # Let ldapadmin have limitless searches limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 09 Jul '09

09 Jul '09

On Thu, Jul 9, 2009 at 9:55 PM, Quanah Gibson-Mount<quanah(a)zimbra.com> wrot= e:. > > I think you mean compiling --with-debug, as opposed to debug symbols (-g = to > gcc). =C2=A0All asserts get added to the code path if you build with > --with-debug, but that is not the same as having debug symbols (which is > generally good practice to have available). Exactly, depends on the testing phase, the slapd are compiled with-debug and -g or it's not compiled with-debug and it's stripped. Regards

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 09 Jul '09

09 Jul '09

--On Thursday, July 09, 2009 9:23 AM +0000 jorge.perez(a)adaptia.net wrote: > The last testing was wrong due to an old slapd.conf without > writetimeout keyword, my apologies. We have been testing for 2 days to > reproduce this problem and we have not seen the problem again, even > though with debug symbols the assert ""assert( SLAP_SOCK_IS_ACTIVE( s > ))"" still fails. I think you mean compiling --with-debug, as opposed to debug symbols (-g to gcc). All asserts get added to the code path if you build with --with-debug, but that is not the same as having debug symbols (which is generally good practice to have available). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#6201) Double free in syncprov
by quanah＠zimbra.com 09 Jul '09

09 Jul '09

--On Thursday, July 09, 2009 10:18 AM +0000 Alister.Winfield(a)sns.bskyb.com wrote: > I think I have it (bad configuration)... > > Okay so it might be a configuration 'error' but I guess its worth trying > to= avoid the crash. Hi Alister, Can you provide an example of your misconfigured slapd for ease of debugging? Obviously, this is non-critical but I agree it would be nice to make sure this sort of configuration error is caught more gracefully. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6207) Build farm
by ghenry＠OpenLDAP.org 09 Jul '09

09 Jul '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Build farm should be complete by now.

1 0

(ITS#6206) Admin guide appendices or tools in contrib should be better than Ubuntu docs
by ghenry＠OpenLDAP.org 09 Jul '09

09 Jul '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Must beat or match: https://help.ubuntu.com/9.04/serverguide/C/openldap-server.html

1 0

(ITS#6205) Discuss slapadd -S in Admin guide appendix
by ghenry＠OpenLDAP.org 09 Jul '09

09 Jul '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry As per http://www.openldap.org/lists/openldap-bugs/200809/msg00140.html

1 0

(ITS#6204) General upgrade procedure missing from Admin guide
by ghenry＠OpenLDAP.org 09 Jul '09

09 Jul '09

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Documenting this procedure should be in the Admin Guide like http://www.openldap.org/faq/index.cgi?file=842 Gavin.

1 0

Re: (ITS#6202) adding command line option to disable line breaking in ldif output
by dieter＠bloms.de 09 Jul '09

09 Jul '09

Hi, On Thu, Jul 09, Michael Str=F6der wrote: > > I want to do an enhancement request for ldapsearch, because it insert a= line > > break after 78 characters. > > Many people like me use the ldapsearch command in shell script and have= to > > workaround this issue. > > Maybe it make sense to add a command line option to deactivate this lin= e breaks. >=20 > I'd rather recommend to use a decent scripting language with LDAP and/or > LDIF modules than using ldapsearch in shell scripts. This gives better > control over data and error handling. there are several ldapsearch binaries from other distributor, which includes an option -T for this concern. http://www.koders.com/c/fidD1B671B4DA7CB116CA077E4694EEBAE167D3F85E.aspx http://docs.sun.com/source/816-6400-10/lsearch.html =2E.. so why doesn't ldapsearch from openldap inlcude this option. It doesn't break any rfc and historcal implementation and as far as I can see (with google), there are many admins who have to workaround this with a little perl script. I think it must be a little diff, with a few lines I can write it, but is someone willing to inlcude it in the upstream versions ? --=20 Gru=DF Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the =46rom field.

1 0

Re: (ITS#6202) adding command line option to disable line breaking in ldif output
by michael＠stroeder.com 09 Jul '09

09 Jul '09

openldap.org(a)bloms.de wrote: > Full_Name: Dieter Bloms > Version: all > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.27.50.90) > > > I want to do an enhancement request for ldapsearch, because it insert a line > break after 78 characters. > Many people like me use the ldapsearch command in shell script and have to > workaround this issue. > Maybe it make sense to add a command line option to deactivate this line breaks. I'd rather recommend to use a decent scripting language with LDAP and/or LDIF modules than using ldapsearch in shell scripts. This gives better control over data and error handling. Ciao, Michael.

1 0

(ITS#6203)
by Andrew.Morgan＠Sun.COM 09 Jul '09

09 Jul '09

wait_until_ready is documented here: http://dev.mysql.com/doc/ndbapi/en/class-ndb-cluster-connection-methods.html #class-ndb-cluster-connection-wait-until-ready -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 09 July 2009 14:51 To: Andrew.Morgan(a)Sun.COM Subject: Re: (ITS#6203) Problem & solution for back-ndb issue connecting to Cluster data nodes *** 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#6203. 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#6203) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#6203) 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=6203 Please remember to retain your issue tracking number (ITS#6203) 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs