openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by hyc＠symas.com 06 Jan '17

06 Jan '17

rick(a)openfortress.nl wrote: > Full_Name: Rick van Rein > Version: 2.4 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8) > > > Hello, > > I found a nit in the OpenLDAP administrator's guide at > http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorization > > It mentions Proxy Authorization as a facility of SASL, something I never heard > of. The fact that you've never heard of it does not indicate a bug. Read RFC2222 about authorization identities. It is defined specifically for LDAP in RFC 4370. So the chapter title, and > perhaps its ordering underneath SASL, are not perfect. > > Good luck, > -Rick > > Closing this ITS. -- -- 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#8560) Proxy Authorization is mentioned as a SASL mech
by rick＠openfortress.nl 06 Jan '17

06 Jan '17

Full_Name: Rick van Rein Version: 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8) Hello, I found a nit in the OpenLDAP administrator's guide at http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorization It mentions Proxy Authorization as a facility of SASL, something I never heard of. It is defined specifically for LDAP in RFC 4370. So the chapter title, and perhaps its ordering underneath SASL, are not perfect. Good luck, -Rick

1 0

(ITS#8559) Syncrepl stuck after duplicated attribute modification on master
by matheus_morais＠sicredi.com.br 06 Jan '17

06 Jan '17

Full_Name: Matheus Morais Version: 2.4.42 OS: Red Hat 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (201.77.94.55) In an environment with syncrepl properly configured, if one modification with duplicated attributes values is applied on the "master" node, the "slave" stuck the replication until the entry is removed from cn=accesslog. Here is one LDIF example: dn: ou=marili_advogados,ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br changetype: modify - replace: SicrediEntidadePai SicrediEntidadePai: ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br - replace: SicrediEntidadePai SicrediEntidadePai: ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br This change is processed by master and appears like that on the cn=accesslog: dn: reqStart=20170103135721.000411Z,%3=accesslog objectClass: auditModify reqStart: 20170103135721.000411Z reqEnd: 20170103135721.000413Z reqType: modify reqSession: 1184351 reqAuthzID: cn=manager,dc=br reqControls: {0}{2.16.840.1.113730.3.4.2} reqDN: ou=marili_advogados,ou=terceiros,%n=sistema,cn=entities,dc=sicredi,dc=c om,dc=br reqResult: 0 reqMod: SicrediEntidadePai:= ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc =com,dc=br reqMod: SicrediEntidadePai:= ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc =com,dc=br reqMod: entryCSN:= 20170103135721.874447Z#000000#000#000000 reqMod: modifiersName:= cn=manager,dc=br reqMod: modifyTimestamp:= 20170103135721Z reqEntryUUID: 61dfd779-5799-4988-927b-914e75d6ae90 When the slaves try to apply that change, it results in a constraint violation. We can see that kind of message on the slaves logs: 2017-01-03T19:14:21.043501-02:00 ds1openldap5p slapd[2245]: syncrepl_message_to_op: rid=000 mods check (SicrediEntidadePai: multiple values provided) 2017-01-03T19:14:21.043599-02:00 ds1openldap5p slapd[2245]: do_syncrepl% r rid=000 rc 19 retrying 2017-01-03T19:15:21.039822-02:00 ds1openldap5p slapd[2245]: syncrepl_message_to_op: rid=000 mods check (SicrediEntidadePai: multiple values provided) 2017-01-03T19:15:21.039863-02:00 ds1openldap5p slapd[2245]: do_syncrepl: rid=000 rc 19 retrying I think we have two options here: 1 - This kind of LDIF should result in a constraint violation on the master node and the modification is not recorded on cn=accesslog. 2 - The accesslog overlay should remove the duplicated values from attributes. The first option seems more rational IMHO.

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