'Catch 22' with fresh install, pfBlockerNG 3.0.0.16 and Python enabled

A Former User

Hi all,

I'm running pfSense 2.5.2 with pfBlockerNG-devel 3.0.0.16. I don’t use RAM-disks.
I have recently switched from Unbound to Python mode. All fine thus far.
Just now, I reinstalled the box, using the most recent 'config.xml' file on the designated partition of the install stick. It restored successfully, and the firewall booted well.

When I wanted to logon to the GUI, I noticed it was terribly slow. Turns out to be Unbound that was in a stopped state. Displaying System Logs > DNS Resolver showed me the following entries:

Aug 14 19:47:26	unbound	79385	[79385:0] fatal error: failed to setup modules
Aug 14 19:47:26	unbound	79385	[79385:0] error: module init for module python failed
Aug 14 19:47:26	unbound	79385	[79385:0] error: pythonmod: can't open file pfb_unbound.py for reading
Aug 14 19:47:26	unbound	79385	[79385:0] notice: init module 0: python

Now, the message is fully clear to me. The Unbound Python module tries to call 'pfb_unbound.py', which does not exist, as pfBlocker is not installed yet. Kind of a 'catch 22', as automatic package reinstallation failed as well, due to Unbound not being started, which in return leads to the package repository not being initialized.

Temporary fix: disabling the Python Module in Unbound will restart Unbound, after which I could reinstall packages, among which pfBlockerNG-devel.

I think this is a bug, as this has not happened with Python mode disabled.
@BBcan177 hope you are doing well, and can have a closer look to indeed verify if this is a bug.

SteveITS

@mg85 there’s a known issue with unbound stopping when pfblocker is installed. Per the maintainer it’s a pfSense issue not a package issue. Just start it from the status/dns page.

A Former User

@steveits thanks for your response! That’s the thing, it was a fresh install with restored config (package info backed up). Unbound will not start after boot, also not when instructing so via the Services panel. This is due to Unbound pointing to a (yet) non-existing pfBlocker script which only is restored after pfBlocker is installed. I had to disable Python mode first before I could even install any package or have DNS resolution at all.

My belief is that the script Unbound is pointing to is not properly restored, even before the whole package itself is installed. It is a hard dependency in the use-case I described, hence my ‘catch-22’ note ;).

I doubt this is a pfSense thing to be honest…

Gertjan

@mg85 said in 'Catch 22' with fresh install, pfBlockerNG 3.0.0.16 and Python enabled:

Just now, I reinstalled the box, using the most recent 'config.xml' file ....

I didn't need the rest of your words. You're right.
When a vanilla pfSense imports a config.xml, it uses these new settings and restart services and packages.
Somewhere, in the backgroun, it finds out that your backed up config.xml references some pfSense pakages that are not present yet, so it start to download and install them;

The resolver, unbound, is already there, and a config for unbound (unbound.ini) is build with this info :

		<python_script>pfb_unbound</python_script>

Or, that file is not part of the 'base' pfSense, but a package not yet installed.

edit 2021-08-19 : I'm wrong. After (re) install, pfSense doesn't know anything about pfBlocker or a "pfb_unbound" (python) script - so it will work.
When importing a pfSense config.xml - if unbound settings gets overwritten with the imported settings (which contain a "pfb_unbound" (python) script setting, and unbound restart before pfBlokcerNG gets a change of being installed, then things go wrong : unbound fails to restart.

Two intermediate solutions :

Some common sense tells me :
When importing a whole 'config.xml', wait until all packages are installed.
When done, do a clean reboot and done.
Consider the system as "not ready" while the reconstruction isn't done yet.
Side effect : because DNS goes down, pfSense will probably nt be able to install the packages (hence the catch 22).

Or, something II would do myself, as I know what packages I'm using :
On a vanilla pfSense, I install manually all packages I use(d).
When done, only then, I feed into pfSense my "config.xml".

A solution would be : pfSense should have a dummy pfb_unbound.py file.
Or, when the unbound.ini is build, a check should make sure that that file exists before informing 'unbound' to use it.

edit 2021-08-19 :

The issues is here.
The python file(s) listed in the config are added to the unbound.conf file
without testing if the(se) python file(s) actually exist in the (/b=var/unbound/) folder. It isn't .... so unbound refuses to start.

A Former User

@gertjan thanks a lot for your help and digging into this!
I will start using method 2, which is just doing a plain install, then install packages, followed by the config.xml restore. Makes perfect sense to me.

It would be great if the developers can raise this as an item on Redmine (I don't have an account there). @jimp would you be able to raise a bug there? Think a fix for this will definitely help others in the long run as well.

Gertjan

I created a redmine issue.

Please check it.

fireodo

@gertjan said in 'Catch 22' with fresh install, pfBlockerNG 3.0.0.16 and Python enabled:

I created a redmine issue.
Please check it.

Thank you! I have stumbled in this issue, a while a go, too:
pfBlockerNG unbound reinstall

Regards,
fireodo

Gertjan

@fireodo

Aha, it really looks like you experienced the same issue.

Gertjan

A solution was posted https://redmine.pfsense.org/issues/12274.

The 'patch' should be installed with the pfSense patch package.

Can't really test it, as I have to re install pfSense, something I've never had to to (for the last 10 years), I just upgraded .....

fireodo

@gertjan said in 'Catch 22' with fresh install, pfBlockerNG 3.0.0.16 and Python enabled:

A solution was posted https://redmine.pfsense.org/issues/12274.

The 'patch' should be installed with the pfSense patch package.

Thank you! Done.

Can't really test it, as I have to re install pfSense, something I've never had to to (for the last 10 years), I just upgraded .....

Lucky You!

Regards,
fireodo