Project

General

Profile

Bug #6603

pfblockerng's Unbound modifications leave system broken post-config restore

Added by Chris Buechler about 3 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
pfBlockerNG
Target version:
-
Start date:
07/11/2016
Due date:
% Done:

0%

Estimated time:
Affected Version:
All
Affected Architecture:

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.

Associated revisions

Revision 5280fd8d (diff)
Added by Renato Botelho over 2 years ago

Fix #6603: Wait while interface is in 'tentative' state before try to bind OpenVPN to its address

History

#1 Updated by BBcan177 . about 3 years ago

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...

#2 Updated by BBcan177 . about 3 years ago

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...

#3 Updated by Kill Bill about 3 years ago

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?

#4 Updated by Kill Bill about 3 years ago

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.

#5 Updated by Jim Thompson almost 3 years ago

  • Assignee set to Jim Pingle

JimP, please verify, and if not valid, close.
If valid, please hand-off to bbcan117

#6 Updated by Jim Pingle almost 3 years ago

  • 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.

#7 Updated by Renato Botelho over 2 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

#8 Updated by Kill Bill over 2 years ago

Definitely wrong ticket reference in the above commit.

#9 Updated by Jim Pingle over 2 years ago

  • Status changed from Feedback to Confirmed
  • % Done changed from 100 to 0

#10 Updated by giskard rt over 2 years ago

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

#11 Updated by John Silva over 2 years ago

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.

#12 Updated by Kill Bill about 2 years ago

Fed up with this issue. It breaks fresh 2.4 installs exactly as noted in the above comment - see https://redmine.pfsense.org/issues/7604#note-6

Use this workaround as needed: https://github.com/pfsense/FreeBSD-ports/pull/395

#13 Updated by Kill Bill about 2 years ago

The above is included in 2.1.1_10.

#14 Updated by Jim Pingle about 2 years ago

  • Status changed from Confirmed to Resolved

Also available in: Atom PDF