Removing Old Audit Logs

[gtjones]

I'm testing auditing on Isilon using a VM and filled the cluster with audit logs. I need to remove the audit logs to continue testing. Does anybody have the procedure for removing audit logs? I would open a case, but with this being a VM, I don't think they would support it.

Thanks,

Greg

[Neproshennie]

You're correct that VMs are not officially supported. What version of OneFS is your virtual node/cluster?

--Jamie Ivanov

[Greg Jones]

EMC provided the procedure for removing audit logs.Like I said in the original post, EMC asks that you call to get support when performing this procedure. I believe the reason they want you to call for support is that stopping auditing disconnects all SMB shares. It's my hope that they Isilon makes this a feature in a future release. 

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Neproshennie]

The current KB article states that you would need to shutdown SMB and make it disruptive.

But why?

It's to maintain the file handles to the current audit logs.

You can cat the log file and redirect the output to another file, if you want, then echo null into the original logical.

echo "" > /path/to/audit/log

No interruption to services and the file handle remains intact.

I did have an amended procedure that goes through this but I was let go prior to me being able to get it published.

--Jamie Ivanov

[Peter Serocka]

On 2015 Feb 22 Sun, at 01:27, Neproshennie <jamie....@gmail.com> wrote:

> The current KB article states that you would need to shutdown SMB and make it disruptive.
>
> But why?
>
> It's to maintain the file handles to the current audit logs.
>
> You can cat the log file and redirect the output to another file, if you want, then echo null into the original logical.
> echo "" > /path/to/audit/log

Please don’t do that.

Truncating a file where another process has an open file handle
will give… interesting results.

The file will appear truncated at first, but when the active
process continues writing it does so at the position retained
in the (kernel’s notion of the) file handle.

The file will appear full size again, with zeros filled from
the beginning up to where the recent write has started.

(And these zeros don’t necessarily occupy disk space:
you’ve got a hole in you file. And by echo “” you didn’t
exactly truncate; now there’s a newline where it presumably
doesn’t belong.)

No way!

-- Peter

[Neproshennie]

Peter,

Actually that is incorrect. Given the way that the auditing daemon writes data, specifically referencing 7.1.x:

187    TAILQ_INSERT_TAIL(&rec->token_q, tok, tokens);

When TAILQ_INSERT_TAIL is called, it checks the file then appends the file with the new element with only one thread locking the file and writing based on the appropriate token.

646#define    TAILQ_INSERT_TAIL(head, elm, field) do {            \
647    QMD_TAILQ_CHECK_TAIL(head, field);                \
648    TAILQ_NEXT((elm), field) = NULL;                \
649    (elm)->field.tqe_prev = (head)->tqh_last;            \
650    *(head)->tqh_last = (elm);                    \
651    (head)->tqh_last = &TAILQ_NEXT((elm), field);            \
652    QMD_TRACE_HEAD(head);                        \
653    QMD_TRACE_ELEM(&(elm)->field);                    \
654} while (0)

Please refer to queue(3) for more information (https://www.freebsd.org/cgi/man.cgi?query=queue&sektion=3&manpath=FreeBSD+10.1-RELEASE)

--Jamie Ivanov

[Neproshennie]

I should have also expanded that when the audit daemon starts, it reads the log file and stores events in an internal array. If the log file was truncated and the events previously mentioned would be unavailable and the daemon would then invalidate previous entries in the cache resulting in a re-read and recreation of said array. So the cursor at that point would be irrelevant and new written events would appended as previously mentioned.

--Jamie Ivanov

[Peter Serocka]

Then how does the auditing daemon write the data?
And what will it do about the newline from echo “”?

If it keeps the handle open, at the position
after the last write, the behavior is as I wrote.

If it repeatedly closes and reopens the file for appending,
then one might interfere and truncate the file (to zero length),
but better not by writing a newline at the beginning…

If the daemons seeks back and forth in the file,
while allowing truncation from outside,
things would get quite unforeseeable.

Anyway, the outcome has no practical use
for dealing with Isilon SMB audit logs, as one should
follow their practice by all means for now.

-- Peter

[Peter Serocka]

But we were not talking about restarting the audit daemon.

Bottom line, the audit daemon has not (yet) been designed
for disposal of old logs on the fly, and apparantly
“dirty tricks” are somewhat hard to verify.

Thanks for sharing you thoughts and insights

-- Peter

[Neproshennie]

The goal is not to hangup or restart the auditing daemon.

You are correct that the auditing daemon has a long way to go but sometimes "dirty tricks" are needed as a band-aid if a hiccup cannot be tolerated.

If you liked this, you would have loved some of the "dirty tricks", requested by the customer, I designed for the FTP daemon. ;)

--Jamie Ivanov