Re: transaction logging

[Will Ballantyne <Will.Ballantyne@gems1.gov.bc.ca>]

James Taylor wrote:
> I'm not clear of the benefit of putting this type of
> information in a database.  Do you mean an LDAP directory?

I had not meant an LDAP directory of transactions (ahem, changes), but
the ideas from Mark's message seem very good.  By using a different
back-end and keeping the changes in the LDAP directory we should be able
to get good results.

> Anyhow the notion of improved auditing has been bothering for
> a while but the approach I was thinking of was to modify the
> replication mechanism so that the transactions it uses are not
> always truncated away.  I've been looking at the replication
> trim log functionality of slurpd but it may be more appropriate
> to have slapd write a second replog file dedicated for archive/auditing.
> 
> Does this replog data suit your needs?

What do you think of the CHANGELOG approach with a separate back end and
possibly (I haven't finished reading the specs) some minor extensions
like new attributes?
 
> James
> 
> Will Ballantyne wrote:
> >
> > 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?
> >
> > --
> > Will Ballantyne             GEMS Technical Architect
> > mailto:Will.Ballantyne@gems1.gov.bc.ca
> 
> --
> James Taylor                         e-mail: JMTaylor@slb.com
> Austin Computing Services            phone:  1 512-331-3146
> Schlumberger Technologies, APC            fax:    1 512-331-3059
> P.O. Box 200015  Austin, Tx. USA

-- 
Will Ballantyne             GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca