openldap-bugs

openldap-bugs@openldap.org

1 participants
20762 discussions

(ITS#4694) syncrepl in refreshOnly dies when bind to provider gails
by bgmilne＠staff.telkomsa.net 04 Oct '06

04 Oct '06

Full_Name: Buchan Milne Version: 2.3.27 OS: Linux 2.4 (RHEL 3) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.15.129.131) One of our replicas sits on the other side of a relatively congested WAN link (with multiple firewalls in between, which I have no control over). Since switching to syncrepl, it has been difficult to achieve a configuration that supports replication reliably to any extent. Using syncrepl consumer configuration with: syncrepl rid=124 provider=ldaps://<master hostname> type=refreshOnly interval="00:00:01:00" searchbase="<suffix>" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="<dn for consumer>" credentials="<password for consumer>" I see replication dies frequently, it seems to occur when (for whatever reason) the consumer fails to bind: ct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: uid=lere1 Oct 2 12:03:37 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:03:43 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=deleted/telkomsa133309,ou=radius,o=intekom,c=za (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=telkomsa158118 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online517446 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online517446 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa158118 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online564666 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=telkomsa220585 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online188476 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=mail109585 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa196118 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online313812 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online519355 Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=online536857 Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa233527 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564379 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564667 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=ihatechromium Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online556601 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online519355 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online519355 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online556601 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online564667 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online534772 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online18609 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=online188476 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=telkomdsl56797 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571 Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=hotkaj Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=magda22 Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:41 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online561383 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online534772 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: uid=online561383 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:06:27 leda slapd2.3[1332]: do_syncrep1: ldap_sasl_bind_s failed (-1)

1 0

Re: (ITS#4692) ppolicy.c module doesn't respect Draft policy
by hyc＠symas.com 03 Oct '06

03 Oct '06

alexandrelabiche(a)yahoo.com wrote: > Full_Name: Alexandre LABICHE > Version: 2.3.27 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.120.54.227) > > > Hello, > > draft-behera-ldap-password-policy-xx.txt says: > > > 5.3.2 pwdChangedTime > > This attribute specifies the last time the entry's password was > changed. This is used by the password expiration policy. If this > attribute does not exist, the password will never expire. > > > > And ppolicy.c overlay says contrary This is now fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4693) Unnecessary licensing statement in core.schema?
by Kurt＠OpenLDAP.org 03 Oct '06

03 Oct '06

At 11:25 AM 10/3/2006, quanah(a)stanford.edu wrote: >Full_Name: Quanah Gibson-Mount >Version: All >OS: NA >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (171.66.155.86) Nothing in this message should be construed or represented as as legal advice to any party. Recent versions of this file (and numerous other files comprising OpenLDAP Software) have contained material copied (with or without modification) from various ISOC-published documents, namely RFCs and I-Ds. It is the OpenLDAP Foundation current policy and practice to include notices from the source documents even where OpenLDAP Foundation believe the nature of our copying is not subject to any license. The inclusion of this notice in recent revisions of this file (including both 1.88 and 1.89) is consistent with the current policy and practice and, hence, is not to be removed. This report should be closed as no further action is required or appropriate. Regards, Kurt (as Executive Director of the OpenLDAP Foundation)

1 0

Re: (ITS#4693) Unnecessary licensing statement in core.schema?
by quanah＠stanford.edu 03 Oct '06

03 Oct '06

--On Tuesday, October 03, 2006 6:25 PM +0000 openldap-its(a)OpenLDAP.org wrote: Follow-on note: note that a literal reading of the current license would say that you're not allowed to modify the schema on your local system unless you write a completely new schema from scratch without referring to that one. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4693) Unnecessary licensing statement in core.schema?
by quanah＠stanford.edu 03 Oct '06

03 Oct '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) The core.schema file has the following included in it: ## Portions Copyright (C) The Internet Society (1997-2003). ## All Rights Reserved. ## ## This document and translations of it may be copied and furnished to ## others, and derivative works that comment on or otherwise explain it ## or assist in its implementation may be prepared, copied, published ## and distributed, in whole or in part, without restriction of any ## kind, provided that the above copyright notice and this paragraph are ## included on all such copies and derivative works. However, this ## document itself may not be modified in any way, such as by removing ## the copyright notice or references to the Internet Society or other ## Internet organizations, except as needed for the purpose of ## developing Internet standards in which case the procedures for ## copyrights defined in the Internet Standards process must be ## followed, or as required to translate it into languages other than ## English. ## ## The limited permissions granted above are perpetual and will not be ## revoked by the Internet Society or its successors or assigns. ## ## This document and the information contained herein is provided on an ## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING ## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ## HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF ## MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This is causing some unhappiness from the Debian folks, but their final conclusion is that core.schema is not copyrightable under US law: [snip email 1] > Doesn't the copyright in question apply to the RFC only? AFAICS, > core.schema basically reads: > 1. Part of OpenLDAP, with the following license: > 2. OpenLDAP license (see license.html) > 3. Based on an RFC, with the following license: > 4. RFC license > 5. Specific RFC attributions > 6. The schema itself [snip email 2] > Plus, this is an interface specification if I've ever seen one, and > interface specifications are not copyrightable under US law. [snip email 3] > If this file is a non-copyrightable interface definition, the bug here is > the presence of a copyright notice and license statement where there should > be none. If these are correct, then shouldn't this license actually be removed from core.schema? --Quanah

1 0

(ITS#4692) ppolicy.c module doesn't respect Draft policy
by alexandrelabiche＠yahoo.com 02 Oct '06

02 Oct '06

Full_Name: Alexandre LABICHE Version: 2.3.27 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.120.54.227) Hello, draft-behera-ldap-password-policy-xx.txt says: 5.3.2 pwdChangedTime This attribute specifies the last time the entry's password was changed. This is used by the password expiration policy. If this attribute does not exist, the password will never expire. And ppolicy.c overlay says contrary /* * Hmm. No password changed time on the * entry. This is odd - it should have * been provided when the attribute was added. * * However, it's possible that it could be * missing if the DIT was established via * an import process. */ Debug( LDAP_DEBUG_ANY, "ppolicy_bind: Entry %s does not have valid pwdChangedTime attribute - assuming password expired\n", e->e_name.bv_val, 0, 0); pwExpired = 1; Regards. Alexandre LABICHE

1 0

Re: (ITS#4691) syncrepl in refreshOnly dies when bind to provider fails
by hyc＠symas.com 02 Oct '06

02 Oct '06

I don't see any indication of an OpenLDAP software bug here. Use the "retry" parameter if your connections are unreliable. bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: 2.3.27 > OS: Linux 2.4 (RHEL 3) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.15.129.131) > > > One of our replicas sits on the other side of a relatively congested WAN link > (with multiple firewalls in between, which I have no control over). > > Since switching to syncrepl, it has been difficult to achieve a configuration > that supports replication reliably to any extent. > > Using syncrepl consumer configuration with: > > syncrepl rid=124 > provider=ldaps://<master hostname> > type=refreshOnly > interval="00:00:01:00" > searchbase="<suffix>" > scope=sub > attrs="*" > schemachecking=off > bindmethod=simple > binddn="<dn for consumer>" > credentials="<password for consumer>" > > I see replication dies frequently, it seems to occur when (for whatever reason) > the consumer fails to bind: -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4691) syncrepl in refreshOnly dies when bind to provider gails
by bgmilne＠staff.telkomsa.net 02 Oct '06

02 Oct '06

1 0

Re: (ITS#4690) segfault in ldap_count_values() with PHP
by Kurt＠OpenLDAP.org 01 Oct '06

01 Oct '06

At 06:12 PM 10/1/2006, ando(a)sys-net.it wrote: >madcoder(a)gmail.com wrote: >... >You know, what makes me mad about PHP is that it internally uses >something comparable to bervals, since the abstract type they use to >wrap strings takes care of the length of the string itself; but in the >LDAP extension, ldap_get_values() is used everywhere, and then strlen is >run to compute the length of the values! Why on earth don't they get >ldap_get_values_len() should be used instead? Somehow it got hardwired >in people's brain that ldap_get_values_len() is only good for "binary" >(that is, non-printable) stuff, and not for strings as well! Folks also tend to forget that U+0000 is a valid Unicode character, as is ASCII 0... but I digress. Kurt

1 0

Re: (ITS#4690) segfault in ldap_count_values() with PHP
by ando＠sys-net.it 01 Oct '06

01 Oct '06

madcoder(a)gmail.com wrote: ... You know, what makes me mad about PHP is that it internally uses something comparable to bervals, since the abstract type they use to wrap strings takes care of the length of the string itself; but in the LDAP extension, ldap_get_values() is used everywhere, and then strlen is run to compute the length of the values! Why on earth don't they get ldap_get_values_len() should be used instead? Somehow it got hardwired in people's brain that ldap_get_values_len() is only good for "binary" (that is, non-printable) stuff, and not for strings as well! p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs