389-ds-base

#50558 nsDS5ReplicatedAttributeList search filter is hard coded
Closed: wontfix by spichugi. Opened by vashirov.

Closed: wontfix
Reopen Issue

Issue Description

nsDS5ReplicatedAttributeList has the following format:

nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof authorityRevocationList accountUnlockTime

as seen here https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing-fractional-repl

The presence of the search filter implies that the filter part can be customized, but it's hard coded and server rejects any other filter:
https://pagure.io/389-ds-base/blob/master/f/ldap/servers/plugins/replication/repl5_agmt.c#_1421

static int
agmt_parse_excluded_attrs_config_attr(const char *attr_string, char ***attrs)
{
    int retval = 0;
    size_t offset = 0;
    char **new_attrs = NULL;
    /* First parse and skip the filter */
    retval = agmt_parse_excluded_attrs_filter(attr_string, &offset);
    if (retval) {
        goto error;
    }

I encountered a corner case where I wanted to customize the filter to exclude attributes from certain entries being filtered out, but couldn't.

I'm opening this ticket to discuss if it makes sense to have a customizable search filter in fractional replication.

I agree that it is tempting to change the filter to only apply the attribute list to a subset of entries. The use of "(objectclass=*) $ EXCLUDE" part is nowhere documented and in fact in the implementaion it is a constant string required.

I think the format was initially created with more ambitious options for fractional replication in mind but were never implemented. A reason for not extending the usage might be some difficult questions:
- if fractional is applied only to a subset of entries, how should the complement of these entries be handled - full replication or nor replication at all (with the problems of potentally missing parents) ?
- how would we handle changes to entries which either make them match the the filter or no longer match the filter, some attributes of these entries should (not)have been replicated, so how do we get a consistent consumer again ?

I think these problems are hard to resolve and so I suggest to still apply the fractional list to ALL entries, we could either remove the "Objectclass=*" part from the format to avoid confusion or at least update documentation to say that it cannot be changed

One change I could think of is to also implement a INCLUDE list to allow a positive list of attributes to be replicated

Metadata Update from @lkrispen:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

I agree with @lkrispen comment. Having a filter looks smart but leads to complex scenario (difficult to anticipate all of them), brings complexity for implementation and will have some performance impact. For example for each update to replicate, we need to retrieve the entry first to evaluate the filter on it.

If we decide to apply on ALL entries (objectclass=*), we could improve the parsing to be more flexible.

Need a doc bug to clarify that the filter is hardcoded, then we can decide later if we want to try and change the DS behavior
Edited by mreynolds

Metadata Update from @mreynolds:
- Issue set to the milestone: FUTURE

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1762843

We could change the format in the existing attribute to remove the filter. Have auto-fix on discovery of the old format and change it (replica_config_to_entry). Also log a warning if a filter is specified that is not "objectclass=*" and say that it has no effect.

Metadata Update from @mreynolds:
- Issue priority set to: normal
- Issue set to the milestone: 1.4.4 (was: FUTURE)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3614

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
High
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.