[Date Prev][Date Next]
Re: Syncrepl nits with operational attributes (ITS#3289)
I've just checked in this functionality to HEAD.
Inside syncrepl spec, you can specify
The original attrs directive remains the same and attrs and exattrs can be
The attributes in the attrs list are the list of attributes syncrepl
consumer request to the provider.
The attributes in the exattrs list are used as a local filter in the
consumer. The syncrepl consumer will filters out the listed attributes from
the entries returned from the provider.
----- Original Message -----
Sent: Friday, August 27, 2004 2:52 AM
Subject: Re: Syncrepl nits with operational attributes (ITS#3289)
> >For the moment you can just explicitly list
> >creatorsName/CreateTimeStamp/etc in the syncrepl attrs, and omit
> >anything else.
> >Perhaps we need to add a "attrs=!foo" config syntax to strip certain
> >attributes from the incoming records. I don't really like this approach
> >because it requires too much manual intervention.
> Interestingly, it looks like attrs!= is already supported (see
> add_replica_attrs()) but it doesn't allow per-attribute exclusions.
> Per-attribute exclusion would be very useful for maintaining
> attributes too expensive to replicate, such as password audit
> information (eg. lastLogon, logonCount, etc).
> Our password policy plugin updates these (it can even do these
> on "read-only" replicas because SLAPI internal operations are
> not subject to a backend's updateref). But of course as soon as
> the entry is changed on the master the attribute is overwritten.
> A workaround would be to explicitly list which attributes to replicate
> but this is inpractical with thousands of attribute types.
> -- Luke