Bind upgrade producing errors on pfsense 2.5 upgrade
-
I did a complete reinstall of PFsense 2.5.2 and restored my last configuration.
It did not reinstall all of the packages incl bind/named automatically after the first reboot
I got the following notice in the upper right cornerGeneral
Package named does not exist in current pfSense version and it has been removed. @ 2021-10-11 13:44:20
Package reinstall process finished successfully @ 2021-10-11 13:44:45It did automatically reinstall all the other packages
-
After the above notice/error I manualy reinstalled bind/named from the package manager
here's the log output
Installing pfSense-pkg-bind...
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
The following 5 package(s) will be affected (of 0 checked):New packages to be INSTALLED:
bind916: 9.16.16_1 [pfSense]
fstrm: 0.6.1 [pfSense]
pfSense-pkg-bind: 9.16_11 [pfSense]
protobuf: 3.14.0,1 [pfSense]
protobuf-c: 1.4.0 [pfSense]Number of packages to be installed: 5
The process will require 43 MiB more space.
6 MiB to be downloaded.
[1/5] Fetching pfSense-pkg-bind-9.16_11.txz: ... done
[2/5] Fetching bind916-9.16.16_1.txz: .......... done
[3/5] Fetching protobuf-c-1.4.0.txz: .......... done
[4/5] Fetching protobuf-3.14.0,1.txz: .......... done
[5/5] Fetching fstrm-0.6.1.txz: ......... done
Checking integrity... done (0 conflicting)
[1/5] Installing protobuf-3.14.0,1...
[1/5] Extracting protobuf-3.14.0,1: .......... done
[2/5] Installing protobuf-c-1.4.0...
[2/5] Extracting protobuf-c-1.4.0: .......... done
[3/5] Installing fstrm-0.6.1...
[3/5] Extracting fstrm-0.6.1: .......... done
[4/5] Installing bind916-9.16.16_1...
[4/5] Extracting bind916-9.16.16_1: .......... done
[5/5] Installing pfSense-pkg-bind-9.16_11...
[5/5] Extracting pfSense-pkg-bind-9.16_11: .......... done
Saving updated package information...
done.
Loading package configuration... done.
Configuring package components...
Loading package instructions...
Custom commands...
Executing custom_php_install_command()...done.
Executing custom_php_resync_config_command()...rndc: connect failed: 127.0.0.1#8953: timed out
rndc: connect failed: 127.0.0.1#8953: timed out
rndc: connect failed: 127.0.0.1#8953: timed out
rndc: connect failed: 127.0.0.1#8953: timed out
rndc: connect failed: 127.0.0.1#8953: timed out
rndc: connect failed: 127.0.0.1#8953: timed out
done.
Menu items... done.
Services... done.
Writing configuration... done.Message from bind916-9.16.16_1:
--
BIND requires configuration of rndc, including a "secret"
key. The easiest, and most secure way to configure rndc is
to run 'rndc-confgen -a' to generate the proper conf file,
with a new random key, and appropriate file permissions.The /usr/local/etc/rc.d/named script will do that for you.
If using syslog to log the BIND9 activity, and using a
chroot'ed installation, you will need to tell syslog to install
a log socket in the BIND9 chroot by running:sysrc altlog_proglist+=named
And then restarting syslogd with: service syslogd restart
Cleaning up cache... done.
Success -
@gertjan
I use ACME with DNS-NSUpdate method on the PFSense box which works great
I need the ACME certificates on de PFSense box because I also use HA-Proxy SSL ofloading for a number of websites. -
Here the complete log:
here's the log output:
>>> Installing pfSense-pkg-bind... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. The following 5 package(s) will be affected (of 0 checked): New packages to be INSTALLED: bind916: 9.16.16_1 [pfSense] fstrm: 0.6.1 [pfSense] pfSense-pkg-bind: 9.16_11 [pfSense] protobuf: 3.14.0,1 [pfSense] protobuf-c: 1.4.0 [pfSense] Number of packages to be installed: 5 The process will require 43 MiB more space. 6 MiB to be downloaded. [1/5] Fetching pfSense-pkg-bind-9.16_11.txz: ... done [2/5] Fetching bind916-9.16.16_1.txz: .......... done [3/5] Fetching protobuf-c-1.4.0.txz: .......... done [4/5] Fetching protobuf-3.14.0,1.txz: .......... done [5/5] Fetching fstrm-0.6.1.txz: ......... done Checking integrity... done (0 conflicting) [1/5] Installing protobuf-3.14.0,1... [1/5] Extracting protobuf-3.14.0,1: .......... done [2/5] Installing protobuf-c-1.4.0... [2/5] Extracting protobuf-c-1.4.0: .......... done [3/5] Installing fstrm-0.6.1... [3/5] Extracting fstrm-0.6.1: .......... done [4/5] Installing bind916-9.16.16_1... [4/5] Extracting bind916-9.16.16_1: .......... done [5/5] Installing pfSense-pkg-bind-9.16_11... [5/5] Extracting pfSense-pkg-bind-9.16_11: .......... done Saving updated package information... done. Loading package configuration... done. Configuring package components... Loading package instructions... Custom commands... Executing custom_php_install_command()...done. Executing custom_php_resync_config_command()...rndc: connect failed: 127.0.0.1#8953: timed out rndc: connect failed: 127.0.0.1#8953: timed out rndc: connect failed: 127.0.0.1#8953: timed out rndc: connect failed: 127.0.0.1#8953: timed out rndc: connect failed: 127.0.0.1#8953: timed out rndc: connect failed: 127.0.0.1#8953: timed out done. Menu items... done. Services... done. Writing configuration... done. ===== Message from bind916-9.16.16_1: -- BIND requires configuration of rndc, including a "secret" key. The easiest, and most secure way to configure rndc is to run 'rndc-confgen -a' to generate the proper conf file, with a new random key, and appropriate file permissions. The /usr/local/etc/rc.d/named script will do that for you. If using syslog to log the BIND9 activity, and using a chroot'ed installation, you will need to tell syslog to install a log socket in the BIND9 chroot by running: # sysrc altlog_proglist+=named And then restarting syslogd with: service syslogd restart >>> Cleaning up cache... done. Success -
Everything was working fine with PFsense 4.5.x, I first encountered the bind issues after the upgrade to 2.5.0
-
Ah, ok.
Executing custom_php_resync_config_command()...rndc: connect failed: 127.0.0.1#8953: timed out
When installed, bind (named) can't run right away. It probably needs some setup first.
And if it runs right away during the install, as the default is 'bind ports (853, 53) to all interfaces, this would clasch with unbound right from the start.Why rndc is used during install : I can't tell.
Maybe related to this :BIND requires configuration of rndc, including a "secret" key. The easiest, and most secure way to configure rndc is to run 'rndc-confgen -a' to generate the proper conf file, with a new random key, and appropriate file permissions.But again, like nearly any other pfSense, package, the service won't run as it needs a proper set up first.
What happens when you install bind, and while it's loading, you stop the unbound service.
bind (named) will probably start as it can use all the ports/interfaces it needs.
After that, you fine tune bind, and restart it.
Then you can start unbound also. -
@gertjan
rndc-confgen -a creates default config in /usr/local/etc/namedb while de pfSense uses a chroot environment for bind/named. (in /cf/named/etc/named/)Like I said bind/named was working fine in psSense 4.5.x without issues
The message/notice after a full new psSense install and restore the configuration is also not good
"General
Package named does not exist in current pfSense version and it has been removed. @ 2021-10-11 13:44:20
Package reinstall process finished successfully @ 2021-10-11 13:44:45"I hope the issues get fixed soon
-
@matthijs said in Bind upgrade producing errors on pfsense 2.5 upgrade:
Package named does not exist in current pfSense version and it has been removed. @ 2021-10-11 13:44:20
'named' is called 'bind' now.
Not really an issue.
It will break the auto re install of course. You had to install in manually. -
I think the issue is caused by something wrong in /usr/local/etc/rc.d/named
-
@matthijs said in Bind upgrade producing errors on pfsense 2.5 upgrade:
/usr/local/etc/rc.d/named
-
Configuration:
unbound is listening on:
192.168.10.1
192.168.20.1
localhost
The control port is set to 953bind is listening on
192.168.10.9
The control port is set to 8953
some zones are dynamic and updated by the dhcp servicepfblocker with dnsbl is enabled
The problem:
Upon rebooting the server, startup is really slow. This happened during and since the upgrade to version 21 (aka 2.5)
Investigation:
reboot the server and connect with the serial console and ssh
When server seems frozen run ps -aux | grep (various names here name/bind/rndc) on the ssh console
We notice rndc is being started multiple times (rndc freeze/thaw commands) and take a long time to complete (it seem to go over all defined bind zones) freeze/thaw operations are related to editing the zone files manually on a dynamic zone
We notice no new services are starting while bind is in this process loop
keep killing the rndc processes and the boot sequence will finish in a reasonable time
leave it running and pfsense will eventually finish starting (seems to depend on the number of zones configured in bind)Possible causes:
rndc commands are being run before bind is started (rndc cannot start bind on its own)
rndc is using the wrong port
bind is started but control channel is on the wrong port -
@aligator638
I rather see this issue fixed, but a workaround can be installing the package "Shellcmd" and add the following line:/usr/local/sbin/named -c /etc/namedb/named.conf -u bind -t /cf/named/
My system boots a lot faster/services starting faster with this workaround
-
@matthijs it is a workaround but still what is meant by these commands ? Are they essential ? That is the question. IMHO pfsense is trying to do something with the zones at startup. like freeze - do something with the zone- thaw etc... bypassing this process could have some impact.
-
@aligator638 said in Bind upgrade producing errors on pfsense 2.5 upgrade:
IMHO pfsense is trying to do something with the zones at startup. like freeze - do something with the zone- thaw etc... bypassing this process could have some impact.
For that to work, named has to be started first ;)
That's what this :
@matthijs said in Bind upgrade producing errors on pfsense 2.5 upgrade:
/usr/local/sbin/named -c /etc/namedb/named.conf -u bind -t /cf/named
does.
-
If you search your (backup) config file for the following lines:
<package>
<name>bind</name>
<internal_name>named</internal_name>change it to:
<package>
<name>bind</name>
<internal_name>bind</internal_name>You do not get the warning during config restore that named is now called bind in PFsense packages, and the packet re installation continues without errors or warnings
-
@gertjan Yes, but this is the job of pfsense to start the service, I should not make a 3 hours long trip to console into the firewall and start the service manually every time a reboot is required.
-
@matthijs said in Bind upgrade producing errors on pfsense 2.5 upgrade:
You do not get the warning
No warnings .... as I'm not using bind / named.
@aligator638 said in Bind upgrade producing errors on pfsense 2.5 upgrade:
I should not make a 3 hours long trip to console
Don't we all have a "remote warrior VPN access" these days, to access the GUI from distance, and be able to SSH (a remote 'close to' console access) ??
-
@aligator638 said in Bind upgrade producing errors on pfsense 2.5 upgrade:
I should not make a 3 hours long trip to console
No offense - but if some install you manage is 3 hours away, and and you have not setup some sort of remote access, even via a out of band, etc. Your doing it wrong ;)
Could be as simple as open up gui/ssh on the wan of pfsense to your known remote IP.. I have this setup on an install that is only 30 minutes from me.. I can access the gui and ssh, from my known home IP..
To issues with upgrades of packages and stuff breaking or working different. It would not be possible for pfsense to simulate every possible config that a user might setup. So it is quite possible that a previous configuration that didn't throw errors, and worked before might have problems after an upgrade where package was changed or checks were put in place to help prevent non standard configs, etc.
I had an issue awhile back where freerad was working, I then upgraded it and it didn't - why because there was an issue in the previous version that allowed it to work how I had it configured - even though it was not right. When I upgraded it that bad config no longer worked, etc.
-
It looks like the issue is resolved with the latest Bind package version 9.16_17
-
I confirm the boot problem is gone on on my firewall
