openldap-bugs October 2020

openldap-bugs@openldap.org

8 participants
426 discussions

[Issue 9342] New: delta-sync: relax requirements on delete ops
by openldap-its＠openldap.org 13 Oct '20

13 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9342 Issue ID: 9342 Summary: delta-sync: relax requirements on delete ops Product: OpenLDAP Version: 2.4.52 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently if the delta-sync consumer encounters any unexpected changes it always falls back to a regular refresh. We should allow it to proceed when a Delete op fails with NoSuchObject. While unexpected changes are still an indication of inconsistent logs, we can still safely advance to the next op in the sequence before giving up (if necessary) since the outcome is the same. The plain syncrepl consumer already has the same behavior for delete ops. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9361] New: accesslog logpurge generates new CSNs for its deletes
by openldap-its＠openldap.org 13 Oct '20

13 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9361 Issue ID: 9361 Summary: accesslog logpurge generates new CSNs for its deletes Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The delete operations that are performed by logpurge are for internal bookkeeping purposes and should not have new CSNs attached to them. In the current code, since each delete has a new valid CSN, the logDB's contextCSN becomes newer than its main DB's, and this can trigger the syncprov on the logDB to send NEW_COOKIE messages to all delta consumers. Meanwhile, the mainDB's contextCSN hasn't changed. As a result, the consumers' contextCSN for that SID will be newer than the provider's. Fix coming shortly. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9331] New: New Mirror in NL
by openldap-its＠openldap.org 13 Oct '20

13 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9331 Issue ID: 9331 Summary: New Mirror in NL Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: info(a)lyrahosting.com Target Milestone: --- Hi, With much pleasure, Lyra Hosting has created a new Mirror for OpenLDAP. Mirror is located in Netherland access methods: http and https Your mirror's available bandwidth: 200mbps An administrative contact email: admin(a)lyrahosting.com http://mirror.lyrahosting.com/OpenLDAP/ https://mirror.lyrahosting.com/OpenLDAP/ Kindly regards Dennis -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9017] Improving performance of commit sync in Windows
by openldap-its＠openldap.org 12 Oct '20

12 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9017 --- Comment #23 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • d1814f7e by Howard Chu at 2020-10-11T01:45:45+01:00 ITS#9017 fixes for encryption -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9357] New: OpenLDAP quick start guide link is 404 not found
by openldap-its＠openldap.org 03 Oct '20

03 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9357 Issue ID: 9357 Summary: OpenLDAP quick start guide link is 404 not found Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: never2fast4me(a)hotmail.com Target Milestone: --- Created attachment 770 --> https://bugs.openldap.org/attachment.cgi?id=770&action=edit Screenshot of the 404 not found error Unable to access the quick start guide: http://www.openldap.org/doc/admin/quickstart.html from: https://www.openldap.org/faq/data/cache/8.html Please update the documentation links. Thanks, Karl -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 02 Oct '20

02 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #22 from Konstantin Andreev <grapvar(a)gmail.com> --- (In reply to Howard Chu from comment #21) > > It's quite poor etiquette to respond to a thread without reading it from the > beginning. This ticket already makes the advantage clear. I certainly read the thread before responding. But I admit I should make this clear to facilitate the discussion. The only advantage I could assume from 2018-year thread is the ability to "Not to fix" the bug originally called [ldapsearch - unexpected behavior with "-h URI -p PORT"]. If this is what you mean as "advantage" then I could say that even simple WONTFIX would be better, because it, at least, does not harm current ldaptools users. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 02 Oct '20

02 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #21 from Howard Chu <hyc(a)openldap.org> --- (In reply to Konstantin Andreev from comment #20) > The most balanced approach is to remove *being used* features only when they > come into conflict with new features or enhancements. Not just because > "there is another way". What is the advantage in removing -h/-p? It's quite poor etiquette to respond to a thread without reading it from the beginning. This ticket already makes the advantage clear. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 02 Oct '20

02 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #20 from Konstantin Andreev <grapvar(a)gmail.com> --- (In reply to Howard Chu from comment #19) > > > > I think you might be mistaken with removing -h/-p. Why not to leave it > > as-is? It just works. > > These options have been deprecated since 2000, so you've had literally 20 > years to migrate away from them. "It just works" is incorrect, these options > are inadequate for most modern use cases. E.g., they're insufficient for > specifying ldaps or ldapi connections, while using -H with a URI handles all > use cases. You should ask instead: how many people do use them? It costs negligible to zero for you to just leave these features well enough alone, but it always costs money and efforts to migrate away. > These options have been deprecated since 2000, so you've had literally 20 > years to migrate away from them. If you are locked in OpenLDAP. But people use them because they are "lowest common denominator", supported by virtually any ldaptools suite. If you discard these options, you become (very?) special. The most balanced approach is to remove *being used* features only when they come into conflict with new features or enhancements. Not just because "there is another way". What is the advantage in removing -h/-p? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 02 Oct '20

02 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #19 from Howard Chu <hyc(a)openldap.org> --- (In reply to Konstantin Andreev from comment #18) > A lot of admin people will now be forces to rewrite, test and debug their > hard-worked and stable management/startup/monitoring scripts. Multiply this > by N, because unforeseen corner cases always arise with time. > > Some times such changes must be conducted via external > auditing/certification authority, that is a way costlier. > > And last, but not least, ... [-h] and [-p] are de-facto standard for > ldap-tools. > > E.g., at the moment I use identical ldapsearch command line parameters on > Linux and on Solaris, but since then I should learn, train and use two > different ways, with unavoidable confusing from time to time. > > I think you might be mistaken with removing -h/-p. Why not to leave it > as-is? It just works. These options have been deprecated since 2000, so you've had literally 20 years to migrate away from them. "It just works" is incorrect, these options are inadequate for most modern use cases. E.g., they're insufficient for specifying ldaps or ldapi connections, while using -H with a URI handles all use cases. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 02 Oct '20

02 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #18 from Konstantin Andreev <grapvar(a)gmail.com> --- A lot of admin people will now be forces to rewrite, test and debug their hard-worked and stable management/startup/monitoring scripts. Multiply this by N, because unforeseen corner cases always arise with time. Some times such changes must be conducted via external auditing/certification authority, that is a way costlier. And last, but not least, ... [-h] and [-p] are de-facto standard for ldap-tools. E.g., at the moment I use identical ldapsearch command line parameters on Linux and on Solaris, but since then I should learn, train and use two different ways, with unavoidable confusing from time to time. I think you might be mistaken with removing -h/-p. Why not to leave it as-is? It just works. -- You are receiving this mail because: You are on the CC list for the issue.

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 October 2020