New pfblockerNG install Database Sanity check Failed
-
@SteveITS Still seeing this error myself but have no further info. It does seem to function, just with the error being shown when it updates/reloads.
-
I was experiencing the same issue too.
After comparing /usr/local/pkg/pfblockerng/pfblockerng.sh from 3.2.0 to 3.2.8, there was only 1 line that changed and it happened to be related to this issue. After reverting that line (#1281) back to the way it was in 3.2.0, the "Sanity Check" works as expected.
Here are the lines as they exist in their respective versions.
#Line 1281 in 3.2.0 if [ "${s1} == ${s2}" ]; then #Line 1281 in 3.2.8 if [ "${s1}" == "${s2}" ]; thenEdit: Corrected my references to pfBlockerNG version numbers. Thanks @Maltz
-
@TheXman Wouldn't the 2.7.2 version always evaluate as true, since the string is non-null? It looks like the sanity check was fixed in 2.8.0, exposing some other issue that may have been there all along but was hidden by the broken sanity check.
(Edit: I guess the version numbers should be 3.2.0_8 and 3.2.8, respectively, since we're talking about pfBlockerNG and not pfSense itself.)
-
@Maltz That is an excellent hypothesis!
-
@marchand-guy Verified hypothesis. The code always reported true before 3.2.8.
Good catch -
Looks like dev (@BBcan177) is already reviewing. Good teamwork, y'all.
Responsible commit here. Remark indicates it was a cleanup commit. I don't have the coding skills to say for sure, but this
pfblocker.phpupdate and thispfblocker_alerts.phpupdate look odd for some reason, in addition to whatever thepfblockerng.shL1281 fix exposed. -
I think I found the last issue. The "masterfile" is a list of Filename/IPs. The "mastercat" file is just the IPs only. So it was trying to grep -v (exclude) any lines that start with the placeholder IP. So we need to change the masterfile to the mastercat in this line.
Try to change this line from:
From:
s1="$(grep -cv ^${ip_placeholder2}$ ${masterfile})"To:
s1="$(grep -cv ^${ip_placeholder2}$ ${mastercat})" -
@BBcan177 Thank you!
-
@BBcan177 Success!
Database Sanity check [ PASSED ]
-
@Maltz How?
No change on pfsense. -
@marchand-guy I manually made the change to the shell script that BBcan177 described.
-
@BBcan177 so next step is a new package for pfSense?
-
@Maltz said in New pfblockerNG install Database Sanity check Failed:
@marchand-guy I manually made the change to the shell script that BBcan177 described.
Ok, done as well.
Thanks -
Thanks, @BBcan177.
Some clear confusion ITT re pfSense system version and pfBlockerNG package version numbers. For posterity:
pfSense 2.7.2 CE - Database Sanity check issue not present, because
pfBlockerNGandpfBlockerNG-develpackages are both on "RELENG_2_7_2" branch ofpfSense / FreeBSD-PortspfSense 2.8 CE - Database Sanity check regression, possibly because branch updated to "devel" for both packages?
(
RELENG_2_7_2branch:pfBlockerNG/pfBlockerNG-devel)
(develbranch:pfBlockerNG/pfBlockerNG-devel)I think that's what's happened. Maybe someone can give me a sanity check.
The package version numbers appear to have been realigned in pfSense 2.8 CE however. The last package versions of
pfBlockerNGandpfBockerNG-develon pfSense 2.7.2 CE were3.2.8and3.2.0_20respectively.But under 2.8 CE, both packages are now currently on version
3.2.8(pfBlockerNGandpfBlockerNG-devel).Will both packages continue to be maintained separately and we should expect version numbers to potentially diverge again?
-
@tinfoilmatt Is there a fix or patch being published for this? Still waiting.
-
@madmaxpr I'm sure there will be, but @BBcan177's manual patch can be applied in the meantime.
File to edit is
/usr/local/pkg/pfblockerng/pfblockerng.sh, Line 1232 on my 2.8 CE/package version 3.2.8 system. -
@tinfoilmatt There are a few things that are not quite right in there... but the short version is that this has always been broken, it seems, but the check doesn't actually do anything apart from display the alert anyway.
In pfSense 2.7.2, pfBlockerNG and devel were at versions 3.2.0_8 and 3.2.0_20, respectively. In pfSense 2.8.0, they are both at v3.2.8.
Note that 3.2.0_8 ≠ 3.2.8
Versions 3.2.0_8 (and 3.2.0_20?) had two issues with the Database Sanity check. The first one broke the check entirely and it always showed PASSED no matter what. The second one was that the check was checking against "masterfile" instead of "mastercat"
The first problem was fixed in v3.2.8, which exposed the second problem. The second problem is fixed by the change BBcan177 described above.
And for those worrying about a patch - Since BBcan177 created the fix himself, I assume it'll be fixed in the next release. Also, this issue is strictly cosmetic, so there's not an urgent need for a new release to fix it. But if your OCD can't let it go (and I can relate lol) then just apply BBcan177's fix manually while we wait.
-
@Maltz said in New pfblockerNG install Database Sanity check Failed:
Versions 3.2.0_8 (and 3.2.0_20?) had two issues with the Database Sanity check. The first one broke the check entirely and it always showed PASSED no matter what. The second one was that the check was checking against "masterfile" instead of "mastercat"
The first problem was fixed in v3.2.8, which exposed the second problem. The second problem is fixed by the change BBcan177 described above.
Solid recap. So when all is said and patched, two relevant lines of
/usr/local/pkg/pfblockerng/pfblockerng.shshould read...Line 1232 (needs manual change until patch released):
s1="$(grep -cv ^${ip_placeholder2}$ ${mastercat})"Line 1281 (should already be present in package version 3.2.8):
if [ "${s1}" == "${s2}" ]; then -
here: running pfSense 2.8.0-RELEASE and pfBlockerNG 3.2.8-dev
Made the suggested change to line 1232.
Still same issue showing DNSBL (unbound mode) out of sync.
Should I revert the channge to ensure that the patch when available works correctly?
Thanks for nay help.
