PfBlockerNG - force rule update after reboot
-
I filed a bug as I was losing internet connection (or more precisely the DNS resolver) after reboot as the pfBlockerNG lists were missing after reboot.
https://redmine.pfsense.org/issues/6116#change-26253
Feedback on that issue traced it back to the fact I was using RAM disk - so on reboot the various files that pfBlockerNG was creating were lost, meaning the "server:include: /var/unbound/pfb_dnsbl.conf" line was failing in unbound so that the service wouldn't start.
I want to continue using RAM disks to avoid undue wear on my SSD. I'm therefore trying to use the shellcmd extension to kick off an update after reboot.
I have added the following line there:
/usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php update >> /var/log/pfblockerng/pfblockerng.log 2>&1
as a shellcmd, but it's not working. From the logs it appears that pfBlockerNG detects that the system is still booting and exits without an update.
Is there any way to force pfBlockerNG to rebuild the lists once rebooting has finished?
I thought of adding a "sleep" instruction into the above line, but that seems a bit clunky and I also haven't checked if shellcmds run asynchronously in pfSense (otherwise it'll block the boot).
Thanks.
-
Hi Andrew,
The package currently has a feature for Nano/RamDisk installations to backup and restore any pfBNG IP Aliastables. I could add more functionality to also backup the DNSBL database and restore that on Reboot… While it may fix the Unbound start issue, its still only a partial fix, as all of the other files in /var are removed on reboot for Nano/RamDisk installs...
There is a PR for RamDisk Management, which could potentially integrate the backup/restore functionality directly into pfSense. This would ultimately be the best solution.
https://github.com/pfsense/pfsense/pull/2902
Maybe the Devs will post some feedback and we can work towards a solution...
-
Thanks. That would seem the sensible way to go, particularly as someone has very kindly already done a pull request for it.
I couldn't see an option for the RAM disk backup/restore in pfBlockerNG itself, so I'm assuming it's always enabled. If you have the time, I could see a benefit to implementing the DNSBL backup too if only because it seems anomalous to have some of the settings backed up but not all.
Thanks for developing pfBlockerNG by the way - it really is a useful and well-used package for pfSense.