public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Burn Alting <burn@swtf.dyndns.org>
To: linux-audit@redhat.com
Subject: ausearch checkpoint capability
Date: Sat, 16 Aug 2014 09:25:16 +1000	[thread overview]
Message-ID: <1408145116.1503.53.camel@swtf.swtf.dyndns.org> (raw)

Steve,

One of the issues with ausearch's checkpoint code is how to recover from
failures. A classic failure is to perform a checkpoint on a busy system
and then delay too long before running the next invocation of ausearch
and as a result of the delay, the checkpointed event cannot be found in
the files in /var/log/audit. There are other failures, such as re-use of
inodes etc.

For those of you who haven't noted the ausearch --checkpoint change, it
basically records the details of the last complete audit event it
processed or printed in a checkpoint file. It records not only the event
time, but also the event node, serial, type and the file device and
inode. Thus, when you next invoke ausearch with this option, the next
event to process is the next complete event since the one recorded.

Should an error occur when attempting to find the next complete event to
process, ausearch will exit. At this point, I believe the best recovery
action is to extract only the event time from the checkpoint file and
ask for all complete events after that time (i.e. as opposed to the
usual action of comparing time, event id, type, log file details etc).

There are at last two solutions:
a. We can patch ausearch to take a --checkpoint-time-only flag which
means ausearch will look for all events since the time in the checkpoint
file. This provides the best granularity in time as it goes down to
msecs.
b. We extract the timestamp from the checkpoint file, convert it to a
date and time and use ausearch's --start option to find all events since
the time in the checkpoint file.

The first provides greater granularity in time as it goes to msecs.

Steve,

I can provide a patch. Do you want it?

Rgds
Burn

             reply	other threads:[~2014-08-15 23:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-15 23:25 Burn Alting [this message]
2014-08-18 18:13 ` ausearch checkpoint capability Steve Grubb
2014-08-18 21:49   ` Burn Alting
2014-08-18 21:59     ` Steve Grubb
2014-08-18 22:29       ` Joe Wulf
2014-08-20  8:18         ` Burn Alting
2014-08-20 16:57           ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1408145116.1503.53.camel@swtf.swtf.dyndns.org \
    --to=burn@swtf.dyndns.org \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox