#50558 nsDS5ReplicatedAttributeList search filter is hard coded
Opened 10 months ago by vashirov. Modified a month ago

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

10 months ago

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

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

8 months ago

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

8 months ago

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)

a month ago

Login to comment on this ticket.

Metadata