Project

General

Profile

Actions
Copy link

Bug #12274

closed

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

Added by Gertjan KROEB over 3 years ago. Updated almost 3 years ago.

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

100%

Estimated time:
Plus Target Version:
22.01
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
Copy link
 #1

Updated by Jim Pingle over 3 years 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
Copy link
 #2

Updated by Jim Pingle over 3 years ago

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

Updated by Kris Phillips about 3 years ago

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

Actions
Copy link
 #4

Updated by Jim Pingle about 3 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #5

Updated by Jim Pingle about 3 years ago

  • Plus Target Version changed from 21.09 to 22.01
Actions
Copy link
 #6

Updated by Viktor Gurov almost 3 years ago

  • Status changed from Resolved to New

Doesn't work as expected, see https://redmine.pfsense.org/issues/12706
pfSense 22.01.r.20220117.2310

Actions
Copy link
 #7

Updated by Jim Pingle almost 3 years ago

Is that script chosen in the unbound options or inserted through custom options? If it's in custom options, it is not the same problem as this issue and can't be solved this way. See note 1 above.

Actions
Copy link
 #8

Updated by Jim Pingle almost 3 years ago

  • Status changed from New to Resolved

Closing this since the problem mentioned above appears to be specific to something pfBlocker is doing.

I can't replicate the original problem here on current snapshots. DNS Resolver is set to use a script, the script doesn't exist, and the DNS resolver is running w/o python as expected. If I put the script back in place and restart the resolver, it restarts with the python module loaded and the script in the config.

So this safety belt is doing all it can.

Actions
Copy link

Also available in: Atom PDF