openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8557) mdb_put may cause a cursor malfunction
by hyc＠symas.com 11 Jan '17

11 Jan '17

lazarev.michael(a)gmail.com wrote: > Full_Name: Michael Lazarev > Version: > OS: Linux, FreeBSD > URL: ftp://ftp.openldap.org/incoming/mdb_put_test.c > Submission from: (NULL) (128.70.151.136) > > > After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation > positions the cursor incorrectly. Test code is submitted here: > ftp://ftp.openldap.org/incoming/mdb_put_test.c > > Thanks for the report. Fixed now in git. -- -- 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#6077) Spurious uniqueness errors with filters in unique overlays
by yann-externe.soubeyrand＠edf.fr 10 Jan '17

10 Jan '17

Hi, It seems to be the same bug as bug #6825. If so, this bug is still present in 2.4.44. Regards Yann Soubeyrand

1 0

Re: (ITS#6825) unique_uri filter reaching beyond its intended target
by yann-externe.soubeyrand＠edf.fr 10 Jan '17

10 Jan '17

Hi, This bug is still present in 2.4.44. Also, it seems to be the same bug as bug #6077. Regards Yann Soubeyrand

1 0

Re: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH
by quanah＠symas.com 09 Jan '17

09 Jan '17

--On Monday, January 09, 2017 3:58 PM +0000 bhalsema(a)purdue.edu wrote: > > I apologize...I am not sure how I caused this to be reposted. I apologize > for the duplicate ticket. Thanks Beth, I'll close this one out as a duplicate. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH
by bhalsema＠purdue.edu 09 Jan '17

09 Jan '17

I apologize...I am not sure how I caused this to be reposted. I apologize for the duplicate ticket. Beth On Mon, 9 Jan 2017, openldap-its(a)openldap.org wrote: > Date: Mon, 9 Jan 2017 10:55:37 > To: bhalsema(a)purdue.edu > From: openldap-its(a)openldap.org > Subject: Re: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on > switching to REFRESH > > > *** 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#8564. > > 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#8564) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8564) > > 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=8564 > > Please remember to retain your issue tracking number (ITS#8564) > 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#8564) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH
by bhalsema＠purdue.edu 09 Jan '17

09 Jan '17

Full_Name: Beth Halsema Version: 2.4.44 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.210.177.153) The ppolicy overlay attempts to perform an LDAP_MOD_DELETE on attributes that have already been removed via a SLAP_MOD_SOFTDEL. This results in an error like the following: bdb_modify_internal: 16 modify/delete: pwdGraceUseTime: no such attribute bdb_modify: modify failed (16) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=16 matched="" text="modify/delete: pwdGraceUseTime: no such attribute" null_callback : error code 0x10 slap_graduate_commit_csn: removing 0x7f38bc11c4c0 20170106184533.027966Z#000000#001#000000 syncrepl_message_to_op: rid=001 be_modify uid=nd,ou=People,dc=example,dc=com (16) ... do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20170106184533.000001Z,cn=log), switching to REFRESH I will be uploading a tarfile th c contains a test script, ldif files (used by the test script), and a suggested patch. We have performed limited testing which demonstrated desirable behavior. NOTE: The test script looks for the LDIFs in the DATADIR. I tested the script using the openldap-2.4.44/tests/run script.

1 0

(ITS#8563) Documentation inconsistency for syncrepl for mdb
by dpa-openldap＠aegee.org 07 Jan '17

07 Jan '17

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4.44 OS: any URL: Submission from: (NULL) (141.2.134.77) The manual states in section 5.2.5.8 olcSyncrepl, second last paragraph: "The syncrepl replication mechanism is supported by the bdb and hdb backends". This text above is repeated in section 6.2.3.7 syncrepl. But in section 18.1.1.2. Syncrepl Details, fourth paragraph, is written 'The syncrepl engine, which is a consumer-side replication engine, can work with any backends. The LDAP Sync provider can be configured as an overlay on any backend, but works best with the back-bdb back-hdb, or back-mdb backends.' Can syncrepl work with any backend and does it work with bdb equally good as with mdb?

1 0

(ITS#8562) Typos in the documentation
by dpa-openldap＠aegee.org 07 Jan '17

07 Jan '17

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4.44 OS: any URL: Submission from: (NULL) (141.2.134.77) In the manual, - section 8.2.5 Access Control Examples, 2nd paragraph replace "allows anonymous to authentication against these entries" with "authenticate"; - section 13.2.4 Attibute Type Specification, 4th code snippet, replace "DESC 'common name(s) assciated with the object" with "associated"; - section8.8.1.1 LDAP Sync Replication, last paragraph, replace "is defined by a general search criteria consisting of base and scope': remove the 'a' in front of criteria. - section 20 Monitoring, 3rd paragraph "This information can be access with ldapsearch", substitute with "accessed".

1 0

(ITS#8561) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH
by bhalsema＠purdue.edu 06 Jan '17

06 Jan '17

1 0

Re: (ITS#8558) LMDB mdb_load plain text
by hyc＠symas.com 06 Jan '17

06 Jan '17

remy.chibois(a)expandium.com wrote: > Full_Name: Remy Chibois > Version: LMDB_0.9+ > OS: Debian "Jessie" > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (46.218.8.100) > > > when loading data into a LMDB database using plain text mode (mdb_load -T), > escaped hexadecimal pairs (such as \09 for a tab character) cause data to be > incorrectly converted. > > Replacing mdb_load.c line 251 with "*c1++ = *c2++;"nsnstead of "c1++; c2++;" > fixes the issue (after the first escaped sequence, characters from c2 pointer > need to be copied to c1 pointer in order to properly overwrite escaped > sequence). > > Thanks, fixed in git. -- -- 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