Manually trigger trim of old firewall configs

[myowlit8930]

Hi there, Greg,

Previously, I was keeping all firewall configs with no time limit, but now I would like to reduce the number retained to 180 days. I followed the directions in the Documentation, Section 18.4. I also ensured all firewalls were set to use the global setting. I even toggled all firewalls it to a different setting and then changed it back to the global setting selection just in case that forced the setting to apply. However, the old firewall configs still exist in my database, and there are about 17k config versions being stored, the same number as when I started.

Is there a manual way to prune these or force the new retention rules to apply? Does this happen on a schedule automatically?

Thanks for your help in advance!

[gregober]

Can you please let us know which version of DynFi Manager you are running ?

We will open a ticket and inspect this.

[myowlit8930]

Hi Greg,

Thank you! We're running v23.3.1 presently, which I believe is latest. Let me know how I can help.

[astojanowski]

Hi!

I tried to reproduce the issue on 23.3.1 but unfortunately couldn't, both global and device specific settings worked and old configs were deleted in my case.

Config removal is automatic, scheduled every 12H (with first run 2H after starting DynFi Manager). If the job finds and deletes deletes any configs meeting the criteria, the event is noted in Manager logs (accessible in main menu), e.g.

Deleted configs older than 2023-12-29T11:22:50.087988Z for device c6aff242-28b5-485d-ab47-9961d5a50e28

Thank you for asking for a manual way of doing this. We'll add this feature and release it in next version.

In the meanwhile, could you please send your dynfi.log to our support? It can be the lastest log, or even better 2-3 latest. It's located in /var/log/dynfi/. If there's any exception thrown when the clearing job runs, we may be able to help faster.

Best regards.

[myowlit8930]

Hi Greg,

I just sent over the logs to your support e-mail for you/your team to review. I see what you mean, that the config removal seems to have run after some time has elapsed, because the count of configs in the database has been reduced upon re-inspection. It would still be helpful to have the manual retention action in case there's ever an acute case like this in the future, so thanks for being willing to build it into a future version. Let me know if you need anything else from us, and we'll be happy to oblige.

[astojanowski]

Hi!

Glad to hear it works. There's also nothing suspicious in the logs you've sent.

Thank you for reporting the issue, that would be all for the time being. We'll let you know when the manual removal is ready. We'll also make sure to clearly state (in docs or in the manager) the schedule of automatic removal.

Best regards.