#50558 nsDS5ReplicatedAttributeList search filter is hard coded
Opened 2 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

2 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 fitler is hardcoded, then we can decide later if we want to try and hcange hte DS behavior

Login to comment on this ticket.

Metadata