[Date Prev][Date Next]
Re: (ITS#6815) Feature Request: Accesslog filter
> firstname.lastname@example.org wrote:
>> Andrew Findlay wrote:
>>> On Wed, Feb 23, 2011 at 08:58:33AM +0000, email@example.com wrote:
>>>> Possibly we can extend the directive to handle exclusion as well as inclusion,
>>>> to simplify this case.
>>> Extending this idea slightly, would it be possible to have
>>> exclusions based on changes to specific attributes? The
>>> particular case I have in mind is where accesslog is used to
>>> keep a permanent audit log of changes, and ppolicy is also
>>> in use, resulting in one audit entry for every login
>>> failure. I have one site where a large proportion of the auditlog
>>> entries are login failures...
>> Perhaps in that case, it would be simpler just to set ppolicy's mods to be
>> internal-only and bypass the accesslog overlay. (Currently it does this
>> already, if the server is a single-master replica.)
>> So far you're talking about two different enhancements - the original poster
>> is trying to exclude a set of searches, and you're talking about excluding
>> modify ops. I'm not seeing any way yet to generalize from here such that all
>> operation types are addressed meaningfully, and I don't want to introduce
>> multiple special cases to the config language.
> A URI-based restriction specification could include/exclude based on
> suffix, filter and listed attributes with a unified syntax.
Yes... But what does the filter *mean* in
a modify op? filter on the target entry before it was modified, or after?
a search op? match the search request's filter, or filter on the search base?
a compare op?
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/