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

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
Clone Of:
Environment:
Last Closed: 2015-03-05 09:31:51 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System 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 14:26:33 UTC

Description Nathan Kinder 2013-12-17 21:33:43 UTC
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 22:04:36 UTC
$ 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 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.

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.