[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: transaction logging
>I would like to put in some code to have transactions automatically
>logged into a database rather than (or in addition to) a simple text
>file for the ldbm back-end. I would like to store the date, id, a
>unique serial number for the transaction, and the transaction data.
>This approach will allow for better and more flexible replication later,
>as well as better auditing.
>
>Anyone have comments/objections to this approach?
There are two relevant internet drafts, just FYI:
[CHANGELOG] G. Good, "Change Record Object Class Definition", 11 March 1998.
http://www.ietf.org/internet-drafts/draft-good-ldap-changelog-00.txt.
[SIGOPS] B. Greenblatt, P. Richard, "Signed Directory Operations Using S/MIME".
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-sigops-02.txt.
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?
Neither of the drafts above properly deals with the consequences
of proxy authentication via SASL -- in theory you'd like to know
both the proxy id and the user the proxy is acting for.
I think Netscape used CHANGELOG in their replication implementation in their
directory server v3 (g. good went to work for netscape). I haven't been
tracking the LDUP debates, so i don't know how good a fit it is anymore.
You have to think about what to do about "automatic" attributes like
modifiersName and modifyTime -- do you also log the changes to them.
Note that Innosoft uses the capability for multiple "backends" in their
LDAP server specifically for the changelog case -- it allows the changelog
entries to be placed not only in a different part of the DIT, but to be
done by a separate engine on a different disk partition, which aids in
performance. Innosoft is based on the umich sources; so far as i know
a similar capability could be added in openldap.
A related capability to changelog is the ability to log a text file in
ldif format which contains all the operations regardless of whether
it is an add, update, or delete. In principle, this file could be directly
imported with ldap_modify, if ldap_modify can handle anything besides adds.
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.
-mda