- openldap-bugs - openldap.org

Problem to connect à LDAP server
by rodrigue Boyom 04 Dec '07

04 Dec '07

Hi , i m a technician of computer science and telecommunication.I have some problem when i configure LDAP server on RedHat 9.0 this a bugs i have when i want cretead a password to connect a LDAP server please help me : root@serveur root]# ldappasswd -s danse SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error [root@serveur root]#

2 1

SIGSEGV in slap_auxprop_store during SASL/OTP bind
by Dan White 04 Dec '07

04 Dec '07

I'm experiencing crashes in slapd when attempting to bind via SASL using the OTP mech. I'm using openldap version 2.3.39 for both slapd and my ldap utils (ldapsearch). I'm using the bdb backend. I'm also using Debian Etch with the following versions of software: Cyrus SASL 2.1.22(.dfsg1-8) libdb 4.2.52(+dfsg-2) libc6 2.3.6(.ds1-13etch2) I've compiled cyrus sasl to use it's internal implementation of OTP, rather than OPIE: --enable-otp (--with-opie is not enabled) The problem I'm experiencing isn't when I successfully authenticate; that seems to work fine. It's when I run an ldapsearch, but instead of entering an OTP password, I press ctrl-c to cancel the search. From the shell, when I perform an LDAP search, all appears normal: hiro:~# ldapsearch -Y OTP -U abrown(a)olp.net SASL/OTP authentication started Challenge: otp-md5 497 hi3182 ext Please enter your one-time password:<ctrl-c> hiro:~# However my slapd process dies. Here's a gdb backtrace of the server process: ... Core was generated by `/usr/sbin/slapd'. Program terminated with signal 11, Segmentation fault. #0 0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0, prctx=0x82351c0, user=0x820a148 "abrown(a)olp.net", ulen=14) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478 478 op.o_hdr = conn->c_sasl_bindop->o_hdr; (gdb) bt #0 0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0, prctx=0x82351c0, user=0x820a148 "abrown(a)olp.net", ulen=14) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478 #1 0xb7eb17d7 in sasl_auxprop_store () from /usr/lib/libsasl2.so.2 #2 0xb7973c89 in otp_server_plug_init () from /usr/lib/sasl2/libotp.so.2 #3 0xb7ebde36 in sasl_server_new () from /usr/lib/libsasl2.so.2 #4 0xb7eb6194 in sasl_dispose () from /usr/lib/libsasl2.so.2 #5 0x080b2992 in slap_sasl_close (conn=0xb7ec3618) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:1331 #6 0x0806cf27 in connection_close (c=0xb75b1148) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:715 #7 0x0806e116 in connection_read (s=12) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:1458 #8 0x0806a49f in slapd_daemon_task (ptr=0x0) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/daemon.c:2468 #9 0xb7cd3240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7c674ae in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) quit I've added a debug statement within slap_auxprop_store, so the openldap debug information below will include some additional information about what's being modified. Here's output from an attempt that crashed (when I pressed ctrl-c in my ldapsearch): Dec 3 13:39:06 hiro slapd[11134]: daemon: activity on 1 descriptor Dec 3 13:39:06 hiro slapd[11134]: daemon: activity on: Dec 3 13:39:06 hiro slapd[11134]: Dec 3 13:39:06 hiro slapd[11134]: >>> slap_listener(ldapi:///) Dec 3 13:39:06 hiro slapd[11134]: daemon: listen=12, new connection on 16 Dec 3 13:39:06 hiro slapd[11134]: daemon: added 16r (active) listener=(nil) Dec 3 13:39:06 hiro slapd[11134]: conn=3 fd=16 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=12 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: daemon: activity on 1 descriptor Dec 3 13:39:06 hiro slapd[11134]: daemon: activity on: Dec 3 13:39:06 hiro slapd[11134]: 16r Dec 3 13:39:06 hiro slapd[11134]: Dec 3 13:39:06 hiro slapd[11134]: daemon: read active on 16 Dec 3 13:39:06 hiro slapd[11134]: connection_get(16) Dec 3 13:39:06 hiro slapd[11134]: connection_get(16): got connid=3 Dec 3 13:39:06 hiro slapd[11134]: connection_read(16): checking for input on id=3 Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: do_bind Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: >>> dnPrettyNormal: <> Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: <<< dnPrettyNormal: <>, <> Dec 3 13:39:06 hiro slapd[11134]: daemon: epoll: listen=12 active_threads=0 tvp=NULL Dec 3 13:39:06 hiro slapd[11134]: do_sasl_bind: dn () mech OTP Dec 3 13:39:06 hiro slapd[11134]: conn=3 op=0 BIND dn="" method=163 Dec 3 13:39:06 hiro slapd[11134]: ==> sasl_bind: dn="" mech=OTP datalen=29 Dec 3 13:39:06 hiro slapd[11134]: SASL Canonicalize [conn=3]: authcid="abrown(a)olp.net" Dec 3 13:39:06 hiro slapd[11134]: slap_sasl_getdn: conn 3 id=abrown(a)olp.net [len=14] Dec 3 13:39:06 hiro slapd[11134]: slap_sasl_getdn: u:id converted to uid=abrown(a)olp.net,cn=OTP,cn=auth Dec 3 13:39:06 hiro slapd[11134]: >>> dnNormalize: <uid=abrown(a)olp.net,cn=OTP,cn=auth> Dec 3 13:39:06 hiro slapd[11134]: <<< dnNormalize: <uid=abrown(a)olp.net,cn=otp,cn=auth> Dec 3 13:39:06 hiro slapd[11134]: ==>slap_sasl2dn: converting SASL name uid=abrown(a)olp.net,cn=otp,cn=auth to a DN Dec 3 13:39:06 hiro slapd[11134]: slap_authz_regexp: converting SASL name uid=abrown(a)olp.net,cn=otp,cn=auth Dec 3 13:39:06 hiro slapd[11134]: slap_authz_regexp: converted SASL name to ldap:///ou=people,dc=olp,dc=net??one?(btcAltUid=abrown@olp.net) Dec 3 13:39:06 hiro slapd[11134]: slap_parseURI: parsing ldap:///ou=people,dc=olp,dc=net??one?(btcAltUid=abrown@olp.net) Dec 3 13:39:06 hiro slapd[11134]: str2filter "(btcAltUid=abrown(a)olp.net)" Dec 3 13:39:06 hiro slapd[11134]: begin get_filter Dec 3 13:39:06 hiro slapd[11134]: EQUALITY Dec 3 13:39:06 hiro slapd[11134]: end get_filter 0 Dec 3 13:39:06 hiro slapd[11134]: >>> dnNormalize: <ou=people,dc=olp,dc=net> Dec 3 13:39:06 hiro slapd[11134]: <<< dnNormalize: <ou=people,dc=olp,dc=net> Dec 3 13:39:06 hiro slapd[11134]: slap_sasl2dn: performing internal search (base=ou=people,dc=olp,dc=net, scope=1) Dec 3 13:39:06 hiro slapd[11134]: => bdb_search Dec 3 13:39:06 hiro slapd[11134]: bdb_dn2entry("ou=people,dc=olp,dc=net") Dec 3 13:39:06 hiro slapd[11134]: search_candidates: base="ou=people,dc=olp,dc=net" (0x00000003) scope=1 Dec 3 13:39:06 hiro slapd[11134]: => bdb_dn2idl("ou=people,dc=olp,dc=net") Dec 3 13:39:06 hiro slapd[11134]: bdb_idl_fetch_key: %ou=people,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: <= bdb_dn2idl: id=68 first=7 last=136 Dec 3 13:39:06 hiro slapd[11134]: => bdb_filter_candidates Dec 3 13:39:06 hiro slapd[11134]: ^IAND Dec 3 13:39:06 hiro slapd[11134]: => bdb_list_candidates 0xa0 Dec 3 13:39:06 hiro slapd[11134]: => bdb_filter_candidates Dec 3 13:39:06 hiro slapd[11134]: ^IOR Dec 3 13:39:06 hiro slapd[11134]: => bdb_list_candidates 0xa1 Dec 3 13:39:06 hiro slapd[11134]: => bdb_filter_candidates Dec 3 13:39:06 hiro slapd[11134]: ^IEQUALITY Dec 3 13:39:06 hiro slapd[11134]: => bdb_equality_candidates (objectClass) Dec 3 13:39:06 hiro slapd[11134]: => key_read Dec 3 13:39:06 hiro slapd[11134]: bdb_idl_fetch_key: [b49d1940] Dec 3 13:39:06 hiro slapd[11134]: <= bdb_index_read: failed (-30990) Dec 3 13:39:06 hiro slapd[11134]: <= bdb_equality_candidates: id=0, first=0, last=0 Dec 3 13:39:06 hiro slapd[11134]: <= bdb_filter_candidates: id=0 first=0 last=0 Dec 3 13:39:06 hiro slapd[11134]: => bdb_filter_candidates Dec 3 13:39:06 hiro slapd[11134]: ^IEQUALITY Dec 3 13:39:06 hiro slapd[11134]: => bdb_equality_candidates (btcAltUID) Dec 3 13:39:06 hiro slapd[11134]: => key_read Dec 3 13:39:06 hiro slapd[11134]: bdb_idl_fetch_key: [b0f0ea63] Dec 3 13:39:06 hiro slapd[11134]: <= bdb_index_read 1 candidates Dec 3 13:39:06 hiro slapd[11134]: <= bdb_equality_candidates: id=1, first=7, last=7 Dec 3 13:39:06 hiro slapd[11134]: <= bdb_filter_candidates: id=1 first=7 last=7 Dec 3 13:39:06 hiro slapd[11134]: <= bdb_list_candidates: id=1 first=7 last=7 Dec 3 13:39:06 hiro slapd[11134]: <= bdb_filter_candidates: id=1 first=7 last=7 Dec 3 13:39:06 hiro slapd[11134]: <= bdb_list_candidates: id=1 first=7 last=7 Dec 3 13:39:06 hiro slapd[11134]: <= bdb_filter_candidates: id=1 first=7 last=7 Dec 3 13:39:06 hiro slapd[11134]: bdb_search_candidates: id=1 first=7 last=7 Dec 3 13:39:06 hiro slapd[11134]: => test_filter Dec 3 13:39:06 hiro slapd[11134]: EQUALITY Dec 3 13:39:06 hiro slapd[11134]: => access_allowed: auth access to "uid=abrown(a)olp.net,ou=People,dc=olp,dc=net" "btcAltUID" requested Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [1] ou=addressbooks,uid=([^,]+),ou=people,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [2] .*,ou=addressbooks,uid=([^,]+),ou=people,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dn: [3] ou=people,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => dn: [4] ou=groups,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => acl_get: [7] attr btcAltUID Dec 3 13:39:06 hiro slapd[11134]: => acl_mask: access to entry "uid=abrown(a)olp.net,ou=People,dc=olp,dc=net", attr "btcAltUID" requested Dec 3 13:39:06 hiro slapd[11134]: => acl_mask: to value by "", (=0) Dec 3 13:39:06 hiro slapd[11134]: <= check a_dn_pat: anonymous Dec 3 13:39:06 hiro slapd[11134]: <= acl_mask: [1] applying auth(=xd) (stop) Dec 3 13:39:06 hiro slapd[11134]: <= acl_mask: [1] mask: auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: => slap_access_allowed: auth access granted by auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: => access_allowed: auth access granted by auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: <= test_filter 6 Dec 3 13:39:06 hiro slapd[11134]: send_ldap_result: conn=3 op=0 p=3 Dec 3 13:39:06 hiro slapd[11134]: send_ldap_result: err=0 matched="" text="" Dec 3 13:39:06 hiro slapd[11134]: <==slap_sasl2dn: Converted SASL name to uid=abrown(a)olp.net,ou=people,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: slap_sasl_getdn: dn:id converted to uid=abrown(a)olp.net,ou=people,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: SASL Canonicalize [conn=3]: slapAuthcDN="uid=abrown(a)olp.net,ou=people,dc=olp,dc=net" Dec 3 13:39:06 hiro slapd[11134]: => bdb_search Dec 3 13:39:06 hiro slapd[11134]: bdb_dn2entry("uid=abrown(a)olp.net,ou=people,dc=olp,dc=net") Dec 3 13:39:06 hiro slapd[11134]: base_candidates: base: "uid=abrown(a)olp.net,ou=people,dc=olp,dc=net" (0x00000007) Dec 3 13:39:06 hiro slapd[11134]: => test_filter Dec 3 13:39:06 hiro slapd[11134]: PRESENT Dec 3 13:39:06 hiro slapd[11134]: => access_allowed: auth access to "uid=abrown(a)olp.net,ou=People,dc=olp,dc=net" "objectClass" requested Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [1] ou=addressbooks,uid=([^,]+),ou=people,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [2] .*,ou=addressbooks,uid=([^,]+),ou=people,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dn: [3] ou=people,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => dn: [4] ou=groups,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [12] .*n=([^,]+),ou=groups,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [13] .*n=([^,]+),ou=groups,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [14] ^cn=admin,cn=([^,]+),ou=groups,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [15] ^cn=([^,]+),ou=groups,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [16] ^cn=admin,cn=([^,]+),ou=groups,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => acl_get: [17] attr objectClass Dec 3 13:39:06 hiro slapd[11134]: => acl_mask: access to entry "uid=abrown(a)olp.net,ou=People,dc=olp,dc=net", attr "objectClass" requested Dec 3 13:39:06 hiro slapd[11134]: => acl_mask: to all values by "", (=0) Dec 3 13:39:06 hiro slapd[11134]: <= check a_dn_pat: self Dec 3 13:39:06 hiro slapd[11134]: <= check a_dn_pat: anonymous Dec 3 13:39:06 hiro slapd[11134]: <= acl_mask: [8] applying auth(=xd) (stop) Dec 3 13:39:06 hiro slapd[11134]: <= acl_mask: [8] mask: auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: => slap_access_allowed: auth access granted by auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: => access_allowed: auth access granted by auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: <= test_filter 6 Dec 3 13:39:06 hiro slapd[11134]: => access_allowed: auth access to "uid=abrown(a)olp.net,ou=People,dc=olp,dc=net" "cmusaslsecretOTP" requested Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [1] ou=addressbooks,uid=([^,]+),ou=people,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [2] .*,ou=addressbooks,uid=([^,]+),ou=people,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dn: [3] ou=people,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => dn: [4] ou=groups,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => acl_get: [8] attr cmusaslsecretOTP Dec 3 13:39:06 hiro slapd[11134]: => acl_mask: access to entry "uid=abrown(a)olp.net,ou=People,dc=olp,dc=net", attr "cmusaslsecretOTP" requested Dec 3 13:39:06 hiro slapd[11134]: => acl_mask: to all values by "", (=0) Dec 3 13:39:06 hiro slapd[11134]: <= check a_dn_pat: anonymous Dec 3 13:39:06 hiro slapd[11134]: <= acl_mask: [1] applying auth(=xd) (stop) Dec 3 13:39:06 hiro slapd[11134]: <= acl_mask: [1] mask: auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: => slap_access_allowed: auth access granted by auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: => access_allowed: auth access granted by auth(=xd) Dec 3 13:39:06 hiro slapd[11134]: send_ldap_result: conn=3 op=0 p=3 Dec 3 13:39:06 hiro slapd[11134]: send_ldap_result: err=0 matched="" text="" Dec 3 13:39:06 hiro slapd[11134]: SASL Canonicalize [conn=3]: authzid="abrown(a)olp.net" Dec 3 13:39:06 hiro slapd[11134]: slap_auxprop_store [conn=3]: Getting ready to set cmusaslsecretOTP to md5^I0499^Ihi5935^I0e81b33e30182715^I00000000001196711046. Dec 3 13:39:06 hiro slapd[11134]: bdb_modify: uid=abrown(a)olp.net,ou=people,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: bdb_dn2entry("uid=abrown(a)olp.net,ou=people,dc=olp,dc=net") Dec 3 13:39:06 hiro slapd[11134]: bdb_modify_internal: 0x00000007: uid=abrown(a)olp.net,ou=People,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => access_allowed: delete access to "uid=abrown(a)olp.net,ou=People,dc=olp,dc=net" "cmusaslsecretOTP" requested Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [1] ou=addressbooks,uid=([^,]+),ou=people,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dnpat: [2] .*,ou=addressbooks,uid=([^,]+),ou=people,dc=olp,dc=net$ nsub: 1 Dec 3 13:39:06 hiro slapd[11134]: => dn: [3] ou=people,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => dn: [4] ou=groups,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: => acl_get: [8] attr cmusaslsecretOTP Dec 3 13:39:06 hiro slapd[11134]: => slap_access_allowed: no res from state (cmusaslsecretOTP) Dec 3 13:39:06 hiro slapd[11134]: => acl_mask: access to entry "uid=abrown(a)olp.net,ou=People,dc=olp,dc=net", attr "cmusaslsecretOTP" requested Dec 3 13:39:06 hiro slapd[11134]: => acl_mask: to all values by "uid=abrown(a)olp.net,ou=people,dc=olp,dc=net", (=0) Dec 3 13:39:06 hiro slapd[11134]: <= check a_dn_pat: anonymous Dec 3 13:39:06 hiro slapd[11134]: <= check a_dn_pat: self Dec 3 13:39:06 hiro slapd[11134]: <= acl_mask: [2] applying write(=wrscxd) (stop) Dec 3 13:39:06 hiro slapd[11134]: <= acl_mask: [2] mask: write(=wrscxd) Dec 3 13:39:06 hiro slapd[11134]: => slap_access_allowed: delete access granted by write(=wrscxd) Dec 3 13:39:06 hiro slapd[11134]: => access_allowed: delete access granted by write(=wrscxd) Dec 3 13:39:06 hiro slapd[11134]: acl: internal mod entryCSN: modify access granted Dec 3 13:39:06 hiro slapd[11134]: acl: internal mod modifiersName: modify access granted Dec 3 13:39:06 hiro slapd[11134]: acl: internal mod modifyTimestamp: modify access granted Dec 3 13:39:06 hiro slapd[11134]: bdb_modify_internal: replace cmusaslsecretOTP Dec 3 13:39:06 hiro slapd[11134]: bdb_modify_internal: replace entryCSN Dec 3 13:39:06 hiro slapd[11134]: bdb_modify_internal: replace modifiersName Dec 3 13:39:06 hiro slapd[11134]: bdb_modify_internal: replace modifyTimestamp Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "account" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "posixAccount" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "shadowAccount" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "krb5KDCEntry" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "krb5Principal" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "sambaSamAccount" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "radiusprofile" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "btcAuthUser" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "cmuSaslUser" Dec 3 13:39:06 hiro slapd[11134]: oc_check_required entry (uid=abrown(a)olp.net,ou=People,dc=olp,dc=net), objectClass "pkiUser" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "uid" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "cn" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "uidNumber" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "gidNumber" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "homeDirectory" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "loginShell" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "shadowMin" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "shadowMax" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "shadowWarning" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "shadowExpire" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "gecos" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "structuralObjectClass" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "entryUUID" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "creatorsName" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "createTimestamp" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "krb5PrincipalName" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "krb5MaxLife" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "krb5MaxRenew" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "krb5KDCFlags" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "sambaSID" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "sambaAcctFlags" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "sambaPrimaryGroupSID" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "shadowLastChange" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "radiusGroupName" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "btcCertificatePassword" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "btcAltUID" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "UNDEFINED" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "userPassword" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "sambaPwdLastSet" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "sambaLMPassword" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "sambaNTPassword" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "krb5KeyVersionNumber" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "krb5Key" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "UNDEFINED" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "objectClass" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "UNDEFINED" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "cmusaslsecretOTP" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "entryCSN" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "modifiersName" Dec 3 13:39:06 hiro slapd[11134]: oc_check_allowed type "modifyTimestamp" Dec 3 13:39:06 hiro slapd[11134]: => entry_encode(0x00000007): uid=abrown(a)olp.net,ou=People,dc=olp,dc=net Dec 3 13:39:06 hiro slapd[11134]: bdb_modify: updated id=00000007 dn="uid=abrown(a)olp.net,ou=people,dc=olp,dc=net" Dec 3 13:39:06 hiro slapd[11134]: send_ldap_result: conn=3 op=0 p=3 Dec 3 13:39:06 hiro slapd[11134]: send_ldap_result: err=0 matched="" text="" Dec 3 13:39:06 hiro slapd[11134]: send_ldap_sasl: err=14 len=22 Dec 3 13:39:06 hiro slapd[11134]: send_ldap_response: msgid=1 tag=97 err=14 Dec 3 13:39:06 hiro slapd[11134]: conn=3 op=0 RESULT tag=97 err=14 text= Dec 3 13:39:06 hiro slapd[11134]: <== slap_sasl_bind: rc=14 Dec 3 13:39:07 hiro slapd[11134]: daemon: activity on 1 descriptor Dec 3 13:39:07 hiro slapd[11134]: daemon: activity on: Dec 3 13:39:07 hiro slapd[11134]: 16r Dec 3 13:39:07 hiro slapd[11134]: Dec 3 13:39:07 hiro slapd[11134]: daemon: read active on 16 Dec 3 13:39:07 hiro slapd[11134]: connection_get(16) Dec 3 13:39:07 hiro slapd[11134]: connection_get(16): got connid=3 Dec 3 13:39:07 hiro slapd[11134]: connection_read(16): checking for input on id=3 Dec 3 13:39:07 hiro slapd[11134]: ber_get_next on fd 16 failed errno=0 (Success) Dec 3 13:39:07 hiro slapd[11134]: connection_read(16): input error=-2 id=3, closing. Dec 3 13:39:07 hiro slapd[11134]: connection_closing: readying conn=3 sd=16 for close Dec 3 13:39:07 hiro slapd[11134]: connection_close: conn=3 sd=-1 Dec 3 13:39:07 hiro slapd[11134]: slap_auxprop_store [conn=-1]: Getting ready to set cmusaslsecretOTP to md5^I0499^Ihi5935^I0e81b33e30182715^I00000000000000000000. If I enter a good OTP password, I get this in my logs: Dec 3 13:43:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to set cmusaslsecretOTP to md5^I0499^Ihi5865^Iec8123986aec6550^I00000000001196711306. Dec 3 13:44:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to set cmusaslsecretOTP to md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000. If I enter an incorrect password, I get this: Dec 3 13:45:21 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to set cmusaslsecretOTP to md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000001196711421. Dec 3 13:45:22 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to set cmusaslsecretOTP to md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000. So in the case where it's crashing, it appears the Cyrus SASL is attempting to revert the OTP entry back to the previous version to "unlock" it. I assume that the connection id of '-1' is relevant to the crash. You should be able to reproduce this error with the following steps: Compile SASL with OTP, but without OPIE Configure a dummy SASL service configuration file, e.g.: hiro:~# cat > /usr/lib/sasl2/test.conf <<EOF > auxprop_plugin: ldapdb > ldapdb_uri: ldapi:/// > ldapdb_mech: EXTERNAL > EOF hiro:~# Create a schema including an attribute of cmusaslsecretOTP, and create an entry in the directory which can use this attribute. Configure slapd.conf with the appropriate sasl configuration to convert both the openldap user (connecting via ldapi:///) and the user specified in the ldapsearch, for example: sasl-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" cn=admin,dc=olp,dc=net sasl-regexp "uid=([^,]+),cn=otp,cn=auth" ldap:///ou=people,dc=olp,dc=net??one?(btcAltUid=$1) Issue a saslpasswd2 to initialize the cmusaslsecretOTP attribute for the user: hiro:~# saslpasswd2 -a test -n abrown(a)olp.net Password: Again (for verification): The cmusaslsecretOTP attribute should look something like: md5 0499 hi8351 1c19abc81f35dc63 00000000000000000000 opiekey can be used to convert the OTP challenge into the appropriate response. For instance: hiro:~# ldapsearch -Y OTP -U abrown(a)olp.net SASL/OTP authentication started Challenge: otp-md5 498 hi8351 ext Please enter your one-time password: Using opiekey to obtain response: dwhite@zek:~$ opiekey -5 -x 498 hi8351 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: 556A 99B3 52FA CEB1 Feed the secret pass phrase back into ldapsearch for a successful bind. To reproduce the bug, of course just kill the ldapsearch before entering any response. - Dan White BTC Broadband

2 1

Re: (ITS#5245) auditlog man page and feature request
by ghenry＠suretecsystems.com 04 Dec '07

04 Dec '07

<quote who="hyc(a)symas.com"> > ghenry(a)suretecsystems.com wrote: >> Hi, >> >> I've just committed my additions and being my first proper man page >> work, >> would someone be so kind as to check I'm using the right syntax. >> >> It looks and reads ok via man anyway. > > Looks OK, but your example shouldn't use olcModule. OpenLDAP doesn't > support > modules by default; anybody who enables module support should already have > read the docs for moduleload and modulepath. Ah, right. Will fix. Thanks.

1 0

Re: (ITS#5245) auditlog man page and feature request
by hyc＠symas.com 04 Dec '07

04 Dec '07

ghenry(a)suretecsystems.com wrote: > Hi, > > I've just committed my additions and being my first proper man page work, > would someone be so kind as to check I'm using the right syntax. > > It looks and reads ok via man anyway. Looks OK, but your example shouldn't use olcModule. OpenLDAP doesn't support modules by default; anybody who enables module support should already have read the docs for moduleload and modulepath. -- -- 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

i have problem with ldap
by francis kigmo 04 Dec '07

04 Dec '07

that is the message [root@localhost samba]# ldappasswd -s projet ldap_sasl_interactive_bind_s: No such attribute i need help

2 1

(ITS#5258) memberof-Overlay issue when deleting all values of the "memberof-member-ad" attribute
by rhafer＠suse.de 04 Dec '07

04 Dec '07

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.197.88) I use the following slapo-memberof config: memberof-group-oc mygroup memberof-member-ad mymember memberof-memberof-ad mymemberof where "mygroup" has "mymember" as an optional ('MAY') attribute. If I know remove all values of "mymember" from a "mygroup" object. With an operation like this: dn: <groupdn> changetype: modify delete: mymember The "mymemberof" Attributes of the associated objects are not updated accordingly.

1 0

Re: (ITS#5245) auditlog man page and feature request
by ghenry＠suretecsystems.com 03 Dec '07

03 Dec '07

Hi, I've just committed my additions and being my first proper man page work, would someone be so kind as to check I'm using the right syntax. It looks and reads ok via man anyway. Thanks, Gavin.

1 0

Re: (ITS#5256) encoding of guide.sdf
by dieter＠dkluenter.de 03 Dec '07

03 Dec '07

"Gavin Henry" <ghenry(a)suretecsystems.com> writes: > <quote who="dieter(a)dkluenter.de"> >> Full_Name: Dieter Kluenter >> Version: REL_ENG_2_4 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.202.173) >> >> >> Hi, >> the guide *.sdf files are UTF-8 encoded, but the online availeable HTML >> files >> seem to be iso8859-1 encoded, which leeds to display errors, an example is >> part >> 9.2.1. >> ... proxyâs efficiency ... > > Is this something I can fix, or is it part of the doc build for the main > site? Whoever is compiling the *.sdf files and putting the result online, so I think it is part of the doc build process. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5257) test008 hanging in bdb
by h.b.furuseth＠usit.uio.no 03 Dec '07

03 Dec '07

I should have appended a 'backtrace full', not just backtrace. Here: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth2-071203.bz2 (Stange, my submitted ITS isn't arriving though the confirmation message did. Hopefully ITS will pick this "reply" up anyway...) -- Hallvard

1 0

(ITS#5257) test008 hanging in bdb
by h.b.furuseth＠usit.uio.no 03 Dec '07

03 Dec '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-071203.tbz Submission from: (NULL) (129.240.6.233) Submitted by: hallvard test008 is hanging. slapd_daemon_task is waiting in epoll_wait(), main in pthread_join(), all other threads in bdb. Backtrace, output and testrun attached. I can reattach with gdb and check further, if someone says what to check.

1 0

Re: (ITS#5256) encoding of guide.sdf
by ghenry＠suretecsystems.com 02 Dec '07

02 Dec '07

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> ghenry(a)suretecsystems.com wrote: >>> <quote who="dieter(a)dkluenter.de"> >>>> Hi, >>>> the guide *.sdf files are UTF-8 encoded, but the online availeable HTML >>>> files >>>> seem to be iso8859-1 encoded, which leeds to display errors, an example is >>>> part >>>> 9.2.1. >>>> ... proxyâs efficiency ... >>> Is this something I can fix, or is it part of the doc build for the main >>> site? >> It's in the SDF source files, therefore something you should fix. I don't know >> what text editor you used on those files, but you should use something else, >> or use one that you can set to just ISO8859-1. >> >> I can't think of a grep regex that will detect 8-bit characters, but you need >> to find them all and get rid of them. > > (Used a binary editor to generate a regexp for [ 0x80 - 0xff ]). There were > only two occurrences in the sdf files; both in backends.sdf. Both are the same > character, an apostrophe used instead of a single quote. > > (binary patch xx) > X=`cat xx` > % grep "[$X]" *.sdf > backends.sdf:same connection. This connection pooling strategy can enhance the > proxys > backends.sdf:maybe stored procedures cant be considered programming, anyway ;). > I use Vim and gedit. The above would have been copy and paste from the FAQ. I'll do a Vim trigger to clean up things like this before a commit/make. Thanks all. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5256) encoding of guide.sdf
by h.b.furuseth＠usit.uio.no 02 Dec '07

02 Dec '07

hyc(a)symas.com writes: > I can't think of a grep regex that will detect 8-bit characters, but > you need to find them all and get rid of them. grep -v '[^ -~<tab>]' where you type ^V tab to the shell to get the <tab>. To search for probably-UTF-8 chars: perl -ne '/[\300-\377][\200-\277]/ && print "$ARGV:$_"' To search for probably-not-UTF-8 8-bit chars: perl -ne '/[\300-\377](?![\200-\277])|(^|[^\200-\377])[\200-\277]/ && print "$ARGV:$_"' -- Regards, Hallvard

1 0

Re: (ITS#5256) encoding of guide.sdf
by kurt＠OpenLDAP.org 02 Dec '07

02 Dec '07

On Dec 2, 2007, at 8:10 PM, ghenry(a)suretecsystems.com wrote: > <quote who="dieter(a)dkluenter.de"> >> Full_Name: Dieter Kluenter >> Version: REL_ENG_2_4 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.202.173) >> >> >> Hi, >> the guide *.sdf files are UTF-8 encoded, but the online availeable >> HTML >> files >> seem to be iso8859-1 encoded, which leeds to display errors, an >> example is >> part >> 9.2.1. >> ... proxy’s efficiency ... > > Is this something I can fix, or is it part of the doc build for the > main > site? You can avoid using non-ASCII characters... > > >> >> -Dieter >> >> >> > >

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 02 Dec '07

02 Dec '07

> Please upload a new patch file which contains both of these notices and then > your diff (updated if > appropriate), and then send an email update to the ITS referencing the new > patch file. Here we are: ftp://ftp.openldap.org/incoming/manu-071202.patch ftp://ftp.openldap.org/incoming/manu-pkg-071202.tgz -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5256) encoding of guide.sdf
by hyc＠symas.com 02 Dec '07

02 Dec '07

hyc(a)symas.com wrote: > ghenry(a)suretecsystems.com wrote: >> <quote who="dieter(a)dkluenter.de"> >>> Hi, >>> the guide *.sdf files are UTF-8 encoded, but the online availeable HTML >>> files >>> seem to be iso8859-1 encoded, which leeds to display errors, an example is >>> part >>> 9.2.1. >>> ... proxyâs efficiency ... >> Is this something I can fix, or is it part of the doc build for the main >> site? > > It's in the SDF source files, therefore something you should fix. I don't know > what text editor you used on those files, but you should use something else, > or use one that you can set to just ISO8859-1. > > I can't think of a grep regex that will detect 8-bit characters, but you need > to find them all and get rid of them. (Used a binary editor to generate a regexp for [ 0x80 - 0xff ]). There were only two occurrences in the sdf files; both in backends.sdf. Both are the same character, an apostrophe used instead of a single quote. (binary patch xx) X=`cat xx` % grep "[$X]" *.sdf backends.sdf:same connection. This connection pooling strategy can enhance the proxys backends.sdf:maybe stored procedures cant be considered programming, anyway ;). -- -- 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#5256) encoding of guide.sdf
by hyc＠symas.com 02 Dec '07

02 Dec '07

ghenry(a)suretecsystems.com wrote: > <quote who="dieter(a)dkluenter.de"> >> Hi, >> the guide *.sdf files are UTF-8 encoded, but the online availeable HTML >> files >> seem to be iso8859-1 encoded, which leeds to display errors, an example is >> part >> 9.2.1. >> ... proxy’s efficiency ... > > Is this something I can fix, or is it part of the doc build for the main > site? It's in the SDF source files, therefore something you should fix. I don't know what text editor you used on those files, but you should use something else, or use one that you can set to just ISO8859-1. I can't think of a grep regex that will detect 8-bit characters, but you need to find them all and get rid of them. -- -- 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#5256) encoding of guide.sdf
by ghenry＠suretecsystems.com 02 Dec '07

02 Dec '07

<quote who="dieter(a)dkluenter.de"> > Full_Name: Dieter Kluenter > Version: REL_ENG_2_4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.202.173) > > > Hi, > the guide *.sdf files are UTF-8 encoded, but the online availeable HTML > files > seem to be iso8859-1 encoded, which leeds to display errors, an example is > part > 9.2.1. > ... proxy’s efficiency ... Is this something I can fix, or is it part of the doc build for the main site? > > -Dieter > > >

1 0

(ITS#5256) encoding of guide.sdf
by dieter＠dkluenter.de 02 Dec '07

02 Dec '07

Full_Name: Dieter Kluenter Version: REL_ENG_2_4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.202.173) Hi, the guide *.sdf files are UTF-8 encoded, but the online availeable HTML files seem to be iso8859-1 encoded, which leeds to display errors, an example is part 9.2.1. ... proxy’s efficiency ... -Dieter

1 0

Re: (ITS#5254) core dump on Solaris 9 when with threads
by hyc＠symas.com 02 Dec '07

02 Dec '07

mills(a)cc.umanitoba.ca wrote: > Full_Name: Gary Mills > Version: openldap-2.3.38 > OS: Solaris 9 SPARC > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.78.105.29) back-ldbm is deprecated and has been deleted from OpenLDAP 2.4. It is known to have many problems. Berkeley DB 3.1.17 is ancient, and also known to have many bugs. Don't use ldbm, and use a recent version of BerkeleyDB. Nobody is going to spend any time investigating these broken code bases. > > > Here's how openldap-2.3.38 was built: > > PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH > > env CC=cc \ > INSTALL=/usr/ucb/install \ > CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix > -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ > LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix > -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ > ./configure \ > --disable-proctitle \ > --enable-crypt \ > --disable-bdb \ > --disable-hdb \ > --enable-ldbm \ > --enable-perl > > In simple tests with an ldbm database, it works correctly. With many clients, > it > dump core hundreds of times a day. The dumps vary, but suggest a memory > management > problem. Here are two: -- -- 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#5254) core dump on Solaris 9 when with threads
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

I neglected to mention that compiling Openldap without threads resulted in a perfectly stable server. Threads seem to be handled incorrectly, somehow. -- -Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

1 0

(ITS#5255) Outlook 2003 says: The search could not be completed.
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29) Here's how Openldap was compiled: PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH env CC=cc \ INSTALL=/usr/ucb/install \ CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ ./configure \ --disable-proctitle \ --enable-crypt \ --disable-bdb \ --disable-hdb \ --enable-ldbm \ --without-threads \ --enable-perl When using an ldbm database, Microsoft Outlook 2003 clients report this error when they attempt a search: The search could not be completed. MAPI_E_CALL_FAILED The LDAP logs show this message: critical control unavailable in context This happens because Openldap advertizes the pagedResults control, even though the ldbm backend does not support it. When OL 2003 obtains the list of available controls, the LDAP server does not know which back end it will use. When OL 2003 does a query, it goes to the ldbm back end which does not support that control. OL 2003 marks it critical, making the situation impossible. In this situation, I'm using only the ldbm back end, so I removed the pagedResults control in servers/slapd/controls.c to fix the problem. Here's my patch: *** controls.Oc Tue Jan 2 15:43:55 2007 --- controls.c Thu Nov 29 19:53:12 2007 *************** *** 123,132 **** --- 123,134 ---- SLAP_CTRL_GLOBAL|SLAP_CTRL_SEARCH, NULL, parseValuesReturnFilter, LDAP_SLIST_ENTRY_INITIALIZER(next) }, #endif + #ifdef VANILLA { LDAP_CONTROL_PAGEDRESULTS, (int)offsetof(struct slap_control_ids, sc_pagedResults), SLAP_CTRL_SEARCH, NULL, parsePagedResults, LDAP_SLIST_ENTRY_INITIALIZER(next) }, + #endif #ifdef LDAP_DEVEL { LDAP_CONTROL_SORTREQUEST, (int)offsetof(struct slap_control_ids, sc_sortedResults), Adding an access list to the config file did not work.

1 0

(ITS#5254) core dump on Solaris 9 when with threads
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29) Here's how openldap-2.3.38 was built: PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH env CC=cc \ INSTALL=/usr/ucb/install \ CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ ./configure \ --disable-proctitle \ --enable-crypt \ --disable-bdb \ --disable-hdb \ --enable-ldbm \ --enable-perl In simple tests with an ldbm database, it works correctly. With many clients, it dump core hundreds of times a day. The dumps vary, but suggest a memory management problem. Here are two: # mdb /usr/local/libexec/slapd /var/core/core.slapd.3610 Loading modules: [ libc.so.1 libthread.so.1 ld.so.1 ] > ::status debugging core file of slapd (32-bit) from electra executable file: /opt/local/libexec/slapd initial argv: slapd threading model: multi-threaded status: process terminated by SIGSEGV (Segmentation Fault) > ::stack is_ad_subtype+0x4c(30000, 3b0120, 33abb0, 33a698, 181ae30, 15949a4) attrs_find+0x2c(181b458, 3b0120, 33a698, 400, 181ae30, 15949a4) 0x8cba4(3d0e08, 17d4e80, 15949c4, 3bd000, 0, fdbff725) test_filter+0x388(3d0e08, 17d4e80, 15949c4, 14baa8, ffffffe0, fdbff8b1) 0x8c808(3d0e08, 17d4e80, 15949c4, 7, ffffffe0, fdbff8f1) test_filter+0x784(3d0e08, 17d4e80, 15949d4, 2, 0, 0) ldbm_back_search+0x12d0(3d0e08, fdbffd50, 0, fdbff2a4, 0, fdbff9fd) fe_op_search+0x594(3d0e08, fdbffd50, 3d0efc, fdbffab0, 0, 0) do_search+0xf54(3d0e08, fdbffd50, fdbffd40, 0, 0, 0) 0x5bbf8(fdbffe14, 3d0e08, 0, 0, 0, 0) 0x153f5c(3aacb8, 0, 0, 0, 0, 0) libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0) # mdb /usr/local/libexec/slapd /var/core/core.slapd.25318 Loading modules: [ libc.so.1 libthread.so.1 ld.so.1 ] > ::status debugging core file of slapd (32-bit) from electra executable file: /opt/local/libexec/slapd initial argv: slapd threading model: multi-threaded status: process terminated by SIGSEGV (Segmentation Fault) > ::stack str2entry2+0xfec(40c010, 0, 2ee1bc, 7, ffffffe0, fe3ff8f1) id2entry_rw+0x484(3d0820, 1da9, 0, 2, 0, 0) ldbm_back_search+0xa14(3d0e08, fe3ffd50, 0, fe3ff2a4, 81010100, ff00) fe_op_search+0x594(3d0e08, fe3ffd50, 3d0efc, 14388f4, fe3ffab0, 1438e4c) do_search+0xf54(3d0e08, fe3ffd50, fe3ffd40, 0, 0, 0) 0x5bbf8(fe3ffe14, 3d0e08, 0, 0, 0, 0) 0x153f5c(3aacb8, 0, 0, 0, 0, 0) libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0)

1 0

Re: (ITS#5252) Several SQL Bugs in back-sql
by ando＠sys-net.it 01 Dec '07

01 Dec '07

h.goebel(a)goebel-consult.de wrote: > Full_Name: > Version: 2.3.38 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.207.201.247) > > > Debugging marks in sql-statement may lead to wrong results. > > The interface I implemented yields statements like this when using Thunderbird > for searching for 'Klaus'. Thunderbird tries to look up in email, name and given > name. > Ans in my setup, search is restricted to "(objectclass=evolutionPerson)". > > SELECT DISTINCT > ldap_entries.id,res_partner_address.id, > text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM > ldap_entries,res_partner_address,ldap_entry_objclasses > WHERE > res_partner_address.id=ldap_entries.keyval > AND ldap_entries.oc_map_id=1 > AND 9=9 > AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id > AND ldap_entry_objclasses.oc_name='evolutionPerson')) > AND (( upper(email) LIKE '%KLAUS%') > OR (upper(name) LIKE '%KLAUS%') > OR 7=7 > OR (upper(substring(name from '\\S+..$')) LIKE '%KLAUS%'))) > > 1) "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done > on email, name or givenname. Thus all records are returned. > > 2) "2=2 OR" renders the restriction to a specific objectclass useless. > > In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this > part away. And exactly this is the problem. This is required to implement attribute and objectClass inheritance, which is required by LDAP. So please don't call them "bugs", they're required hacks. If they're not in place, back-sql would give the wrong response to queries; if they're in place, back-sql would give the right response, possibly inefficiently on braindead RDBMSes. Please choose what you prefer: the wrong answer quickly or the right one maybe slower? 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#5252) Several SQL Bugs in back-sql
by h.goebel＠goebel-consult.de 01 Dec '07

01 Dec '07

Full_Name: Version: 2.3.38 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.207.201.247) Debugging marks in sql-statement may lead to wrong results. The interface I implemented yields statements like this when using Thunderbird for searching for 'Klaus'. Thunderbird tries to look up in email, name and given name. Ans in my setup, search is restricted to "(objectclass=evolutionPerson)". SELECT DISTINCT ldap_entries.id,res_partner_address.id, text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,res_partner_address,ldap_entry_objclasses WHERE res_partner_address.id=ldap_entries.keyval AND ldap_entries.oc_map_id=1 AND 9=9 AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='evolutionPerson')) AND (( upper(email) LIKE '%KLAUS%') OR (upper(name) LIKE '%KLAUS%') OR 7=7 OR (upper(substring(name from '\\S+..$')) LIKE '%KLAUS%'))) 1) "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done on email, name or givenname. Thus all records are returned. 2) "2=2 OR" renders the restriction to a specific objectclass useless. In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this part away. And exactly this is the problem.

1 0

Re: (ITS#5251) getaddrinfo might return duplicate results
by hyc＠symas.com 29 Nov '07

29 Nov '07

Ralf Haferkamp wrote: > On Donnerstag, 29. November 2007, hyc(a)symas.com wrote: >> rhafer(a)suse.de wrote: >>> Full_Name: Ralf Haferkamp >>> Version: All >>> OS: Linux, glibc 2.7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (89.166.161.148) >>> >>> >>> Newer versions of glibc (2.7) in my case might return duplicate addrinfo >>> structs in the results under certain circumstances. According to the >>> friendly glibc maintainer ;) this is not a bug: >>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 >>> Unfortunately he doesn't give a reason for this change in behavior. >> Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and >> ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus. > The glibc code explicitly checks the /etc/hosts entry for IN6_IS_ADDR_LOOPBACK > and returns the the in_attr_t for INADDR_LOOPBACK in that case. For reasons > that the glibc author seemingly doesn't want to share with the outer world. We're calling getaddrinfo with hints.ai_family = AF_UNSPEC, so we should be getting both IPv4 and IPv6 addresses back. In this case, converting the V6 address to V4 format is obviously not desired. Also RFC2553 pretty much forbids this: (Page 25) Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4- compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned and a query of the address not performed. Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false for "::" and "::1". >>> BTW, I didn't find any reference in the related RFCs that state that the >>> getaddrinfo results need to be unique (nor the opposite). >>> In my current builds I simply patched slapd to check the getaddrinfo() >>> results for uniqueness in the slap_get_listner_addresses() function. Has >>> anybody a better idea how to fix this? >> I'm sure there's nothing that states that the returned info is required to >> be unique. The returned data must accurately reflect the host databases >> being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts, >> then it's reasonable to get it returned twice. But if it's only in there >> once, then returning it twice is a bug. > -- -- 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#5251) getaddrinfo might return duplicate results
by rhafer＠suse.de 29 Nov '07

29 Nov '07

On Donnerstag, 29. November 2007, hyc(a)symas.com wrote: > rhafer(a)suse.de wrote: > > Full_Name: Ralf Haferkamp > > Version: All > > OS: Linux, glibc 2.7 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.161.148) > > > > > > Newer versions of glibc (2.7) in my case might return duplicate addrinfo > > structs in the results under certain circumstances. According to the > > friendly glibc maintainer ;) this is not a bug: > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 > > Unfortunately he doesn't give a reason for this change in behavior. > > Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and > ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus. The glibc code explicitly checks the /etc/hosts entry for IN6_IS_ADDR_LOOPBACK and returns the the in_attr_t for INADDR_LOOPBACK in that case. For reasons that the glibc author seemingly doesn't want to share with the outer world. > > BTW, I didn't find any reference in the related RFCs that state that the > > getaddrinfo results need to be unique (nor the opposite). > > In my current builds I simply patched slapd to check the getaddrinfo() > > results for uniqueness in the slap_get_listner_addresses() function. Has > > anybody a better idea how to fix this? > > I'm sure there's nothing that states that the returned info is required to > be unique. The returned data must accurately reflect the host databases > being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts, > then it's reasonable to get it returned twice. But if it's only in there > once, then returning it twice is a bug. -- Ralf

1 0

Re: (ITS#5251) getaddrinfo might return duplicate results
by hyc＠symas.com 29 Nov '07

29 Nov '07

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: All > OS: Linux, glibc 2.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.161.148) > > > Newer versions of glibc (2.7) in my case might return duplicate addrinfo structs > in the results under certain circumstances. According to the friendly glibc > maintainer ;) this is not a bug: > http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 > Unfortunately he doesn't give a reason for this change in behavior. Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus. > BTW, I didn't find any reference in the related RFCs that state that the > getaddrinfo results need to be unique (nor the opposite). > In my current builds I simply patched slapd to check the getaddrinfo() results > for uniqueness in the slap_get_listner_addresses() function. Has anybody a > better idea how to fix this? I'm sure there's nothing that states that the returned info is required to be unique. The returned data must accurately reflect the host databases being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts, then it's reasonable to get it returned twice. But if it's only in there once, then returning it twice is a bug. -- -- 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#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 29 Nov '07

29 Nov '07

Howard Chu writes: > OK, you're right, it's trivial, and I see that the configure script > already #defines sig_atomic_t to int if the system doesn't already > define it. So your suggested changes are harmless, go ahead and make > them. If you're going to that trouble, you should change gotintr to > use an explicitly defined contiguous range of values. OK, later.. that's why I filed an its first (in particular, need to look at WAKE_LISTENER first.) Which makes the rest of this reply irrelevant to the ITS, so skip it if that helps your blood pressure: > Backward compatibility only reinforces my point, since int has always > been atomic in the past. Where do you get that from? A brief search find nothing like that in the draft and standard versions I've lying around. It would also mean that sig_atomic_t would be a pointless type. >> Otherwise the standard would not have needed to define sig_atomic_t. > > Note that sig_atomic_t is an *optional* part of the standard; > implementations are not required to provide it. Irrelevant. Freestanding implementations need not provide it (nor most of the rest of the C library), but <signal.h> requires it. > The standard says it is impossible for arithmetic operations on valid > values to generate trap representations. Think about it - if it were > *possible* for intermediate states to be invalid, (...) A signal breaks the rest of the execution model. A variable need not be in an "intermediate state" according to that model when a signal arrives. Otherwise C could not use *any* inherently non-atomic types, which would rather limit which CPUs could support C. That's why the standard says signal handlers can do so aburdly few things in the first place. > Nobody is stupid enough to design a machine like that, and the > standard guarantees that programmers never have to worry about such a > stupidity ever existing. > (...) > Not on any machine ever built (for which a C translator exists). On the countrary, the existence of such hosts is precicely why the section about signal handlers explicitly contradicts you. And as Doug Gwyn said, even the little part it does guarantee was hard to get agreement for. -- Regards, Hallvard

1 0

(ITS#5251) getaddrinfo might return duplicate results
by rhafer＠suse.de 29 Nov '07

29 Nov '07

Full_Name: Ralf Haferkamp Version: All OS: Linux, glibc 2.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.161.148) Newer versions of glibc (2.7) in my case might return duplicate addrinfo structs in the results under certain circumstances. According to the friendly glibc maintainer ;) this is not a bug: http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 Unfortunately he doesn't give a reason for this change in behavior. BTW, I didn't find any reference in the related RFCs that state that the getaddrinfo results need to be unique (nor the opposite). In my current builds I simply patched slapd to check the getaddrinfo() results for uniqueness in the slap_get_listner_addresses() function. Has anybody a better idea how to fix this?

1 0

Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com 29 Nov '07

29 Nov '07

Hallvard B Furuseth wrote: > [rearranging] > Howard Chu writes: > >> The C standard defines "int" to be the most efficient machine word, >> and that is always atomic. > > It does neither, that I can see. Among other things because "most > efficient" is not well-defined. E.g. by space or time? Efficient with > which operations? It's the recommended intent somewhere (the > Rationale?), but that must be subject to whatever other restrictions an > implementor faces. (16+ bits, backwards compatibility, etc.) Backward compatibility only reinforces my point, since int has always been atomic in the past. Likewise when migrating old code to new hardware, machine word sizes only grow if they change at all, so any word small enough to be atomic on old hardware is also atomic on new. > And the compiler can choose between an atomic and non-atomic operation, > even with volatile. Volatile guarantees a change is complete at a > sequence point. Signals need not arrive at sequence points. (C99 > 5.1.2.3p2,4. You can download the standard with amendments free at > <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.) Hm, seems I have a much older draft, this language in 6.2.5 Types has changed. > Otherwise the standard would not have needed to define sig_atomic_t. Note that sig_atomic_t is an *optional* part of the standard; implementations are not required to provide it. >> sig_atomic_t is irrelevant in slapcat. Whether we detect zero/non-zero >> immediately, one entry, or two entries after the signal occurs isn't >> going to make any difference. > > Well, I don't see any reason not to use it when the standard says so and > the change is trivial, even if we don't know of a real-life failure. > (E.g. if the compiler detects that the variable will not legally change > and optimizes it away, or if it is being read during a signal which > changes it so the result of the non-atomic read is a trap > representation.) The standard says it is impossible for arithmetic operations on valid values to generate trap representations. Think about it - if it were *possible* for intermediate states to be invalid, then it would be *inevitable* that they occur in normal code and you'd be producing traps practically all the time, at which point the only way to get useful work out of the hardware would be to disable the trap mechanism completely (e.g. mask off parity error exception generation). Nobody is stupid enough to design a machine like that, and the standard guarantees that programmers never have to worry about such a stupidity ever existing. >> Likewise, there's no issue with gotintr/abcan. The signal handler >> isn't armed until the writes are complete. Therefore whether it can be >> read atomically or not inside the handler is irrelevant, the value is >> constant. > So reading abcan is safe, but reading gotintr is not. Read first half > before signal as 0, last half as -1. Then the switch on it fails. Not on any machine ever built (for which a C translator exists). OK, you're right, it's trivial, and I see that the configure script already #defines sig_atomic_t to int if the system doesn't already define it. So your suggested changes are harmless, go ahead and make them. If you're going to that trouble, you should change gotintr to use an explicitly defined contiguous range of values. -- -- 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#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 29 Nov '07

29 Nov '07

[rearranging] Howard Chu writes: > The C standard defines "int" to be the most efficient machine word, > and that is always atomic. It does neither, that I can see. Among other things because "most efficient" is not well-defined. E.g. by space or time? Efficient with which operations? It's the recommended intent somewhere (the Rationale?), but that must be subject to whatever other restrictions an implementor faces. (16+ bits, backwards compatibility, etc.) And the compiler can choose between an atomic and non-atomic operation, even with volatile. Volatile guarantees a change is complete at a sequence point. Signals need not arrive at sequence points. (C99 5.1.2.3p2,4. You can download the standard with amendments free at <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.) Otherwise the standard would not have needed to define sig_atomic_t. > sig_atomic_t is irrelevant in slapcat. Whether we detect zero/non-zero > immediately, one entry, or two entries after the signal occurs isn't > going to make any difference. Well, I don't see any reason not to use it when the standard says so and the change is trivial, even if we don't know of a real-life failure. (E.g. if the compiler detects that the variable will not legally change and optimizes it away, or if it is being read during a signal which changes it so the result of the non-atomic read is a trap representation.) > Likewise, there's no issue with gotintr/abcan. The signal handler > isn't armed until the writes are complete. Therefore whether it can be > read atomically or not inside the handler is irrelevant, the value is > constant. So reading abcan is safe, but reading gotintr is not. Read first half before signal as 0, last half as -1. Then the switch on it fails. -- Hallvard

1 0

Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com 28 Nov '07

28 Nov '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Some non-atomic variables are used both outside and inside signal handlers: > > clients/tools/common.c: > static int gotintr; > static int abcan; > servers/slapd/daemon.c: > static volatile int waking; > (used via WAKE_LISTENER in signal handler) > slapd/slapcat.c: > static int gotsig; > > They need to be volatile sig_atomic_t. > That can be signed or unsigned char, so abcan must be set to some > #define in range 0..127 instead of -1. > > Two more problems: > > WAKE_LISTENER will not be correct anyway since it does '++waking' (not > atomic) and is called both inside and outside a signal handler. > The !NO_THREADS version is OK. > > For that matter, behavior is only defined when the signal handler > _writes_ a volatile sig_atomic_t, not when it _reads_ it: > http://groups.google.no/group/comp.std.c/msg/d01196111ce93615 > Dunno what the problem is, or if it is worse than variables > accessed by threads. I don't see anything to do about it either. No. volatile is used in daemon.c, yes. It is not needed in clients/tools or slapcat. sig_atomic_t is irrelevant in slapcat. Whether we detect zero/non-zero immediately, one entry, or two entries after the signal occurs isn't going to make any difference. Likewise, there's no issue with gotintr/abcan. The signal handler isn't armed until the writes are complete. Therefore whether it can be read atomically or not inside the handler is irrelevant, the value is constant. And of course... http://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html#Atomic-… The C standard defines "int" to be the most efficient machine word, and that is always atomic. -- -- 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#5250) CVSWeb log file issue
by quanah＠OpenLDAP.org 28 Nov '07

28 Nov '07

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.104.138.6) The log for the file is not complete when viewed via cvsweb. This is easily apparent when looking at the changes for doc/man/man5/slapd.conf.5, as it is missing recent commits. --Quanah

1 0

Re: (ITS#5249) OpenLDAP memory leak
by hyc＠symas.com 28 Nov '07

28 Nov '07

sumith.narayanan(a)gmail.com wrote: > Full_Name: Sumith Narayanan > Version: 2.3.27 > OS: MacOSX 10.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (17.216.21.198) There are two known memory leaks related to syncrepl and one related to ACL sets in 2.3.x releases since 2.3.27. Your 2.3.27 is quite old, the current 2.3 is 2.3.39. There are no known leaks related to the loglevel though. That sounds more like a memory leak in your platform's C library, in the syslog() function. You would need to use a malloc debugger to verify that. > My openLDAP DB is divided into 3 physical DBs, each of 4 GB , 12 GB and 26 GB > sizes , 42 GB total. > > We were running with ldbm backend till 6-7 months back when the total size of > the DB was below 30 GB. It started crashing once in a while as the size started > increasing. > > We then changed the backend to Berkeley DB (Version:4.4.20) and the openLDAP > version 2.3.27. It is running in a 8 GB memory machine with 32 bit processing > and receives updates through an custom interface which binds to ldap and do the > update / inserts and deletes. > > The rate at which the updates/inserts/deletes come is around 1-2 K / hr. > > Now when I start the slapd process in loglevel 256 or 512 , it starts crashing > with in a few hours running out of memory. The maximum memory that 32 bit > processor can use is around 2 GB. It crashes after that. I was trying to tune > the DB_CONFIG : > > DB_CONFIG settings for each DB : > > For 26 GB DB. > set_cachesize 0 42428800 0 > # Transaction Log settings > set_lg_regionmax 1048576 > set_lg_max 20485760 > set_lg_bsize 2097152 > > For 12GB DB > set_cachesize 0 15485760 0 > set_lg_regionmax 1048576 > set_lg_max 20485760 > set_lg_bsize 2097152 > > for 4 GB DB > set_cachesize 0 10485760 0 > set_lg_regionmax 1048576 > set_lg_max 10485760 > set_lg_bsize 2097152 > > > Slapd.conf settings : > > loglevel 16 > gentlehup on > idletimeout 300 > sizelimit 1000 > timelimit 300 > password-hash {SSHA} > allow bind_v2 > threads 32 > > These parameters are set same for all the three DBs : > > dbcachesize 100000 > cachesize 100000 > > There is a replica also which gets updates from the master. > > Now when I change the loglevel to 32 or 16 , the process lives longer , > sometimes for a week or for more than a month.... However , as soon as I switch > back to old loglevel , it starts crashing. This is happening in both master and > slave. > > Could you please advice whether there is a fix for this in the current version > or is it getting fixed in the coming version OR is it something that I can fix > by configuring. Logs are important for us as we need to know where the requests > are coming from. Also , the DB is accessed 250 K times in a day approximately. > > Please let me know if I need to furnish any more details. > > Thanks, Sumith. > > > -- -- 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#5249) OpenLDAP memory leak
by sumith.narayanan＠gmail.com 28 Nov '07

28 Nov '07

Full_Name: Sumith Narayanan Version: 2.3.27 OS: MacOSX 10.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (17.216.21.198) My openLDAP DB is divided into 3 physical DBs, each of 4 GB , 12 GB and 26 GB sizes , 42 GB total. We were running with ldbm backend till 6-7 months back when the total size of the DB was below 30 GB. It started crashing once in a while as the size started increasing. We then changed the backend to Berkeley DB (Version:4.4.20) and the openLDAP version 2.3.27. It is running in a 8 GB memory machine with 32 bit processing and receives updates through an custom interface which binds to ldap and do the update / inserts and deletes. The rate at which the updates/inserts/deletes come is around 1-2 K / hr. Now when I start the slapd process in loglevel 256 or 512 , it starts crashing with in a few hours running out of memory. The maximum memory that 32 bit processor can use is around 2 GB. It crashes after that. I was trying to tune the DB_CONFIG : DB_CONFIG settings for each DB : For 26 GB DB. set_cachesize 0 42428800 0 # Transaction Log settings set_lg_regionmax 1048576 set_lg_max 20485760 set_lg_bsize 2097152 For 12GB DB set_cachesize 0 15485760 0 set_lg_regionmax 1048576 set_lg_max 20485760 set_lg_bsize 2097152 for 4 GB DB set_cachesize 0 10485760 0 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 Slapd.conf settings : loglevel 16 gentlehup on idletimeout 300 sizelimit 1000 timelimit 300 password-hash {SSHA} allow bind_v2 threads 32 These parameters are set same for all the three DBs : dbcachesize 100000 cachesize 100000 There is a replica also which gets updates from the master. Now when I change the loglevel to 32 or 16 , the process lives longer , sometimes for a week or for more than a month.... However , as soon as I switch back to old loglevel , it starts crashing. This is happening in both master and slave. Could you please advice whether there is a fix for this in the current version or is it getting fixed in the coming version OR is it something that I can fix by configuring. Logs are important for us as we need to know where the requests are coming from. Also , the DB is accessed 250 K times in a day approximately. Please let me know if I need to furnish any more details. Thanks, Sumith.

1 0

Re: (ITS#4008) [JLDAP] LDAPConnection class does not handle null LDAPSearchQueue and LDAPSearchConstraints in search method
by rarpit＠novell.com 28 Nov '07

28 Nov '07

This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartD3F5D4E2.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I tried to replicate the above problem using the following code snippet=20 =20 .......... ........... LDAPSearchQueue queue =3Dlc.search(searchBase,searchScope,searchFilter,null= ,false,null,null); .............. .............. =20 But I am not able to find a NullPointerException as stated in the bug . It = is working fine for me . Please use the latest Jldap code and do let me know if I need to do = something more to replicate the problem .=20 --=__PartD3F5D4E2.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>I tried to replicate the above problem using the following code = snippet </DIV> <DIV> </DIV> <DIV>..........</DIV> <DIV>...........</DIV> <DIV>LDAPSearchQueue queue =3Dlc.search(searchBase,searchScope,searchFilter= ,null,false,null,null);</DIV> <DIV>..............</DIV> <DIV>..............</DIV> <DIV> </DIV> <DIV>But I am not able to find a NullPointerException as stated = in the bug . It is working fine for me .</DIV> <DIV>Please use the latest Jldap code and do let me know if I need to do = something more to replicate the problem . </DIV></BODY></HTML> --=__PartD3F5D4E2.1__=--

1 0

Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException
by rarpit＠novell.com 28 Nov '07

28 Nov '07

This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5C7A5B2F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Generally, the extensions (extended operations) are not common to all the = LDAP servers. Most of the extensions available here as part of jldap(includ= ing the GetBindDN) are exensions supported by eDirectory. However one = should not get such exceptions, which you've reported even on the other = LDAP servers (as Active Directory).=20 =20 However, I tried the same code as stated on AD server and I didn't get the = exception you got. Instead I am getting the following exceptions=20 =20 Login succeeded=20 Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: = Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown = extended request OID, data 0, vece=20 =20 which is the expected behavior. =20 Please check the issues once again with the latest JLDAP code and please = do let me know if I need to do something more for replicating the problem, = if it still persists. --=__Part5C7A5B2F.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>Generally, the extensions (extended operations) are not common to all = the LDAP servers. Most of the extensions available here as part of = jldap(including the GetBindDN) are exensions supported by eDirectory. = However one should not get such exceptions, which you've reported even on = the other LDAP servers (as Active Directory). </DIV> <DIV> </DIV> <DIV>However, I tried the same code as stated on AD server and I didn't = get the exception you got. Instead I am getting the following exceptions = </DIV> <DIV> </DIV> <DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol = ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, = comment: Unknown extended request OID, data 0, vece </DIV> <DIV> </DIV> <DIV>which is the expected behavior.</DIV> <DIV> </DIV> <DIV>Please check the issues once again with the latest JLDAP code and = please do let me know if I need to do something more for replicating the = problem, if it still persists.</DIV></BODY></HTML> --=__Part5C7A5B2F.0__=--

1 0

Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException
by rarpit＠novell.com 28 Nov '07

28 Nov '07

This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6A4C6D19.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Generally, the extensions (extended operations) are not common to all the = LDAP servers. Most of the extensions available here as part of jldap(includ= ing the GetBindDN) are exensions supported by eDirectory. However one = should not get such exceptions, which you've reported even on the other = LDAP servers (as Active Directory).=20 =20 However, I tried the same code as stated on AD server and I didn't get the = exception you got. Instead I am getting the following exceptions=20 =20 Login succeeded=20 Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: = Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown = extended request OID, data 0, vece=20 =20 which is the expected behavior. =20 Please check the issues once again with the latest JLDAP code and please = do let me know if I need to do something more for replicating the problem, = it it still persists. --=__Part6A4C6D19.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>Generally, the extensions (extended operations) are not common to all = the LDAP servers. Most of the extensions available here as part of = jldap(including the GetBindDN) are exensions supported by eDirectory. = However one should not get such exceptions, which you've reported even on = the other LDAP servers (as Active Directory). </DIV> <DIV> </DIV> <DIV>However, I tried the same code as stated on AD server and I didn't = get the exception you got. Instead I am getting the following exceptions = </DIV> <DIV> </DIV> <DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol = ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, = comment: Unknown extended request OID, data 0, vece </DIV> <DIV> </DIV> <DIV>which is the expected behavior.</DIV> <DIV> </DIV> <DIV>Please check the issues once again with the latest JLDAP code and = please do let me know if I need to do something more for replicating the = problem, it it still persists.</DIV></BODY></HTML> --=__Part6A4C6D19.0__=--

1 0

(ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 27 Nov '07

27 Nov '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Some non-atomic variables are used both outside and inside signal handlers: clients/tools/common.c: static int gotintr; static int abcan; servers/slapd/daemon.c: static volatile int waking; (used via WAKE_LISTENER in signal handler) slapd/slapcat.c: static int gotsig; They need to be volatile sig_atomic_t. That can be signed or unsigned char, so abcan must be set to some #define in range 0..127 instead of -1. Two more problems: WAKE_LISTENER will not be correct anyway since it does '++waking' (not atomic) and is called both inside and outside a signal handler. The !NO_THREADS version is OK. For that matter, behavior is only defined when the signal handler _writes_ a volatile sig_atomic_t, not when it _reads_ it: http://groups.google.no/group/comp.std.c/msg/d01196111ce93615 Dunno what the problem is, or if it is worse than variables accessed by threads. I don't see anything to do about it either.

1 0

(ITS#5247) ldapmodify results misleading
by quanah＠OpenLDAP.org 27 Nov '07

27 Nov '07

Full_Name: Quanah Gibson-Mount Version: HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.21.80.71) When ldapmodify prints "modify complete" all it has done so far is send the request to the server. It hasn't actually read the server's reply yet. This should be fixed so that better information is given to the end client about the state of the modify request.

1 0

Re: (ITS#5241) slapd crashes with "loglevel 0"
by rhafer＠suse.de 26 Nov '07

26 Nov '07

On Freitag, 23. November 2007, Ulrich.Windl(a)rz.uni-regensburg.de wrote: > Full_Name: Ulrich Windl > Version: 2.3.32 > OS: SLES10 SP1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.199.156.178) > > > The version of OpenLDAP shipped with SUSE Linux Enterprise Server 10 > (SLES10) SP1, openldap2-2.3.32-0.23 crashes with a segmentation fault if > "loglevel 0" is used. For other log levels things seem to work. The problem > has been seen on x86_64 (segfaults are logged in syslog). If you want to report bugs in OpenLDAP through the OpenLDAP ITS you should always test if the bug is present in most recently release version of the software (2.3.39 in this case). If you want to report bugs against older Versions, that were shipped with a product of some vendor you should report the bug to the vendor of that product. So in your case please either test with OpenLDAP 2.3.39 (you can find SLES packages here: http://download.opensuse.org/repositories/OpenLDAP/SLE_10/ Or report the bug to SUSE/Novell here: http://support.novell.com/additional/bugreport.html or, if you have a valid support contract to you contact in support. Btw, I have some x86_64 SLES10-SP1 systems with openldap-2.3.32 running here with 'loglevel 0' without any problem, so I suspect there are some additional things that trigger your problem. But to go further please choose one of the options I gave you above -- Ralf -------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

1 0

Re: (ITS#5245) auditlog man page and feature request
by ghenry＠suretecsystems.com 26 Nov '07

26 Nov '07

<quote who="hyc(a)symas.com"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: 2.4.6 >> OS: F8 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> Note to self about man page missing any cn=config examples, for example: >> >> dn: cn=module{0},cn=config >> changetype: modify >> add: olcModuleLoad >> olcModuleLoad: {2}auditlog.la >> >> dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config >> changetype: add >> objectClass: olcOverlayConfig >> objectClass: olcAuditLogConfig >> olcOverlay: auditlog >> >> dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config >> changetype: modify >> add: olcAuditlogFile >> olcAuditlogFile: /tmp/auditlog.ldif >> > > The above is a poor example, you should set all the relevant attributes > when > the object is created. Doing a subsequent modify is a waste. This was just a quick c&p I did from test050, but yes, a waste. > >> Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp > > The doc says it's a fully qualified path. That means it is not a URL. This > point is superfluous. Aye, it will be obvious in the example. Thanks. > >> Feature request: >> >> New config setting to define mode. At the moment it's 0644 >> >> Thanks. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > >

1 0

Re: ITS#5240
by quanah＠zimbra.com 26 Nov '07

26 Nov '07

--On November 26, 2007 3:53:34 AM +0000 hyc(a)symas.com wrote: > I don't know what timestamp you're looking at, but according to CVS > init.c still has not been sync'd. (11/18/2007) > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/init.c?hi > deattic=1&sortbydate=0 > > You should not be making blind commits into the Release Engineering > branches. It's your job to verify that the commits are correct. back-bdb > is broken in RE24 right now. I wasn't making blind commits, I've been making commits in the same sequence as they come into the commit list, after confirming with you. In any case, I think I must have been looking at your commit to fix back-bdb/init.c, because I was seeing 0 difference between HEAD/2.4 when looking prior to writing my mail, and missed that it had been your commit. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5240
by hyc＠symas.com 26 Nov '07

26 Nov '07

quanah(a)zimbra.com wrote: > --On November 22, 2007 5:11:30 PM +0000 ando(a)sys-net.it wrote: > >> A fix for ITS#5183 has been partially imported into re24 (back-bdb.h; >> init.c not yet). I don't know if it was intended, or if the merging is >> just in progress. > > init.c was sync'd prior to this ITS even being filed, unless its a > timestamp issue somewhere (11/21/2007). back-bdb.h was sync'd except for > the ifdef LDAP_DEVEL, which shouldn't have had an effect since > BDB_MONITOR_IDX was already defined. If things still aren't working with > 2.4, then something else is the matter. I don't know what timestamp you're looking at, but according to CVS init.c still has not been sync'd. (11/18/2007) http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/init.c?hide… You should not be making blind commits into the Release Engineering branches. It's your job to verify that the commits are correct. back-bdb is broken in RE24 right now. -- -- 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#5240
by quanah＠zimbra.com 26 Nov '07

26 Nov '07

--On November 22, 2007 5:11:30 PM +0000 ando(a)sys-net.it wrote: > A fix for ITS#5183 has been partially imported into re24 (back-bdb.h; > init.c not yet). I don't know if it was intended, or if the merging is > just in progress. init.c was sync'd prior to this ITS even being filed, unless its a timestamp issue somewhere (11/21/2007). back-bdb.h was sync'd except for the ifdef LDAP_DEVEL, which shouldn't have had an effect since BDB_MONITOR_IDX was already defined. If things still aren't working with 2.4, then something else is the matter. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5245) auditlog man page and feature request
by hyc＠symas.com 25 Nov '07

25 Nov '07

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: 2.4.6 > OS: F8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Note to self about man page missing any cn=config examples, for example: > > dn: cn=module{0},cn=config > changetype: modify > add: olcModuleLoad > olcModuleLoad: {2}auditlog.la > > dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config > changetype: add > objectClass: olcOverlayConfig > objectClass: olcAuditLogConfig > olcOverlay: auditlog > > dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config > changetype: modify > add: olcAuditlogFile > olcAuditlogFile: /tmp/auditlog.ldif > The above is a poor example, you should set all the relevant attributes when the object is created. Doing a subsequent modify is a waste. > Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp The doc says it's a fully qualified path. That means it is not a URL. This point is superfluous. > Feature request: > > New config setting to define mode. At the moment it's 0644 > > Thanks. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5245) auditlog man page and feature request
by ghenry＠OpenLDAP.org 25 Nov '07

25 Nov '07

Full_Name: Gavin Henry Version: 2.4.6 OS: F8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Note to self about man page missing any cn=config examples, for example: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {2}auditlog.la dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcAuditLogConfig olcOverlay: auditlog dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config changetype: modify add: olcAuditlogFile olcAuditlogFile: /tmp/auditlog.ldif Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp Feature request: New config setting to define mode. At the moment it's 0644 Thanks.

1 0

(ITS#5244) Problem configuring openldap 2.4.6
by pierre42d＠9online.fr 25 Nov '07

25 Nov '07

Full_Name: Pierre Version: 2.4.6 OS: GNU/Linux URL: Submission from: (NULL) (82.224.217.20) [...] checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking db.h usability... no checking db.h presence... no checking for db.h... no configure: error: BDB/HDB: BerkeleyDB not available I have Berkeley DB 4.6.21 installed

1 0

Re: ITS#5243
by ando＠sys-net.it 23 Nov '07

23 Nov '07

hyc(a)symas.com wrote: >> There have been at least 10 syncrepl-related fixes in 2.3 since 2.3.32, >> with substantial bug fixes and improvements. Please update and check if >> the issue has been already fixed. > > This works as designed. The identity that the syncrepl consumer uses to > retrieve results must have sufficient privilege to retrieve a complete set of > results. Right, I probably misunderstood the question. If it was related to the "sizelimit" option of the "syncrepl" statement, as far as I understand, that parameter sets the amount of data the consumer is willing to replicate, in case one wants to set up a partial replica. It must be set to "unlimited" (i.e. no "sizelimit" used) to replicate as much as possible of the producer. In the latter case, the amount of data a consumer can get depends on the size limit the producer is willing to return. For this purpose, the identity used by the consumer must have no size limits to work correctly. A "limits" statement that sets the size limit to "unlimited" for a "who" clause that includes the consumer's replication identity should be used. 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#5243
by hyc＠symas.com 23 Nov '07

23 Nov '07

ando(a)sys-net.it wrote: > There have been at least 10 syncrepl-related fixes in 2.3 since 2.3.32, > with substantial bug fixes and improvements. Please update and check if > the issue has been already fixed. This works as designed. The identity that the syncrepl consumer uses to retrieve results must have sufficient privilege to retrieve a complete set of results. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs