You are viewing limited content. For full access, please sign in.

Question

Question

audit trail missed rollover

asked on April 24, 2015

My Laserfiche installation had a period of time where audit logs failed to rollover due to file system permission problems.  I was left with about 50 .tmp files in my audit file location that represent the audit logs that failed to rollover.

 

How do I perform a rollover on them so they get compressed, renamed, and moved to the rollover directory like all the rest of my logs?

0 0

Answer

SELECTED ANSWER
replied on April 24, 2015

Erik,

First, backup the Laserfiche Repository database, Audit folder, and the rollover folder. That way you have a starting point you can go back to in case there is an issue with the following steps.

1. Query the auditlogs table in the repository database and there should be a row for each rolled over audit log (both ones that had succeeded and ones that had failed). For the audit logs that had failed to rollover, you can tell because there will be something in the tempname column. If it had succeeded, then the tempname would be NULL. Here is a screenshot showing three rolled over audit logs, one of which that had failed.

Now, what you will need to do is copy the .tmp file into the audit log rollover folder, where the rest of the rolled over log files are. Then you will need to rename the file back to its actual log name. In my case, I would rename LFAF9A4.tmp to Alex3-20150424-2.log after I had copied the file over.

Next, you need to update the auditlogs table and change the log_state for that failed rollover file from 0 to 1. I would run something like

update auditlogs
set log_state=1
where logname='Alex3-20150424-2.log'

Alternatively, you can rename all the files first and after cross-referencing them with the auditlogs table in the repository database correctly, just run something like

update auditlogs
set log_state=1

if you're sure all rows in that table should now be valid.

Finally, I'd recommend deleting the Audit Trail database and then going back into the Audit Trail Configuration page and reconfigure the database and date ranges so it creates a new Audit database and loads the audit data back into it. Now you should be able to report on all audit data in your date range.

1 0

Replies

replied on April 24, 2015

Thank you Alexander, I will do this during weekend maintenance.

 

One thing I still need is a way to compress these files as they are about 10x the size of their neighbors.

0 0
replied on April 24, 2015 Show version history

There isn't a way to manually compress those audit logs. They will need to remain in the uncompressed state while the other logs and future successfully rolled over logs can be compressed.

With that being said, you'll need to run a different query because compressed logs have a different log_state than uncompressed logs. The compressed logs have log_state 2 so those will need to remain. You may be able to run a query like

update auditlogs
set log_state=1
where log_state=0

to mass update the rows.

0 0
replied on April 24, 2015

Should I also update the tempname column to NULL?

0 0
replied on April 24, 2015

Sure. That will make things cleaner. We'll look into a better way of handling this situation in a future release.

0 0
replied on April 24, 2015

Got it.  Thanks.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.