openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#7619) Unable to start OpenLDAP 2.4.35 with Oracle 10g
by lokesh.kumar1＠thomsonreuters.com 11 Jun '13

11 Jun '13

Full_Name: Lokesh Kumar Version: 2.4.35 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (163.231.6.66) I am unable to start the LDAP on my linux machine with openldap-2.4.35 using back-sql with Oracle 10g as my datasource. I am able to connect to the Oracle database, but it fails to load the data on to the LDAP object schema. I am using the default sample data for Oracle RDBMS and the schema files which comes with the installable. Can you please look into this and let me know if I am missing something here? My sladp.config file looks like this: include <InstallFolder>/etc/openldap/schema/core.schema include <InstallFolder>/etc/openldap/schema/cosine.schema include <InstallFolder>/etc/openldap/schema/inetorgperson.schema pidfile <InstallFolder>/var/run/slapd.pid argsfile <InstallFolder>/var/run/slapd.args database sql suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw secret dbname OracleODBC-10g dbuser username dbpasswd password subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" insentry_stmt "INSERT INTO ldap_entries (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" upper_func UPPER has_ldapinfo_dn_ru no The startup console output looks something like this: . . . 51b70f81 backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" 51b70f81 objectClass: id="1" name="inetOrgPerson" keytbl="persons" keycol="id" create_proc="call create_person(?)" create_keyval="" delete_proc="call delete_person(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" 51b70f81 create_proc="call create_person(?)" 51b70f81 delete_proc="call delete_person(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 objectClass: id="2" name="document" keytbl="documents" keycol="id" create_proc="call create_document(?)" create_keyval="" delete_proc="call delete_document(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "document": keytbl="documents" keycol="id" 51b70f81 create_proc="call create_document(?)" 51b70f81 delete_proc="call delete_document(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 objectClass: id="3" name="organization" keytbl="institutes" keycol="id" create_proc="call create_org(?)" create_keyval="" delete_proc="call delete_org(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "organization": keytbl="institutes" keycol="id" 51b70f81 create_proc="call create_org(?)" 51b70f81 delete_proc="call delete_org(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 backsql_load_schema_map(): at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" 51b70f81 backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 51b70f81 backsql_oc_get_attr_mapping(): error executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 51b70f81 Return code: -1 51b70f81 <==backsql_load_schema_map() 51b70f81 backsql_db_open(): schema mapping failed, exiting 51b70f81 backend_startup_one (type=sql, suffix="dc=example,dc=com"): bi_db_open failed! (1) 51b70f81 slapd shutdown: initiated . . .

1 0

Re: (ITS#7618) pcache overlay does not allow the use of NOT ("!") in templates
by hyc＠symas.com 10 Jun '13

10 Jun '13

amoneger(a)cisco.com wrote: > Full_Name: Alex Moneger > Version: 2.4.35 > OS: centos 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.103.25.102) > > > Hi, > > When trying to define a template which query contains a '!', slapd complains > about a syntax issue in the config file and refuses to start. This is by design. Read the Proxy Cache design paper. http://www.openldap.org/pub/ -- -- 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#7618) pcache overlay does not allow the use of NOT ("!") in templates
by amoneger＠cisco.com 10 Jun '13

10 Jun '13

Full_Name: Alex Moneger Version: 2.4.35 OS: centos 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.103.25.102) Hi, When trying to define a template which query contains a '!', slapd complains about a syntax issue in the config file and refuses to start. This is because there seems to be a missing check for '!' in template_attrs() in pcache.c, so '!' char is passed to slap_bv2ad() which correctly errors out. i.e: May 27 20:53:53 centos63 slapd[44623]: line 71 (pcacheTemplate (&(gidNumber=)(objectClass=)(cn=*)(&(gidNumber=*)(!(gidNumber=)))) 0 3600) May 27 20:53:53 centos63 slapd[44623]: /etc/openldap/pcache.conf: line 71: unable to parse template: AttributeDescription contains inappropriate characters. I believe the use of "not" should be allowed in cacheable templates, since they appear to be a valid search filter definition as per RFC 2254. The fix is very easy. I cannot upload the diff to the ftp server, since it errors with space related errors when uploading the file. Content of the diff: --- openldap-2.4.35/servers/slapd/overlays/pcache.c 2013-03-28 15:41:51.000000000 +0000 +++ openldap-2.4.35/servers/slapd/overlays/pcache.c0 2013-05-27 21:27:20.847919253 +0100 @@ -523,7 +523,7 @@ allop = an_find( attrs, slap_bv_all_operational_attrs ); for (;;) { - while ( *p1 == '(' || *p1 == '&' || *p1 == '|' || *p1 == ')' ) p1++; + while ( *p1 == '(' || *p1 == '&' || *p1 == '|' || *p1 == ')' || *p1 == '!') p1++; p2 = strchr( p1, '=' ); if ( !p2 ) break; It can be applied this way if you consider this of any use: cd "${HOME}"/openldap-2.4.35 patch -p0 --verbose < ~/pcache.p0 Cheers, Alex

1 0

RE: (ITS#7617) Stack issue Openldap!ldap_unbind_s
by quanah＠zimbra.com 07 Jun '13

07 Jun '13

--On Friday, June 07, 2013 8:34 AM +0000 lily.zhang(a)emc.com wrote: > Hi > > Thank you for looking at it. > > A dump is generated when user login via LDAP account. > [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 OpenLDAP 2.4.16 is years old. Please confirm you see the issue using a current release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7617) Stack issue Openldap!ldap_unbind_s
by lily.zhang＠emc.com 07 Jun '13

07 Jun '13

Hi Thank you for looking at it. A dump is generated when user login via LDAP account. 1. This is the code call in my code: NAVsint32 status = ldap_unbind_s( _ldapHandle ); 2. Below is the call stack and the content of _ldapHandle(dap 0x1b4b3d58). From the call stack, it seems call stack corrupts in function call ldap_unbind_s(). 3. Issue can be solved by restarting the process, but issue can reproduced once in while in the user's environment. 4. Please let me if you need other material about this issue. 0:112:x86> kb *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 1fd5c19c 0cb83b74 12ad21c8 1b291110 0cb839e8 0x56414e24 1fd5c1a8 0cb839e8 23fb4c18 23fa62f0 0cd41433 SecurityProvider!ri_cert_ctx_free+0x30 1fd5c1b4 0cd41433 1b291110 0cd4e533 1b291110 SecurityProvider!ri_cert_free+0x6d 1fd5c1bc 0cd4e533 1b291110 4173e2a8 00000000 Openldap!R_CERT_free+0x19 1fd5c1d0 0cd41a41 23fa62f0 4173e1d8 4173e1d8 Openldap!R_SSL_SESSION_free+0x9a 1fd5c1e8 0cd35e32 4173e1d8 0000002f 4173e1d8 Openldap!R_SSL_free+0x11e 1fd5c214 0cd265a7 00000168 4aaaf310 1fd5c238 Openldap!SSL_free+0xe2 1fd5c224 0cd2eefe 390c45b0 390b7c18 390c45b0 Openldap!tlso_sb_remove+0x57 [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 0cd2f3e6 390b7c10 0cdc8b04 00000014 Openldap!ber_sockbuf_remove_io+0x9e [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 230] 1fd5c250 0cd2eb03 390b7c10 1fd5c280 0cd272a8 Openldap!ber_int_sb_destroy+0x76 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 405] 1fd5c25c 0cd272a8 390b7c10 74834c39 00000000 Openldap!ber_sockbuf_free+0x53 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 75] 1fd5c280 0cd26f41 1b4b3d58 00000001 00000000 Openldap!ldap_ld_free+0x2f8 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 195] 1fd5c29c 0cd272e0 1b4b3d58 00000000 00000000 Openldap!ldap_unbind_ext+0x71 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 52] 1fd5c2b0 0cb019fe 1b4b3d58 1fd5c35c 48d8e868 Openldap!ldap_unbind_s+0x10 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 213] 1fd5c2c4 0cafd615 eedd5f4e 1fd5c35c 1fd5c4ec SecurityProvider!ecom::caprovider::OpenLDAPLogin::_disconnect+0x1e [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldaplogin.cpp @ 1344] 1fd5c2e0 0caf98dd eedd5956 1fd5c324 1fd5c324 SecurityProvider!ecom::caprovider::OpenLDAPLogin::~OpenLDAPLogin+0x35 [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldaplogin.cpp @ 198] 1fd5c4f8 0cada203 1fd5c63c 1fd5c64c 1fd5c5d4 SecurityProvider!ecom::caprovider::OpenLDAPAuthLoginContext::login+0x37d [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldapauthlogincontext.cpp @ 159] 1fd5c604 0cabd419 1fd5c63c 1fd5c64c 1fd5c724 SecurityProvider!ecom::caprovider::NaviCA_LDAPFeature::AuthenticateUser+0x203 [z:\naviservices\providers\securityprovider\commonauthenticationprovider\generated\mynavica_ldapfeature.cpp @ 1415] 1fd5c634 0ca668db 4aab2ba0 00000006 00000007 SecurityProvider!NaviSec_SecurityAdmin::AuthenticateCAUser+0x69 [z:\naviservices\providers\securityprovider\generated\navisec_securityadminmethods.cpp @ 4211] 1fd5c734 0ca63e3b 1fd5c85c 4aab2ba0 00000006 SecurityProvider!NaviSec_Authentication::CanUserAccess+0x1bb [z:\naviservices\providers\securityprovider\generated\navisec_authenticationmethods.cpp @ 154] 0:112:x86> dt -r8 ldap 0x1b4b3d58 Openldap!ldap +0x000 ld_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x004 ld_options : ldapoptions +0x000 ldo_valid : 2 +0x004 ldo_debug : 0 +0x008 ldo_tm_api : timeval +0x000 tv_sec : -1 +0x004 tv_usec : 0 +0x010 ldo_tm_net : timeval +0x000 tv_sec : 30 +0x004 tv_usec : 0 +0x018 ldo_version : 3 +0x01c ldo_deref : 0 +0x020 ldo_timelimit : 0 +0x024 ldo_sizelimit : 0 +0x028 ldo_tls_ctx : (null) +0x02c ldo_tls_connect_cb : (null) +0x030 ldo_tls_connect_arg : (null) +0x034 ldo_tls_info : ldaptls +0x000 lt_certfile : (null) +0x004 lt_keyfile : (null) +0x008 lt_dhfile : (null) +0x00c lt_cacertfile : (null) +0x010 lt_cacertdir : (null) +0x014 lt_ciphersuite : (null) +0x018 lt_crlfile : (null) +0x01c lt_randfile : (null) +0x020 lt_protocol_min : 0 +0x058 ldo_tls_mode : 0 +0x05c ldo_tls_require_cert : 0 +0x060 ldo_tls_impl : 0 +0x064 ldo_tls_crlcheck : 0 +0x068 ldo_defludp : (null) +0x06c ldo_defport : 389 +0x070 ldo_defbase : (null) +0x074 ldo_defbinddn : (null) +0x078 ldo_def_sasl_mech : (null) +0x07c ldo_def_sasl_realm : (null) +0x080 ldo_def_sasl_authcid : (null) +0x084 ldo_def_sasl_authzid : (null) +0x088 ldo_sasl_secprops : sasl_security_properties +0x000 min_ssf : 0 +0x004 max_ssf : 0x7fffffff +0x008 maxbufsize : 0xffffff +0x00c security_flags : 0x11 +0x010 property_names : (null) +0x014 property_values : (null) +0x0a0 ldo_refhoplimit : 5 +0x0a4 ldo_sctrls : (null) +0x0a8 ldo_cctrls : (null) +0x0ac ldo_rebind_proc : (null) +0x0b0 ldo_rebind_params : (null) +0x0b4 ldo_nextref_proc : (null) +0x0b8 ldo_nextref_params : (null) +0x0bc ldo_urllist_proc : (null) +0x0c0 ldo_urllist_params : (null) +0x0c4 ldo_conn_cbs : (null) +0x0c8 ldo_booleans : 0 +0x0d0 ld_lberoptions : 1 +0x0d4 ld_errno : 0 +0x0d8 ld_error : (null) +0x0dc ld_matched : (null) +0x0e0 ld_referrals : (null) +0x0e4 ld_msgid : 4 +0x0e8 ld_requests : (null) +0x0ec ld_responses : (null) +0x0f0 ld_nabandoned : 0 +0x0f4 ld_abandoned : (null) +0x0f8 ld_cache : (null) +0x0fc ld_defconn : (null) +0x100 ld_conns : (null) +0x104 ld_selectinfo : (null) -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 2013$BG/(B6$B7n(B7$BF|(B 16:19 To: Zhang, Lily (USD) Subject: Re: (ITS#7617) Stack issue Openldap!ldap_unbind_s *** 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#7617. 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#7617) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#7617) 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=7617 Please remember to retain your issue tracking number (ITS#7617) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#7617) Stack issue Openldap!ldap_unbind_s
by lily.zhang＠emc.com 07 Jun '13

07 Jun '13

Full_Name: Zhang, Lily Version: 2.4.16 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.159.144.57) Here is the code we call ldap_unbind_s(). void OpenLDAPLogin::_disconnect() { if (_ldapHandle == NULL) { return; } // ldap_unbind_s will free up the space // allocated for the LDAP handle NAVsint32 status = ldap_unbind_s( _ldapHandle ); if (status != LDAP_SUCCESS) { return; } _ldapHandle = NULL; } Here is the call stack, eip become an invalid pointer. If the process was restarted, issue was disappeared, but it may be reproduced sometimes later. Please help me have a look that whether is a bug that fixed in the latest version. *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 1fd5c19c 0cb83b74 12ad21c8 1b291110 0cb839e8 0x56414e24 1fd5c1a8 0cb839e8 23fb4c18 23fa62f0 0cd41433 SecurityProvider!ri_cert_ctx_free+0x30 1fd5c1b4 0cd41433 1b291110 0cd4e533 1b291110 SecurityProvider!ri_cert_free+0x6d 1fd5c1bc 0cd4e533 1b291110 4173e2a8 00000000 Openldap!R_CERT_free+0x19 1fd5c1d0 0cd41a41 23fa62f0 4173e1d8 4173e1d8 Openldap!R_SSL_SESSION_free+0x9a 1fd5c1e8 0cd35e32 4173e1d8 0000002f 4173e1d8 Openldap!R_SSL_free+0x11e 1fd5c214 0cd265a7 00000168 4aaaf310 1fd5c238 Openldap!SSL_free+0xe2 1fd5c224 0cd2eefe 390c45b0 390b7c18 390c45b0 Openldap!tlso_sb_remove+0x57 [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 0cd2f3e6 390b7c10 0cdc8b04 00000014 Openldap!ber_sockbuf_remove_io+0x9e [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 230] 1fd5c250 0cd2eb03 390b7c10 1fd5c280 0cd272a8 Openldap!ber_int_sb_destroy+0x76 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 405] 1fd5c25c 0cd272a8 390b7c10 74834c39 00000000 Openldap!ber_sockbuf_free+0x53 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 75] 1fd5c280 0cd26f41 1b4b3d58 00000001 00000000 Openldap!ldap_ld_free+0x2f8 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 195] 1fd5c29c 0cd272e0 1b4b3d58 00000000 00000000 Openldap!ldap_unbind_ext+0x71 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 52] 1fd5c2b0 0cb019fe 1b4b3d58 1fd5c35c 48d8e868 Openldap!ldap_unbind_s+0x10 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 213]

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 05 Jun '13

05 Jun '13

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> If a cursor is at a clean subDB page, and its current item is deleted >>> by another cursor, then MDB_GET_CURRENT returns the deleted item. >> >> Fixed now in mdb.master. The subcursor on the clean page will be invalidated >> when the page is touched. > > MDB_NEXT/MDB_PREV crash on assert(mc->mc_flags & C_INITIALIZED) > since commit e31c7d3b31d8d5073195e31b283e8ccb46bd13cf, with the > patch below to the test program. OK, I've reverted that commit. > mdb.master output with patched test program: > > With clean page: > Name: Key -> Data (mv_data[mv_len]): > m2: a[2] -> x[2] > mc/del: a[2] -> [0] > a.out: mdb.c:4386: mdb_cursor_next: Assertion `mc->mc_flags & 0x01' failed. No longer asserts. Also, [0] was the wrong result here. Also fixed. > Branch mdb/its7594 output: > > With clean page: > Name: Key -> Data (mv_data[mv_len]): > m2: a[2] -> x[2] > mc/del: a[2] -> [0] > its7594a.c:48: mdb_cursor_get(m2, &key, &data, MDB_NEXT): MDB_BAD_CURSOR: Cursor is unusable > > That assert is OK since it's the test program asserting success. > > --- its7594.c > +++ its7594a.c > @@ -28,4 +28,6 @@ > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); > + E(mdb_cursor_put(mc, STR2VAL("b"), STR2VAL("z"), 0)); > + E(mdb_cursor_put(mc, STR2VAL("c"), STR2VAL("w"), 0)); > > if (argc < 2) { > @@ -42,8 +44,8 @@ > > E(mdb_cursor_del(mc, 0)); > - E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); > - SHOW("m2/del"); /* Should output the same as... */ > - E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); > - SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ > + E(mdb_cursor_get(mc, &key, &data, MDB_NEXT)); > + SHOW("mc/del"); /* Outputs "a[2] -> [0]"... */ > + E(mdb_cursor_get(m2, &key, &data, MDB_NEXT)); > + SHOW("m2/del"); /* ...and this should output the same. */ > > mdb_txn_abort(txn); > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 05 Jun '13

05 Jun '13

Michael Ströder wrote: > hyc(a)symas.com wrote: >> I was considering returning LDAP_BUSY for this case, but it may make more >> sense to return a REFERRAL to the provider instead. (Although again, if we >> have two MMR servers pointed at each other starting at the same time, they >> would just refer to each other and clients would get nowhere until one of them >> finishes its refresh.) > > IMO referrals are harmful. > Just returning LDAP_BUSY seems best to me because if reliable HA is really > important for a deployment you have decent load-balancers in front of your > LDAP server which should do a proper health-check. Agreed. > Just a question: Is this database-specific? Maybe only one of several DBs is > in this initial syncrepl phase and access to others should simply work. Overlays are db-specific. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by michael＠stroeder.com 05 Jun '13

05 Jun '13

This is a cryptographically signed message in MIME format. --------------ms020809020606000104080607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > I was considering returning LDAP_BUSY for this case, but it may make mo= re=20 > sense to return a REFERRAL to the provider instead. (Although again, if= we=20 > have two MMR servers pointed at each other starting at the same time, t= hey=20 > would just refer to each other and clients would get nowhere until one = of them=20 > finishes its refresh.) IMO referrals are harmful. Just returning LDAP_BUSY seems best to me because if reliable HA is reall= y important for a deployment you have decent load-balancers in front of you= r LDAP server which should do a proper health-check. Just a question: Is this database-specific? Maybe only one of several DBs= is in this initial syncrepl phase and access to others should simply work. Ciao, Michael. --------------ms020809020606000104080607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA1MTgxNDAzWjAj BgkqhkiG9w0BCQQxFgQUiEZEhMlpWaio/7q/OgE6XehCSTswbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEA0dEsxfOK4N2Ee5bXv8bgeDj+DFV5pK4X YH8lJkCSkq9qberav4nqRGq7Ka50HZuIzMmWj2t6JR4Y/gIJfCZpSJ6fGtEMKXmuFmT9Kj8l IwlvnmoVyMnrQYVLXz/pnl1AG7vj0n00eYIe2ZlYYT2mVDT9RwBXe5T1UZoOvRmm4fy6AgSU wlNIuyClUgk/5z4jsYb8bf+abz2MWKwNA3Pv3mwB/pTUMdB90WmgfnKI1u0G5aBIsidLd7Ec aVMirzK3Ur7fNSj59/lQdnZixG2p37F+1ZkFXwtAFub5d01osWoCVePJJF16DUzJVgzZBv3Q wtcP0eJdkAwf3tBY4mkfJgAAAAAAAA== --------------ms020809020606000104080607--

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 05 Jun '13

05 Jun '13

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 2.4.35 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.155.233.73) > Submitted by: hyc > > > We've discussed this on -devel a few times in the past. Sometimes it would be > desirable to prevent a consumer from answering client requests if it has just > started up and needs to perform an lengthy refresh. > > In prior discussions, there was a concern that in an MMR situation, two servers > coming up at the same time would deadlock waiting for each other. We can avoid > this problem by allowing any search request with a Sync control to proceed as > normal. Or, any search request with a Sync control and a non-empty, valid > cookie. > > Implementation can be done using an overlay hook. Note that syncrepl already > installs an overlay hook now for delta-mmr, this would just expand the scope of > that internal overlay. I was considering returning LDAP_BUSY for this case, but it may make more sense to return a REFERRAL to the provider instead. (Although again, if we have two MMR servers pointed at each other starting at the same time, they would just refer to each other and clients would get nowhere until one of them finishes its refresh.) -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs