openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#8802) ldappasswd ppolicy
by matsl＠irf.se 08 Feb '18

08 Feb '18

Full_Name: Mats Luspa Version: openldap-2.4.40+dfsg OS: 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) i686 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:6b0:27:cc:2740:e692:a5b1:4b0f) Hello! When you are using ppolicy password changed are recorded in pwdHistory attribute. ldappasswd can't be used due to that. It checks of some reason that pwdHistory not exists before it changes that password. If pwdHistory exists then the ldappaswd can't change the password. Here's the log file: 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace userPassword 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace pwdChangedTime 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: add pwdHistory 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace pwdChangedTime 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: add pwdHistory 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: 20 modify/add: pwdHistory: value #0 already exists 2018-02-08T09:42:45+01:00 mailserver slapd[725]: send_ldap_result: err=20 matched="" text="modify/add: pwdHistory: value #0 already exists" /Regards Mats

1 0

Re: (ITS#8801) Fix pending CSN queue
by Howard Chu 06 Feb '18

06 Feb '18

The problem was noticed because the accesslog overlay was invoking a spurious slap_graduate_commit_csn() on a CSN that had already been graduated by the underlying backend.

1 0

(ITS#8801) Fix pending CSN queue
by hyc＠openldap.org 06 Feb '18

06 Feb '18

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.75) Submitted by: hyc The CSN queue tracks in-progress write operations. It uses connID and opID to identify a CSN queue entry that corresponds to a given operation. This is error-prone in the case of syncrepl, which always uses the same connID and opID for all of its internal operations. Should just use the Operation pointer, which is always unique and unambiguous.

1 0

Re: (ITS#8800) MMR: out of date master will ignore history of its own changes
by quanah＠symas.com 30 Jan '18

30 Jan '18

--On Tuesday, January 30, 2018 9:04 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > Did the following test: > > 4-way MMR setup, database populated from an initial DB that has history > to it Per Howard's suggestion, I commented out lines 2390-2396 in syncprov.c, which allows the master to get fed back its own operations on startup. On the plus side, the database indeed get all the operations sent back. There were 1187 entries in the accesslog DBs of all 4 nodes. On the minus side, while server IDs 2,3, and 4 all agreed on the final resulting contextCSN, serverID 1 did not. Which then broke the ability for the nodes to communicate with each other (err=53) Last entry on serverIDs 1/2/3/4: dn: reqStart=20180130233019.000017Z,cn=accesslog objectClass: auditModify reqStart: 20180130233019.000017Z reqEnd: 20180130233019.000018Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=xxx,dc=yyy reqDN: dc=xxx,dc=yyy reqResult: 0 reqMod: contextCSN:= 20180130233019.035885Z#000000#001#000000 reqMod: contextCSN:= 20171130222521.056018Z#000000#002#000000 reqMod: contextCSN:= 20171130222318.939265Z#000000#003#000000 reqMod: contextCSN:= 20171203041258.811473Z#000000#004#000000 reqEntryUUID: 156eb8cc-18e9-1027-80e5-d3f2010890dc contextCSNs on 2/3/4: base contextCSN: 20180130233019.035885Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 accesslog contextCSN: 20180130233019.035885Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 contextCSNs on 1: base contextCSN: 20180130233019.035885Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 accesslog contextCSN: 20180130233016.137867Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 Note that the contextCSN is correct on the database root, but incorrect in the accesslog entry. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8800) MMR: out of date master will ignore history of its own changes
by quanah＠openldap.org 30 Jan '18

30 Jan '18

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Did the following test: 4-way MMR setup, database populated from an initial DB that has history to it Make several thousand MODs to serverID 1 only Stop serverID 1 wipe its database reload serverID 1 from the initial DB Expected result: serverID 1 REFRESHes from the other servers to sync up its database Actual result: serverID 1 updates its contextCSN to the last change op, but does not sync any actual changes back, leaving it out of sync with the rest of the cluster.

1 0

Re: (ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠symas.com 29 Jan '18

29 Jan '18

--On Monday, January 29, 2018 10:23 AM -0800 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > I'll continue testing for the other half of the fix (Deleting all but the > most recent entry from the accesslog during purge) This part appears to work as desired. I set the purge interval to 10 minutes, checking every 5 minutes. Made changes. All entries but the most recent one were removed after 15 minutes went by. Made more changes, did the same wait period, and again, all entries but the most recent were removed during the next cleanup interval. --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#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠symas.com 29 Jan '18

29 Jan '18

--On Friday, January 26, 2018 8:23 PM +0000 hyc(a)symas.com wrote: > A patch which skips deleting the final entry, and creates an initial > dummy log entry if needed, is available in > https://github.com/quanah/openldap-scratch/tree/its8100 for testing. Hi Howard, When reinstalling a 4-way MMR system from scratch, we still end up in REFRESH mode. In the database I'm loading, there are 4 contextCSN values, one per active master: contextCSN: 20171203010043.825769Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 When I start up the first master (serverID 4 in this case), a contextCSN value is properly written for it to the underlying db: Jan 29 10:06:06 anvil4 slapd[1949]: slapd starting Jan 29 10:06:06 anvil4 slapd[1949]: slap_queue_csn: queueing 0x7f54d4104220 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_queue_csn: queueing 0x7f54d4104cc0 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_graduate_commit_csn: removing 0x7f54d4104cc0 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_graduate_commit_csn: removing 0x7f54d4104220 20171203041258.811473Z#000000#004#000000 But when I start the other 3 masters, they do not write an entry for their CSN, and since there's no CSN value for them on the other masters either, they all fall back to REFRESH_DELETE: Jan 29 10:06:26 anvil4 slapd[1949]: do_syncrep2: rid=003 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Even worse, they do this for every master that comes online. I think the code needs to add an entry to the accesslog for every contextCSN value, not just the final contextCSN? I'll continue testing for the other half of the fix (Deleting all but the most recent entry from the accesslog during purge) Thanks! --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#8553) LMDB Windows UWP Patch
by hyc＠symas.com 29 Jan '18

29 Jan '18

temp(a)zeropass-app.io wrote: > Hi, why is this not merged yet? Any particular reason? Lack of support. AFAICS the only reason UWP exists is to support Windows 10 Mobile, which Microsoft has discontinued. The LMDB source is C code. Compiling under a C++ compiler is a non-goal and we will not support C++ syntax compatibility going forward. 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#8553) LMDB Windows UWP Patch
by temp＠zeropass-app.io 29 Jan '18

29 Jan '18

Hi, why is this not merged yet? Any particular reason?

1 0

Re: (ITS#8486) Syncprov sessionlog is inefficient, kills perf
by hyc＠symas.com 26 Jan '18

26 Jan '18

quanah(a)zimbra.com wrote: > --On Monday, August 29, 2016 9:16 PM +0000 quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.44 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.52.177) > > In doing testing for ITS#8491, I encountered this problem in my lab. Any > time a single replica is parsing the session log, all other operations on > the server come to a complete halt. I.e., slapd does *nothing* other than > handle the sessionlog query. This seems like a fatal problem. A patch for this is available for testing in https://github.com/quanah/openldap-scratch/tree/its8486. It no longer keeps the sessionlog mutex locked for the entire time that it's playing the log. -- -- 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