Re: transaction logging

["Mark D. Anderson" <mda@discerning.com>]

"Will Ballantyne" wrote:
>"Mark D. Anderson" wrote:
>> You should consider what your use case is -- do you want this
>> to build replication (that is what inspired CHANGELOG), or do
>> want this for auditing (SIGOPS), or for some other reason?
>
>I would like to do both. We have a requirement to be able to easily tell
>who changed what and when, and it would also be very useful if the
>replication was a little safer.

I think that the requirements for these two are divergent enough
that ultimately one solution will not satisfy both.

Auditing will need to be customizable, in much the same way
that web server logs are. Different sites may want the audit logs
to be in an efficient storage (binary) in a file not part of
the db, others might want it kept in an ascii ldif file (also
not part of the db), others might want it accessible over ldap.
Some sites may want lots of change data (user id, source ip, etc.), others not.

Replication is a very specific need, and hopefully openldap is
looking at LDUP:
    http://www.ietf.org/internet-drafts/draft-merrells-ldup-model-00.txt
The goal would be that an interoperable implementation be made
(abandoning slurpd which is less capable also).
Since the goal of replication is convergence, it is not necessary for
example to have the user id of changes to achieve it -- replication requires
less information than an audit. (It also requires a bunch of admin
entries though, for the replication agreements and so on.)
Because of interop requirements, it will not be very customizable
(and access control will probably be specific to replicas).

The two interrelate as well, of course -- what sort of change log
do you keep for changes performed as a result of being a replication consumer?

>
>I would be a little concerned with putting the transactions in the
>directory itself as CHANGELOG indicates.  Export of the directory using
>ldbmcat would export the entire change history as well.  That could be
>huge and add unnecessary work for sync runs to external systems that
>require checking the whole directory image.

presumably such sync's can be over just part of the DIT, but
anyway i agree; in most cases change history accessible over ldap
is probably too much of a hit for the mild benefit of uniform access.

>> You want to watch your use of the word "transaction", as making the
>> ldap server truly transactional (in the ACID sense) is an entirely
>> different project from merely change logging.
>
>Well, I would rather state "ACID transactional" if that's what I meant. 
>By transaction I mean the dictionary term: a communicative action
>involving two parties that influence each other.  

Oh, like email :).

-mda