Bug 1044159 - [RFE] Support 'Content Synchronization Operation' (SyncRepl) - RFC 4533
Summary: [RFE] Support 'Content Synchronization Operation' (SyncRepl) - RFC 4533
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
Depends On:
Blocks: 1082754 1109759 1115294 1185092 1249775 2084180
TreeView+ depends on / blocked
Reported: 2013-12-17 21:33 UTC by Nathan Kinder
Modified: 2022-05-11 15:23 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Enhancement
Doc Text:
Feature: One of the LDAP standards RFC 4533 'Content Synchronization Operation' (SyncRepl) has been newly supported. For more details, see also RFC: https://tools.ietf.org/html/rfc4533
Clone Of:
Last Closed: 2015-03-05 09:31:51 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1134 0 None None None 2020-09-13 21:05:35 UTC
Github 389ds 389-ds-base issues 1136 0 None None None 2020-09-13 21:05:52 UTC
Github 389ds 389-ds-base issues 725 0 None None None 2020-09-13 20:35:56 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Nathan Kinder 2013-12-17 21:33:43 UTC
This bug is created as a clone of upstream ticket:

FreeIPA (bind-dyndb-ldap component) does synchronization between LDAP and external DNS database. Persistent search has some drawbacks for this use case:

=== Persistent search deficiencies ===
1. Persistent search doesn't offer 'signal'/'indication' that all existing records were sent to client already and now the client waits for updates. (I.e. an equivalent of 'Sync Info Message' from [[http://tools.ietf.org/html/rfc4533#section-3.4|RFC 4533 section 3.4.1]].)[[BR]]
 It seems that there is a workaround for this problem, but it complicates a client application: https://lists.fedoraproject.org/pipermail/389-users/2013-June/015990.html

2. The client application has to dump content of whole LDAP sub-tree to maintain consistency between LDAP and own state (e.g. application-specific database). This dump have to be re-done after any connection failure (and reconnection).

=== RFC 4533 use cases ===
1. More effective bind-dyndb-ldap.

2. (Potentially) A migration path to/from OpenLDAP?

Comment 2 Viktor Ashirov 2014-11-18 22:04:36 UTC
$ rpm -qa | grep 389

I verified functionality manually while drafting a test plan. 
Test coverage is pending.

Comment 4 errata-xmlrpc 2015-03-05 09:31:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.