Bug #6603
closed
pfblockerng's Unbound modifications leave system broken post-config restore
Added by Chris Buechler almost 8 years ago.
Updated over 6 years ago.
Description
pfblocker's "include: /var/unbound/pfb_dnsbl.conf" in the Unbound config leaves you with a broken system after config restore (if the system never had pfblocker installed previously). Unbound won't start, so package reinstall will fail, and without the reinstall of pfblocker on the restored system, the pfb_dnsbl.conf will never exist.
You end up with:
The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '/var/unbound/unbound.conf:93: error: cannot open include file '/var/unbound/pfb_dnsbl.conf': No such file or directory read /var/unbound/unbound.conf failed: 1 errors in configuration file [1468274779] unbound[81962:0] fatal error: Could not read config file: /var/unbound/unbound.conf'
Opening this in packages, though it might be something to address in base in unbound.inc. If the advanced config specifies any include file, and that file doesn't exist, touch it before starting.
Yes, this is a known issue... I can't fix it in the package as it needs to be addressed in unbound.inc.
I can add this to my todo list... but so far, I have not made any changes to the base pfSense code that are directly related to pfBlockerNG...
Something simple in unbound.inc - (Add the following after line 273):
if (strpos($ent, 'pfb_dnsbl.conf') !== false &&
!file_exists("{$g['unbound_chroot_path']}/pfb_dnsbl.conf")) {
touch("{$g['unbound_chroot_path']}/pfb_dnsbl.conf");
}
This will avoid the Resolver from failing. The User still has to "Force Update" pfBlockerNG to get the DNSBL file to populate.
I can post a PR, or this can be added to the file if deemed appropriate...
It can get complicated if a user adds other include: /blah/blah.conf lines, but splits it into two lines.... For the pfBlockerNG pkg, its all in one line...
Rather than such ad hoc hacks - cannot we get something like the sanity checking from pfBNG to Unbound itself? Like, test the config for sanity and drop any includes producing errors like "cannot open include file" from the config?
Oh, and - the original problem is much worse on nanobsd - no config restore needed. This breaks on every system upgrade due to /var being a ramdisk. If you do not have any other nameservers configured beyond the implicit 127.0.0.1, it also breaks packages reinstall and is pretty much game over due to Bug #6594.
- Assignee set to Jim Pingle
JimP, please verify, and if not valid, close.
If valid, please hand-off to bbcan117
- Assignee changed from Jim Pingle to Jim Thompson
It's still a problem on 2.3 and 2.4
Nov 29 16:10:54 php-cgi rc.bootup: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '/var/unbound/unbound.conf:88: error: cannot open include file '/var/unbound/pfb_dnsbl.conf': No such file or directory read /var/unbound/unbound.conf failed: 1 errors in configuration file [1480435854] unbound[22866:0] fatal error: Could not read config file: /var/unbound/unbound.conf'
The GUI validation is smart enough to reject the options since they cause unbound not to load, but that doesn't help until someone manually logs into the GUI to clear out the option. Perhaps the backend code needs to fall back to loading without advanced options if the first attempt fails.
bbcan177 isn't available as an assignment target in the list, assigning back to Jim T.
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Definitely wrong ticket reference in the above commit.
- Status changed from Feedback to Confirmed
- % Done changed from 100 to 0
maybe now I can only solve the ramfs related problem by completely backup /var and restore it on boot up, maybe with shellcmd and service watchdog
Ran into this issue today building a new 2.4 snapshot machine.
Is there any reason that /var/unbound/conf.d isn't being leveraged for included configurations? pfBlocker_NG could simply write its config there, and if not present unbound would still happily continue loading.
The above is included in 2.1.1_10.
- Status changed from Confirmed to Resolved
Also available in: Atom
PDF
Updated by 
Updated by Kill Bill 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by