Define log retention

[Johannes_Schoen]

Hi Community,

I'm quite surprised, that I'm unable to answer a simple customer question:

How can I set a log retention time to the SmartLog/SMS server?
If I remember right, in R77.x there was a setting on the SMS object > Logging where a count of days could be defined to say: 'delete everything older than 30 days' or similar.

I cannot find anything about this in the R80.20 admin guides.

Can anybody help me out here?

The same goes to the Database Revision Controls - can I limit them to e.g. 10 Versions?
Is there a comfortable way to delete 30 of them in one command?

Best Regards
Johannes

[Vladimir]

The truncation of the old logs is configured here:

And the index retention is configured at the bottom of the screenshot above.

You can read this short write-up by me here:

https://community.checkpoint.com/t5/General-Management-Topics/Document-Logging-in-R80-in-a-single-se...

for additional information about logging in R80++.

[Johannes_Schoen]

@Vladimir: thanks for your reply, but that doesn't answer my question.
I've never seen a data retention policy by legal department which says we will need to store logs for 5GiB long.

Typically there is a duration of 30 or 60... days defined.

Isn't there a way to configure that with Check Point?

The market leader is able to do that - shouldn't be that hard:

The same goes for database revision backups

Looking forward to your input

[Vladimir]

@Johannes_Schoen , the size and the percentage of space are predictable values, the duration is not, as it dependent on the volume of logging which may vary drastically based on the complexity of your policy, number of users, depth of logging and numerous other factors.

Your management server may not even be capable of retaining said 30 days of logging, in which case this setting will be moot.

This said, there is some discussion going on about merits of enabling it and improving the logging configuration:

https://community.checkpoint.com/t5/Logging-and-Reporting/How-to-store-logs-Focus-on-time-range-inst...

There are also two workarounds mentioned, one script-based and another using GUIDBEDIT.

Yet another option is rotating files at Midnight and forwarding them to external server.

Forwarding will be purging local logs.

You are still stuck with the retention limit problem on the target server though.

[Johannes_Schoen]

in addition: the predictable space wasn't an issue with R77.30 - I guess this setting was just forgotten to migrate or because of deadline issues and as a customer and reseller, I think it's unacceptable to do a forced upgrade to a recommended version and we have less features as before

[LMartins]

How to obtain the "checkpoint daily logs retention configuration" using a command in clish mode ?

Thanks in advance

[Uri_Lewitus]

Hi Johannes

Hitting F1 while in SmartDashboard (this part is the 'old' SmartConsole) opens up the help window (attached)

Having said that I agree it should be part of the admin guide.

Thanks,

Uri

[Johannes_Schoen]

@Uri_Lewitus: thanks for your reply, but the issue with the retention stays the same.

@Vladimir: I know, that it's hard to calculate logs in advance, but other vendors got the same issue.
I guess this customer will be open to muddle things the dirty way by scripting a cron job - but this is an unacceptable way.

What do you do, if you have a big customer Check Point vs Palo Alto and this is a base requirement?
Manual scripting won't be satisfying - would cron-jobs be upgrade-persistent?

And I want to steer the questions as well regarding the revision control (same issue).
I found a mgmt_cli command to set a limit to eg. 30 files - is this a permanent setting or do I need to rerun this command every few days? Is this command documented in an official document? I don't want to say the customer it's written in a forum

[Vladimir]

@Johannes_Schoen , the issue of log retention based on duration as a decisive deal breaker has not come-up in the past four years that I've been involved with the client-facing practice. Not saying it is not needed, but that I have not run into it.

As to revision retention, there are no longer files as there were in R77 and prior versions, they are database records detailing changes. I am still uncertain as to the reason for purging these, but if you can explain it to me, perhaps I'll see the light 🙂

[Johannes_Schoen]

Hi,
well, that was just an example - I still think, this is a base requirement for every big system, that creates log files and that setting was present in R77.30.
Regarding revision control: Where is written that the versions are database records? The log partition is filling up and from my view there are 2 major factors: log files and database revisions which could be responsible for that.

[Dror_Aharony · Accepted solution]

Hi Johannes,

Regarding the Log Retention by Days option you're requesting:

We're currently working on it, Hopefully it'll be available in the next upcoming version or two.

Stay tuned...

[Johannes_Schoen]

@Dror_Aharony: Okay, thanks for your response - then we need to wait.

Can you tell me, if "mgmt_cli purge-published-sessions number-of-sessions-to-preserve "20"“ will limit the files permanently to 20 versions or just deleting all >20 on a one-time base?

[Dror_Aharony]

Hey, 

It will leave 20 revisions on a one-time basis.

After the command finishes, new revisions will be created, even over 20.

There’s no way to permanently limit the number of revisions from the API (or any other way AFAIK) 

[Johannes_Schoen]

Many thanks for your reply, answered all my questions