Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1044159 - [RFE] Support 'Content Synchronization Operation' (SyncRepl) - RFC 4533
[RFE] Support 'Content Synchronization Operation' (SyncRepl) - RFC 4533
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.0
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Rich Megginson
Viktor Ashirov
: FutureFeature
Depends On:
Blocks: 1082754 1109759 1115294 1185092 1249775
  Show dependency treegraph
 
Reported: 2013-12-17 16:33 EST by Nathan Kinder
Modified: 2015-08-03 15:06 EDT (History)
3 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.3.1-1.el7
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
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-05 04:31:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 09:26:33 EST

  None (edit)
Description Nathan Kinder 2013-12-17 16:33:43 EST
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47388

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 17:04:36 EST
$ rpm -qa | grep 389
389-ds-base-1.3.3.1-9.el7.x86_64
389-ds-base-libs-1.3.3.1-9.el7.x86_64

I verified functionality manually while drafting a test plan. 
Test coverage is pending.
Comment 4 errata-xmlrpc 2015-03-05 04:31:51 EST
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.

https://rhn.redhat.com/errata/RHSA-2015-0416.html

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