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.
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.
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.
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.
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.
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.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=8618
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|ldapsearch - unexpected |Remove deprecated -h HOST
|behavior with "-h URI -p |and -p PORT options from
|PORT" |clients
Resolution|--- |TEST
Status|UNCONFIRMED |RESOLVED
--- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 66af4cfd
by Quanah Gibson-Mount at 2020-10-01T21:27:59+00:00
ITS#8618 - Remove deprecated -h and -p options to client tools
--
You are receiving this mail because:
You are on the CC list for the issue.