https://bugs.openldap.org/show_bug.cgi?id=8847
--- Comment #40 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to HoweverAT from comment #39)
> Created attachment 807 [details]
> Add SOCKET_BIND_ADDRESSES Option
>
> New patch against latest master
>
> Changed:
> - Debug Improvements (Add client address in ldap_dump_connection, also print
> binded address in DEBUG_TRACE if used)
> - Bugfix
I would suggest submitting a merge request via your existing account at
https://git.openldap.org for review to ease the review process.
Regards,
Quanah
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8847
HoweverAT <laeufer4321(a)gmx.at> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #804 is|0 |1
obsolete| |
--- Comment #39 from HoweverAT <laeufer4321(a)gmx.at> ---
Created attachment 807
--> https://bugs.openldap.org/attachment.cgi?id=807&action=edit
Add SOCKET_BIND_ADDRESSES Option
New patch against latest master
Changed:
- Debug Improvements (Add client address in ldap_dump_connection, also print
binded address in DEBUG_TRACE if used)
- Bugfix
Thank you for your feedback in advance
Lukas
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Lukas Wimmer laeufer4321(a)gmx.at. I have not assigned rights and/or
interest in this work to any party.
I, Lukas Wimmer, 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.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9079
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|IN_PROGRESS |RESOLVED
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 9d5267e1
by Quanah Gibson-Mount at 2021-03-09T19:12:49+00:00
ITS#9079 - Fix minor issues with slapo-unique man page
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7865
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.5.3 |---
Assignee|quanah(a)openldap.org |bugs(a)openldap.org
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7865
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|has_patch |
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
Depends on|7335 |
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** This issue has been marked as a duplicate of issue 7335 ***
Referenced Issues:
https://bugs.openldap.org/show_bug.cgi?id=7335
[Issue 7335] Create process for updating man pages to handle both cn=config and
slapd.conf configurations
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7335
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|7865 |
CC| |wandel(a)b1-systems.de
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** Issue 7865 has been marked as a duplicate of this issue. ***
Referenced Issues:
https://bugs.openldap.org/show_bug.cgi?id=7865
[Issue 7865] man slapo-refint extended with olc-example
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8847
--- Comment #38 from Howard Chu <hyc(a)openldap.org> ---
(In reply to HoweverAT from comment #37)
> (In reply to Howard Chu from comment #36)
> > Since I've just been tinkering with debug output, this came to mind. With
> > this patch, it would be a good idea to add the locally bound IP:port to the
> > debug output somewhere, e.g. in ldap_dump_connection. Should probably use
> > the recently added lutil_sockaddrstr, and that function likely should be
> > moved into ldap_pvt_ instead of lutil.
>
> Hello,
>
> thank you for your input.
>
> I tried to add to ldap_dump_connection( see the "from" part, which is always
> printed out independet of )
>
> e.g. Output:
> ** ld 0x55974c710680 Connections:
> * host: localhost port: 389 (default)
> * from: IP=127.0.0.1:33676
> refcnt: 2 status: Connected
> last used: Tue Mar 9 12:01:18 2021
>
>
> ** ld 0x55974c710680 Outstanding Requests:
> * msgid 1, origid 1, status InProgress
> outstanding referrals 0, parent count 0
> ld 0x55974c710680 request count 1 (abandoned 0)
> ** ld 0x55974c710680 Response Queue:
> Empty
> ld 0x55974c710680 response count 0
>
> I tried to add to ldap_dump_connection the "from" part which is always
> output regardless of the new SOCKET_BIND_ADDRESSES option
>
> If this ok, i could provide a patch for it tomorrow :)
Yes, this is what I had in mind, thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8889
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|OL_2_5_REQ |
Assignee|ondra(a)mistotebe.net |quanah(a)openldap.org
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8847
--- Comment #37 from HoweverAT <laeufer4321(a)gmx.at> ---
(In reply to Howard Chu from comment #36)
> Since I've just been tinkering with debug output, this came to mind. With
> this patch, it would be a good idea to add the locally bound IP:port to the
> debug output somewhere, e.g. in ldap_dump_connection. Should probably use
> the recently added lutil_sockaddrstr, and that function likely should be
> moved into ldap_pvt_ instead of lutil.
Hello,
thank you for your input.
I tried to add to ldap_dump_connection( see the "from" part, which is always
printed out independet of )
e.g. Output:
** ld 0x55974c710680 Connections:
* host: localhost port: 389 (default)
* from: IP=127.0.0.1:33676
refcnt: 2 status: Connected
last used: Tue Mar 9 12:01:18 2021
** ld 0x55974c710680 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x55974c710680 request count 1 (abandoned 0)
** ld 0x55974c710680 Response Queue:
Empty
ld 0x55974c710680 response count 0
I tried to add to ldap_dump_connection the "from" part which is always output
regardless of the new SOCKET_BIND_ADDRESSES option
If this ok, i could provide a patch for it tomorrow :)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6912
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |needs_review
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6912
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9495
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8847
--- Comment #36 from Howard Chu <hyc(a)openldap.org> ---
Since I've just been tinkering with debug output, this came to mind. With this
patch, it would be a good idea to add the locally bound IP:port to the debug
output somewhere, e.g. in ldap_dump_connection. Should probably use the
recently added lutil_sockaddrstr, and that function likely should be moved into
ldap_pvt_ instead of lutil.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8847
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
Target Milestone|2.6.0 |2.5.4
Keywords|needs_review |
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8682
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|quanah(a)openldap.org |bugs(a)openldap.org
Keywords|needs_review |
Target Milestone|2.5.3 |---
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Patch welcome
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8682
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Malformatted man pages on |Malformatted man pages on
|AIX and Solaris |AIX
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8871
--- Comment #8 from hsuenju_ko(a)stratus.com <hsuenju_ko(a)stratus.com> ---
Sorry for not using the right forum. I will use a more appropriate mailing list
in the future.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8871
--- Comment #7 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
On Mon, Mar 08, 2021 at 12:30:55PM +0000, openldap-its(a)openldap.org wrote:
> --- Comment #6 from hsuenju_ko(a)stratus.com <hsuenju_ko(a)stratus.com> ---
> It seems cancel is not very useful if one cannot cancel itself and other thread
> can not cancel over same connection until the thread which performs the
> cancelled operation timeout either during the operation itself or during
> ldap_result, or doing the polling while waiting for ldap_result. Once you have
> timed out, there is no need to cancel, isn't it?
This bug tracker is not for usage questions, these should be posted to
the appropriate mailing list, usually openldap-technical.
None of what you're asking for would have worked if the thread calling
ldap_result were to release its locks anyway. You can still send a
cancel exop and you will get a response to both, if you require that the
other thread be notified immediately, you need to do that in your own
application as libldap has never had such ambitions.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8871
--- Comment #6 from hsuenju_ko(a)stratus.com <hsuenju_ko(a)stratus.com> ---
It seems cancel is not very useful if one cannot cancel itself and other thread
can not cancel over same connection until the thread which performs the
cancelled operation timeout either during the operation itself or during
ldap_result, or doing the polling while waiting for ldap_result. Once you have
timed out, there is no need to cancel, isn't it?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8871
--- Comment #5 from hsuenju_ko(a)stratus.com <hsuenju_ko(a)stratus.com> ---
Thanks for the explanation. What you are saying is that operations over same
connection needs to be serialized among threads if not doing what you
suggested. Is that correct? So if the application needs to do different
operations over same connection among thread it needs to do the following:
do async operation
get fd
do select/poll on the fd
do ldap_result with 0 timeout
And since every operation involves ldap_send_initial_request even the timeout
value specified for the operation itself has to be reasonable short enough to
prevent same lock situation. For most part we can use different connections to
perform various operations among threads except cancel has to be done over same
connection. Is that assumption correct?
Thanks!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8847
HoweverAT <laeufer4321(a)gmx.at> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #803 is|0 |1
obsolete| |
--- Comment #35 from HoweverAT <laeufer4321(a)gmx.at> ---
Created attachment 804
--> https://bugs.openldap.org/attachment.cgi?id=804&action=edit
Client Address Binding Option
A new try. I also updated the patch against latest.
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Lukas Wimmer laeufer4321(a)gmx.at. I have not assigned rights and/or
interest in this work to any party.
I, Lukas Wimmer, 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.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9079
--- Comment #4 from gray(a)nxg.name <gray(a)nxg.name> ---
> > * Each URI defines a set of object attributes
> > * One can have multiple olcUniqueURI attributes, _each of which_ creates a
> > 'domain'
> > * This doesn't say what a 'domain' is
>
>
> The concept of a "domain" is a key part of the mathematical concept of "sets". As this is clearly talking about sets, the definition of domain follows.
We may be thinking of different set theories, but in the mathematical set
theory I'm familiar with, there is no notion of 'domain'. Functions have
domains, codomains and ranges which are each sets, but that is part of the
theory of functions, not of sets.
Not that it matters, because 'domain' has a variety of meanings in computing
contexts, so it does no harm to be precise here. Since the text just above
this in the manpage talks of 'scope', in a sense which appears to at least
overlap with 'domain' here, I merely suggest that the text explain what it
means by 'domain'.
For concreteness, can I suggest:
Each `unique_uri` option defines a 'uniqueness domain' consisting of the set of
attributes which would be returned by the specified (RFC 4516) LDAP URI, or the
union of the sets of attributes returned by the URIs, if there is more than
one. The overlay ensures that no two attributes in this set have the same
value. In a 'strict' uniqueness domain (when the keyword 'strict' is present),
at most one attribute in the domain may have a null value; in a non-strict
domain more than one attribute may have a null value.
This uniqueness constraint is imposed independently for the attributes in each
uniqueness domain.
...and delete the paragraph 'It is possible...'
[If 'scope' is a different notion from 'domain', then the text might benefit
from some clarification about what the difference is; if they are the same
notion, then it might be useful to use the same term for both, or else the
careful reader will worry that there is a distinction being made that they
don't understand.]
> > * It's not clear where the quotes go, when combining with 'strict' or
> > 'ignore'
> > (I guess "strict ldap://...").
> > * Can 'strict' or 'ignore' be combined with the second or subsequent URIs?
>
>
> This is already explicitly answered in the man page:
>
> "Strictness applies to all URIs within a uniqueness domain" thus it must be combined with the full set of URIs in a given statement.
True. As implied above, it might be useful to relocate the remark about what
'strict' means, but the answer to my question was indeed implicit in the text
as it stands.
To be clear, I reiterate that I'm not suggesting the text is inaccurate, simply
that it is not as clear as it could be, and I wouldn't bother suggesting
documentation edits if the OpenLDAP documentation were not already unusually
high quality. Also, when I first read the manpage I largely got the point
pretty quickly (it's not a complicated notion), and it's only when I re-read
carefully that I started to have doubts.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8415
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
Keywords|OL_2_5_REQ |
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 59a21512
by Quanah Gibson-Mount at 2021-03-06T00:39:22+00:00
ITS#8415 - Fix copyright update for all known cases
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8682
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |needs_review
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9079
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |IN_PROGRESS
Keywords|OL_2_5_REQ |
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
https://git.openldap.org/openldap/openldap/-/merge_requests/277
--
You are receiving this mail because:
You are on the CC list for the issue.