...
You might want to allow updates to this partition to only create snapshot tags. This way you don't need an extended operation to take a snapshot.
Design
...
There are different levels to which we can implement this feature. I think we should enable different pluggable implementations for the change log service to expose different levels of functionality. To enable this we have to design a few different interfaces for the service and it's subcomponents. The following levels of functionality should be possible:
- Simple Change Log: logs changes only (no snapshots)
- Taggable Change Log: allows tagging for snapshots
- Searchable Change Log: allows tagging and taking snapshots with search capabilities
The same change log logic can be used to swap out different components of a log store to provide varying capabilities and still apply tags and changes to the store interface. Let's take a look at some of the store interfaces which really act as an SPI for this subsystem:
Representing Changes
Every change in an LDAP server can be logged and tracked using an LDIF. A log of LDIF entries can track each new revision of the server. This can be used to audit changes on the DIT, on subtrees of the DIT, their entries and even on attributes. Each entry can track revisions in the change log using the revisions operational attribute. The revisions represent primary keys into the change log.
The change log should also track
Simple Logger
The first very basic functionality is to implement a basic logger. It has already been added, but some more elements need to be defined, like the way to start the logger turn versioning on and off, either via an LDAP extended request, or programmatically.
There is an existing page started by Ersin Er where you have a description of the existing ChangeLog interceptor :
Logging Subsystem
Semantics
We need to be able to start the logger, to stop it, to configure it, to select the requests, to select the users, etc. Here are a list of parameters we may want to set :
...
Parameter
...
Description
...
Mandatory
...
Logger name
...
The logger's name
...
...
Active
...
Activate or desactivate the log. Default to TRUE, and when set to FALSE, no other parameters should be given
...
Max Size
...
The maximum size of the log file
...
...
Saved Requests
...
The list of requests we want to save (AddRequest, DelRequest, for instance)
Default to ALL_REQUESTS
...
Saved Attribute
...
A list of attributes we want to store in the file. It may be associated with the
previous selection. '*' and '+' will be used for 'all users attribute' and 'all
operationnal attributes'
Default to '*'
...
Subentry
...
Define the subentry we want the logger to apply when logging. The user may want
to allow some users to log or not, or may define a set of entries which may be logged, etc.
Default to null : everything is loggable by default
...
Rotate
...
Define the way the file will be rotated : Daily, when exceeding a given size, after a certain period of time
Since this takes up a lot of space we're do this on a child page here
...
Active
...
Activate or desactivate the log. Default to TRUE
...
When we have defined those parameters, we will have to describe them using ASN.1, and to implement the ExtendedOperation.