Project

General

Profile

Actions

Bug #12274

closed

Unbound fails to start if its configuration references a python script which does not exist

Added by Gertjan KROEB about 1 month ago. Updated about 24 hours ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
DNS Resolver
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
21.09
Release Notes:
Default
Affected Version:
2.5.2
Affected Architecture:
All

Description

After the installation, unbound works 'out of the box'.

When a previously saved config.xml is imported
and pfBlockerNG-devel was previously installed
and pfBlockerNG-devel was using the 'python' mode
then this part is added to unbound.conf

# Python Module
python:
python-script: pfb_unbound.py

The issue : this part is added without checking if /var/unbound/pfb_unbound.py actually exists.

Its possible that, after the "import.xml", pfBlockerNG-devel isn't installed yet, or not finished to install.

Solution (?) : before adding 'python' part (see above), the a file_exist() should be used to check if that file really exists.
( and if it doesn't (yet), a reminder should be logged / returned to the GUI that the unbound should be restarted later on, as python mode was asked for, but not available yet ? )

Unbound is restart with a failing config - /var/unbound/pfb_unbound.p is missing, and stops.

See also this forum thread :
'Catch 22' with fresh install, pfBlockerNG 3.0.0.16 and Python enabled

Actions #1

Updated by Jim Pingle about 1 month ago

  • Subject changed from New install : importing config.xml and pfBlockerNG was previous installed with Python mode enabled : unbound will fail to restart. to Unbound fails to start if its configuration references a python script which does not exist
  • Assignee set to Jim Pingle
  • Plus Target Version set to 21.09

As long as that script is actually selected in the unbound config GUI (picked as "Python Module Script") and not in custom options it should be possible to add a test like that.

It isn't specific to pfBlockerNG, the same could happen with any custom script on a fresh install since the user couldn't have copied it back in place yet.

Actions #2

Updated by Jim Pingle about 1 month ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #3

Updated by Kris Phillips 2 days ago

Tested in RC builds of pfSense Plus. Confirmed no longer an issue.

Actions #4

Updated by Jim Pingle about 24 hours ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF