Project

General

Profile

Actions
Copy link

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.

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

0%

Estimated time:
Plus Target Version:
Affected Version:
All
Affected Plus Version:
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.

Actions
Copy link
 #1

Updated by BBcan177 . almost 8 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...

Actions
Copy link
 #2

Updated by BBcan177 . almost 8 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...

Actions
Copy link
 #3

Updated by Kill Bill almost 8 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?

Actions
Copy link
 #4

Updated by Kill Bill almost 8 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.

Actions
Copy link
 #5

Updated by Jim Thompson over 7 years ago

  • Assignee set to Jim Pingle

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

Actions
Copy link
 #6

Updated by Jim Pingle over 7 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.

Actions
Copy link
 #7

Updated by Renato Botelho over 7 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #8

Updated by Kill Bill over 7 years ago

Definitely wrong ticket reference in the above commit.

Actions
Copy link
 #9

Updated by Jim Pingle over 7 years ago

  • Status changed from Feedback to Confirmed
  • % Done changed from 100 to 0
Actions
Copy link
 #10

Updated by giskard rt about 7 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

Actions
Copy link
 #11

Updated by John Silva almost 7 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.

Actions
Copy link
 #12

Updated by Kill Bill over 6 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

Actions
Copy link
 #13

Updated by Kill Bill over 6 years ago

The above is included in 2.1.1_10.

Actions
Copy link
 #14

Updated by Jim Pingle over 6 years ago

  • Status changed from Confirmed to Resolved
Actions
Copy link

Also available in: Atom PDF