Introduction
This document describes design choices made regarding the ChangeLogService.
Representing Changes (deltas)
Every change made to the LDAP server can be logged and tracked using an LDIF. This is especially the case if the server's configuration is also moved into the DIT.
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 and act as a reference which can be used to query for information about changes from the server.
To enable operations to be reverted a change log must capture complete information to revert the change. The best way to do this is by calculating the reverse LDIF from the change and storing it along with the forward LDIF. We can calculate these reverse LDIF pretty easily using the following reverse operations on forward changes:
Forward Change |
Reverse Operation |
|---|---|
Add |
Delete |
Delete |
Add |
ModifyRdn |
ModifyRdn |
ModifyDn |
ModifyDn |
Modify.Add |
Modify.Remove |
Modify.Remove |
Modify.Add |
Modify.Replace |
Modify.Replace |
To revert a sequence of forward (F) LDIFs { F0, F1, F2, F3 } the reverse (R) LDIF operations are applied in the opposite order { R3, R2, R1, R0 }. Some optimizations can be inferred from a sequence to make reverting faster. For example if F0 represents an Add operation and the other changes represent Modify operations on the same entry then only R0 can be applied instead of the R3->R0 sequence of reverse LDIFs. For the time being we just note that these optimizations are possible for implementing reversion capabilities.
So the whole point to this exercise was to clearly define what we need to track for a change. Obviously we need a unique auto incrementing synchronized sequence to pull new revision numbers from. This will be used for the revision of a change. Each revision has a change associated with it. Here's a list of what needs to be tracked for each change:
- Revision Number: number assigned to the new state of the server once the change is applied
- Forward LDIF: the LDIF applied to switch from S0->S1 (rev0->rev1)
- Reverse LDIF the LDIF applied to revert from S1->S0 (rev1->rev0)
- Change Timestamp: the time the change occured (GMT)
- Principal: the distinguished name of the authorized user that made the change
Change Stores
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:
- Basic Change Log: logs changes only (no snapshots)
- Searchable Change Log: logs changes and allows searching on changes
- Taggable Change Log: allows tagging for snapshots
- Searchable and Taggable 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.
There are 4 kinds of stores represented:
- ChangeLogStore: the simplest kind of change log store that can be implemented (just for logging)
- Primary method is
long log( Principal dn, Entry forward, Entry reverse )
- Another method exists to get the current revision number (should be published in RootDSE perhaps)
- Primary method is
- TaggableChangeLogStore: this store allows for tagging for snapshots
- Two tag() methods exist one which generates a tag on the current revision another on a revision in the past
- SearchableChangeLogStore: a simple store which exposes access to a search engine over change log events
- SearchableTaggableLogStore: a taggable log store which enables searching over changes and tags
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) |
|
Saved Attribute |
A list of attributes we want to store in the file. It may be associated with the |
|
Subentry |
Define the subentry we want the logger to apply when logging. The user may want |
|
Rotate |
Define the way the file will be rotated : Daily, when exceeding a given size, after a certain period of time |
|
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.