https://bugs.openldap.org/show_bug.cgi?id=8113
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
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=8113
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.5.0 |---
Keywords|OL_2_5_REQ |
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8113
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Never mind, bug with the build of OpenLDAP I was using.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8113
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
In fact, for the ldap_get_dn.3.links file, only the first three links are
created, the rest are not:
Links file has:
ldap_explode_dn.3
ldap_explode_rdn.3
ldap_dn2ufn.3
ldap_str2dn.3
ldap_dnfree.3
ldap_dn2str.3
ldap_dn2dcedn.3
ldap_dcedn2dn.3
ldap_dn2ad_canonical.3
on an installation:
[root@tx02 man3]# ls ldap_explode*
ldap_explode_dn.3 ldap_explode_rdn.3
[root@tx02 man3]# ls ldap_dn2ufn*
ldap_dn2ufn.3
[root@tx02 man3]# ls ldap_str2dn.3
ls: cannot access ldap_str2dn.3: No such file or directory
[root@tx02 man3]# ls ldap_dnfree.3
ls: cannot access ldap_dnfree.3: No such file or directory
[root@tx02 man3]# ls ldap_dn2dcedn.3
ls: cannot access ldap_dn2dcedn.3: No such file or directory
(etc)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8113
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Quanah Gibson-Mount from comment #3)
> It's definitely not fixed.
>
> While it is a part of the ldap_get_dn.3 man page, the installation piece
> that's supposed to create a link to that man page for the ldap_str2dn
> function is not working.
According to commits, this has been in place since 2001. This bug report is
invalid.
Note:
make install DESTDIR=/tmp/xman
...
installing ldap_get_dn.3 in /tmp/xman/usr/local/share/man/man3
installing ldap_explode_dn.3 in /tmp/xman/usr/local/share/man/man3 as link to
ldap_get_dn.3
installing ldap_explode_rdn.3 in /tmp/xman/usr/local/share/man/man3 as link to
ldap_get_dn.3
installing ldap_dn2ufn.3 in /tmp/xman/usr/local/share/man/man3 as link to
ldap_get_dn.3
installing ldap_str2dn.3 in /tmp/xman/usr/local/share/man/man3 as link to
ldap_get_dn.3
installing ldap_dnfree.3 in /tmp/xman/usr/local/share/man/man3 as link to
ldap_get_dn.3
installing ldap_dn2str.3 in /tmp/xman/usr/local/share/man/man3 as link to
ldap_get_dn.3
installing ldap_dn2dcedn.3 in /tmp/xman/usr/local/share/man/man3 as link to
ldap_get_dn.3
installing ldap_dcedn2dn.3 in /tmp/xman/usr/local/share/man/man3 as link to
ldap_get_dn.3
installing ldap_dn2ad_canonical.3 in /tmp/xman/usr/local/share/man/man3 as link
to ldap_get_dn.3
...
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8113
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
It's definitely not fixed.
While it is a part of the ldap_get_dn.3 man page, the installation piece that's
supposed to create a link to that man page for the ldap_str2dn function is not
working.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8113
--- Comment #2 from jscott(a)posteo.net ---
This has been fixed. It's in my manpage on Debian Bullseye:
ldap_str2dn() parses a string representation of a distinguished name contained
in str into its components, which are stored in as ldap_ava structures,
arranged in LDAPAVA, LDAPRDN, and LDAPDN terms. Space for dn will be obtained
dynamically and should be freed by the caller using ldap_dnfree(3). The LDAPDN
is defined as:
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9015
--- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• afc970b1
by Howard Chu at 2020-09-15T12:08:22+01:00
ITS#9015 syncprov: fix for zero-length suffix
If the "" glue entry exists and lacks a contextCSN, must perform
an additional search to be sure the DB is otherwise empty. If so,
skip creating the contextCSN.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9338
Issue ID: 9338
Summary: slapd write waiter doesn't resume pending ops
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
If a socket output buffer fills up (e.g. because the client is not reading
responses fast enough) slapd will queue up any newly received operations on
that connection and defer their execution till later. In the new write waiter
code in master/2.5, after the socket becomes writable again the pending ops
are not getting rescheduled for execution because of a missing call to
connection_write(). As a result, a client waiting for these ops on that
connection to finish will be hung forever.
This bug impacts the syncrepl consumer in delta-sync mode if it loses sync and
has to fallback to Refresh mode, and its connection was backlogged on the
provider side. In the fallback case the consumer sends an Abandon for the
current search and issues a new Refresh search, but if the socket was blocked
on the provider side the new search won't execute.
A fix for the write waiter is ready, and also the consumer will be patched to
simply close the connection and open a new one on its fallback, to avoid
running into this problem.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8055
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
Keywords|replication |
Target Milestone|2.5.0 |---
--
You are receiving this mail because:
You are on the CC list for the issue.