Unbound TCP buffer settings not sticky
-
Yes that was a mistake. Thanks @bryan.paradis. Fix pushed.
-
I stand corrected, the old syntax is still putting forward zones in the config file. Options are pushed way down with the recent expansion of reserve leases and hostnames. Thanks for clarifying the syntax bryan.
-
I've never had an issue with forward zones taking. Bryan, where did you get the syntax document? Is it for the unbound package or unbound stand-alone, two different animals. And your work begs another question. Do the custom options override the GUI settings or cause unbound to not start?
Guess I'll have to do some testing myself. Looks like forward zones no longer make it from the GUI to the config file. If so, the GUI notes below the custom options box is in need of editing to clarify the syntax required.
Forward zones would take but the custom options are being put in the forward zones clause area and not in the server clause area causing errors if you add any.
I stand corrected, the old syntax is still putting forward zones in the config file. Options are pushed way down with the recent expansion of reserve leases and hostnames. Thanks for clarifying the syntax bryan.
GUI generates a config file in unbound.inc out of what you fill out which is then what unbound uses. Just like the standalone.
Yes that was a mistake. Thanks @bryan.paradis. Fix pushed.
:) Your welcome
-
Thanks for clarifying Bryan. Wagonza, either it's not installing correctly or the unbound fix broke the service. When I install the package it always fails the first time and shows installed but won't run. Reboot and reinstall pkg, then unbound starts but doesn't resolve 100%. Hit'n'miss on the queries. Some webpages load, via google links all connections would fail. Had to point router to backup Unbound service on another box.
When I finally get it to install it shows in GUI as 1.4.21_3 just as it does in the available packages list. When I uninstall it the script reports it's uninstalling 1.4.21_1. Leaving remnants behind? Also notice watchdog leaves unbound in it's list and fills the log. Maybe its normal the uninstall wouldn't remove a watchdog entry.
And I'm still not clear when it can't install the unbound pkg from pfsense server that it doesn't use a cached copy of the package from local drive like the pkg installer says it will do. When unbound acts up its very hard to fix PfSense since all web updates are reliant on it. I'm going to look into putting unbound on an embedded linux box and forget it as a PfSense package at least until such time as it gets a thorough looking over.
On the bright side, outgoing-num-tcp & incoming-num-tcp GUI entries are now sticky.
-
Interesting…looks like you may have remnants of an old package lying around which might be the cause of your problems.
The fact that Watchdog still has it in its list is a good indicator of this.Sorry you have had problems with the package its been kind(er) to others.
Its going into 2.2 as a replacement for DNSMasq so no longer will it be a package. Might be a better experience for you then. -
Just noting that I reinstalled unbound multiple times on multiple boxes without any problems whatsoever after the latest batch of commits… So yeah, you probably have some state junk leftovers on your box.
-
States get reset on reboot, no? Don't think it's states unless only a state reset will do. So I should console ipkg list then ipkg remove package.name? Or is more cleanup needed?
-
Check your config.xml for multiple entries for Unbound.
Look between <installedpackages>xml tags.</installedpackages> -
./conf.default/config.xml or ./cf/conf/config.xml?
-
The latter one.
-
./conf.default/config.xml or ./cf/conf/config.xml?
Same thing /conf is a link of /cf/conf
mark62 are you running pfsense 2.1 that has been upgraded? Likely you need to manually clean out unbound.
Uninstall unbound
Turn on rw
Find / -name *unbound*
Delete everything you can find
/conf/config.XML clear out all everything to do with unbound. Backup first maybe.
Once you are sure you have killed everything reinstall.
If you have problems with internet try adding a DNS to resolv.conf -
./conf.default/config.xml or ./cf/conf/config.xml?
Same thing /conf is a link of /cf/conf
Yeah but /conf.default is not the same thing thats used, as an example, for reverting to factory defaults.
-
./conf.default/config.xml or ./cf/conf/config.xml?
Same thing /conf is a link of /cf/conf
Yeah but /conf.default is not the same thing thats used for factory defaults.
Haha whoops Justin woke UP didn't notice default
-
Thanks guys. Where are the firmware upgrades and package upgrades hosted to do a DNS resolve on? Same for both? Do I just need pfsense.com. Suppose a netstat during a temp pkg install might answer for one of the two. Hope the host IP doesn't change often. Good suggestion to locally resolve should happen to scramble Unbound again.
I find one unbound install in the xml after I had uninstalled the pkg by GUI this morning. As well, two unbound files remain. I'll clean these up tonight, cron a reboot, and report back.
Really appreciate your help…
-
Thanks guys. Where are the firmware upgrades and package upgrades hosted to do a DNS resolve on? Same for both? Do I just need pfsense.com. Suppose a netstat during a temp pkg install might answer for one of the two. Hope the host IP doesn't change often. Good suggestion to locally resolve should happen to scramble Unbound again.
I find one unbound install in the xml after I had uninstalled the pkg by GUI this morning. As well, two unbound files remain. I'll clean these up tonight, cron a reboot, and report back.
Really appreciate your help…
files.pfsense.org - pbi
www.pfsense.com - config -
Cleaned the XML of remnant Unbound package info. The reinstall went well and seems to be working normally now. Odd though, the install reported 21_1 rather than 21_3. After install the "Installed Packages" reports 21_3. And the Unbound Status reports 21_3. Looks like outgoing-num-tcp: 0 & incoming-num-tcp: 0 are still making it from GUI to XML.
–-------------------
Checking for package installation...
Downloading http://files.pfsense.org/packages/amd64/8/All/unbound-1.4.21_1-amd64.pbi
version: 1.4.21
verbosity: 1
threads: 2
modules: 2 [ validator iterator ]
uptime: 51 seconds
unbound (pid 34067) is running…
Unbound Services 1.4.21_3
Unbound is a validating, recursive, and caching DNS resolver. This package is a drop in replacement for Services: DNS Forwarder and also supports DNSSEC extensions. Once installed please configure the Unbound service by visiting Services: Unbound DNS. -
Cleaned the XML of remnant Unbound package info. The reinstall went well and seems to be working normally now. Odd though, the install reported 21_1 rather than 21_3. After install the "Installed Packages" reports 21_3. And the Unbound Status reports 21_3. Looks like outgoing-num-tcp: 0 & incoming-num-tcp: 0 are still making it from GUI to XML.
–-------------------
Checking for package installation...
Downloading http://files.pfsense.org/packages/amd64/8/All/unbound-1.4.21_1-amd64.pbi
version: 1.4.21
verbosity: 1
threads: 2
modules: 2 [ validator iterator ]
uptime: 51 seconds
unbound (pid 34067) is running…
Unbound Services 1.4.21_3
Unbound is a validating, recursive, and caching DNS resolver. This package is a drop in replacement for Services: DNS Forwarder and also supports DNSSEC extensions. Once installed please configure the Unbound service by visiting Services: Unbound DNS.Great! Wagonza updated the file already so the configuration should be working properly as you see.
As far as I can see its just the packages list xml has the newer version number and the unbound package xml has the older version number still. Wagonza just needs to update that line.
-
Yup that's all. Package just needs a rebuild on the package servers as well. Glad to hear all ok markn62.
-
Not what I was hoping to report. Thought all was well after the reinstall. Watched for about an hour and everything appeared normal. Bout 30 minutes after I walked away Unbound died and would not restart. Pointed back to the stand-alone unbound service AGAIN. This is getting so frustrating!
-
Any logs (both system and package logs) giving an indication as to why?