openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

(ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by douglas.royds＠taitradio.com 17 Oct '18

17 Oct '18

Full_Name: Douglas Royds Version: HEAD OS: Ubuntu 16.04 URL: ftp://ftp.openldap.org/incoming/douglas-royds-181017.patch Submission from: (NULL) (202.37.96.2) To achieve binary-reproducible builds across different build hosts, build paths, and users, we need to set the WHOWHERE value with something fixed. In this patch I set it to the SOURCE_DATE_EPOCH if set (see https://reproducible-builds.org/specs/source-date-epoch/). If you're not trying to do a reproducible build, it won't be set, so the existing WHOWHERE string will apply. Debian have set this string to their own Debian-specific value: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833179 WHOWHERE="$(dpkg-vendor --query vendor) package version $(dpkg-parsechangelog -SVersion)" Tait Communications Ltd hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8925) Please remove the entry for mirror.switch.ch from the Download page
by quanah＠symas.com 17 Oct '18

17 Oct '18

Hi Thomas, --On Thursday, October 11, 2018 12:08 PM +0000 switchmirror(a)switch.ch wrote: > I already sent twice a message to info(a)openldap.org, but no action or > answer received. The ITS system is the correct spot for this request. ;) > So I try it on this channel. > > Please drop the reference to SWITCH (Switzerland, mirror.switch.ch) on the > Download web page: > http://www.openldap.org/software/download/ Done. > BTW: I noticed that the Austrian mirror on gd.tuwien.ac.at has completely > disappeared, there is no DNS entry for it anymore. Thanks, I removed that one as well. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re:Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by quanah＠symas.com 17 Oct '18

17 Oct '18

--On Sunday, October 14, 2018 10:03 PM +0800 =E8=8E=AB=E4=BA=9A=E7=94=B7 = <nanmor(a)126.com>=20 wrote: > Run ' ldd /usr/local/openldap.2.4.46/bin/ldapsearch' in Redhat, result: > linux-vdso.so.1 =3D> (0x00007ffd959d6000) > libsasl2.so.3 =3D> /lib64/libsasl2.so.3 (0x00007fae80012000) > libssl.so.10 =3D> /lib64/libssl.so.10 (0x00007fae7fd9f000) > libcrypto.so.10 =3D> /lib64/libcrypto.so.10 Your Redhat build is linked to the system OpenSSL 1.0.2k release. This=20 clearly won't support TLS 1.3. lrwxrwxrwx 1 root root 16 Jun 19 14:00 libssl.so.10 -> libssl.so.1.0.2k Closing this ITS as invalid. I suggest fixing your build process on your=20 RedHat box to link to the correct OpenSSL build. It appears you have the=20 RH openssl development package installed, which is why you're encountering=20 various issues. However, none of this is related to OpenLDAP itself, which = as I've already noted, behaves correctly when all sides (client & server)=20 are linked to OpenSSL 1.1.1. --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#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 16 Oct '18

16 Oct '18

--On Tuesday, October 16, 2018 1:30 PM +0200 Ond=C5=99ej Kuzn=C3=ADk=20 <ondra(a)mistotebe.net> wrote: >> - test we're a replicated op, not just on shadow > > The patch is available here: > https://github.com/mistotebe/openldap/tree/its8927 I still get err 16 with this patch and the servers fall back to REFRESH. --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#8927) slapo-ppolicy is destructive to delta-sync replication
by ondra＠mistotebe.net 16 Oct '18

16 Oct '18

On Fri, Oct 12, 2018 at 05:32:52PM +0000, quanah(a)symas.com wrote: > --On Friday, October 12, 2018 5:27 PM +0000 quanah(a)symas.com wrote: > > > So this should succeed, and yet it fails. Need to figure out why. > > I dug into this further with Ondrej, and the issue is that ppolicy was > never updated to work correctly in a delta-sync MMR environment. ppolicy on > the receiving server currently has logic to test if it is a shadow (i.e., > replica) and if so, change its behavior. But there is no similar logic to > handle the case if the receiving server is an MMR node (i.e., a shadow and > a master). > > The following 3 changes to the code base for ppolicy would alleviate this > issue and other potential issues: > > - test we're a replicated op, not just on shadow The patch is available here: https://github.com/mistotebe/openldap/tree/its8927 > - issue MOD_REPLACE (concurrent binds could have cleared that attribute on > the other servers) > - expect MOD_REPLACE as well as MOD_DELETE on replicated ops Maybe not exactly required since ppolicy will actually treat these deletes as soft deletes if needed. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by ondra＠mistotebe.net 16 Oct '18

16 Oct '18

On Mon, Oct 15, 2018 at 02:54:56PM +0000, hyc(a)symas.com wrote: > Ondřej Kuzník wrote: >> On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc(a)symas.com wrote: >>> ondra(a)mistotebe.net wrote: >>>> Also, whenever we fall back from deltasync into plain syncrepl, >>>> we should make sure that the accesslog entries we generate from >>>> this are never used for further replication which might be >>>> thought to be a separate issue. >>> >>> That should already be the case, since none of these ops will have a >>> valid CSN. >> >> I faintly remember Quanah seeing these accesslog entries used by >> consumers at some point, but I might be mistaken. >> >> The more general point is making sure its potential syncrepl consumer >> not even try and use the accesslog entries we added before these - the >> refresh has created a strange gap in the middle (or worse, duplicated >> ops if a contextCSN element jumped backwards). But if we enforced that, >> the question is how to get modifications originating from this replica >> replicated elsewhere - unless we decide they can't be salvaged? > > We could set the replica to reject user mods while in refresh phase. > Not sure how friendly that is, whether apps would be smart enough to > retry somewhere else. The concern here is about changes that have happened before we found out we can't replicate from another server. And it is likely some of these changes are the reason we couldn't reconcile with our provider and would cause the same if we decided to push them. >> And should the contextCSN reset terminate not just all inbound syncrepl >> sessions, but the outbound ones as well? > > Need to be careful about race conditions here, or you could end up > with all nodes just terminating each other and everything halting. Yes, that would actually happen... The existing state seems quite destructive though, if you have that same situation now (two masters in present phase from each other at the same time), you lose data. The question is what is the priority here? Currently it seems we want replication to continue at the expense of losing modifications on conflict. We might at least log that happened and allow someone to revert this decision later. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by hyc＠symas.com 15 Oct '18

15 Oct '18

Ond=C5=99ej Kuzn=C3=ADk wrote: > On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc(a)symas.com wrote: >> ondra(a)mistotebe.net wrote: >>> Also, whenever we fall back from deltasync into plain syncrepl, we >>> should make sure that the accesslog entries we generate from this = are >>> never used for further replication which might be thought to be a >>> separate issue. >> >> That should already be the case, since none of these ops will have a v= alid CSN. >=20 > I faintly remember Quanah seeing these accesslog entries used by > consumers at some point, but I might be mistaken. >=20 > The more general point is making sure its potential syncrepl consumer > not even try and use the accesslog entries we added before these - the > refresh has created a strange gap in the middle (or worse, duplicated > ops if a contextCSN element jumped backwards). But if we enforced that, > the question is how to get modifications originating from this replica > replicated elsewhere - unless we decide they can't be salvaged? We could set the replica to reject user mods while in refresh phase. Not = sure how friendly that is, whether apps would be smart enough to retry somewhe= re else. > And should the contextCSN reset terminate not just all inbound syncrepl > sessions, but the outbound ones as well? Need to be careful about race conditions here, or you could end up with a= ll nodes just terminating each other and everything halting. --=20 -- 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#8125) MMR throws away valid changes causing drift
by ondra＠mistotebe.net 15 Oct '18

15 Oct '18

On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> This is my understanding of the above discussion: >> - deltasync consumer has just switched to full refresh (but is ahead >> from this provider in some ways) >> - provider sends the present list >> - consumer deletes extra entries, builds a new cookie >> - problem is that the new cookie is built to reflect the union of both >> the local and received cookies even though we may have undone some of >> the changes which we then ignore >> >> If that's accurate, there are some approaches that could fix it: >> >> 1. Simple one is to remember the actual cookie we got from the server >> and refuse to delete entries with entryCSN ahead of the provided CSN >> set. Problem is that we get even further from being able to replicate >> from a generic RFC4533 provider. >> >> 2. Instead, when present phase is initiated, we might terminate all >> other sessions, adopt the complete CSN set and restart them only once >> the new CSN set has been fully established. > > (2) makes sense. >> >> Also, whenever we fall back from deltasync into plain syncrepl, we >> should make sure that the accesslog entries we generate from this are >> never used for further replication which might be thought to be a >> separate issue. > > That should already be the case, since none of these ops will have a valid CSN. I faintly remember Quanah seeing these accesslog entries used by consumers at some point, but I might be mistaken. The more general point is making sure its potential syncrepl consumer not even try and use the accesslog entries we added before these - the refresh has created a strange gap in the middle (or worse, duplicated ops if a contextCSN element jumped backwards). But if we enforced that, the question is how to get modifications originating from this replica replicated elsewhere - unless we decide they can't be salvaged? And should the contextCSN reset terminate not just all inbound syncrepl sessions, but the outbound ones as well? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by hyc＠symas.com 15 Oct '18

15 Oct '18

ondra(a)mistotebe.net wrote: > This is my understanding of the above discussion: > - deltasync consumer has just switched to full refresh (but is ahead > from this provider in some ways) > - provider sends the present list > - consumer deletes extra entries, builds a new cookie > - problem is that the new cookie is built to reflect the union of both > the local and received cookies even though we may have undone some of > the changes which we then ignore > > If that's accurate, there are some approaches that could fix it: > > 1. Simple one is to remember the actual cookie we got from the server > and refuse to delete entries with entryCSN ahead of the provided CSN > set. Problem is that we get even further from being able to replicate > from a generic RFC4533 provider. > > 2. Instead, when present phase is initiated, we might terminate all > other sessions, adopt the complete CSN set and restart them only once > the new CSN set has been fully established. (2) makes sense. > > Also, whenever we fall back from deltasync into plain syncrepl, we > should make sure that the accesslog entries we generate from this are > never used for further replication which might be thought to be a > separate issue. That should already be the case, since none of these ops will have a valid CSN. > Maybe the ITS#8486 work might be useful for this if > we have a way of signalling to accesslog to reset minCSN accordingly > to the new CSN set. > > The former is simpler, but the latter feels like the only one that > actually addresses these problems in full. > -- -- 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#8125) MMR throws away valid changes causing drift
by ondra＠mistotebe.net 15 Oct '18

15 Oct '18

This is my understanding of the above discussion: - deltasync consumer has just switched to full refresh (but is ahead from this provider in some ways) - provider sends the present list - consumer deletes extra entries, builds a new cookie - problem is that the new cookie is built to reflect the union of both the local and received cookies even though we may have undone some of the changes which we then ignore If that's accurate, there are some approaches that could fix it: 1. Simple one is to remember the actual cookie we got from the server and refuse to delete entries with entryCSN ahead of the provided CSN set. Problem is that we get even further from being able to replicate from a generic RFC4533 provider. 2. Instead, when present phase is initiated, we might terminate all other sessions, adopt the complete CSN set and restart them only once the new CSN set has been fully established. Also, whenever we fall back from deltasync into plain syncrepl, we should make sure that the accesslog entries we generate from this are never used for further replication which might be thought to be a separate issue. Maybe the ITS#8486 work might be useful for this if we have a way of signalling to accesslog to reset minCSN accordingly to the new CSN set. The former is simpler, but the latter feels like the only one that actually addresses these problems in full. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

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