https://bugs.openldap.org/show_bug.cgi?id=5919
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=8204
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6462
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=5919
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5919
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=6462
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5919
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gray(a)nxg.name
--- Comment #33 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** Issue 9080 has been marked as a duplicate of this issue. ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9080
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** This issue has been marked as a duplicate of issue 5919 ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8610
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=6462
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6462
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=8610
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10267
Issue ID: 10267
Summary: stats loglevel reduction
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: chris.paul(a)rexconsulting.net
Target Milestone: ---
In high volume situations, stats logging of all transactions is not worth the
cost of disk space and disk iops. However, turning logging off altogether
(loglevel 0) results in no visibility for errors.
It would be very useful to be able to log errors only.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10259
Issue ID: 10259
Summary: Wrong RID sends when using syncrepl provider
Product: OpenLDAP
Version: 2.6.8
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: florent.david(a)gmail.com
Target Milestone: ---
When using a custom syncrepl consumer bind to an OpenLDAP v2.6.8 provider and
it quickly appears than this provider sends to our consumer a cookie with a
Replica ID different from the original one.
In the logs below, we clearly see a refreshAndPersist synchronization
initialized whith a RID with value 606. After a while, on the same connection,
OpenLDAP syncrepl provider sends a new cookie with RID=612
66f2ea7d.3b1f8427 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: got a
persistent search with a
cookie=rid=606,csn=20240924154708.334351Z#000000#000#000000
66f2ea7d.3b1fafc0 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_findbase: searching
66f2ea7d.3b20ca28 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: registered
persistent search
66f2ea7d.3b20e5bf 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: no change,
skipping log replay
66f2ea7d.3b20ed6a 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: nothing
changed, finishing up initial search early
66f2ea7d.3b20f874 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_sendinfo:
refreshDelete cookie=
66f2ea7d.3b229483 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_search_response:
detaching op
66f2ed56.12f82965 0x7fa816dfe6c0 conn=92750 op=1 syncprov_qresp: set up a new
syncres mode=4 csn=20240924164822.305028Z#000000#000#000000
66f2ed56.12fa5399 0x7fa7f58fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a
new cookie=rid=612,csn=20240924164822.305028Z#000000#000#000000
66f2ed8d.053d71e3 0x7fa8165fd6c0 conn=92750 op=1 syncprov_qresp: set up a new
syncres mode=4 csn=20240924164917.069189Z#000000#000#000000
66f2ed8d.05405bb4 0x7fa7ed3fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a
new cookie=rid=612,csn=20240924164917.069189Z#000000#000#000000
Is it a normal behaviour ? Should consumer checks the Replica ID sends by
OpenLDAP before storing it ?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10265
Issue ID: 10265
Summary: Make it possible to change olcBkLloadListen at runtime
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Currently, olcBkLloadListen changes only take effect on lloadd startup:
- an added olcBkLloadListen should come online at the end of the modify
operation
- at the end of the modify operation a removed olcBkLloadListen will stop
listening on the sockets associated with it, clients that connected over these
are marked CLOSING
- to facilitate replacing a value where URIs resolved sockets overlap,
olcBkLloadListen should become a MAY in olcBkLloadConfig objectclass
Lloadd's startup was modelled upon slapd's, but the requirements have changed
considerably when it was turned into a module. Sockets are acquired at module
configuration time, which is much later than standalone/slapd's own startup and
so the way the URLs are handled also needs to be reworked. This will resolve
other related issues.
--
You are receiving this mail because:
You are on the CC list for the issue.