Project

General

Profile

Actions

Bug #10927

closed

pfBlockerNG-devel fullfill the pfsense config history when RAM disk in use

Added by Laurent BONNIN over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
pfBlockerNG
Target version:
-
Start date:
09/24/2020
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
2.4.5-p1
Affected Plus Version:
Affected Architecture:
amd64

Description

Hi !

I set pfBlockerNG-devel to update DNSBL hourly, and it works fine.
But this hourly update use to be logged in the pfsense config history, and this cause the history to be full of pfBlockerNG-devel update, so we are unable to restore settings from other services.

On thread
https://forum.netgate.com/topic/156827/pfblockerng-fullfill-the-pfsense-config-history

A guy named John told me that is coming from the usage of RAM disk

He said "It looks like there is a issue in the pfb code (bad reference var usage in pfb_aliastables()) where it tries to create the earlyshellcmd and shellcmdsettings. Those changes never make it into the config.xml, so it just keeps trying to write them everytime pfb updates.

It might be a problem if you are using ramdisks. It is actually writing a "new" config file every time, so the logging is correct."


Files

pfsense.jpg (171 KB) pfsense.jpg Laurent BONNIN, 09/24/2020 03:21 AM
pfsenseramdisk.jpg (92.8 KB) pfsenseramdisk.jpg Laurent BONNIN, 09/24/2020 03:27 AM
Actions #1

Updated by Jim Pingle over 3 years ago

  • Project changed from pfSense to pfSense Packages
  • Category set to pfBlockerNG
Actions #3

Updated by Renato Botelho over 3 years ago

  • Status changed from New to Feedback
  • Assignee set to Renato Botelho

PR has been merged. Thanks!

Actions #4

Updated by Azamat Khakimyanov over 3 years ago

  • Status changed from Feedback to Resolved

Tested on 2.4.4_p3, on 2.4.5_p1 and on 2.5.0-DEVELOPMENT (built on Wed Nov 11 01:06:53 EST 2020)

On 2.4.4_p3 I still see '(system): pfBlockerNG: saving earlyshellcmd' in Config History which occur every hour.
But on 2.4.5_p1 and 2.5.0-DEV I don't see this behavior any more.

This bug can be marked resolved.

Actions

Also available in: Atom PDF